Introduction to Organisation Groups and Smart Groups

Workspace ONE UEM right back to the early days when it was Airwatch is inherently multi-tenanted. We achieve this through Organisation Groups.

Our Shared SaaS tenants are the same codebase as what you'd get to deploy On-Premises so even we rely on Org Groups to achieve the required separation.

With this in mind, there are many reasons why you as a customer may need to rely on this capability. Read on to find out more.



The easier way I find to define an Org Group is to compare it to on Organisational Unit in Active Directory. They are like folders where devices can "land" after enrollment. What makes them so powerful is that they are hierarchical with a Parent -> Child relationship with settings inheritance that you can inherit or block.

We like to talk about the very top level being the 'Parent' where a majority of the organisation wide settings take place. This is where settings that are common to everyone would get configured. Things we typically see configured here (among other things) are:

• Airwatch Cloud Connector
• Email Domain Enrollment Registration
• Directory Services
• Syslog
• Certificate Authorities
• Identity Manager Connector/Workspace ONE Access/Identity Manager integration
• Device Enrollment Program
• Volume Purchase Program

 This is done here because its usually unlikely to have more than one of these configurations for each environment.

Its important to point here that (generally) there is no reason why some of these settings' inheritance can't be set to "Override" so you can add another configuration applied at a 'child' Org Group.

So if we're talking about setting up a good structure, and remember there is no "one size fits all", we configure a majority of the above at the Parent, and then set up Children Org Groups for different use cases or scenarios.

Child Org Groups can have their own Apps, Settings, Profiles and Configurations. If you need to separate configurations based on your logic device structure this is where you'd use them. Some scenarios we see are:

• PARENT ORG GROUP (Company)
• BYOD 
• Corporate Devices
• Executives
• Kiosk Devices
• Contractors

This may be needed because you could have more restrictive policies on Corporate Devices or you may have a different set of Support Staff looking after these use cases. As an example, you may only give administrator rights to see the location of Executives devices' to a subset of admins and you can apply this role on the 'Executives' Child Org Group.

This is role-based administrative access which can be configured anywhere in the hierarchy.

Another scenario is could be a structure like:

• Worldwide Manufacturing Company
• Global IT Services
• Australia
•  Corporate Devices
• BYOD
• New Zealand
• Logistics
• USA
• Warehouse
• IT Services
• Canada
•  Finance
• HR
• South America
• Mining Company
• Shipping Company

As you can see the structure allows you to logically separate use cases, devices, functions, companies etc. Each of these may have their own Active Directory so with this setting you can configure this at each 'Countries'. Global IT Services may also manage the entire environment so they can have an Adminstrator account created at "Worldwide Manufacturing Company" with rights to all the children.

So how do we get devices to enroll at these Org Groups?

Well we can do it in a few ways:

•  A different email domain defined at each Org Group
• You could "pre-stage" a device record in the location where you can it to end up
• Or you can use enrollment groups
• This one allows you can to create rules so that when a user from an AD Security group enrolls a device, its automatically moved to where you configure it to.

Creating an Org Group

You can do this in the Workspace ONE UEM Console at Groups & Settings -> Groups -> Organization Groups

 

If you click on Details, and then the Add Child Organization Group you'll now get to the area to create a Child OG.

Most of these can be left as default, the important part is just the Name (something relevant eg. Country/Use Case) and the GroupID. This is a unique identifier that identifies the Org Group (obviously). But until you set up enrollment rules or email autodiscovery you need to enter this during enrollment so you may want to make it something easy to type.

To navigate between Org Groups you can open up the dropdown list and select the one you want go to like below.

Cool. Org Groups sorted, right?

Now I mentioned Smart Groups as well in the title so I'd better also cover them.

A Smart Group is a granular group that (can, but not always) dynamically group devices based on all kinds of criteria. Rather than having to manually add devices to a group, you can specify the criteria for membership and when a device matches a rule they are dynamically added.

You can then use this Group to assign Applications, Profiles or Settings/Policies.

Note: Smart Groups are also hierarchical. If you create a Smart Group and a Child Organisation Group you will not be able to see it or use it at an Org Group equal to or lower than where it was created.

Smart Groups can be created by going to Groups & Settings -> Groups -> Assignment Groups

 Once you select Add Smart Group you'll see all the options available.

I won't get into detail, but these are VERY granular. Usually in a new deployment we create a few Smart Groups based on User Group which are AD Security Groups.

The other option for assignment you can see is DEVICES OR USERS. This doesn't allow for attributes for membership, but you could create a group manually for a specific set of devices or dynamically create a group for all devices from a specific users as an example.

Note that by default a Smart Group is create for each Organisation Group when one is created so you're always going to be able to target devices in child Org Groups.

These Smart Groups can now be used to assign applications to users, exclude devices/users from profiles or any way that you want to target a specific configuration to a subset of devices.