1. Each installed component is a NUGET package - herein referred to as "Packages"   
   
   1. The package contains a set of files and some PowerShell code which is run to perform an install, migrate or upgrade.  
      
   2. They use a technology called NUGET - this is a simple mechanism that allows packages to be published, versioned and downloaded systematically via command-line utilities.    
      
   3. We publish versions of the packages to a NUGET gallery - this is like a web server that hosts the NUGET files.  
      
2. CORE components for the system are : 
   
   1. configservice  a shared component used to centrally access configuration information.   
      
   2. database  installs/upgrades the SQL server database used by Atria.   
      
   3. directoryws  installs the key web service used for active directory authentication.   
      
   4. provisioning  installs the provisioning engine.
      
   5. platformapi installs the platform api
      
   6. web  installs the main web application onto the web server which is split into 4 components
      
   1. WebForms
      
   2. AtriaProxy
      
   3. Atria
      
   4. ExternalApi
      
3. For  Services  there are one or two packages for each service.  
   
1. <servicename>  relates to the installer which pushes the service configuration into the Atria system.  
   
2. <servicename>ws  is the name of a web service installer, for that service (some services may not have a ws as they don't require a web service to be deployed).   
   
3. For example, Exchange has a package and a web service:  
   
1. exchange  deploys the service, it's schema, UI elements, provisioning rules, etc into Atria 
   
2. exchangews deploys the Exchange web service. 
   
4. Additional Information: Package Action Types (Only the database is being flagged as Migrate during the install - the rest are either Install or Upgrade)
   
1. Install - clean/fresh install of Atria v12
   
2. Migrate - v11.5 CU4 to Atria v12 (note: existing config, app, branding, other custom settings)
   
3. Upgrade - Atria v12 to Atria v12.x
   
5. Atria Deployment Approaches
   
1. Fresh install of Atria v12.x - Deployment of a new installation of Atria v12.11
   
2. CPSM to Atria v12.x (in-place or sideways migration) - In-place migration from CloudPortal Services Manager v11.5 CU4
   
1. If you need to migrate server operating systems as part of your upgrade plan or you are running on a version below 11.5 CU4, please refer to the following article: Sideways Migration Process for Atria v12.11+
   
3. Atria v12.6 to Atria v12.x
   
1. If you need to upgrade from an earlier version of Atria v12 going to Atria v12.11+, please refer to the following article: Early Atria v12 to Atria v12.11+ upgrade
   

Prerequisite for the Atria Setup

1. Set-AtriaRegistrationDetails -Environment  'Production' | 'Staging'  -CRMId 'CRMId' -Customer 'CustomerName'
   

This step can be initiated on the Provisioning Server. 

1. Install-AtriaComponent -Database -ServerInstance 'ATRIASQL\instance' -ServerPort 'sqlport' -UseWindowsAuth
   

instance is optional depending on SQL Server setup

If using Windows Authentication, make sure that the account has sysadmin role into the database

Web Server (New)

1. Install-AtriaComponent -Web
   

If DMZ or non-domain joined server,

$creds is the local user account being used

$primarycreds is the domain admin account used with ConfigService

The web server should be allowed to pass-thru 8095 port traffic going to the provisioning server

1. $creds = (Get-Credential)
   
2. $primarycreds = (Get-Credential)
   
3. Install-AtriaComponent -Web -Credential $creds -PrimaryLocationCredential $primaryCreds -PrimaryConfigServiceBaseURL 'http://atriaconfigservice:8095/configservice'
   

For a New Remote Location Install - Setup Server Credentials, Roles and Connection

For a New Remote Location Install - Provisioning of Reseller - <Remote Location> and <First Remote Customer>

1. Navigate to Customers and on the service provider customer, open Services
   
2. Expand Reseller - <Remote Location>, update what needs to be configured and then Provision
   
3. Provision a new customer under the remote location
   

                                                                              Remote Location Installation/Migration Complete                                                              

Services

Deploying services includes installing and configuring services for resources such as Microsoft Exchange, Citrix Apps and Desktops, and Office 365. Before deploying any service, you must ensure the resources supporting the service are fully deployed in your network environment. For example, to deploy the Hosted Exchange service, Atria requires you have a working Exchange deployment in your environment. 

Services must be installed or upgraded to enable the functionality within the Atria platform.  Once installed and configured you can offer that service to resellers and customers.  

All services have a Schema/Service Configuration as listed in the table in the following section, these must be installed on the Provisioning Engine server.  In addition to the Schema, some services require a Web Service to be installed to enable management of that service, this will typically be installed on the server that hosts that service.  A table of available Web Services is listed in the following section.

The service installer requires a login account within Atria that has the Schema Administrator role.

Service Installers (Schema/Service Configuration)

Run the following PowerShell command on the PRIMARY LOCATION Provisioning Engine Server.

By default the service schema import will be done against http://atriaweb if this binding is removed from the AtriaProxy IIS bindings then we need to set the APIUrlBase to be used.

To set it, kindly run the following commands on PowerShell (admin)

1. Set-AtriaApiUrlBase -urlBase 'atriaproxy url binding'
   

To query out the changes made:

1. Get-AtriaApiUrlBase
   

Here's a sample of a changed APIUrlBase

After setting this, all service schema imports will be done against the new APIUrlBase

1. Navigate to Configuration > System Manager > Service Deployment
   
2. Locate the "Multi Factor Authentication Service"
   
3. Enable the service
   

1. For each Active Directory Location, you will need to enable the service
   
2. Ensure that there is a single customer plan created - the MFA Provider property must be set to the "Atria Provider"
   
3. Save and apply changes to enable the service
   

1. For each reseller and customer, provision the MFA service with default settings to enable it for provisioning to end-users.
   

Once the MFA service has been enabled to a customer, provision the MFA service to each user to enforce MFA, this will come into effect the next time they log in to Atria.

Setup Process

Once the MFA service has been provisioned to a user – when they authenticate to Atria the following screen will be presented:

Scan the QR Code with your authenticator App, this should then display a token – which should look something like this:

1. Update-AtriaComponent -ComponentName (configservice, database, provisioning, directory, platformapi, web)