From the client perspective the enrollment process is the first thing you do on the device to join it to the SCMDM infrastructure. For the average user this may be the only thing they proactively do regarding SCMDM. In this article I’ll try to take a closer look at how the process works, thereby giving (hopefully) a deeper understanding of the process. If you ever tried troubleshooting you’ll appreciate the value of this

So what is the enrollment process? The short answer is that this is the process that takes a generic device, joins it to your domain, and gives you some device certificates along the way.

The longer answer is that there are three distinct phases in the enrollment process achieving the goal above, and we’ll have a look at each of them here.

Technically there’s a fourth phase, but that happens server side, and is not something the device performs. (And must be performed before the process starts on the device.) This is called creating a pre-enrollment request. This creates an entry in the database on the server keeping details of the name of the device, which OU to place it in, and other stuff that is important when a device is being enrolled. The possibly most important part of this pre-enrollment is the enrollment password which works as a shared secret between the server, and the user of the device. More on this later.

Discovery/eligibility – phase one
The first thing you’re prompted to provide when enrolling is your email-address. If you provide andreas@contoso.com, the enrollment client will try to look up mobileenroll.contoso.com. If for some reason this cannot be resolved and reached you’ll get a new prompt asking you to provide the server address. If this is intentional, and you’re not running your enrollment server on that address that’s ok – mobileenroll is predefined as the default setting but you can provide your own. Just remember that the address to the server must match the common name of the certificate on the site. So if mobileenroll.contoso.com is only resolved externally, and you’re trying an emulator on your LAN-connected computer pointing it to 192.168.10.30, (or whatever the IP is in your scenario), this will not work. After checking that the device has connectivity get your DNS settings right.

If the server is located, and the certificate name matches, your device will check if it is eligible for enrollment. This is done by providing the email-address you typed in, to the server. The server will check if there is a pre-enrollment waiting for you, and accept or dismiss you on the basis of this. If this check passes it’s on to the next phase.

Bootstrapping – phase two
Up to this point the enrollment client has actually disabled a security check regarding SSL certificates. Usually your device will not trust an SSL certificate not issued by a trusted Root CA. (Remember, you’re most likely using a self-signed certificate on the enrollment web site and this is by default not trusted by your device.) But if the device is to be able to request a device certificate, and be managed by the Device Management Server it needs to trust the certificate of the Root CA. Creating this server trust is known as “Bootstrapping” the server.

The device requests this certificate by sending it’s identity (email-address), and an HMAC (Hashed Message Authentication Checksum) of this identity. This HMAC is computed on the basis of your enrollment password, (shared secret, remember?), so when the server receives the bootstrap request it can generate the same HMAC to verify the integrity of your request, and that you are indeed allowed to perform this action. (This also means that if there are multiple pre-enrollment requests for the same email-address this will identify each of them, as the password will be different for each of the requests.) If you’re allowed to bootstrap, the server sends back the base64-encoded certificate, and an HMAC of the certificate allowing the client to verify the authenticity of the server. The client then provisions this certificate into the Root Certificate Store on the device. If you have ever configured your device to synchronize through ActiveSync to an Exchange server with a self-signed cert you’re familiar with this concept.

This means that if you had a typo in the enrollment password this is where it will fail, and that would most likely be the most common cause of bootstrapping failure. Not that the device will provide you with an error message giving you this clue…

If you are certain that you typed it correctly you should check on the enrollment server that the SSL certificate on the enrollment site is good, and that it chains correctly to your Root CA.

Enrollment – phase three
The third phase is where the enrollment is actually performed. Your device generates a certificate request, computes the now familiar HMAC of this request, adds the HMAC of your identity and pass it along to the server. The server verifies these properties, adds the information that is kept in the pre-enrollment request in the database and requests the certificate from the CA. The server sends back a provisioning document, and an HMAC of this document to your device which will try to process it. The provisioning document contains the certificate for the device, configures the address to the Device Management server, and adds it as a trusted OMA DM server. In addition it flags the device as enrolled so you don’t try to enroll it once more through the “Domain Enroll”-icon, sets the device name field (kept in HKLM\Ident), and some other minor details. Depending on whether your pre-enrollment request had the VPN option enabled or disabled, you’re either prompted to reboot the device, or not.

When you’ve gotten this far in the enrollment process it should either work as expected or you have some buggy setting in your server configuration. (The important take away being that it’s not likely to be a client-side error.) Note that if your device fails to establish the VPN tunnel next, or be managed by your DM server this does not mean your enrollment failed. Unless you are specifically instructed something went wrong with the enrollment, it’s either a configuration error in the “EnrollmentConfig”, or an error with the configuration of the Gateway and/or Device Management Server. Maybe even some routing or firewalls issue –but that’s really another topic entirely, and this time we are focusing on the enrollment process exclusively