Best Practices for Apple Admins in Workspace ONE UEM
Overview
Background
I was recently reading a post about What to do when you have to lay off your Jamf administrator, and it got me thinking. The Workspace ONE UEM documentation generally specifies what you need from a software and hardware perspective in pre-requisites. That said, over the years I've come to know a few unwritten (or written but obscure) best practices for setting up Workspace ONE UEM to manage Apple devices. Hopefully you find this post helpful, but I welcome any comments and feedback!
Best Practices for Apple Services Pre-Requisites
When your organization pursues the intiial setup for many of Apple's services, there are some best practices to follow which helps maintain supportability in unforseen circumstances. Additionally, many of the accounts you create to manage Apple-related services should be dedicated for that specific service. In other words, an Apple ID created for push certificate creation should not be used to sign-in to the App Store or iCloud on an iPhone. That said, let's dig into some of the critical best practices that I've seen over the years.
Admin Apple ID's for ABM (ASM)
Apple calls out a number of pertinent pre-requisites for Administrator Apple ID's in ABM/ASM that are worth noting:
- The email address hasn't been used as an Apple ID for any other Apple service, website, App Store, or iCloud content.
- This email address DOES need to route to a real person as it will receive critical notifications about ABM/ASM.
Because Apple wants this initial admin account to be a real person, I highly recommend signing up using an alias email address (or distribution list email address) for your real org-based email address. By doing this, you need not worry if you've already used your org-based email address as an Apple ID in other services. Additionally, should you decide to leave the organization, the alias can be moved to someone else's mailbox (or one or more new email addresses added to the Distribution List). The idea here is to make business continuity easier. The Distribution List option also adds flexibility if you have other administrators that would benefit from awareness of program and software license agreement changes.
NOTE: Use an email alias and NOT a shared mailbox, as this eliminates any overhead related to managing the additional mailbox and keeps ABM-related emails front-and-center.
Once your Admin ID is created and you have access to ABM (or ASM), set up additional administrators immediately and work with those individuals to ensure they go through the entire setup process (including 2-factor authentication). Also, set a recurring calendar reminder for your group of administrators to validate logins/credentials are working if they will not be actively managing ABM. If an organization loses access to all the administrator accounts, it can be painful to re-establish access and could potentially involve downtime related to Apple Business Manager programs (automated enrollment and volume licensed apps).
Push Certificates Portal Admin Apple ID
Push Certificates (used for APNS messaging), are unfortunately tied to a single Apple ID. Once a device is enrolled using an APNS push certificate, that certificate chain must be maintained (renewed) for continued functioning AND cannot be changed without re-enrolling the device. In other words, if you lose access to the account that created the Push Certificate, eventually your devices stop responding to MDM. Because of the criticality of this piece, DO NOT tie this Apple ID to a single Admin user.
Prior to setting up Push Certificates, create a new Apple ID at appleid.apple.com using an email alias for a Distribution List or Group in your organization. This distribution list should contain all the users in your organization that will be managing MDM (which may or maynot be the same as those folks added as admins for ABM/ASM) Additionally, work with your co-administrators to immediately configure a set of Trusted Phone Numbers. Yes, you should have multiple trusted phone numbers just in case of emergency! Then, ensure everyone knows how to login to the Push Certificates Portal and keep the password in a shared password vault.
REMEMBER: The crticial point with the Push Certificates Apple ID is that you need access to that account in order to periodically renew your APNS certificates. Without this capability, you'll lose the ability to manage your devices.
Locations and MDM Servers in Apple Business Manager
Locations and MDM Servers in ABM equate to a container holding volume-purchased app/book licenses and devices (respectively) for management. Over the years, I've known organizations which aimed to keep the number of MDM servers or Locations small as possible. To be honest, I never understood this thought process (or the organizational politics that discouraged liberal use of this ABM feature). I encourage you to create as many as you need to adequately test new configurations. With ABM, you can move devices and licenses easily between different Locations/Servers, allowing you the following opportunities:
- Testing new configurations in a Sibling (same level) Organization group
- Testing new configurations in a Child Organization group (overriding or replacing)
- Using a spare paid (non-free) license for testing in a UAT environment
- Purchasing additional "Free" licenses for testing in a UAT environment
My point is this, Apple gives you a great deal of flexibility to move devices and app/book licenses around. Combine this with the multi-tenancy (Org-Group Heirarchy) of Workspace ONE and you get a great deal of flexibility for testing app or device deployment changes without "testing in production". That is, unless you firmly believe in YOLO'ing your UEM environment... (NOT recommended!)
Best Practices for Workspace ONE
Define Multiple Customer-Level Administrators
As a best practice, you should never have a single UEM admin user at the top of your Workspace ONE org structure. I would recommend having at least two (one of which is the manager of the UEM Admins) and if possible keep them geographically distributed (for business continuity). That said, having folks with access isn't enough. Create documentation on how to revoke admin privileges and create new admin accounts. Keep this documentation readily available in case of emergency (or if you have a place to store business continuity documention, keep it there).
Define Additional Support Contacts
Work with your sales reps to ensure there are multiple contacts in your organization that can open support tickets. You don't want to wait for a major outage to then discover there's noone listed as a valid support contact with VMware support.
Define a Basic UEM Admin Recovery Account
It may be tempting to force all your admins to log in with corporate directory-based credentials, but it is critical to maintain at least one basic (non-directory) account in UEM. If you experience an issue with your directory integration, you would not be able to make any corrections to the configuration in UEM without a non-directory user available.
REMEMBER: The Basic UEM admin account should still point to a real email address (or distribution list) in the case of password resets and notifications.
Encourage Custom Apps for iOS
If you're an organization that develops enterprise iOS apps and signs them with Enterprise (In-House) signing certificates, I strongly recommend moving to Custom Apps. I've seen many times in the past where an organization runs into a fire-drill when the provisioning package for their Enterprise iOS app expires and they need to find the correct iOS app developer who can create the new provisioning package for the UEM administrator. Custom Apps eliminate this headache. Yes, it may require some process changes for your developers and require some coordination with you for the app purchase in ABM, but it is the way forward.
Wrapping Up
I'm sure over time I'll think of more to add to this list, but I wanted to make sure I got some of these ideas in my head down on "paper." Please feel free to add a comment below if you think I've missed something.