In MDM, Windows Mobile 6.1 devices must enroll to a Windows 2003 Active Directory domain to become managed by IT. In the "How MDM Works" technical documentation located at http://technet.microsoft.com/en-us/library/cc135573.aspx our documentation on MDM describes how the MDM device enrollment process works. I've pasted the steps here to provide a context for this article. At a high level, the steps for enrollment of Windows Mobile 6.1 devices to MDM are as follows:
MDM Enrollment Server creates an Active Directory Domain Service computer account for the device, and the device certificate is issued based on the certificate request received from the device. MDM Enrollment Server also links the computer account to the Active Directory account for that user.
In lieu of this, some customers have asked the following question:
Assuming we don't have a load balanced MDM Device Management server configuration or our main datacenter goes down, if we have MDM gateways deployed in other datacenters will the MDM enrollment still work or complete successfully?
The answer to this question is that the MDM Device Management server does not need to be up and running at all times for devices to enroll to MDM. It is important to note that if the MDM Device Management Server(s) is down or unreachable after the device has completed its enrollment sequence and has restarted as described above, there may be a window of time in which specified corporate mobile policies may not yet be applied to the device but the mobile user will still be connected to the MDM VPN Gateway Server. In this scenario, the mobile user could access corporate resources but not yet have the required mobile policies applied such as PIN lock, require a password, etc.
Breaking this down even further: After the first device reboot when enrollment completes, the mobile device tries it's first MDM Device Management server (OMA) session at 3 minutes, and if failed for whatever reason, the next session DM will start at minutes 15 and keep retrying 192 times (cover 48 hours) or until success.
An expected response from customers is: How can we ensure that corporate policies are enforced BEFORE users can connect to our internal corporate assets?
One way to mitigate this would be to have a centralized enrollment model where all corporate devices would be enrolled internally by IT first then sent to users once policies have been applied and confirmed. If companies wish to permit over the air (OTA) enrollment for user, this may not be a desirable solution.
Another option is to a create an interim device quarantine solution by which a "special" MDM gateway server is deployed with a specific device address pool, and restrict that device address pool traffic to only route to the MDM Device Management server from the MDM device address pool. A mobile policy that specifies the fully qualified domain name of the "full service" gateways (device address pools that have full routing capabilities to internal corporate resources) would be pushed to the mobile device which would change the GatewayURI value that is assigned to enrolling mobile devices by default with the MDM Set-EnrollmentConfig Powershell cmdlet that is specified during MDM setup.
Note: This solution is NOT required for every MDM deployment but can work if IT security teams desire this addtional functionality. :)