The Device Enrollment Program (DEP) simplifies initial setup by automating devices Enterprise Mobility Management (EMM) enrollment and supervision during setup, which enables you to streamline the configuration of your organization’s devices. To further simplify the process, you can skip certain Setup Assistant screens so the end-users can start using their devices right out of the box.
Exodus support two approaches of managing your DEP devices migration:
- The Official approach by initiating a Device Wipe of your devices and let Apple's servers dealing with the un-enrollment and re-enrollment
- or what we call the Legacy approach by skipping the mandatory Device Wipe and proceed to a classic migration workflow.
The second option should be considered a workaround to avoid the inconvenience of initiating a Device Wipe of all your end-users' data. It is a viable solution but comes with drawbacks that you should be aware of before proceeding (see dedicated section below)
DEP Workflow options
In this section, we'll explain in details both workflows Exodus supports.
Apple's standard approach: with Device Wipe
The first option is the standard approach which will migrate all your DEP devices by initiating a Device Wipe. It will migrate your devices automatically, keeping them supervised and prevent your end-users from un-enrolling from your new EMM server. Exodus will help you reassign the devices in the Apple Business portal and sync them with the new EMM server.
On the other hand, your users will lose all their personal data in the process. If this is a real problem, you can choose the second workflow explained in the next section.
This option is the official approach and is recommended by both Apple and Exodus. But you need to be aware that your end-users will lose all their data in the process. If this is a problem, you can choose the second approach explained in the next section.
Exodus Legacy workflow: without Device Wipe
The second option is to skip the Device Wipe of your end-users devices and do a legacy migration by simply un-enrolling and re-enrolling devices. By doing this, all your end-users will keep their personal data and your devices will be migrated while still being supervised. This workflow will also include the assignment of your DEP devices to your newly assigned virtual EMM server in the Apple Business portal and will sync them in your new EMM server.
This workflow works perfectly, but comes with some drawbacks that you need to be aware of.
As this option is not the recommended approach by Apple, you need to be aware of the following points:
- Despite the fact that the device will still be supervised, your users will be able to un-enroll from your new EMM server (by going to the Settings app) which the standard DEP workflow prevents by design.
- Once un-enrolled, if your end-users decide to erase their device on their own, their device will be assigned again to the correct virtual EMM server in Apple Business portal but will not be associated to the correct end-user. Their device will be migrated in your EMM server as a generic unauthenticated staging user. You can prevent this by restricting your devices from being erased by their users once your migration is over, which is possible thanks to the supervised state (see the instructions in the next section).
Last configuration steps
In order to make the Legacy workflow safer, we recommend that you install a restriction profile on your DEP devices after the migration is done. To do so, you can use Apple Configurator 2 and follow the instructions below:
- Open Apple Configurator 2 and select the menu
File › New Profile
- A new window should appear, you can define the
Generalsettings as you see fit.
- Click on the
Restrictionssection on the left (see fig 1.1, step 1.), then click on the
Configurebutton (see fig 1.1, step 2.)
- The screen should update with a very long list of options. Scroll and find the one titled
Allow Erase All Content and Settings (supervised only)(see fig 1.2, step 1.)
- Uncheck it
- If you need additional restrictions or configurations in this profile, feel free to add them
- Once you have finished, save the file and push it on your devices using your favorite method (check out your EMM documentation).
How to manage your DEP devices in Exodus?
Before you start: Assign and sync your devices
After creating your migration, Exodus will automatically detect if it contains DEP devices and propose you to assign and synchronize them with the target EMM. This will allow the DEP devices to be automatically enrolled to the target EMM on device wipe.
Even if you choose the Legacy workflow, it is required to assign and synchronize your devices so you won't lose them once wiped.
First, you need to reassign your DEP devices to the target EMM on the Apple Business portal:
- Click the
Downloadbutton on Exodus to retrieve the list of DEP devices (see fig 2.1, step 1.)
- Go to the Apple Business portal
Device Assignmentsin the side menu (see fig 2.2, step 1.)
- In the
Choose Devicessection, select
Upload CSV Fileoption (see fig 2.2, step 2.)
Upload File...(see fig 2.2, step 3.) and select the file downloaded from Exodus.
- In the
Choose Actionsection, select
Assign to Serverin
Perform Actionlist (see fig. 2.2, step 4.)
- Select the target EMM where you want your device to be enrolled in the
MDM Serverlist (see fig. 2.2, step 5.)
- Finally, click
Done(see fig. 2.2, step 6.). You should see an
Assignment Completeconfirmation dialog: your devices are now assigned to your target EMM.
Your newly affected devices should now appear on your target server details, under the
MDM Servers section. They should also have disappeared from your source server details.
Once your DEP devices are assigned to the target EMM on Apple Business portal, you can click the
Sync button on Exodus (see fig 2.1, step 2.). It will ask the target EMM to synchronize the list of DEP devices with Apple's servers.
Exodus will then regularly fetch the list on the target EMM and show the progression of synced devices (see fig 2.1, step 3.)
The synchronization of the target EMM with Apple's servers might take a while. You might want to consider the synchronization stuck if the progression did not change for at least 30 minutes.