This step can be initiated on the Provisioning Server.
- 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
- Install-AtriaComponent -Provisioning -CreateScheduledTasks
Directory Web Service Component
- Install-AtriaComponent -Directory
- Install-AtriaComponent -PlatformAPI
Web Server (New)
This will install 4 components (WebForms, Proxy, Atria, ExternalAPI)
- 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
Finalize Primary Location Setup
FOR NEW INSTALL, THIS IS IMPORTANT BEFORE PROCEEDING!
Using your browser, navigate to the front-end website - default is http://atriaweb/
1. The default platform account created is <installercredential_asp> and the password will be the domain account password used during the installation
2. After logging in, on the Atria Menu, select Configuration > System Manager > Server Roles
a. Assign domain controller server role to the servers that will be used by the platform
b. Click on Save
3. On the Atria Menu, select Customers. You will notice that the customer name is "Service Provider - Change This"
a. Expand this customer and select Edit Customer
b. Input the Service Provider name
c. Update the domain management according to your environment
d. Update other customer details as needed.
e. Save and Provision the Customer
6. Go to the Users of the current Customer. You will notice that the only user is the <installercredential_asp>
a. Expand and Edit the user <installercredential_asp>
b. Expand Account Settings and then click on Advanced Options
c. Make sure that "Service Schema Administrator" is enabled for this user
d. Update other user details
e. Provision the User
7. Validate if provisioning is working successfully through the provisioning logs
a. On the Atria Menu, select Configuration > Provisioning & Debug Tools > Provisioning Requests
b. Provisioning Requests Overview should show green status on all the made requests above
c. If Provisioning Requests reports are NOT showing green status. Report it to Automate101 Support
Core Components Installation (Migration Complete)
Remote Location Deployments
1. Add DNS Aliases on the Remote DC
- PrimaryConfigService DNS entry (Host) pointing to the Primary ConfigService IP Address
- AtriaSQL DNS entry (Host) pointing to the Database IP Address
2. Add an entry on the Site Bindings where the ConfigService was installed (IIS > Atria Web Services > Edit Site Bindings).
New Site Binding
- Host Name: PrimaryConfigService
- Port: 8095
Do not remove other default site binding entries
3. Make sure that the step on Atria.Tools.Setup-Bootstrap has been completed on the Remote Location Provisioning Server
Remote Location Components
Run the following PowerShell command on the server that will host the Remote Config Service, this is typically the Remote Provisioning Engine Server. The Config Service is required for new installations as well as upgrades from CPSM.
ConfigService should have the same server time with the PrimaryConfigService
- $creds = (Get-Credential)
- $primaryCreds = (Get-Credential)
- Install-AtriaComponent -LocationComponents -Credential $creds -PrimaryLocationCredential $primaryCreds -PrimaryConfigServiceBaseURL 'http://primaryconfigservice:8095/configservice'
Web Service Configuration and Application Settings Configuration
IMPORTANT UPDATE for CPSM Customers - The consolidated Web Service Configuration (web.config) has been split. Application-specific settings have moved to a separate config file appsettings.config
When performing a MIGRATION (v11.5CU4 to Atria), the web.config and appsettings.config will both be in a default state (out-of-the-box configuration), to apply your previous customization into the config file, you may retrieve the configuration details from the old web.config file that is located in the folder of the web service. This also applies to an old appsettings.config. Apply accordingly the required parameters and configurations that are set.
We suggest using a text editor that has a compare functionality/plug-in to help manage this. (Notepad++, Beyond Compare, etc.)
Location of old config files:
Old CortexWeb - C:\inetpub\Cortex Management\CortexDotNet\
Old CortexAPI - C:\inetpub\Cortex Management\CortexAPI\
Old Provisioning Engine - C:\Program Files (x86)\Citrix\Cortex\Provisioning Engine
Old CortexService - C:\inetpub\CortexServices\<web service>\
Apply the necessary configurations and customizations to the new config files
AtriaWeb - C:\inetpub\Automate101\Atria\AtriaWeb\
AtriaAPI - C:\inetpub\Automate101\Atria\AtriaWeb\CortexAPI\
Provisioning Engine - C:\Program Files (x86)\Automate101\Atria\Provisioning Engine\
AtriaWebService - C:\inetpub\Automate101\Atria\Atria Web Services\<web service>\
Apply the new credentials for server connections for each web service that is updated into Atria. By default, the old web app pool service account should still work, but we recommend updating it into the new Atria generated web app pool service accounts for clean up purposes in the future.
Some service like Hosted Exchange, needs to be re-saved in order to make sure that the Mail Store Databases will be picked-up during provisioning of customer and users.
Enabling MFA within Atria
MFA is now built in as a service within Atria, the service package "atriamfa" must be imported to enable the MFA features (see above).
For further details about Atria MFA please refer to the follow article: Atria MFA
Activate within Atria
- Navigate to Configuration > System Manager > Service Deployment
- Locate the "Multi Factor Authentication Service"
- Enable the service
Enable for each location
- For each Active Directory Location, you will need to enable the service
- Ensure that there is a single customer plan created - the MFA Provider property must be set to the "Atria Provider"
- Save and apply changes to enable the service
Enable for each reseller and customer
- For each reseller and customer, provision the MFA service with default settings to enable it for provisioning to end-users.
Enforcing MFA for a user
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.
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:
Enter the QR code, and click register – you are now set up with MFA and will now be prompted every time you login to provide the token.
Resetting the MFA Token
There are some cases when you may want to reset a token
- Phone with the token has been lost or stolen
- Phone with the token has been wiped
- User has a new phone and needs to transfer the token
Essentially, if the token (the phone) has been lost, you may need to recreate it.
Option 1 – Administrator reset
- Locate the user
- Deprovision the service from the user
- Reprovision the service to the user
Option 2 – Self-reset (cannot be done without phone/token)
- Log in and authenticate
- Click on your login name at the top of the screen – this will take you to the password reset page
- At the bottom of the page you will get the option to
- Display your current token again – this allows you to have the same token on another device, or
- Reset the token – this will create a new token and force you to re-validate the setup.
- For a new install, follow the implementation procedure in the following article: How to setup Atria portal branding
- For migration from v11.x or v11.5.x, previous customization on the portal branding can be applied using your CSS files and resources. The files can be located in the old path of the CortexWeb site files (C:\inetpub\Cortex Management\CortexDotNet)
- We also recommend to update and configure the Help Link within Atria to point to the Service Provider's internal support who will assist the users of the panel.
Performing an upgrade applies to Atria v12 upgrading to a higher version (i.e. Atria v12.11 upgrading to Atria v12.12), any version below 12.x will first need to perform a migration.
Package Action Type : Upgrade
For upgrade run the following commands for each component on the appropriate server. Upgrade does not require any additional parameters.
- Update-AtriaComponent -ComponentName (configservice, database, provisioning, directory, platformapi, web)
- Update-AtriaComponent -WebServiceName (exchange, hostedappsanddesktops, msol, etc.)
Changes to this upgrade process may occur as we progress on releases, please refer back to this guide prior to each upgrade.
Once you have completed a migration or upgrade it is always important to test, a simple test plan is available in the following article: Atria Post Upgrade Checklist