MDM Enrollment for Users

Click Azure Active Directory as seen in Figure 2.7.

In a new tab, you’ll be seeing Azure AD and can click Mobility (MDM and MAM), then Microsoft Intune, as seen in Figure 2.8. Then, in the Configure Microsoft Intune dialog box that appears next, as seen in Figure 2.9, you specifically need to enable MDM user scope. For our examples, I recommend selecting All (also seen in Figure 2.9).

Then, back at the Mobility (MDM and MAM) page (again, Figure 2.8), you’ll click Microsoft Intune Enrollment. This gets you to the “Microsoft Intune Enrollment” page seen on Figure 2.10. For MDM user scope, click All again and click Save.

What you just configured was the user side of the MDM equation. Users need to be prompted to acknowledge the terms of use and so on.

But the real magic is in devices. You need to configure the device registration authority.

MDM Enrollment for Computers

Just 10 seconds ago you were in the Azure AD Console. Now it’s time to get into Intune and tell it that you wish to have it accept requests and perform auto-enrollment.

As I write this, there are three ways to jump into Intune. Way #1 is from the main Admin center, as seen in Figure 2.7. within the Admin center, you could click Intune.

But if you’re still in Azure’s portal, you might not see a link to Intune.

My favorite way to just “go to Intune” is just to search as shown in Figure 2.11. Just click the search spyglass, type Intune, and click the word Intune when it pops up, like I’m doing in Figure 2.11.

So if you ever get lost and just want to go to Intune (or you cannot find Intune), use the spyglass as seen in Figure 2.11.

Bingo.

Another way to add Intune to the list of Azure resources is to click “All services” (seen also in Figure 2.11). Then find Intune and click the star next to it. This will magically add it to the long menu list on the left. This then puts it (basically) on every page, and makes it much easier to just click on to jump to Intune.

Once you’re in Intune, the first stop will be “Device enrollment,” as seen in Figure 2.12. This is where you’ll explain to Intune what’s allowed and not allowed. For instance, if you wanted to allow Apple phones and Windows devices but disallow Android devices, this is the right place.

Then, you’ll see the Choose MDM Authority blade, shown in Figure 2.13. You will only see Choose MDM Authority if you have not done this step ever before.

The correct option to select is Intune MDM Authority as I’ve selected here. Configuration Manager MDM Authority would enable what’s known as Hybrid Intune + SCCM and is going away. (I talk more about Hybrid Intune and SCCM, why it’s going away, and what replaces it in Chapter 4.)

When you do you’ll get a toast notification that it was set correctly.

What Not to Do: Azure AD Join, but No MDM Enrollment

Why am I showing you what not to do first? Because, it seems like the most obvious path you (or your users) would take. Trust me, you’ll see what I mean.

These examples are using a Windows 10 1809 machine; your experience may be a little different in future versions of Windows. But this is what I’ve got to show you today.

Pretend to be a Standard User (that is, one without any local admin rights), and go to the Start bar and type in MDM. For me, and I swear I’m not making this up, I also got some nice recommendations about the mind-altering drug MDMA. But, erasing the recommended A in MDMA will get you what you see in Figure 2.18.

This enables the user to click either “Enroll in MDM only” (two choices) or “Access work or school.”

Again, maybe it’s just me, but in 1809, clicking “Enroll in MDM only” (the left side or the big right-side link) actually did nothing at all except bring me to the Windows Settings page (yippee). (I even tried this as a local admin, and nothing occurred at all.)

Now as this pretend user, inside Windows Settings I have to type MDM again, where you’ll see what’s in Figure 2.19.

Once again, trying “Enroll in MDM only” again from here gives me…exactly nothing again. Literally. It goes nowhere at all.

Okay. (Remember, you’re trying to think like the user, and a Standard User at that.) So let’s try “Access work or school.” Okay! That works. On that page is a big + (plus) with the word Connect. Great, let’s click on that.

Then the big, beautiful dialog box you’ll see next is seen in Figure 2.20, where you would expect a user to put in their Azure AD account information.

Then, they log on with the username and password they got from email.

As it’s cooking, it will look like Figure 2.21.

You’ll get an “All set” message and a chance to click Done. When you do, you’ll fall right, directly, squarely into the snake pit, like Indiana Jones does in Raiders of the Lost Ark.

Here’s an example of the wrong icon, seen in Figure 2.22. It looks like the Windows flag icon. This is not what you want to see if you wish to be MDM enrolled.

How do you know you are not actually MDM enrolled? Only because you’re reading this book of course. Because to me, a nice Windows flag seems like a good thing. But it’s actually wrong and not enough for MDM.

But you can see for yourself if you click on the flag, click “Manage your account,” and open the page in a browser, like Edge. You’ll see in Figure 2.23 where the computer is merely Workplace joined and not MDM enrolled.

To understand what you’ve just done, which, again, is called Workplace Join, see the sidebar “What Is Workplace Join?”

What Is Workplace Join

If you’re not MDM enrolled in Figure 2.22, then what have you done there?

As you can see in Figure 2.23, after you click into it for further inspection, it’s called Workplace Join and it’s really part 1 of the 2 part process to really be MDM enrolled. Said another way, there are two parts to MDM enrollment: joining Azure AD (aka Workplace Join) and Enrollment into MDM.

That big, inviting window is where you put in the username, that literally only takes care of part 1, the Workplace Join part and not the MDM enrollment part.

So what is Workplace Join and why would you want it?

Again, for clarity, it’s not MDM, so for the purposes of this book, you really don’t want it. But its function is to enable people who bring their own device to join your Azure AD, where you can then provide single sign-on to apps like Box, Salesforce, and so on.

And that’s it.

With Workplace Join, you’re not able to deliver applications, manage settings, or perform any other MDM function.

It’s really there just to, well, join your Azure AD, and then when you provide access to resources, you can dictate who can get what resources.

The other upside of Workplace Join is that anyone can do it. By that I mean Standard Users (aka non-admins) can do it. So if you’ve already got 300 contractors working for you and you want them to now magically get access to your Salesforce data, you just spin up Azure AD accounts, marry Azure AD to Salesforce, and set the permissions and…bingo.

You don’t have to magically figure out how to get them local admin rights to MDM enroll, and besides, those 300 contractors wouldn’t want you to manage their machines with your MDM service anyway.

So Workplace Join has its place, but it doesn’t enable you to actually control, manage, or lock down a machine or deploy Windows applications. But it does give you the ability to marry people (that is, their identity) to services you provide through Azure AD.

If you go into Azure AD portal and look at Devices ➢ All devices, you will see the computer “registered” to AD, and even the MDM field might light up saying your MDM service, like Microsoft Intune. But, oh no. You are not MDM enrolled, you are “Azure AD registered.”

If you followed me down the snake hole, let’s get a clean slate. First, back at the client, click the Windows flag icon, like what you saw in Figure 2.22 (and 2.23). Then click Disconnect and then Yes. Then, here inside the Azure AD portal, click on the computer itself, then click Delete and say Yes.

Poof. Out of the snake pit.

What to Do: MDM Enroll

Snake pits: bad. Treasure: good.

To get to the MDM treasure you need to knock on the secret door.

And, Indiana Jones is no regular user, he’s a hero…a Local Admin. (I’ll just call him an Admin, but you’ll know I mean Local Admin.)

So, log off the machine as a Standard User and back in on as an Admin. When you do, you’ll be able to knock three times and find the secret door. Indeed, Figure 2.24 is the secret door and the X marks the spot. Well, not an X, but an oval.

Before you continue, take a look at the difference between Figure 2.24 and Figure 2.20. See that as a Standard User, you don’t even get the chance to find the treasure (labeled as “Join this device to Azure Active Directory.”

Now, because you’re an Admin, click on the treasure “Join this device to Azure Active Directory.”

Then, and only then, on the next page (not shown), you will put in Jack’s username and password. Once you do, you’ll get a pre-confirmation of what is about to occur as seen in Figure 2.25. Click Join to enroll.

Then a confirmation page can be seen in Figure 2.26.

And, finally, your MDM gold awaits. You can see the briefcase icon, as seen in Figure 2.27, showing a proper MDM enrollment.

Now on your Windows 10 machine, log off, and log on as [email protected] as seen in Figure 2.28.

Remember when enrolling using the “out of the box experience” made the person a local admin?

Bam. Same problem here too: The user who just enrolled the machine is automatically a local admin on the box. That’s bad. I get that. But hang tight; we’ll rectify this situation when we talk about using Group Policy to bootstrap existing machines to enroll into MDM as the system in Chapter 4 in the section entitled “Auto-Enroll in Your MDM Service Using Group Policy.”

Killing Windows Hello and PINs (Just for This Book)

Additionally, during the enrollment, you might have been prompted for a device PIN (not shown in the walk-through or screen shots). This is actually Windows Hello, a mechanism to help you walk away from passwords. I like Windows Hello, but you won’t need PINs for this book. And if you’re enrolling lots and lots of machines for testing, it could slow your testing down but decrease security in your test computers.

That said, you might want to kill Windows Hello…just for this book.

For clarity: I am not anti–Windows Hello.

But when you enroll a machine, there are several extra steps asking users to provide a PIN (which can replace a password), and it just generally takes longer to perform your test enrollments.

Counterintuitively, using PINs instead of passwords is safer, because the PIN is bound only to the device. On the other hand, if someone has eight devices, they may have to remember eight unique PINs instead of one password. If you want to read a good article on the subject, check out:

http://www.brucebnews.com/2016/08/logging-in-with-a-pin-is-easier-than-a-password-and-safer-too/

For our purposes, if you wish to turn it off, just for now, the global way to do this would be Intune ➢ Device Enrollment ➢ Windows Enrollment ➢ Windows Hello for Business. Then click the one entry in there for All Users, then Settings.

You can, if you want to, have multiple Windows Hello for Business profiles. It means that you can disable Windows Hello from your test users but enable it for your real users.

But, since this whole book will be about testing, go forth and disable Windows Hello for Business, as shown in the following image.

MDM Enrollment via Shortcuts (aka Deep Links)

In the previous example, we used the Windows 10 Settings app to find the Azure AD/MDM enrollment section of the universe.

But what if you wanted to:

• pre-create the Azure AD accounts, and
• email everyone with step-by-step join directions, and
• pray to the universe people follow your steps correctly, and not Azure Workplace join, but actually perform the MDM enrollment?

There’s a better way. Again, though, MDM enrollment can only be done by Admins and not Standard Users.

That said, you can use a magical shortcut, also known as a deep link. There are a few ways to do this. You can send your people (the people who have Azure AD accounts now) an email telling them to click on a link, say, in an email specified like this:

ms-device-enrollment:?mode=mdm

You can copy and paste that string into a browser (as seen in Figure 2.28), or use Windows + R (to bring up the Run dialog box) and type it in directly like what’s seen here.

When you do, you’re bypassing all the steps to find the Settings app, know what to type to discover the MDM section within the Settings app, and also avoid the snake pit. Basically: Let’s get people directly to the MDM enrollment treasure. As you can see in Figure 2.29, just put in the magic syntax into a Microsoft Edge browser window, and… poof. You’re off to the races.

Then the user must know their account information.

What’s that I hear you cry? Users shouldn’t even need to know that much? No problem. You can embed their username into the deep link like this.

ms-device-enrollment:?mode=mdm&[email protected]

And when you do, that information is automatically filled out, as seen in Figure 2.30.

And, for some MDM systems, like Workspace ONE, you might be required to enter in a specific server name (if you’re doing all the steps manually). You can bypass all that as well, by entering in the server name inside the deep link like this:

ms-device-enrollment:?mode=mdm&[email protected]&servername=https://techp-ds.awmdm.com

The result might look like Figure 2.31 where the user’s name and server, which is pre-placed on the special link, can be seen in the dialog box.

Azure AD Connect

Again, the tool you want to find is called Azure AD Connect.

There have been a lot of iterations of this tool, with several versions and name changes. But this is it, this is the tool now: Azure AD Connect. Said another way, if you have or had the old DirSync or Azure AD Sync…those tools are toast, and it’s now only Azure AD Connect. The good news is that if you had these old tools, there are upgrade options from them to Azure AD Connect.

The basics of the tool can be found at https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect, including advice for those who are upgrading from one of the older tools.

In this example, I’m going to assume you have a single on-prem domain, named Fabrikam.com (as I recommended in the opening pages of this book). If you have something more complex in real life, that’s fine; you can use the aforementioned URL to find your scenario and give it a go.

Do not start out by downloading the Azure AD Connect tool. No. Don’t. Don’t start there. Instead, inside your on-prem AD, run the Active Directory Domains and Trusts tool. Then right-click over the root node and select Properties. Then in the UPN Suffixes tab, add the name of your (now verified) Azure AD domain. In Figure 2.43, I added fabrikam1000.com and clicked OK.

Alternatively, you could have added your onmicrosoft.com name, like fabrikam1000.onmicrosoft.com. That would work as well, but since I went to the trouble to purchase and verify Fabrikam1000.com, I’m using that.

Next, after adding the UPN suffix, you can now continue by downloading Azure AD Connect and installing it directly upon the DC of your on-prem AD domain. You can use a spare server as well, but for me, and this book, I’m installing it right onto the Domain Controller. The download can be found at http://go.microsoft.com/fwlink/?LinkId=615771.

After you run it, you’ll start out with a welcome screen. The next screen can be seen in Figure 2.44 explaining Express Settings.

I would also say that Express settings are good for the book exercises and to get you up and running but might be suboptimal for “real life.” Typically you want to point it toward specific OUs, so you don’t sync all accounts to Azure AD, like your admin and/or service accounts.

That said, so I don’t have to go down every rat hole with the tool, and I can get you on the road with examples quickly, the Express Ssettings should be fine for our use.

On the next screen, you’ll provide your Azure AD creds (as seen in Figure 2.45); this is what you used to set up your E5 trial. Then you’ll provide your on-prem AD creds as seen in Figure 2.46.

Now when you get to the Azure AD sign-in configuration page, you should see the UPN name you added to on-prem AD marry up to the Azure AD domain name as seen in Figure 2.47. Also in Figure 2.47, a small bug in the Azure AD Connect program requires you to select the “Continue without any verified domains” check box, even though you do have a verified domain. It might be fixed by the time you read this.

Click Next and then start the process going. You will be notified when the process is complete, as seen in Figure 2.48.

Wait a few minutes. Then, you can refresh the Azure AD Admin Center and see the results. I found that the best way to get results was not to hit the refresh button, circled as seen in Figure 2.49, but rather to refresh the whole page (see the arrow), then click Users then “All users.” And, bingo.

You’ll also see in Figure 2.49 in the Source column which users were created from which source: Azure Active Directory versus Windows Server AD.

Changing Over the Users’ Suffixes

But, wait a second! After the synchronization occurs, synchronized users from on-prem AD will not have the the nice, pretty fabrikam1000.com as part of their username but instead still have the ugly fabrikam1000.onmicrosoft.com as part of their username.

Why would this be? Because your on-prem AD users need to already be expressly using the suffix, and only then will you see it after synchronization.

To change it, for one user, use Active Directory Users and Computers, find an account, like EastSalesUser1, like what’s seen in Figure 2.50. Then click the Account tab so you can perform two steps:

• Step 1: Actually enter in a name in the “User logon name” field. Usually this will be the name they already use, know, and love.
• Step 2: Pull down and select the custom domain name you specified within Active Directory Domains and Trusts earlier. In my case, it’s Fabrikam1000.com.

You can wait a while, and the changes will naturally occur.

Or you can see the changes happen in real time. To see them, find the Azure AD Connect folder and launch Synchronization Service as seen in Figure 2.51.

Then, the tool itself doesn’t seem to have a big “Click Here to Sync” button. But there’s a PowerShell way to do it.

You should be able to push up just the changes, or deltas. That command is:

Start-AdSyncSyncCycle -policytype delta

If that doesn’t do the trick, wait until the first command finishes and just try pushing it all up again. That command is:

Start-AdSyncSyncCycle -policytype initial

You can see the result of these two commands running in Figure 2.52.

When it’s complete, refresh Azure AD and look again at all users. Carefully notice that the one user you specified now has the right username: [email protected] and not the onmicrosoft.com one any longer, as shown in Figure 2.53.

Mass Updating the UPN for On-Prem AD (Instead of Clicking Through to Each User)

Of course you don’t want to spend your whole weekend updating each and every user’s UPN name by hand just so it synchronizes correctly to Azure AD.

The secret to mass updating all users’ UPN names is quickly revealed in a blog entry here:

https://blogs.technet.microsoft.com/heyscriptingguy/2013/08/13/add-user-principal-names-in-active-directory-via-powershell/

If you named your on-prem domain fabrikam.com, and if your custom Azure name is say, Fabrikam.com, then this one-line script ought to populate each user’s UPN attributes in a jiffy. In my case, specifically in the Sales OU.

Get-ADUser -Filter * -SearchBase 'ou=Sales,dc=fabrikam,dc=com'

-Properties userPrincipalName | foreach

{ Set-ADUser $_ -UserPrincipalName

(“{0}@{1}” -f $_.name,“fabrikam1000.com”)}

Then, use the technique earlier to re-sync on-prem AD to Azure AD, and bingo.

Everyone now has the exact right username in Azure AD, populated from on-prem AD, as seen in Figure 2.54.

Deleting Accounts in Azure AD

For fun, inside the Azure AD Admin Center try to click on an existing Windows Server AD user and click Delete user from the menu command bar.

Spoiler alert: you cannot.

The synchronized user is born, lives, and dies inside on-prem AD and is only synchronized here. And you can try this yourself. Create a new user in on-prem Active Directory Users and Computers. Then wait a while, and bingo. You should see it in Azure AD.

And nothing ever, ever goes wrong when syncronizing things. Not ever. Ahem. So, if you do get caught in a jam, I learned a little PowerShell trick that can nuke a record inside Azure AD. The commands are:

Install-Module msonline

Connect-MSolService.

This will prompt you for your Azure admin creds; in our case, [email protected].

Remove-MsolUser -userprincipalname [email protected]

The result can be seen in Figure 2.55.

Then a refresh of Azure AD will show the user now nuked but remaining in on-prem AD.

A good article on removing objects synchronized from on-prem AD can be found at:

https://support.microsoft.com/en-us/help/2619062/you-can-t-manage-or-remove-objects-that-were-synchronized-through-the

Yep, this URL just ends in the word the.

Get Windows 10 to Automatically Join Azure AD (Hybrid Azure AD-Joined Devices)

Again, All the steps in this section are optional, but over the long run you might want to consider this interesting idea. That is, you can teach your on-prem AD to synchronize all the existing Windows 10 accounts from on-prem AD, and push them up to Azure AD.

Big, big sort-of warning here: While this gets all your Windows 10 computers registered into Azure AD, it doesn’t magically also get them enrolled into your MDM service. Don’t worry: We set that up in Chapter 4 (and, ironically, we use Group Policy to do it).

And, speaking of Group Policy, you can use it to pre-block some Windows 10 machines from being synchronized from on-prem AD to Azure AD. The policy setting is Computer ➢ Policies ➢ Admin Templates ➢ Windows Components ➢ Device Registration ➢ Register domain-joined computers as devices (as seen in Figure 2.56). When you set this policy to Disabled (yes, Disabled), then computers that pick up this policy will ignore the magic trick we’re about to perform.

So, I suggest you pre-deliver the Register domain-joined computers as devices Group Policy setting to the machines you want to exclude before performing the next steps. (And, as another blatant plug, if you wanted to know and verify the setting made it to all your intended machines, you could utilize the paid version of the PolicyPak Group Policy Compliance reporter, which tells you which on-prem machines got which GPOs and settings, so the guesswork is removed…but I digress.)

Anyway, when you’re ready to start the Vulcan mind-meld between on-prem Azure AD and Azure AD, here is each PowerShell command to type, one on each line. You’ll do this on the machine running the Azure AD Connect program.

In case you want to copy and paste these, instead of typing them in, I’ll tell you where I found them, which is this URL (which I’ll mention again a little later): https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-manual-steps.

Here are the PowerShell lines of code:

Import-Module -Name "C:Program FilesMicrosoft Azure Active Directory ConnectAdPrepAdSyncPrep.psm1";

$aadAdminCred = Get-Credential;

Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [email protected] -AzureADCredentials $aadAdminCred;

The result of these PowerShell commands can be seen in Figure 2.57 in the first section. Then, if you want to see that it really took effect, you could run a sort of verification check, which would be the following PowerShell commands (again, these lines are also in the aforementioned URL at Microsoft):

$scp = New-Object System.DirectoryServices.DirectoryEntry;

$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com";

$scp.Keywords;

You can see the result of that in the second block in Figure 2.57, where it spits out some stuff, including my domain name fabrikam1000.onmicrosoft.com!

Now your Windows 10 machines (1607 and later) on your network will automatically get the memo and self-register in Azure…when they’re domain-joined fresh, or existing Windows 10 machines, when they’re rebooted and/or logged into.

And you can see it happen too. After your Windows 10 systems are rebooted, and after some synchronizations happen naturally using Azure AD Connect, you should see new Windows 10 computers pop into Azure AD when you examine all devices, as seen in Figure 2.58 with a W10-1703-PRO-64 computer. If you look at Join Type, it says “Hybrid Azure AD joined.”

Back on the Windows 10 machines, you need to see if they get the signal to magically perform their Azure AD join. When you go to a Windows 10 machine and run the command dsregcmd /status, you might see what I have in Figure 2.59, where it clearly shows AzureADJoined is NO.

Then, after some time, the change occurs on the Windows 10 machine.

You can see the change in Figure 2.60 as you keep running and rerunning dsregcmd /status. The command will show you a ton of information you don’t care about. But it’s the first line that counts: AzureADJoined is set to YES as seen in Figure 2.60.

Again, this only happens after the Azure AD sync happens once or twice. If you want to goose it, then see the earlier commands on how to run a delta sync. That worked for me to “rush” things.

Additionally, if you want to see all the computers that are now joined to Azure AD, you can use a few PowerShell commands.

• Install-Module msonline
• Connect-msolservice then give Frank’s admin credentials when prompted.
• Get-MSoLDevice -all will show you the machines joined in Azure AD.
• Or use Get-MSOLDevice -all | Select displayname, objectid for a prettier view, like what’s seen in Figure 2.61.

That’s the basics, and that’s how you get machines to be both AD joined and Azure AD joined. Again, that’s got a nifty lingo we call DJ++. You can drop that acronym at a cocktail party now that you’re badass and got it set up.

That said, there is more information, including all sorts of additional magic tricks like the following:

• Dealing with multiple forests syncing to Azure AD
• Using older 2008 Domain Controllers instead of Server 2016 and later
• Including Windows 7 machines into Azure AD

Then that guidance (again) can be found at:

https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-manual-steps

Azure AD Connect Health

If you’d like, you can also do nice, ongoing monitoring of the synchronization. This is beyond the scope of the book, but if you wanted to check it out, it’s included in the Azure AD subscription.

Here are three good links on the subject:

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect

And

https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health.

And finally, the most important one:

https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-sync