Atria for Software Vendors

Yes, this is a supported configuration, an Atria agent needs to be deployed into the network (on a member server) and can then be managed through Atria.

Many of our Service Providers offer Microsoft 365 services, depending on how you purchase licensing, we can also provide delegated administration of Microsoft Subscriptions and assign licenses to users. 

We have a number of Hosting partners globally who work closely with Software vendors to deliver their applications using Atria.  They have expertise in Hosted Desktop Infrastructure and Atria.  Some partners operate globally and others are regional.  If you are in this situation, please get in touch and we can discuss and make introductions.

We have several tools available which we use for migrations, mostly this is handled via PowerShell and we can do this in a staged approach. We build a process for a sample customer, then create scripts to extract data from your directory (and any other relevant sources) then using the Atria API’s we create tenants, users and services. Depending on consistency in your directory (are all the tenants constructed in the same way?) it could be a matter of a few days effort, or in more complex cases it could take longer. Either way, we will help you get there and have tackled all sorts of different environments in the past. Contact us and we can discuss how to best approach.

Atria is a good source of information for SPLA licensing as Atria is controlling when users are being provisioned.  We store data against users such as date disabled, and provided you know which licenses are needed for the services you are provisioning, then it is simple to extract the basis of a licensing summary via the API.

Absolutely, we have a number of options for approaching, on provisioning the user with your application, we can add scripts to create the user in the database.  Our provisioning processes are all “soft” – that is they can be changed via a UI, when the provisioning engine restarts, it will recompile the logic.  So in this case, we just add a rule to run a SQL script, or Powershell script to add or update the user , and the user will be provisioned automatically.

The core concept of multi-tenancy is to ensure that each tenant is segregated from each other, and when sharing a directory, this means that we also need a mechanism to ensure uniqueness across tenants.  Atria accomplishes this for you by

• Changing default permissions structures in Active Directory
• Creating a unique Organisational Unit in AD for each tenant with a naming convention
• Adding security to the OU so only users within that OU can see it.
• Generating users with a unique sAMAccountName (using a naming convention)

This is one of Atria’s unique features, Atria will route provisioning tasks to the appropriate directory – this means that for any user of Atria – e.g. your Service Desk, they can perform tasks on any of the customers, in the same way, without needing to know where the infrastructure is located or how it’s structured.  Customers in both the private AD and shared AD can also log into Atria and manage their own users.

Atria has an optional service called ADSync which can be used to synchronise accounts from a customer directory into the directory where your application is hosted.  ADsync will look for directory changes, based on policy (e.g. group membership) it will initiate updates into Atria.

So for example, in the customer AD there is a group called “AssignAppX” – whenever a user is added or removed from this group, ADSync will initiate an add or remove in Atria.  Similarly, if the password is changed, the password will be changed in Atria.  For the customer ,this means that they can manage your Application access via their Active Directory.