Managing Atria 15
Quick start guide to key changes introduced in Atria 15.
Note – this document is still in progress and will be added to.
Atria 15 is available for assisted deployments only. Self-upgrade is coming.
Atria 15 introduces significant architectural changes from previous versions, this document is designed as a quick start guide to help Atria administrators to get up to speed quickly
Hello RabbitMQ, Goodbye MSMQ
RabbitMQ is an Open Source Message Broker, it is a lightweight and easy to deploy platform that enables Atria service components to securely communicate asynchronously with each other.
RabbitMQ is a core part of Atria’s modernisation and replaces the Microsoft MessageQueue technology which has been in Atria for the past 15 years.
Rabbit provides a communication backbone to Atria and enables us to reduce the complexity involved in the different aspects of provisioning. Consumers (services) make an outbound connection to the broker and subscribe to queues in order to receive and process messages.
Messages are sent over encrypted channels using AMQPS, this is an industry standard for secure messaging.
RabbitMQ should run along as a background service and by default we will install this onto the Provisioning Server. Find out more at https://rabbitmq.com
Locations, Environments and Active Directories
One of the largest changes has been around “Locations”.
Prior to Atria 15, if you wanted Atria to manage a Private AD, you needed to add a Location, configure all the web services for that location, publish the services and plans, add the customer, then complete a migration exercise. In all, this was a complex and time consuming operation, it also needed multiple outbound network ports to be opened to the infrastructure being managed.
In Atria 15 Locations still exist, but play less of a role in private directories – Consider them as a container for configuration for all the customers created within that location.
We have introduced a new term “Environment” – consider this as being equivalent to an AD. The environment provides the segregation between tenants.
if you have a shared multi-tenant AD, one environment is shared across all of the customers. If you have a Private AD which is dedicated to a single customer, then this Private AD will have its own Environment.
Each Environment has its own set of Rabbit queues for receiving and transmitting data to and from Atria. These are secured so only that Environment (Think customer) can receive the messages designated for this customer.
So to recap – when Managing Private AD’s,
– A Location can now contain many environments,
– Each environment has an Active Directory and a single customer.
Below is a diagram showing the difference between the location types
The core goal is a simplification of the process for onboarding new customers with their own private infrastructure. This process can now be completed in one step, with minimal configuration and without the need for firewalls to be touched.
- You do not need to create a new location
- You don’t need to manually install and then configure Atria to talk to web services with addresses and ports
- You do not need to go through the process of enabling and publishing services into a location.
Networks for Private AD management
Network access requirements have been simplified by the introduction of RabbitMQ and Environments. Detailed requirements, diagrams and Firewall/Access ports are listed in the pre-requisites documentation.
Components installed in Remote ADs communicate to the Atria platform via RabbitMQ, they hence only require outbound network access to the Atria Platform.
Only the Platform Location requires network access to the Atria database. Provisioning rules and any logging is transmitted using the messaging system
- There is no requirement for outbound ports to be open from the Atria system to any Active Directory being managed
- All Cloud Service Management – e.g. Microsoft 365/PartnerCenter actions are run from the Main Atria Provisioning Engine.
In 12.13 a Location was synonymous with an Active Directory being managed by Atria. In 15 Locations have evolved to become a configuration container for managed Environments.
– A Location can have one or more Environments.
– Locations still contain service configuration.
– Each customer inherits service configuration from the location.
There are three types of Location
1. Platform Location – where the Atria components and system lives.
2. Shared Location – Contains multiple customers, in a shared Active Directory.
3. Private Location – Contains multiple customers, each in private environments.
At present, Atria will only use the first created private location.
An Environment is a connection point for Atria and is representative of an Active Directory. An Environment can be Shared (contain multiple customers), or Private (contain one customer).
The main difference is that a Shared Environment uses a secured OU for each customer and a Private Environment has the Active Directory dedicated to the customer.
|Customer||A Customer always has an Environment. In the case of a Shared Location, many customers exist in the same Environment. In the case of a Private Location, each customer has their own Environment.|
Notes on Usage at 15
Only ONE Private AD Location is currently supported, all Private AD Customers are created in the first Private AD location. If further Private Locations are added, Atria will not currently use them. This will be resolved in a future release but should not be a limitation for most use cases.
Enabling Resellers to add Private AD Customers
The system also allows resellers to add and manage Private AD Customers.
Permissions can be configured to allow a reseller to
- Resell services into a Private AD Location
- Create new Private AD Customers, including installing components.
If you need this setup – we can walk you through it. Note that you will need to impersonate (or login as) the reseller, then create the customer to ensure the customer is underneath the reseller in the hiearachy.
Services and Components
The table below has some notes on changes in some of the core components.
|RabbitMQ||New||RabbitMQ is by default installed on the Provisioning Engine server.|
|MSMQ||Retired||Microsoft Message Queue is no longer utilised in any part of Atria from 15 – it has been completely replaced by RabbitMQ|
|Atria Config Service||Updated||The Atria Config Service is used to safely store secrets and configuration needed to operate Atria. It is a lightweight service which has been updated and improved in 15. Most components utilise the Atria Config Service for configuration settings and secrets.|
|Atria Agent||New||The Atria Agent is a lightweight service which operates as the core communication client between the Atria system and an Environment.|
This is now called the AtriaProvisioningService (previously called the CortexQueueMonitor)
This service is also now 64 Bit – it was previously 32bit
|Atria Tools||Updated||Atria Tools is a PowerShell library that is used for Atria installation, configuration and administration tasks.|
|PlatformAPI||Updated||This is an internal API used by Atria components.|
Atria Provisioning Manager
The Provisioning Manager can only be run as Administrator. An error will occur if you attempt to run as a user without administrative access.
This is installed by default on the Provisioning Server, you can also install on any machine within the domain where the Atria platform is installed by running the following command:
(Note that the Atria Tools component must be installed prior to running any Atria PowerShell command)
Reloading Rule Changes
Provisioning rules are requested and distributed to Provisioning Engine components at start up. If you change rules, you will need to restart the AtriaProvisioningService. To restart the Provisioning engine, run the following command on the provisioning server
Logging remains similar to 12.13
- Provisioning Requests processed are logged into the OLM RequestLog
- General informational and error logging is logged into the OLM Logs table
- Microsoft Online Services sync logs are recorded in the OLM AzureSyncJobs and AzureSyncJobItems
- Components in each Environment, all transmit logging back to Atria via Messaging and will appear in the Logs or RequestLogs table.
- Note that all of these tables can generate a large volume of data, we recommend regular trimming of these tables and can assist with procedures for this purpose.
Maintenance & Updates
At time of release, the Atria team will provide assisted upgrades, refined upgrade processes will be documented and released for self-upgrade.
An environment update mechanism is currently in testing, this will allow automated update of Atria components.
Adding New Private AD Customers
The creation process for adding Private AD Customers is as follows:
1. Configure the Private AD Location in Atria
2. Deploy the Services required into the Location
3. Enable the Location and Services to the required resellers
You are now ready to add a new Private AD Customer
4. Configure the Private AD Location in Atria
5. Deploy the Services required into the Location
6. Enable the Location and Services to the required resellers
You are now ready to add a new Private AD Customer
7. Import Users directly : How to import Active Directory users from the Atria UI
Users are now imported and can be managed through Atria
Import Groups into the Workspace Service
The Workspace service (previously known as the Citrix service) is used to provide simple management of applications and resources across and within tenants. This also allows customer specific role groups to be created to streamline user management.
The process for importing is simple, with a user friendly UI
1. Using the Workspace import feature discover the AD Groups to be imported
2. Select the Groups to be imported
3. Decide if they are to be presented as an Application or a resource
4. Users already in groups can automatically have this information pulled into the Workspace service
5. Import the groups into Atria and you’re ready to start managing users and groups