Deployment Groups - Best Practices?

[Steven Sweeny]

In the Airwatch world they offer a concept of organizational groups.  Much like AD policies applied to the top apply to all children.

 

We don't have that same concept here.  What is defined as the best practice in the Xen world?  To make completely self defined deployment groups for each and every possible scenario (getting a headache thinking about this)?  Or to create my own OU structure with group memberships add more and more Deployment groups based on rights? 

e.g.

member of XenUsers - Grants rights to enroll

XenMail is a member of xenUsers and has another group to grant rights to mail

XenWeb is a member of XenUsers and has a group to grant access to Web.

If you are a member of users you can enroll but no mail and no web.

 

This unfortunately gets harder for local accounts.  Since groups cannot be member of other groups it requires that during provisioning you add the user to multiple groups.  Some admins may forget this and I am left with devices not getting all the required profiles or apps.

[Ryan Tsamouris]

That's one thing I really miss about AirWatch, as well as being able to exclude certain groups or people from policies (helpful for when one person is in multiple groups or you know...VIPs). For XenMobile, you use Delivery Groups, which are tied to Active Directory security groups. You then deploy one policy for all platforms (Restrictions for iOS, Android, Mac, etc), which are assigned per Delivery Group. So you'll probably have one primary Delivery Group that is assigned to all users, and that DG has all of your policies for all device types. Then you can assign apps, ShareFile, Enrollment Modes, etc.

 

To make it as a clean as possible we really focused on separating out Active Directory groups and then automating the process to get users into the groups they needed, whether it was via our ticketing system or scripting. If there was a general set of apps we want everyone to have (e.g. Secure Mail, Secure Web), then we put those apps in the main Delivery Group. But if there is one specific app that we only want certain people to have, we create a new Delivery Group, assign it to a new AD security group, and then put those users in it.

 

Where it gets complicated is when you want to target device types. So if you want to give iPhone users a different policy than iPad, or separate policy by Android model, then that's where you use Deployment Rules (see screenshot below), which are found in the Delivery Policies or Apps. This can get more complex when you factor in Shared Devices and DEP.

 

To take it further down the rabbit hole, you can also support multiple domains using similar methods, but it gets pretty complex when you factor in the MAM Gateway, single-sign on, and separating out the Secure Apps (e.g. Secure Mail per region with different EAS URLs). Hopefully you don't have that issue though.

 

Also, I wouldn't recommend using any local accounts. That's only meant for the web console, REST API admin accounts, or TEST environments.

 

None of this ideal and it's one key item that AirWatch does much better than XenMobile.