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:
An Intune Trial (30 day evaluation is more than enough!)
A Certificate Authority serving your Forest (Server 2012 R2)
An activated copy of Windows 10 Enterprise (Virtual machine or Physical)
An additional Server 2012 R2 Site system for native mode (PKI) roles
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:
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.
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.
Now, we need to allow double escaping and Directory Browsing for our new Virtual Directory
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.
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.
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.
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.
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.
Now we need to enable the Windows Platform for support via On premise MDM.
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.
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.
Now we need to configure Default Client settings to allow modern devices to enrol.
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.
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
Powered by Zimbra