ConfigMgr B1511 and On-Premise MDM

I thought I’d cover On premise Mobile Device Management using ConfigMgr Build 1511. So let’s take a look.

The simplified list of the pro’s and con’s of mobile device management versus full client management, laid out on the Microsoft TechNet page tell us

Moving from zero using this

To a fully operational one of these

May seem like climbing this, in just your pants

But with a guide to hand, the problem is broken down and thus, we get all the climbing kit laid out in front of us, and have a personal Sherpa to help get up there!

Ahead of my climb to get On Premise MDM working, fellow MVP climbers Panu Saukko, Kent Agerlund and Gerry Hampson already summited and provide their own guides, one for TP3 and a more recent one by Gerry for B1511, this is my attempt to make it to the top using the documentation and B1511, while leaning on Gerry to figure out that I needed to do this, for the enrolment roles

This guide is of epic length, there are lots of screenshots, multiple step by step procedures, frequent summaries of activity and of specific steps, and requests for you to go further and set a few things up on your own, such as PKI. I did not run through this guide a second time to repro due to the vastness of the steps involved, but believe it should all hang together and result in Windows 10 devices enrolling correctly.

What we’re going to need is a lab environment consisting of the following:

1. An Intune Trial  (30 day evaluation is more than enough!)
2. A Certificate Authority serving your Forest  (Server 2012 R2)
3. An activated copy of  Windows 10 Enterprise (Virtual machine or Physical)
4. An additional Server 2012 R2 Site system for native mode (PKI) roles
5. A Stand-alone Primary  Hierarchy  with a single Site system is enough, running on Windows 2012 R2, Build 1511 minimum or higher with at least the following roles deployed

• Primary Site Service Connection Point
• Site system Remote Secure Management Point
• Site system Secure Distribution Point
• Site system Secure Enrollment Point
• Site system Secure Enrollment proxy point

The need for Intune is for licensing purposes only, devices will not talk to Intune, instead they will have a relationship with the Site server that the device is enrolled with. Setting up an Intune evaluation is well documented, I won’t include it in this guide, see Niall’s guide here that includes the steps for the sign up process, but do not proceed to integrate Intune with your Site server, return back here for that. If you’re using the browser on the site server you may need to turn off IESC to avoid prompts during sign up, and add login.microsoftonline.com to the safe\trusted zone if you get stuck.

You’re going to need Certificate Services in your lab, if you do not have one setup then go and roll your own Certificate Authority on your lab domain. Guidance on going through this procedure can be found here Install a Root Certification Authority, but please do have a look around for other guide to get a good overview of what is needed to get PKI up and running.

You’re also going to need to setup a few more roles to get Certificate Services fit for purpose. The Roles required and their installation order are:

1. Certificate AuthorityandCertificate Authority Web Enrollment
2. Certificate Enrollment Web Service after

There are a lot of guides on setting up your Certificates, the Certificate Templates and issuing Certificates for ConfigMgr, nothing has changed much at all with PKI and ConfigMgr guides from several years back, one of which from Microsoft I’m going to be lazy and point too here, and a community one here.

Once you’ve gone through that lot you’ll have certificates ready for use on the MP\DP web server and the clients.

Now that the Certificate Authority is up and running, you need to perform an additional step that we didn’t need too in the past when playing with PKI and ConfigMgr in the lab, and that is to setup a Certificate Revocation List held on a Distribution Point (CDP).

The tiniest of background on this is  that any certificates that have been revoked by the Certificate Authority will be listed in the Certificate Revocation List, and this list is made available via IIS over HTTP to any Operating System that wants to verify that a certificate is valid. Windows 10 during registration for Mobile Device Management, will check to see if the certificate being used for authentication is valid, if it is not then access is denied. Validity depends on the certificate duration having not yet expired, or from intentionally invalidating certificates by the Certificate Authority for security purposes (compromised, risk mitigation).

Setting up an Certificate Revocation List Distribution Point, and telling the Certificate Authority to use it is a pretty simple process, fully documented by Microsoft and others, but I describe the steps here so that you do not have to travel out of the guide to continue with this set of configuration steps.

Let’s get underway.

Later on, we’re going to modify Certificate Templates on the Certificate Authority so that they include a reference to the soon to be created CDP using an FQDN, so that this works, we need to create a DNS A record that resolves to the IP address of the Certificate Authority that will host the CDP.

I assume you have your DNS service running on your lab Domain Controller, so head on to it.

• Open the DNS management console 
• Expand the Forward Lookup Zones node and right click your domain entry
• Add in a HOST A record called crldp as shown in the example below
• Add the IP address of the server hosting the CDP

• Select Add Host to add it to your Forward Lookup zone.

You can test this by opening a CMD prompt and using NSLOOKUP or PING, so as to make sure it resolves by is name crldp, and the FQDN equivalent for your domain. All devices that you enrol should be able to resolve this FQDN and get a response.

Now that the DNS entry has been created and it points to the CDP, we next create a folder and an IIS Virtual Directory (website) to build the framework needed for the CDP to respond to requests for certificate validation.

For the lab I create a folder on the root of the C: volume called CRLD (I should have used CDP, if you change this be aware of it as several key steps ahead rely on this) on my Certificate Authority server hosting the CDP, this can be a different drive\path of your choosing, just make a note of it for later.

• Share the newly created folder out using a hidden share by right clicking the Folder, selecting Properties and selecting the Share tab. From there select Advanced Sharing, tick Share this folder, and add the $ (Dollar) suffix so that it looks like this:

• Select Permissions and for Everyone select Full Control.

• The folders Sharing tab should now look like this:

• Select Close
• Remaining on the Certificate Authority that is hosting the CDP (assuming you’ve set it up to use IIS, which it should in the lab), fire up the Internet Information Services console
• From within the Internet Information Services console, expand out the Sites node, right click Default Web Site then select Add Virtual Directory
• In the Alias type CRLD
• For Physical Path type C:\CRLD

• Select OK
• Remaining in the console, selecting the new Virtual Directory (CRLD) and switching to Content view will show that the Virtual Directory (our new CDP website) is empty, since the Certificate Authority has not yet published too it

Now, we need to allow double escaping and Directory Browsing for our new Virtual Directory

• Remaining on the CRLD Virtual Directory, Switch back to Features View, then scroll down to Management and double click Configuration Editor.
• Now that the editor has appeared, from the Section drop down navigate through System.WebServer to Security and onto Request Filtering. Now set allowDoubleEscaping to True and click Apply.

• Click back on your CRLD virtual directory, and navigate to the IIS section, double click Directory Browsing, select Enable

All of that came from this Microsoft guide.

Next up is to add the CDP to the CRL Distribution Point location list extension for the clients to use, when attempting to validate Certificates.

• Open the Certificate Authority Management Console
• Right click your Certificate Authority and select Properties

• From Properties Select Add

• Wipe the Location field as we’re about to reconstruct it, and type http://crldp.<domain>.com/
• Select CaName from the variable drop down and select Insert
• Select CRLNameSuffix and Insert it, then select DeltaCRLAllowed and insert it then add .crl
• It should look like this with your domain name

• This is the same dialog that shows the end of the Location field

• Select OK

• Back at the Extensions tab and while highlighting the newly created entry, tick the following check boxes

1. Include in CRLs. Clients use this to find Delta CRL locations.
2. Include in CDP extension of issued certificates.
3. Include in the IDP extension of issued CRLs

• We haven’t clicked OK for a reason, hold off

In my lab, this doesn’t allow me to publish the CRL to the CDP, it will however include this extension modification in any future certificates issued by the Certificate Authority.

To publish the CRL to the CDP, I had to repeat the above steps with some different inputs.

• Add another CRL Distribution Point, this time so that we can publish to it by clicking Add again
• Wipe the Location field as we’re about to reconstruct it, and type file://C:\CRLD\
• Select CaName from the variable drop down and select Insert
• Select CRLNameSuffix and Insert it, then select DeltaCRLAllowed and insert it then add .crl
• It should look like this

• This is the same dialog that shows the end of the Location field

• Back at the Extensions tab and while highlighting the newly created entry, tick the following check boxes

1. Publish CRLs to this location
2. Publish Celta CRLS to this location

• Now select the Exit Module tab, and Select Properties

• Tick the Allow certificates to be published to the file system
• Select OK

• Opt to recycle Active Directory Certificate Services, only takes a moment to complete.

Great, we’ve got several things in place now, an Intune trial, Certificate Services, a DNS entry, a  directory for the CDP, an IIS Virtual Directory, and the CDP has been configured for publishing and client use in Certificate Services.

Let’s make the Certificate Authority publish the CRL to the CDP.

• From Certificate Authority console, right click Revoked Certificates, select All Tasks then Publish

• Select a New CRL:

• Select OK
• You should now see the Full and Delta CRL’s listed in the CRLD directory from File Explorer, it should not take more than a few moments

• You can point a browser at the CDP and should see the main and delta certificate lists as well

If any of this is broken, circle back to see where you’ve possibly deviated.

Now we turn to the Intune Evaluation, so as to integrate it with ConfigMgr for Hybrid mode.

• From the ConfigMgr Console create a User Collection to host the accounts that can perform Intune device enrolment

• I’ve called it Intune On-Premise Enrollment Users

• I’ve not enabled incremental updates or a schedule, I'll be adding a test user manually. Complete the Collection wizard
• Make sure you have Active Directory User Discovery enabled, and that at least one discovery of the Forest\Domain has taken place, confirm the user you want to do all the device enrolment with is seen by ConfigMgr
• Add the enrolment administrator you’ve selected from your discovered Users to the newly created collection

Before you can continue, your Site server must have the Service Connection Point role installed, a prerequisite for Intune, make sure this is done, and that it is working. Once you have a working Service Connection Point (not blocked by a Proxy, Firewall, is synchronising) proceed.

• From the ConfigMgr Console now go to Administration, expand Cloud Services, and right click Microsoft Intune Subscriptions, finally select Add Microsoft Intune Subscription

• Select Next

• Select Sign In

• Tick off “I understand …” and Select OK

• Sign into Intune using your Intune administrator account. If this fails, at the top of the guide I mentioned adding the Intune website to Internet Explorers Safe Zone …

• You’ll see that the sign in is greyed out and you can proceed, Select Next

• Select Browse
• Select your newly created User Collection for Intune use

Select OK

• Add some details, company name, choose colour scheme, select Site code, Select Next

• Select Next

• Add in a logo if you want, Select Next

• Select Next

• Select Next

• Select Next

• Select Close

Now we need to enable the Windows Platform for support via On premise MDM.

• Right click the Subscription that has just shown up in the Microsoft Intune Subscriptions pane

• Select Configure Platforms then Select Windows

• Tick Enable Windows enrolment
• Select OK

Since Mobile Device Management requires a secure Management Point and Distribution Point, and because I want to run the Primary in HTTP mode due to the Fallback Status point residing there, we need a new Site system - “We’re going to need a bigger boat!”.

Make sure your new Site system has a web certificate in place before you proceed, if you jumped the gun and gave it a certificate before we changed the Extension properties on the Certificate Authority, reissue the certificate to get the updated extensions for the CRL Distribution Point properties. I’m not sure if this is an important step for the web server certificate, most likely just the client certificate, but get it done anyway or circle back to it if things won’t work.

A Windows 10 device that has been domain joined will receive a Trusted Root Certificate as well as a Client Certificate, the trusted root cert from the domain join, and the client cert from a group policy that should already be setup to auto enrol devices. For workgroup devices, make sure you’ve exported your Trusted Root Certificate, and the Client Certificate (use the DP Client certificate if you made one, or the WINPE Boot Image as they all have the Client Authentication purpose) as you’ll need them.

• Create a VM for your new Site system, install IIS and make sure IIS is configured for an MP and DP, has the site servers computer account added to local administrators, and has the web certificate added (see this guide for the steps)
• From the ConfigMgr Console create the new site system,  make sure your Site server is in the local administrators group of the Site System beforehand, setup the roles using HTTPS mode. Note that when adding roles, include the internal FQDN in the Internet FQDN field

• Add the Enrollment Point and Enrollment proxy point

• Select Next

• Nothing to configure, Select Next

• Select Next, Next, Close.
• Check SITECOMP log to confirm the roles were installed correctly. Also check the components log files on the Site system. If the Site system that you are installing these roles onto has not yet been configured for HTTPS\SSL yet, you’re going to get errors. Restarting Site Component manager on the Site server will retry if you fall foul of a prerequisite issue
• I had problems in this area, I had to reboot the Site system before the roles would install and activate correctly. A significant indicator that something is up is if the CMEnrollmentService.log is missing. I re-seated the roles then rebooted, but I suspect and Gerry Hampson has confirmed, that a single reboot after initial role deployment would have fixed the problem

• Once you know that HTTPS is working fine for the two roles you just installed, go ahead and install the Management Point and Distribution Point in HTTPS mode
• Make sure the Distribution Point is configured as below, importing the Distribution Point Client certificate
  

• Tick Allow mobile devices to connect to this distribution point
• Make sure your Management Point is configured as below. I had issues with the Management Point where I had to configure SQL permissions for the newly created Site system by hand, so that the Management Point had access to the smsdbrole_DMP and smsdbrole_MP SQL roles

• Tick Allow mobile devices and Mac computers to use this management point
• Make sure both roles go on correctly, MPControl log on the Site system should let you know all is well with the Management Point, and DistMgr on the Site server will let you know if the Distribution Point went on ok and is working.

• Import the exported Trusted Root Certificate into your Site server. Note that I do not think this step should be necessary. If you skip it and get stuck at the end of the guide with devices that won’t enrol, come back here and set it. I don’t think this is necessary in B1511 and onwards but I imported while I was troubleshooting (it did not move things forward at the time) so cannot confirm myself.

If you want too, you can install the ConfigMgr Agent onto a device in HTTPS mode and deploy something to it, this will test your MP and DP running in HTTPS mode.

We’ll now make a change to the Default Client Settings so that Users will be able to enrol Modern Devices (Windows 10 et al), we’ll first create a Certificate Profile, and specify the Trusted Root Certificate that is used to verify authenticity of the device. This certificate is not passed to the device being enrolled, it is merely being used to validate authenticity of the device being enrolled.

• From the ConfigMgr Console head to Assets and Compliance, expand Compliance Settings, Company Resource Access and right click Certificate Profiles, select Create Certificate Profile

• Enter a descriptive name
• Select Trusted CA certificate
• Select Next

• Point to your exported Certificate Authority Root Certificate file, making sure the Destination store is Computer certificate store – Root
• Select Next

• Select Windows 10

• Select Next, Close

Now we need to configure Default Client settings to allow modern devices to enrol.

• Open up your Default Client settings

• Make sure Allow users to enroll modern devices is set to Yes
• Select Set Profile …

• Select Create

• Give it a descriptive Name
• Select the Management site code
• Select the newly created Certificate Profile from the Certification Configuration pane
• Select OK

• Select OK

• Your Client Settings should now be enabled and show the enrolment profile being used

Now on the Windows 10 device, if it is in workgroup mode import the Trusted Root Certificate into the computers Trusted Root Certification Authorities store, and the Client certificate into the Personal store, both for the Computer. If it is domain joined this isn’t necessary, both certificates are provided, the root certificate is issued during the domain join, and the client certificate auto-enrolled via Group Policy (if all is setup correctly!).

The Client certificate is necessary so that the device can contact the Device Management Point for policy, and the Distribution Point for content post-enrolment. The trusted root certificate is needed to get the enrolment underway via the HTTPS enabled Enrollment Proxy Point, which wouldn’t trust us if we didn’t have it.

If in workgroup mode without the trusted root certificate, you’ll get blocked as in the example below. Without the client certificate you’ll enrol but have issues later on with deployments to the device.

Now let’s manually enrol a device. Note that there is the option to bulk enrol which is covered here, it leverages ConfigMgr and the Windows 10 ADK to produce a package that can be executed on a Windows 10 device, automating and watering down the enrolment process to just handling the execution of a package (local interaction) on the device.

I’m using an activated version of Windows 10 Enterprise Build 10240.

• Open Settings

• Click Accounts

• Click Connect

• Tap in the credentials (UPN) for the Intune enrolment administrator that you put in the user collection a while back and select Continue

• Now you’ll be prompted for the Enrollment Proxy Point FQDN, select Continue
• We are now talking to the ConfigMgr Enrollment Proxy Point!

• Tap in the credentials (UPN) again and select Sign In

• This is pretty much confirmation that we’re able to talk to the Enrollment Point
• Let Windows store the credentials away, and Select Yes to get underway

• We wait a few moments for the process to complete

• That’s it, the device is enrolled. Select Done
• If the device wouldn’t enrol, you can take a look at the devices event log, open Applications and Services , take a bit of time to render the list, then expand Microsoft, Windows and DeviceManagment-Enterprise-Diagnostics-Provider, click Admin and you’ll be greeted with events that may show why the enrolment failed
• Click on the Intune Evaluation grey box, it will expand out to show multiple buttons

• Clicking Info will show us whether the sync is underway, problems with certificates will cause this to fail instantly

• Errors at this point are most likely going to be due to the enrolment point or the enrolment proxy point not installing correctly, or the certificates are not configured correctly. If you are in doubt whether your PKI is working, install a ConfigMgr Agent in HTTPS mode and test it.

• Open up the ConfigMgr Console and go look for your Windows 10 device by its host name in the Devices node

• You’ll see that it has a different icon than for a normal device, a mobile device,
• Right click and select Start then Resource Explorer
• It may take a few minutes for it to appear, but we will see a limited set of inventory appear, for now this really is all we’ve got

• Come back to ConfigMgr, and right click the device again

• As you can see the options for this resource record are different than that of a normal device resource record

• A good end to end test is to tell the device to lock . Make sure the device is unlocked, then select Remote Device Actions and select Remote Lock

• We’ll be prompted to confirm

Head to your device, confirm that the console session has locked.

And to wrap things up here is a shot of part of the resource record

Well, for those of you that made it up the mountain, congratulations!

I’d recommend checking out Kent, Panu and Gerry’s guides as well since they had bits I've not covered here as deeply on troubleshooting.

I found this handy to lookup MDM Errors