In our MDM practice at LINQ, we sometimes will meet with a client for the first time and come to realize their environment has been configured in such a way that requires a lot of manual attention, sometimes by default. Certain MDM’s resources will even walk an unsuspecting admin right into a sub-optimal architecture. Whether this is the babysitting of a shared Apple ID, manually putting users into certain groups, or utilizing pre-stage enrollment identifiers – there are several ways you can design an MDM environment to slow you down. We do not typically make a habit of stating there is a wrong way to setup an MDM, but we at least recommend considering using the automation at your fingertips.
Let’s align on a goal. We would like to make the MDM as “set it and forget it” as possible. At a high level we outlined that workflow below. Critically, we recommend making each step automatic as applicable.
Macro Overview:
At every turn you will be faced with an option to make something occur by default – we advise you take those opportunities.
- Carriers / Vendors
- Most will allow for the automatic addition of devices to ZTEP. Carriers especially are used to this expectation, but if you’re routinely purchasing devices from another source some will require you to manually add the device to ABM in your cart when checking out. This is not ideal and subject to human error. You want the onus to be on the vendor and not on a procurement staff member to remember to add the addition to the ZTEP in the cart.
- ZTEPs – ABM / KME/ AZT and Enrollment Profiles
- Each manufacturer specific program will allow you to automatically assign devices to your MDM of choice. If you’re manually assigning enrollment profiles – you probably don’t need to be.
- User Creation and Assignment
- Most MDMs will allow you to integrate with your identity provider and require authentication for enrollment. This connection is critical to making your MDM zero-touch so that you do not have to manually create users / assign them to devices. They instead will automatically assign to the devices when they authenticate.
- Deployments
- Many deployments (apps, Wi-Fi, configurations, etc.) will go to everyone and will just be a simple assignment to all devices or users. Others might have department specific apps that only go to certain folks. Some may fall into babysitting groups for each department. If you instead rely on dynamic groups to automatically assign users to groups based on IdP flags like department or job title, you can instead just focus on auditing the attribute to ensure its correct.
Things to avoid
In addition to the above recommendations you ought to do, there are a few pit-falls you shouldn’t as well. Unknowing sysadmins may fall into complicating their environment if you take the MDM’s support resource at face value. LINQ has found that some of the articles for configuring an MDM for the first time will lead you into some odd processes that are not necessary.
- App Deployment (iOS)
- Imagine exploring in your MDM for the first time and you stumble on the apps section. Intuitively, you might think it appropriate to add the application right into the MDM. Unfortunately if you do so, then the end user’s Apple ID will be required. Instead, we encourage you to “purchase” the applications through Apple Business Manager via their Volume Purchasing Program (purchase is used generously here, as many apps are free). This will yield silent deployment that does not require the end user to know their Apple ID password or have an Apple ID to begin with.
- Pre-stage Enrollment Identifiers (iOS)
- Some MDMs have built out pre-stage enrollment identifiers. This is a way to pre-assign users to devices, or pre-approve devices to enroll. This system is over complicating the process. We discourage the bottle-neck of having to login for every enrollment to assign a user or approve a device. Generally, devices that are added to Apple Business Manager can be considered approved with little risk. Users will get assigned to devices when they authenticate. Despite how some support articles may be written, Pre-Stage Enrollment Identifiers are not mandatory and can be disregarded in our opinion.
- Managed Apple IDs / Apple Account Driven User Enrollment (formerly known as “Apple User Enrollment”) (iOS)
- Managed Apple IDs, while they may seem appealing at first glance, are not typically used once organizations fully understand the scope of what they are signing up for. The premise is that businesses can manage Apple IDs for their end users, or even take it a step further and integrate with their Identify Provider such as Azure AD / Entra ID for SSO. The key issue is that Managed Apple IDs cannot be used to download applications from the app store – full stop, not an adjustable setting. For any company looking to have devices personally enabled, this a no-go. In conjunction with Managed Apple IDs, Apple has built a system for enrollment and App Distribution that leverages the end user’s Managed Apple ID. We recommend against the use of “Apple User Enrollment” as it actually offers less control to the business as well. This is not to say that devices are not assigned to users (they are, just not via the Apple ID).
- Automatic clean up rules
- IT hygiene is a HOT topic and MDM Admins may find themselves wanting to keep their environment clean of old devices that have long since not connected. While there is probably some merit to something like 365 days, we caution you against going too much lower. Depending on your MDM, you may be inadvertently locking yourself out of the device. One of the key reasons to have an MDM and enroll devices in supervised mode is to be able to reuse devices from user to user without concern of their Apple ID locking the device via FindMyiPhone. MDM can freely clear off Activation Lock as long as the device is still connecting and was originally enrolled in supervised mode. But what happens if the device is no longer connecting? MDMs provide a failsafe, get-out-of-jail-free-card, called the Activation Lock Bypass code, which allows you to enter a 30-character code to bypass the Activation Lock. If you delete a device, and it later comes back with an Apple ID > in some MDMs such as Microsoft Intune you have deleted your method of recovering the device (the bypass code is stored on the device record). Also consider an issue that causes all devices to stop connecting such as a token expiration. If your clean up rules are set too liberally, you could find yourself with your MDM automatically removing all your devices before you notice the token has expired.
- Not using LINQ
- Make sure to lean on LINQ for more best practices and helpful tips! We are here to help you ensure you MDM is as “set it and forget it” as possible.