Set Up Device Page

When you’re in the “Set up device” page, you’ll see what’s in Figure 8.4. You can specify a device name after the machine accepts the package. The format might be something like Fabrikam%RAND:4%, which would make a machine name something like Fabrikam0001.

Additionally, my favorite feature is on this page, the “Remove pre-installed software” switch, which will remove darn near everything in the box and do a Windows reset. In other words, it will automatically get rid of bloatware and junk someone might have had in the box and make it spring-fresh! Yes, this adds some more time, but who wouldn’t want the cleanest machine to get started with?

Also on this page, but not used in my example, is a way to just throw in a product key for your enterprise, and if a machine starts out life as Windows 10 Pro and you put in a key for Enterprise or Business, then…bingo. Your machine will be re-born as that machine type when this is all over. That’s amazing.

Set Up Network Page

If you know you have Wi-Fi on the target, you can prefill in a network SSID to connect to. I didn’t try this end to end, but to me it looks like only Open and WPA2 Personal password types are supported.

You can also click this to Off, which will ensure that you must use hardwired Ethernet to continue.

Account Management Page

The Account Management page can be seen in Figure 8.5. On this page you’ll select if the machine should enroll into on-prem Active Directory (provided you also have a VPN connection), enroll in Azure AD (which we’ll set up), or just have a local admin. I’ll select Enroll in Azure AD. You’ll also set a Bulk Token Expiry date, which is how long you will allow this package to enroll machines. Maybe you want to set this for 30 or 90 days, or even maybe 10 years in the future. It’s your choice. Note that as far as I know, you cannot revoke an enrollment token once it’s baked into the .PPKG file. But each time you create a token, it creates an account in AAD that corresponds with that token. If you can figure out which account is used to create that token, just delete that account and that would effectively deactivate the token.

In Figure 8.5, you can see my success after providing Frank Rizzo’s Azure admin credentials and setting the date into the future.

Add Applications Page

The “Add applications” page, seen in Figure 8.6, is useful if you have some package that might not be deployed automatically through MDM. In this example, I’m adding PuTTY (www.putty.org), a common networking application. After selecting it, the command-line arguments are nicely already put in for me, a nice touch.

Note that the actual application itself is embedded into the .PPKG file. So the more applications you add, the bigger and badder this file gets. Note that there is a catch with this: you can only have one file for each app, along with a command line to install that one file. So if you have an installer that consists of multiple files, you’ll have to bundle those that are utilizing some kind of self-extracting installer, which isn’t hard, but it’s not really fun either.

Remember, at some point you’re going to have to get this .PPKG file over to the user, usually on a USB stick or a DVD or something. So just be cognizant of that. Additionally, as I said, there’s no need to deliver stuff through the .PPKG file that you’re also going to be deploying over the Internet via MDM anyway, so also keep that in mind.

Add Certificates Page

The “Add certificates” page is useful too. There are lots of times you may need to pre-populate a certificate into the machine’s brain, so it starts to immediately trust resources. In Figure 8.7, I’m feeding it a certificate in .CER format.

You can click Finish and see a review of the .PPKG file before you save. You can optionally protect the package with a password, which isn’t a bad idea, but for this example, I’m not going to.

The Advanced Editor

Additionally, I noted earlier that there is the Advanced editor within the WCD (which I won’t be using, but did want to show you). You can see this in Figure 8.8.

The WCD Advanced pane opens up even more possibilities of knobs and things to do. Some are pretty awesome and important, like turning on BitLocker, DeviceGuard, and Defender. And some are just fun, like Desktop background and other look-and-feel items (that could be covered in MDM-land).

I have two warnings about the advanced editor though:

1. The Simple editor we’ve been using then becomes unavailable for the same .PPKG file. That is, going forward, if you use the Advanced editor for the advanced stuff, you cannot use the Simple editor again.
2. When you save your packages out using the Advanced editor, you need to expressly specify that you are an IT admin and not an OEM or other vendor type. You can see this in Figure 8.9. You’ll also need to update the Version number in case you make any updates later, or else existing machines will ignore any files (with the same version) they’ve seen before.

Implementing the .PPKG File Automatically during OOBE

Back to Jack. Remember Jack? He just went to Best Buy and bought a new laptop. And you’ve got him a USB stick with the .PPKG file.

All Jack has to do is put in the USB stick with the .PPKG file in the machine and turn on the machine when it starts the first time.

That’s it.

When he uses the USB stick, Windows OOBE will open the .PPKG file and just ask him if he wants to set up the device (not shown in any screen shot). Jack simply says yes, and then…Jack gets some coffee while Windows does its thing.

Implementing the .PPKG File Manually during OOBE

What if Jack already turned on the machine because he couldn’t wait a second longer? But he didn’t know all the answers, and now Windows is not quite ready but still in the OOBE. In this case, Windows started to take care of some initial housekeeping items and Jack missed the window to get the OOBE to see the USB stick automatically and start to use it.

No problem. Tell Jack to hit the Windows key five times. Then it will wake up and see the USB stick with the .PPKG file on it. Jack then says yes to use the file, and Jack will see what’s in Figure 8.10.

Implementing the .PPKG File after Windows Is Already on the Machine

What if Jack didn’t know you were going to send him a USB stick with a .PPKG file and finished OOBE and now Windows is running? Or, similarly, what if Jack was handed a machine from the supply closet, with Windows already running?

In this case, Jack will need to feed Windows the .PPKG file on the USB stick. It’s as simple as double-clicking on the .PPKG file. The person doing it will need local admin rights, but that’s all there is to it. When they double-click on the file, they’ll get what’s in Figure 8.11.

Manually Getting a Hardware ID into Autopilot

What we’ll do in this section is an excellent “walk before you run” with Autopilot. We’ll grab one machine’s hardware ID and put it into Autopilot.

We’ll use a PowerShell script running upon an existing, “up and running” Windows 10 machine (1703 or higher). The script outputs a CSV file that we’ll then have Autopilot consume.

Why would you want to do this with an “up and running” Windows 10 machine? Well, normally you wouldn’t. Remember, the core scenario of Autopilot is “you buy a bunch of machines from Dell or Lenovo and then ship them to your end users.”

But you’re going to need to pre-flight-test Autopilot so you know it’s working perfectly. So when you get the ID of a test system or two or three, you can then keep trying and retrying. Nuking the box, and restarting the out of box experience. Try and try again until you know you’ve got it right.

Then you’ll have it down to a science with your test machines, so that your real “bulk purchased” machines will correctly check in to Autopilot and get bootstrapped and get started with the experience I outlined earlier.

So this is going to be the best first steps and first experiences with Autopilot. But you would have to touch each machine in order to utilize this method, which is not handy…not at all. But don’t panic. In the next sections you’ll learn how to mass-gather device hardware IDs.

In this example, I’m using a machine with Windows 1809 on it that is not domain-joined, not enrolled in MDM. It just exists. And one I plan to blow away again and again, so it has nothing particularly useful on it. If you’re following along, for this chapter, I highly recommend bringing up a brand-new VM you’ve never registered into Intune before. In this way you won’t run into any problems where your hardware ID is already preassigned to some computer name in Azure and/or Intune.

Once your newly created test Windows 1809 machine is running, there’s a script we can leverage from the PowerShell gallery. You can get it the hard way directly from the PowerShell gallery at www.powershellgallery.com/packages/Get-WindowsAutopilotInfo/. Or, you can get it the easy way. Let’s go with the easy way.

To use it, start out by running an Admin PowerShell prompt. Then run:

Install-Script -name Get-WindowsAutopilotInfo

Say yes to any prompts (see Figure 8.15).

When done, you’re almost ready to use the script. You’ll need to tell Windows it’s A-OK to run scripts. Then run the script and save the hardware ID as a CSV file someplace handy.

Set-ExecutionPolicy Unrestricted

Get-WindowsAutopilotInfo -outputfile c:out1.csv

Then open the file with Notepad, as shown in Figure 8.16, to check it out.

Get this file over to your management station and keep it handy. In the next step, you’ll upload the CSV file into Autopilot (through the Intune console).

Uploading Your Device CSV File into Autopilot

Back in the screen shown in Figure 8.14, look for, and then click upon the Devices category.

Next you’ll be able to click Import and then feed it your CSV file. You can see this in Figure 8.17.

In this example I’m feeding one hardware ID, but you can feed it up to 175 IDs at a time. Then sit back and wait. This process takes a while to complete.

When done it will look similar to what’s seen in Figure 8.18.

You can come back here in a bit to verify that the hardware ID is A-OK.

In the meantime, you can continue onward and make your Intune Autopilot profile. Before I forget, here are some more resources about getting the hardware ID manually:

https://blogs.technet.microsoft.com/mniehaus/2017/12/12/gathering-windows-Autopilot-hardware-details-from-existing-machines/

https://docs.microsoft.com/en-us/windows/deployment/windows-Autopilot/add-devices#collecting-the-hardware-id-from-existing-devices-using-powershell

Edition Upgrade and S Mode Switch

You might be familiar with Windows 10 in S Mode. We talked about this ever-so-briefly in Chapter 1. Windows 10 in S mode is a way you can buy a machine that will be very secure (hence, the S) and only trust applications downloaded and purchased via the Windows Store, and not those attempted to be installed on the machine like a Win32 app.

This is great, until you run into some showstopper where, at least on some machines, it turns out you do need to have, say, Windows 10 Pro or Enterprise instead. This can happen if your application is absent from the Windows Store, or needs a driver to drive some kind of unusual hardware. As I stated in Chapter 1, a one-way upgrade path is possible from Windows S to Windows Pro or Enterprise.

And, you can do this with Intune to one or more machines.

You do this with an Edition Upgrade Profile, as seen here.

Then, you select the version (seen here) and give it a key (not shown).

Finally, you can specify to No Configuration, “Keep in S mode,” or Switch.

Note that the Windows S Mode switch only works for Windows 10 1809 and later.

Remember though, this really is a one-way trip. If you wish to go backward again to Windows 10 in S mode, you need to format the hard drive and reinstall Windows 10 in S mode.

For more information on edition upgrades and switching away from Windows 10 S mode, see https://docs.microsoft.com/en-us/intune/edition-upgrade-configure-windows-10.

Creating an Assigned Group for Autopilot

Creating an assigned group is the quickest way to get started.

But I recommend you read through this section and the next section, because ultimately you might want to just create and use dynamic groups.

If you want to create an assigned group, go back to the Azure Active Directory console and create an assigned group and pick one or more serial numbers, as seen in Figure 8.19. I’m calling my group Autopilot Assigned.

As you can see in Figure 8.19, you can assign and click upon very specific serial numbers, which adds them to a group. And then (a little later) you’ll associate this group to a profile.

Note that after the machine is used for Autopilot, magically the display of the machine will change from the serial number to the assigned computer name.

This tripped me up the first time.

So, if you don’t see serial numbers here after you uploaded the hardware IDs to Autopilot, chances are you already enrolled the system into Intune, and the amorphous blob in Autopilot (which has the computer’s serial number embedded within it) has already been converted into a real computer name. As a little side note, to be honest, discovering which computer names have come from what serial numbers is really, really hard. I expect this to change in the future.

Creating Dynamic Groups for Autopilot

Alternatively, you might want to just sweep 100% of Autopilot devices into one big ol’ group, to manage en masse. You likely don’t want to do this in the real world, but this is a good exercise to get you up and going right away.

To do this, you’ll use Azure AD groups and create a Dynamic Device group as seen in Figure 8.20.

The secret sauce to sweep all Autopilot devices in is:

(device.devicePhysicalIDs -any _ -contains "[ZTDId]")

In case you’re having a little trouble reading this, after the -any there’s a space, an underscore, another space, then the -contains.

You can see me use this dynamic query in Figure 8.20.

You can also have queries specific to the PurchaseOrder:

(device.devicePhysicalIds -any _ -eq "[PurchaseOrderID]:24601")

Same idea here with the syntax. After -any, add a space, an underscore then another space before the -eq.

You can also make a query which discovers computers by OrderID. OrderID is a generic field you can use for, say, expressing Sales machines versus Marketing machines versus Human Resources machines. If you decide to use the OrderID field, your query might be something like this:

(device.devicePhysicalIDs -any _ -eq "[OrderID]:Marketing")

Later on, if you follow all the examples in this chapter, you’ll be using this exact query in a different way; to automatically sweep in machines that will have no human interaction (also called self-deploying machines). So, stay tuned for that.

I made mention about the weird syntax in the preceding examples with the -any, the space, then an underscore, then another space before the -eq. The unusual syntax means to enumerate all the values for that property. The devicePhysicalIDs property is a multi-valued property and, as such, the unusual syntax.

A good blog entry on dynamic groups with Autopilot can be found at Using:

https://blogs.technet.microsoft.com/mniehaus/2018/06/13/Autopilot-profile-assignment-using-intune/

And, I also got a little help from the man himself, Michael Niehaus, to get this information. Thanks Michael!

Setting Up Enrollment Options and Setting Up Branding

At this point you can dictate more of the Autopilot user experience via the enrollment options and (optionally) the Azure AD branding.

Both of these hone and craft the look and feel and user experience when users kick off the OOBE. So let’s get these out of the way before we even attempt our first Autopilot dry run.

Setting Up Enrollment Options

In Intune you’ll want to express the look and feel of the user experience when the machine is getting all its brains downloaded from Autopilot.

To do this, click on the Device Enrollment ➢ Windows enrollment ➢ Enrollment Status Page.

Then click on the Default profile, which affects all users and devices. Note that you could create a new profile and be selective, but I’m not going to do that here.

In the Default profile, select Settings, as seen in Figure 8.24.

You can poke around here if you like, but for now, I would keep the defaults for your initial test flight. You can make it such that the machine waits for certain conditions to be true before releasing control to the end users to start working. Those options are seen in Figure 8.25, but again, I don’t recommend you turn them on right now.

Let’s take a look at some of the policies seen in Figure 8.25.

Block device use until all apps and profiles are installed When this item is selected, you get the remainder of the options. As expected, the entirety of all the applications and profiles must be downloaded before the machine is ready for the end user to use.

Note that any problems in downloading any applications at all could also hang up the installation.

Allow users to reset device if installation error occurs It might be a good idea to set this to Yes. In this way, a user can click the Reset button at the end of a failed OOBE and at least try again and maybe contact Autopilot and then the MDM service and succeed the second time.

Allow users to use device if installation error occurs You can get hard core and block the use of the Windows PC if any installation problems occur with this option set to No.

Block device use until these required apps are installed if they are assigned to the user/device This is a nifty feature you can use to guarantee that maybe one or two key applications are installed first on the machine and then control is released to the user. And then, later, in the background, the other nonessential applications are installed. This gets the user to work more quickly and defers the installation of lesser-used applications to a later time. You can learn more about this particular nuanced feature here:

https://blogs.technet.microsoft.com/mniehaus/2018/12/06/blocking-for-app-installation-using-enrollment-status-page/

There are some other settings here as well, but again, I suggest you use the defaults as seen in Figure 8.24.

Azure AD Branding for Autopilot

A completely optional step, which is neither Autopilot-nor Intune-related, is to update the branding of your Azure AD. But when you’re done in this area, users utilizing Autopilot will see a visual difference from the defaults.

We call this “the warm fuzzies” in the IT business. Users really like this stuff. They know they’re on the right track after they get the machine out of the box; it’s a gentle reminder they’re going to be alright.

To get to Azure AD branding, click Azure ➢ Azure Active Directory ➢ Company Branding. There are really two fields you might want to populate: the square logo field and the rectangular logo field. The square one can be seen in various areas, but it’s the rectangular logo field that you pretty much must populate. Self-deploy mode actually requires the rectangular logo! The square logo should be 240×240. The rectangular logo should be 280×60. Also, you might need to tweak and tinker with your logos to reduce the size. Use a tool like Paint.Net or GIMP or Snag-It to reduce the physical size and on-disk size to get these small enough to be accepted.

In Figure 8.26, you can see I’ve added a bunch of logos, square and rectangular. If I took a little more time, I could make it perfect, but for my purposes, these are good enough and we’ll see them later.

Additionally, beyond the use of branding for Autopilot, branding has a handful of other functions. For instance, from this point onward, when people go to log on to, say, the Azure portal (like Frank Rizzo), they’ll also see these graphics to let them know they’re on the right track.

A great and detailed blog entry about which branding elements will appear in Autopilot as well as other areas of Azure can be found at:

https://blogs.technet.microsoft.com/mniehaus/2017/12/22/windows-Autopilot-azure-ad-branding/

Final Preparation for Autopilot: Reset, Sysprep, or Reinstallation

At this point, you now have one hardware ID in Autopilot. You have set up an Assigned or Dynamic group and the Autopilot deployment profile. You’ve set up enrollment options and optional Azure AD branding.

Now you need to get a machine ripped down to the (almost) bare metal and start the out of box experience. There are three main ways to accomplish that goal:

• Sysprep a machine (not recommended; but we’ll go through it anyway).
• Reset a machine.
• Reinstall a machine.

Let’s explore all those options here.

Sysprep an Existing Machine

Now, you’ve likely used Sysprep before, but here are some quick notes:

• Sysprep can now be run 99 times before the whole Windows image needs to be replaced. So if you’re using a virtualized machine (say, VMware Workstation or Hyper-V), I recommend you take a snapshot before the Sysprep. Then tell Sysprep to perform a Shutdown option. Then take another snapshot when the machine is powered down. (Then you’ll be ready to test and retest Autopilot.)
• The Generalize flag seen in Figure 8.27 can be problematic. If you have any downloaded Windows Store apps, you have to uninstall them first before this will work.
• If Sysprep just doesn’t want to cooperate, then don’t spend an hour on it. Just move on. As I said, there are other ways to flatten a machine.

Some quick side notes if Sysprep just doesn’t want to work for you:

• Try rebooting the Windows 10 PC; then try Sysprep again.
• You can try the steps in this article, which is kind of like a Sysprep “mind erase.”

https://www.wintips.org/fix-sysprep-fatal-error-dwret-31-machine-invalid-state-couldnt-update-recorded-state/

Resetting the PC

You can use the “Reset this PC” feature in the Settings application to initiate a full PC reset. This takes longer than Sysprep, but you can do it an unlimited amount of times. You can see the button to kick this off in Figure 8.28.

Stepping through a Sample Autopilot Experience

The first three screens after the OOBE starts are not that interesting, and as of this writing, in user-deployed mode, you cannot turn them off. Those initial screens are as follows:

• Pick your region.
• Pick your keyboard layout.
• Pick your second keyboard layout.

Booooring. So I’m not going to show them.

The interesting stuff happens immediately after that where, if you’re paying close attention and can catch it, you’ll see a very, very brief “Connecting to Microsoft.” This is the Autopilot handshake. After that, a reboot occurs to provide the computer with its new name.

Then you’ll know you got it all right when you see a screen similar to Figure 8.29. You’ll see your company name and company logo (mine is super-duper small—sorry).

Then, give it the credentials for Jack Tors. As you’ll remember, he is not an admin, just a standard user. You’ll see Autopilot do its thing (Figure 8.30). If you’d like to also, you can expand the categories by clicking “Show details” and see some more details (Figure 8.31).

The final results of Autopilot are…a beautiful new Desktop:

• You should see your OneDrive data in place.
• You should see your deployed applications from Chapter 6, “Deploying Software and Scripts,” in place (like VLC Media Player).
• You should have your policies in place. For example, when you open Edge, you should have your desired tabs always open.

And, remember what happens if this machine needs to get reset?

It just gets reset and it’s back in business.

Note for fun that you may want to go back into Azure AD Groups and see that the groups you created, which originally only showed serial numbers instead of computer names, will now show the actual computer name, like Fabrikam7542.

Autopilot Resets: Local Reset and Remote Reset

The two Autopilot Reset types are local reset, and remote reset.

Both reset types have the same gist and provide the same benefits. Here are the basics of what occurs:

• All the apps, settings, and personal files are nuked. If it’s not on a network or external disk, it’s nuked.
• The Azure AD join and MDM enrollment are preserved and reused. In other words, when this process is over, you’re not going to see another phantom record in either AD or MDM.
• If you happened to apply a provisioning package using the Configuration Designer, those settings are maintained.
• Language and keyboard settings are maintained.
• Wi-Fi settings are maintained with any pre-known and stored passwords.

Local Autopilot Reset This doesn’t perform a full OOBE reset. What this will do is discard all the apps, and data. It will also preserve the MDM enrollment, Azure AD join, and the languages.

This is awesome in school scenarios where you just want to nuke a machine from the dirty work of those mischievous kids and return a machine back to a baseline.

Then it will connect back to MDM and get anything new to reload and or download.

But you might also want to walk up to a machine and perform this local reset. This is initiated by the keystroke Windows+Ctrl+R at the login screen, except that it won’t work unless it’s first enabled by MDM.

In Intune, you’ll find the setting called Automatic Redeployment under “Device restrictions” ➢ General, as seen here. (Don’t forget to associate a profile to a computer group.)

Then to try this out: At the login screen, press Windows+Ctrl+R. Then when you give it admin credentials (local or Azure), as seen in Figure 8.36, the machine will immediately start to reset.

Remote Autopilot Reset Another choice is to nuke a machine, or multiple machines from your cozy console, all from afar using the Internet.

Just for a moment, you can feel like Dr. Evil.

So, how do you do it? Use Intune’s Devices ➢ “All devices” and click on the device. Select More and then find Autopilot Reset as seen noted with (1) in Figure 8.37.

Note that Autopilot Reset requires Windows 1809 or later; if you see this option grayed out, that means the machine is not likely Windows 1809 or later.

When you remotely reset a PC, you’ll get a notification that’s it been initiated, like this:

Then, on the endpoint, the end user will get a message like this:

The machine will restart in 45 minutes and be totally reset again and rejoin Autopilot.

The end user doesn’t get the out of box experience (OOBE); it’s just ready to go because it maintains its MDM enrollment.

Then when the machine is done, end users see the normal login page. But before you press Ctrl+Alt+Del, in verrrrry small letters, you’ll see “Success! Windows is set up and ready to go.” If you squint, you’ll see what’s seen here.

Retiring a PC

The Retire button can be seen in Figure 8.37 noted with (2).

Retiring a PC basically removes it from Intune. This doesn’t perform a wipe of the PC. You just won’t see it in Intune anymore because you’re not managing it anymore. Any MDM policies on the machine are removed; some settings will peel back, others may stick. Software that is on the machine will usually stick around. The user’s personal data that is stored on the device is maintained.

Wiping a PC (Previously Known as Factory Reset)

The Wipe button can be seen in Figure 8.37 noted with (3).

The MDM Wipe feature has two methods: Retain enrollment state and user account…nor not. I’ll call this Wipe + Retain and Wipe-Retain to keep it simple.

In both cases the wipe will remove user accounts, user data, user-installed apps, and OEM-installed apps and reset the operating system to the default.

Wipe + Retain will maintain Intune enrollment.

Wipe-Retain will remove Intune enrollment (but it could be reenrolled if the device’s hardware ID is in Autopilot).

The docs on this function are at https://docs.microsoft.com/en-us/intune/devices-wipe.

MDM Fresh Start (aka Clean PC)

The Fresh Start button can be seen in Figure 8.37 noted with (4).

This is a way to mini-nuke a machine, but not fully. You can see Fresh Start in Intune’s Devices ➢ “All devices.”

Fresh Start (also known as Clean PC) will remove any Win32 or UWP applications on the machine and upgrade them to the latest version of Windows. The device can be told to preserve (or nuke) the user’s data.

And, if you choose not to preserve the user’s data, you’re actually un-enrolling it from Azure AD and your MDM service as well, so be careful using this feature.

Only if the device is established in Autopilot will it magically reconnect and still be managed by MDM.

When you log back in, you can see an HTML document on the Desktop called “Removed apps,” which express which applications were in fact, cleaned off.

A good blog entry with a lot of nice screenshots about Clean PC can be found at

https://osddeployment.dk/2017/05/13/windows-10-1703-cleanpc-csp-with-intune-1704/

If your head is spinning from all the options, please take a look at Table 8.1. That said, it’s good to pre-try your Wipe, Reset, or Fresh Start option and make sure you get the expected result in the test lab, before your real emergency is nipping at your heels.

Preparing for Autopilot Self-Deploy Devices

In the real world, you would likely buy a gaggle of machines and then have them shipped where you need for them to be. And as I explained in the section “Creating Dynamic Groups for Autopilot,” hardware IDs can be associated with an order ID, which in turn you can use as a generic tag for similar devices (Sales machines, Marketing machines, and so on).

Additionally, when you buy machines from Dell or Lenovo, and so on, you could get the OrderID (or the PurchaseOrderID) fields pre-populated.

Well, for this test, you won’t be ordering anything, but you will pretend to buy and deploy a machine where the OrderID field is pre-populated. The OrderID will be like a tag we use to know, “Okay, these machines are all our self-deploy machines.”

To do this, you’ll need to acquire the hardware ID and get it into CSV format as we did earlier in the section “Manually Getting a Hardware ID into Autopilot.” Then, before you upload to Autopilot, I want to show you how to add an OrderID as if you were buying 100 of these systems with the OrderID pre-populated.

If you look at the CSV file for this machine, you’ll see the following items (which represent columns):

Device Serial Number,Windows Product ID,Hardware Hash

I want you to add a column so it looks like this instead:

Device Serial Number,Windows Product ID,Hardware Hash,OrderID

Then, at the very end of the CSV file, add in a comma and enter in a bogus OrderID. In my example, I just put in ORDER1.

Then I uploaded the file to Autopilot. The result can be seen in Figure 8.41. Note that this screen shot shows a virtual machine’s ID uploaded, which won’t work in real life. So remember, Autopilot self-deploying mode only works for real machines.

Next stop is to create a dynamic membership rule to sweep in all the machines with the ORDER1 tag into one place. The advanced dynamic membership rule would be this, and it’s seen in Figure 8.42. I’ve called my group “Self Deploy Dynamic Group.”

(device.devicePhysicalIds -any _ -eq "[OrderID]:Order1")

Next stop is to create a profile, similar to what we did earlier. This time though, we’ll specify the deployment mode as Self-Deploying, as seen in Figure 8.43.

The settings of the profile are reasonably self-explanatory and can be seen in Figure 8.44. Of course, you want this to be as optimal as possible, pre-answering all the questions you can, as seen in Figure 8.44.

Next, you’ll assign the profile to the group you created just before, as shown in Figure 8.45. This then marries the Autopilot profile to the Self Deploy Dynamic Group.

One more thing: You don’t want the general “catchall” Autopilot profile we created in the first part of the chapter to collide with the self-deploying profile for these specialized machines. As such, you can (and should) go back into your original Autopilot profile (which was called All Devices - Assignments) and exclude your newly created dynamic group.

In Figure 8.46, you can see the first Autopilot profile, and where I’ve clicked on the Exclude tab and selected Self Deploy Dynamic Group, thus keeping the user-driven and the self-deploy worlds separate.

Testing Self-Deploying Autopilot Devices

Testing a device like this is similar to the testing we did earlier. You’ll need to nuke the machine via reset, Sysprep, reinstall, or maybe you took a snapshot before OOBE started.

When OOBE starts, you’ll see something like the screen in Figure 8.47.

And with that, you’ve accomplished the goal: A device self-enrolling device to Autopilot.

Remember, if you get 95% of the way through, and this catches fire, chances are there is some problem with the TPM 2.0 chip (not ready, not initialized, and so on).

Remember again, the machine you’re testing on might not have the “right” TPM chips at all. Many, many devices are using TPM 1.2 chips. And those are simply the wrong kind and won’t work. And what’s more, just because a chip is labeled as a TPM 2.0 chip doesn’t mean it performs the attestation part of the equation, which is necessary for the handshake to occur. When I tested this on a few laptops with TPM 2.0 chips, I got 95% through with the process only to realize the laptops didn’t have the right kind of TPM 2.0 chips. The attestation simply didn’t work as expected. Frustrating! If you get this far, and it’s not working, again, try to flash-upgrade your TPM chip to get it to support attestation. In these cases, go back to the screen in Figure 8.40 on an example machine and reinspect: Do I have TPM 2.0? Does it support attestation? Am I using a real machine and not a VM?

The official docs on Autopilot with self-deploy devices are at:

https://docs.microsoft.com/en-us/windows/deployment/windows-Autopilot/self-deploying

And a good blog is found at:

https://www.petervanderwoude.nl/post/windows-Autopilot-self-deploying-mode/

Bonus Points: Making Self-Deploying Kiosk Machines

So having machines that self-deploy is pretty nifty. But it’s what you do with it that counts.

Two good options for self-deploying kiosk machines would be:

• Anything that uses a webpage (airline display at the airport, stock ticker, etc.)
• A specific application you want to lock users into using

If you’re going to use a web page, you want to use what’s called Edge Kiosk mode. This is a pretty involved topic that has a lot of particulars and options. It’s just too many pages, so you’ll have to check this out yourself here:

https://docs.microsoft.com/en-us/microsoft-edge/deploy/microsoft-edge-kiosk-mode-deploy#use-microsoft-intune-or-other-mdm-service

The second option I mentioned would be to use an application from the Windows Store. Well, not the Windows Consumer Store, no no. You’ll have to pre-stage that app in your Windows Store for Business as we did back in Chapter 6.

In a moment, I’ll give you a URL for the lash-up of how to do that. But note that this blog entry is a bit out-of-date. It recommends using the Kiosk browser application, which is downloadable from the Consumer Windows store (and, of course, which you could then stage in your Windows Store for Business).

But there’s another choice as well.

As I said two paragraphs ago, Edge (now) comes with its own Kiosk modes, which opens up some enhanced scenarios like multi-tab, printing, and more. It’s somewhat more complicated to set up than the Kiosk browser application found in the Windows Store.

But if you wanted to set up a simple web page to show on your kiosk, the Kiosk browser application still works and is a perfectly fine choice.

So, if you want to, you can follow these directions and pick…well, any application from the Windows Consumer Store and get it into your Windows Store for Business, then tell that self-deploying machine to run that Windows app. Here’s some handy URLs:

https://blogs.technet.microsoft.com/mniehaus/2018/06/07/deploying-a-kiosk-using-windows-Autopilot/

https://docs.microsoft.com/en-us/microsoft-edge/deploy/microsoft-edge-kiosk-mode-deploy

https://www.petervanderwoude.nl/post/single-full-screen-kiosk-browser-app-in-kiosk-mode/

Additionally, a good speech on this topic can be found at YouTube by searching for BRK3016 for a talk titled, “Shared Devices for Kiosk and Firstline workers (with Windows 10 and Intune)” and THR3003 for a talk entitled “Specialized device deployments for Windows 10 with Microsoft Intune.”

What Is an ODJ Blob?

How can you join a machine if the machine isn’t connected (right now) to the LAN such that the computer can be joined by a technicion?

The truth is, you can’t. But you can do the next best thing.

So this idea has existed for a long time in on-prem AD-land (since Windows 7 to be precise) and it’s called Offline Doman Join, or ODJ for short.

With ODJ you can create a reservation for a computer in Active Directory. Then you can tell a computer to consume that reservation.

It’s easy to try yourself, just to get the hang of what’s about to go on automtically in a few minutes when we add Intune to the mix. On any AD-joined machine at all, run the following command to reserve the space for the “not yet joined” computer named testjoin01:

djoin /provision /domain fabrikam.com /machine testjoin01 /savefile provision.txt

This is the output file, provision.txt, which is technically known as an ODJ blob, and you can just check it out in Notepad. You can see the command and the file in Figure 8.49.

Then go over to a machine that is not domain-joined but is on the same network as your Active Directory. And, of course, get your ODJ blob file over there. Then, using an elevated command prompt, let’s claim the reservation. Use the following command:

djoin /requestodj /loadfile provision.txt /windowspath c:windows /localos

You can see the command run in Figure 8.50.

After the client reboots, the first time the client can make contact to on-prem Active Directory, they sync up and magic happens: The machine is now really domain-joined.

The full docs on Offline Domain Join can be found here (but you won’t really need them for what we’re going to do):

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd392267(v=ws.10)

The takeaway here is that Intune is going to do all the hard work to make the reservation and the ODJ blob for you, then download it and apply it on a target machine, thus joining a computer to Active Directory automatically.

But there is a catch with Intune. Hang tight for the reveal in a moment.

Preparing Active Directory for Hybrid Azure AD Join

There’s a little pregame setup involved in Hybrid Azure AD Join.

One of the optional steps in Chapter 2 was to set up AAD synchronization using the Azure AD Connect tool. If you didn’t do this, and want to get your on-prem AD married to your Azure AD, then you can flip back to Chapter 2 and see the section titled “Syncing Your On-Prem AD to Azure AD Automatically.”

Then, after that, you need to first tell your on-prem Active Directory that it’s A-OK for some computer on your network to add other computers to your domain.

Your on-prem Active Directory doesn’t usually work like that; people usually do the joining of computers to your Active Directory. But you can gently explain to Active Directory that, yes, it really is okay for another computer to create computer records and do the joining of other computers.

Really Active Directory, it’s going to be okay.

To teach Active Directory about this, you’ll delegate the ability to create computer objects as well as manage their properties and permissions. In most Active Directories, the place where new computers magically show up when joined is the Computers container (and yes, I did mean container…it is not an OU).

This is typically where you’d start your delegation. It is possible that this is not your default location (this is changeable via the old and crusty (but it still works) command redircmp). If you’re unsure if the Computers folder is where computers appear when you join one to Active Directory, then just join one. Then find it. Once you know your default location, right-click over it and select Delegate Control as seen in Figure 8.51.

Then once inside the Delegation of Control Wizard, you need to change the view such that it lets you look for computers. (Again, this is unusual for Active Directory, so the default is that it doesn’t show you computers.) In the screen shown in Figure 8.52, you’ll click Object Types and then click to check on Computers.

Then, as seen in Figure 8.53, search for the computer name where you plan to install the Intune Connector for Active Directory. This can be a Domain Controller or member server within Active Directory. I’m picking my DC.

Then, in the Delegation of Control Wizard, select “Computer objects” as seen in Figure 8.54 along with “Create selected objects in this folder” and “Delete selected objects in this folder” and click Next.

Last, you’ll specify that the computer can manipulate the Permissions. In the next page of the wizard, select Full Control as seen in Figure 8.55. This will automatically check every other box.

The final page is a review from the wizard. Click Finish and you’re all set.

Installing the Intune Connector for Active Directory

Now, let’s flip back to Intune. This is where you’re going to find and then download the Intune Connector for Active Directory. Head over to Intune ➢ Device Enrollment ➢ Windows Enrollment ➢ Intune Connector for Active Directory. Then click the link in Step 2 as seen in Figure 8.56.

Back on your on-prem server, it’s time to install it. You can do this upon a DC or a member server. It’s a simple MSI and doesn’t take very long. You can see the MSI and opening screen in Figure 8.57.

After clicking through the installation, you should see an “Installation Successfully Completed” message (not shown) and a “Configure now” button (also not shown). Also, if needed there is a Start Menu item if you need to re-access it.

Simply click the Sign In button (seen in Figure 8.58), and then give it the credentials for the main Global Azure Administrator, Frank Rizzo (who also needs an Intune license for this to work). When it’s all done, you should see what’s seen in Figure 8.58.

At this point we’re almost ready to try this out.

Verifying the Installation of the Intune Connector for Active Directory

Once you’ve installed the Intune Connector, as we just did, you can take a moment to look inside Windows’s Services and see that it’s present and running. It’s called the Intune ODJConnector Service and can be seen in Figure 8.59.

You can also see logs for the ODJConnector Service on this same machine. You would look in Windows’s Event Viewer ➢ Applications and Services Logs then ODJ Connector Service as seen in Figure 8.60.

You can see interesting event logs from the ODJ Connector Service, like the one in Figure 8.61, in case you need to do any troubleshooting.

Finally, back in Intune, you should (eventually) see the computer you’re using notated as performing a sync, as seen in Figure 8.62. This took about 10 minutes for me, and the Refresh button didn’t actually refresh it for me. I had to press F5 to refresh to the actual page.

Note that you can have multiple connectors if you anticipate a huge onslaught of computers attempting to do this. For instance, if you were doing a company-wide refresh and expected everyone to get new computers within the same few days, you might want multiple connectors to shoulder the load. Note that at this time, there’s no way to delete a connector. You would simply uninstall the on-prem component you installed a little earlier, and the Intune Connector pane will realize the sync time has not updated and will stop attempting to use the connector.

Create and Use an Autopilot Hybrid AD Join Profile

Next, you’ll create a Windows Autopilot profile specifically for machines for which you wish to perform an MDM enrollment and the on-prem Active Directory join. In Intune ➢ Device Enrollment ➢ Windows Enrollment ➢ Windows Autopilot deployment profiles, you’ll create a new profile. Then, as shown in Figure 8.63, you’ll select User-Driven and “Hybrid Azure AD joined.”

A little warning about the field “Apply computer name template,” which is seen grayed out in Figure 8.63. It’s possible to save, then come back to this field and try to use this to auto-name the computer. Do not attempt to use it. There’s another place for that, which is right around the corner, in the Domain Join profile.

Create and Use a Domain Join Device Profile

Creating the Autopilot piece of the profile is only a part of it.

There’s a second part. It’s called the Domain Join profile. This is back in Intune’s device configuration, something you’ve done a few times now. Head over to Intune ➢ Device Configuration ➢ Profiles and then “Create profile.”

Put in a name of your choice, like Offline Domain Join Policy, and for Platform, pick “Windows 10 and later,” and finally, select Domain Join in “Profile type,” as shown in Figure 8.64.

Next you’ll have to click the Settings category (see Figure 8.64), and the resultant window is shown in Figure 8.65. The settings express the Computer name prefix (I’ve picked DJPP-, meaning Domain-Joined Plus Plus) and the on-prem AD domain name, Fabrikam.com.

I’m leaving “Organizational unit” blank because I’m using the Computers folder as the drop-in point after they join on-prem AD.

And with that, you’re ready to test!

Performing Your Hybrid AD Join

So, earlier I said there was a catch to using the ODJ blobs with Intune.

The catch is that the machine must actually be available with “line of sight” connectivity to a Domain Controller to complete the ODJ blob to Active Directory handshake. If that Windows 10 machine cannot see the DC, the handshake doesn’t happen, and the Autopilot process doesn’t complete.

So practically this cannot be done just “over the air,” say at Starbucks or via VPN connection (because there isn’t one yet). If I had to guess, this might be something that I could foresee changing in the future, but that’s not the story as I write this.

So before you start your test, be sure your machine has access to the Internet (for Intune enrollment) and to the DC for Active Directory joining. Before you roll back your snapshot, reset the machine, or reinstall Windows, you can do two itty-bitty little tests to give yourself the best chance of this working.

• Test 1: Ping the DC by NETBIOS and fully qualified DNS names.
• Test 2: Map a share (net use) from the Windows client to Domain Controller (and also to the machine running the Intune connector).

By testing the connectivity on your test system, you’re ensuring that you really do have line of sight from your endpoint to the DC.

Okay. Now if you created a snapshot of your Autopilot machine before it started OOBE, then reset to that or otherwise nuke the machine such that OOBE is restarted.

OOBE will start, and you will give it credentials like [email protected], one of your on-prem accounts that is auto synchronized to Azure AD.

When you do, it won’t look a lot different than usual, but if you interact with the setup page, you can see what’s in Figure 8.66.

The next time you start the machine, you should be able to log on as any Active Directory user (like EastSalesUser1) but not any “only born in the cloud” Azure Active Directory user (like Jack Tors). The usual screen can be seen in Figure 8.67.

At this point your computer will go through some gyrations getting set up and trying to make connection to your MDM service to enroll.

The computer then downloads any new policies and software from MDM, as you’ve seen before. Then, you have a happy full Desktop as you expect for EastSalesUser1.

Back in on-prem AD, you should see your computer show up in the Computers folder, as seen in Figure 8.68.

Troubleshooting Hybrid AD Join

There are a handful of problems you may encounter when performing the Hybrid AD Join. The number one problem you’re most likely to encounter is that the endpoint cannot reach a Domain Controller to perform the final handshake.

Again: The endpoint computer needs “line of sight” connectivity to a Domain Controller—right now, right during OOBE. It cannot happen later.

When this occurs, the machine keeps trying for about 30 minutes, and then you’ll see an 80070774 message like the one in Figure 8.69.

I also got the 80070774 when I failed to realize I needed a device configuration profile; I thought just having the Autopilot profile was enough. It isn’t. So make sure you have both.

The other common occurrence is that the machine is already MDM enrolled. When this happens, you’ll see a similar, but different error message, like the one in Figure 8.70.

If you want to check out the docs on Windows Autopilot Hybrid AD Join, the official docs can be found at:

https://docs.microsoft.com/en-us/intune/windows-Autopilot-hybrid

And the blog from the man himself can be found at:

https://blogs.technet.microsoft.com/mniehaus/2018/11/22/trying-out-windows-Autopilot-user-driven-hybrid-azure-ad-join/

A good third-party MVP post on this subject can be found at:

https://www.petervanderwoude.nl/post/hybrid-azure-ad-join-with-windows-Autopilot/

Final Thoughts on Hybrid AD Join

You might think that someone like Jack Tors, who is born “only in the cloud,” could magically use the machine we just utilized with the Hybrid AD Join.

But that’s not how it works.

Devices can only be joined to one or the other: either to Active Directory or Azure Active Directory.

If the computer is joined to Active Directory, the device can also register with Azure AD to get that Hybrid Azure AD Join state. Again, this happens via the Azure AD Connect you set up in Chapter 2. When using a hybrid AD-joined computer, a user still always signs on with their on-prem AD credentials. And when they do, they will simply also get their on-prem Kerberos token plus an Azure AD token. The Azure AD token enables single sign-on to AAD-protected resources and additional benefits.

Conversely, if the computer is joined strictly to Azure Active Directory (and not to on-prem Active Directory), the user must sign in with cloud-only Azure AD credentials and can thus access cloud-based resources. But if Windows sees that there is an AD Domain Controller available, my understanding is that it also gets a Kerberos ticket, which it can use to access on-prem resources.

So, the summary here is as follows:

• AD-joined computers can access on-prem resources but still get access to cloud resources.
• AAD-joined computers can naturally access cloud services but still get to on-prem resources.

Amazing how that works.

If you want to read more about this magic trick, here are the write-ups for that:

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

https://blogs.technet.microsoft.com/mniehaus/2018/01/19/afraid-of-windows-10-with-azure-ad-join-try-it-out-part-1/

https://blogs.technet.microsoft.com/mniehaus/2018/02/21/afraid-of-windows-10-with-azure-ad-join-try-it-out-part-2/

Final Autopilot Resources

Clearly Microsoft is investing a lot in Autopilot. It’s a big, big deal and a nice game changer and articulates a bunch of scenarios that cannot be done with on-prem infrastructure alone.

If you want to see some of this in action, let me recommend some videos. An awesome two-part talk on Autopilot was at Ignite 2018. Go to YouTube and watch BRK3014 and BRK3015.

Autopilot may be a moving target for the next few years. That said, here’s what I plan to do to keep up-to-date on Autopilot.

The documentation is found here:

https://docs.microsoft.com/en-us/intune/enrollment-Autopilot

But for generally staying up-to-date in Autopilot happenings, I recommend subscribing to Mike Niehaus’s blog, which has an RSS feed (if you’re into that sort of thing).

https://blogs.technet.microsoft.com/mniehaus/

And, of course, I’ll keep you up-to-date as fast as I can at MDMandGPanswers.com.

Now that you made it all the way through this chapter, tweet me @jeremymoskowitz and let me know what you learned in Chapter 8 with hastag #mdmbook. Thanks !