I was following the very in-depth guides below. Thanks Matt, Kenny, Tim, Pierre, and Benoit for the great guides!
- Matt Hinson – Blog – Setting Up Windows Intune/ConfigMgr 2012 R2 with ADFS On-Prem and Azure Lab
- Kenny Buntinx and Tim De Keukelaere – MMS 2014 – ConfigMgr 2012 R2 & Intune
- Pierre Roman – Blog – Step-By-Step: Setting up the new Azure AD Sync Tool
- Benoit Lecours – Blog – How to enroll an Android device in SCCM
I admit that I am no server guy, I generally stay in the client realm and thus I had a few gotchyas in my setup. Here we go!
Going in, this was a leap. I know next to nothing about certificates and could not find a straight answer on what kind of certificate was needed. Most recommended a wildcard SSL cert, but those were over $500.
I ended up going with a UCC SSL cert from GoDaddy.com for $200 and it ended up working! A UCC cert supports up to 5 SANs, and this was enough for a lab.
- Domain: potentengineer.com
- SAN: fs.potentengineer.com
- SAN: enterpriseregistration.potentengineer.com
The ADFS certificate requirements are actually listed on TechNet, but it can be hard to decipher them.
The certificate I got from GoDaddy was a .cer file, and I needed a .pfx for ADFS. It was a quick and easy conversion using the Certificate Manager MMC console.
Additional NIC on ADFS server
Your on-prem DC in your lab must have two NICs to setup the remote access VPN for ADFS. I added an additional NIC in Hyper-V and let it pull a DHCP address from my internal DHCP server.
When I ran through the ADFS setup (Part 3 of Matt’s blog) on my DC, the configuration went through successfully, but did not work.
https://fs.potentengineer.com/adfs/ls/IdpInitiatedSignon.aspx just loaded a blank page.
I ran through the configuration once more (the database was already created) and it worked the second time. I am not sure what the hiccup was.
External DNS TXT record
I got the error as mentioned in Part 3 when running the below command. (I had some screenshot gathering issues on my first run through, so the screenshot below does not match my domain.)
Given the TXT record can take a few days to propogate, I gave mine some time. After the second day and no update I started troubleshooting and found the value needed for the TXT record changes…every single time you run it. I had the wrong TXT value the whole time. After I updated the proper one, the federation connected within an hour.
AD Sync Tool
Pierre’s guide was spot on, I only had two minor additions.
- The Azure AD Credentials used are not your Azure creds, but instead your Intune creds.
- After configuration, I had to logout of the tool and back in to get synchronization to kickoff.
Intune user setup
When I added my synced user account email@example.com to the Intune Users group, the page refreshed and I got a “User could not be found” error. I went back out and into the user settings, re-added to the group and it went through the second time.
I was looking around in Intune and after another AD sync, my user UPN had reverted to firstname.lastname@example.org. My domain was verified, and the UPN was correct in ADUC internally. Fortunately PowerShell saved the day, and a simple command on my internal ADFS server fixed it.
Set-MsolUserPrincipalName -UserPrincipalName email@example.com -NewUserPrincipalName firstname.lastname@example.org
Technet documentation: http://support.microsoft.com/kb/2523192
I had a couple spare Galaxy S3’s laying around at home and used them for testing over wireless. I got the Company Portal app installed, but when I tried to enroll the devices I would type in my user account, the app would redirect and I would get the error on the right.
I verified I could manually login to the Intune web portal with the user account, so the account and portal seemed functional. I made a post on TechNet, got a few suggestions, but still could not get enrolled.
I checked a few minor things over the next two days, but had no luck. I finally tried again on the test devices and it just worked! I really have no idea what the delay was, but I took the easy win.
The portal app was a beautiful sight to the eyes after the couple weeks it took me to get setup.
Managing Android with ConfigMgr
This part is less of issues found, and more a walkthrough of some basic settings.
The fun finally began! It was very satisfying finally seeing an Android device in my console.
I deployed a Compliance Baseline to my new device and looked at what the options were for managing Android. They were pretty limited, but I hear there are more options coming to ConfigMgr + Intune later this year (2015 Q3?) for Android management.
When you walk through the CI wizard for Mobile Devices, you see a lot of settings, but really have no way to see what platform is supported. How do I know what will or will not work on Android?
The good news is, there is an option to Configure additional settings that are not in the default setting groups, and that lists the platforms supported. Just search on Android and you can see its basically just password, lock, storage, and camera settings.
I just setup a policy to disable the camera. Deployed away, ran a compliance check on the device, and within seconds it was all setup! The camera app opened, closed, and I got the message below.
What a fun, albeit tough, project!