With Windows 10 1809 now available, we’ve added new scenarios to Windows Autopilot.  You can read about them in the announcement blogs:

• Windows Autopilot: What’s new and what’s next (overview)
• Deploying a kiosk using Windows Autopilot (details on self-deploying mode)
• Upgrade Windows 7 using Windows Autopilot in Configuration Manager (details on Windows Autopilot for existing devices)
• Speeding up Windows Autopilot for existing devices (more on Windows Autopilot for existing devices)
• Windows Autopilot: Hybrid Azure AD join and automatic registration

I wanted to dive a little deeper into the user-driven scenario for Hybrid Azure AD Join, the last link above.  To summarize that blog:

• You need to set up/install the Offline Domain Join connector on a server on your internal network.  (It makes an outbound connection to the Intune service, waiting for the service to send it requests to create device objects in Active Directory.)
• The device must be on the corporate network (no support for VPNs).  We need line of sight to a domain controller for the user to sign in to Active Directory, to apply GPOs, etc.
• You need to create and assign a new user-driven Hybrid Azure AD Join Autopilot profile.
• You need to create and assign a new Domain Join (Preview) device configuration profile that specifies the domain name, OU, and computer name prefix to use.  (These settings are not part of the Autopilot profile, so you could have different device configuration profiles, e.g. for different OUs, targeting different device groups, with one overall Autopilot profile.
• You need to enable the enrollment status page (ESP for short, more on that later).

Let’s take a look at what the end-to-end process ends up looking like with this time-compressed video:

Let’s review the steps that this goes through:

• The device boots up and connects to the network.  (This is a VM with an Ethernet connection, so it connects right away.)
• It downloads the Autopilot profile.
• It asks for Azure AD credentials (0:00:54), which are used to enroll the device in Intune.  (The device does not join Azure AD.)
• The device enrolls in Intune.  Using the “Domain Join” device configuration profile settings, the device will request an Offline Domain Join blob from Intune.  Intune passes this request to the Offline Domain Join connector service (running on a device on your internal network) and gets back the ODJ blob.  That blob is passed back to the client PC.
• The client PC applies the ODJ blob and then reboots to complete the Active Directory join process (0:01:45).  (The computer won’t reboot if it can’t find a domain controller.  Instead, you would see a “Something went wrong” screen with error 0x80070774.)
• After the reboot, the enrollment status page (ESP) will be shown to process the device configuration (apps, settings, etc.).  (You don’t see this in my video because I didn’t have anything to wait on.)
• Now, the user will be asked to sign in again (0:02:00), but this time using their Active Directory credentials.  Notice that I type in the same account (anna@contosocm.com) and password that I did for the initial AAD sign-in, which makes sense:  Both accounts have the same UPN and are synchronized using AAD Connect.  (In my case, I am using passthrough authentication.)  You could specify DOMAIN\USER instead (e.g. CONTOSO\Anna) in this case (but not for AAD).
• The AD account signs on, goes through the first sign-on experience (pulsing blue screens), and then sees the desktop (0:02:19).  Notice that the enrollment status page (ESP) isn’t displayed for the user (again, more on that later).

The whole process would have taken 20-25 minutes without editing the video (longer if you had more configuration to apply and apps to install).

The Offline Domain Join process

Now, let’s talk a little about the offline domain join process.  For those that aren’t familiar with that, it was introduced years ago (with Windows Server 2008 R2 I believe) to join devices to Active Directory without the device needing to talk to an Active Directory domain controller.  You could create these offline domain join blobs using DJOIN.EXE, then tell Windows to use them via an unattend.xml or other methods.  Not surprisingly, there are also APIs available to do the same thing, which is what Intune is using to request the ODJ blob from AD, and what the Windows 10 client is using to apply that blob to the computer.

The Offline Domain Join Connector, provided by Intune, runs on a server on the internal network, where it can talk to the domain controller using the same APIs previously mentioned.  Those APIs actually create an account in Active Directory, either in the OU you specified or in the default OU for the domain (or the Computers container if you haven’t configured a default).  In order for that to work, you have to grant the computer account rights to create objects in the OU or container that you specified.  The service, named “Intune ODJConnector Service," runs as SYSTEM, hence the need to grant the computer account (e.g. SERVERNAME$) access to create objects.

To see what the ODJ Connector service is up to you can check the event log at “Application and Services Logs –> ODJ Connector Service”.  You’ll see two events created every minute with event IDs 30121 and 30150; ignore those because they aren’t useful.  (You might want to make that event log bigger, maybe by a factor of 100, so those not-useful events don’t push out the useful ones.)  Look for event ID 30130 or 30140 to see each request that it processes, including the name that was assigned to each computer that was added to AD:

To filter out those every-minute events, you can also specify an event filter that specifies “-30121,-30150” and you’ll be left with only the more interesting events.

If by chance you don’t target the device with a Domain Join device configuration profile, the offline domain join will fail because the device won’t know what domain to join, obviously.  But the error that you will see is a little less obvious, as it will try for about 25 minutes before failing with a “Something went wrong” error screen with an error 0x80070774, which translates to network error 1908, “Could not find the domain controller for this domain.”  (Technically, the offline domain join doesn’t require connectivity to the corporate network, but since after the reboot the user will need to sign in with Active Directory credentials, it won’t let the machine reboot if it can’t talk to a DC.  So you could see that same 0x80070774 error when a proper Domain Join profile is received but a DC can’t be located.)

The Device ESP process

As I mentioned previously, the computer will reboot to complete the offline domain join process.  After the reboot, it should display the enrollment status page (if enabled – highly recommended) to complete the device configuration.  Once that is complete, the user should be asked to sign on.

The user sign-on

After the device enrollment status page (ESP) completes, you’ll see the lock screen.  The process isn’t really complete yet because no user policies from Intune have been applied yet.  Ideally, these would be applied immediately after the user signs in with their Active Directory credentials.  (Remember, this is an AD-joined device, so the user is putting in AD credentials to be verified by a domain controller, hence the “on the corporate network” requirement.)

But I hinted before that there was more to know about the ESP.  More specifically, the user ESP won’t work – it will typically time out waiting for policies to be received.  But why does that happen?  Well, this goes back to the Hybrid Azure AD Join process.  The device is initially joined to Active Directory, but not yet registered with Azure AD.  That registration process (tied to AAD Connect) could take some time, maybe 30 minutes.  Until that happens, the user can’t get an Azure AD token, and without that Azure AD token it can’t authenticate to Intune so it can’t get any user-targeted policies.  So the ESP could time out, or just sit there for a very long time waiting for that stuff to happen in the background.

Since most users would rather get to the desktop to at least be somewhat productive with the device, it is possible to disable the user ESP, while leaving the device ESP enabled.  To do this via Intune, you do need to use a custom OMA-URI policy, as that setting isn’t exposed otherwise.  To do that, create a device configuration profile in Intune, specifying Windows 10 and above and a type of “Custom.”  You can give the profile a name (e.g. “Disable user ESP”), and then add one custom OMA-URI setting:

• Name:  SkipUserStatusPage (or whatever you want)
• Description:  (whatever you want)
• OMA-URI:  ./Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage
• Data type:  Boolean
• Value:  True

That ends up looking like this:

And that’s it.  Let us know if you have any burning questions, have suggestions for improvements, or are running into any issues.  Also be sure to check out the documentation links:

Windows Autopilot user-driven mode for hybrid Azure Active Directory join

Deploy hybrid Azure AD joined devices using Intune and Windows Autopilot (Preview)

When you do an Autopilot deployment, we recommend configuring the Enrollment Status Page (ESP) to block until those app installations are done – the user won’t be able to get to the desktop until the device is configured so that they can be secure and productive.

But we recognize that some apps are more important than others.  So we’ve added a new feature in Intune that allows you to select which apps should block and which ones shouldn’t.  See the new setting at the bottom of the list of available ESP settings:

Change from “All” to “Selected” and then you can select the list by clicking the “Select apps” button and choosing the ones you want:

which will be displayed on the ESP settings page once you have made your selections and clicked “Select”:

It’s also worth noting that we recently made changes so that Office 365 ProPlus is tracked during the ESP as well.  If you want Office to be tracked, then you might need to increase your ESP timeout values to account for the increased time.  If you don’t want Office to be tracked, make sure it’s not in the blocking list.  See https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Support-Tip-Office-C2R-installation-is-now-tracked-during-ESP/ba-p/295514 for more information.

Back in October, I posted a blog talking about speeding up Windows Autopilot for existing devices, with a custom task sequence template to avoid the extra sysprep generalize and specialize that happens with the default ConfigMgr task sequence template for Windows Autopilot for existing devices (now built into ConfigMgr current branch).  Based on feedback from Sandy, I modified that example (attached below and updated on the original blog as well) to remove the final “Restart computer” step as it’s not necessary.

One of the steps you should make sure to perform after performing an Windows Autopilot for existing devices deployment is to get the device registered with Autopilot.  To do that, make sure you follow these steps:

• Create a dynamic group that specifies the ZtdCorrelationId as part of the query.  For example, my AutopilotConfigurationFile.json contains this line:

  "ZtdCorrelationId":  "55be23da-e32a-468e-a1b1-fe1833fc9b63"

  So the dynamic membership rule in Azure AD specifies that as part of the enrollment profile name:

• Make sure the Autopilot profile that you used to create the JSON file specifies to “Convert all targeted devices to Autopilot”:

• Make sure that same Autopilot profile is assigned to the dynamic group that you created in the first step, so that each deployed device gets the right profile assigned.

If you initially tried to use the ZtdCorrelationId in a dynamic group membership rule and you noticed that it didn’t work, give it another try – some additional Intune changes were needed to support that, and those weren’t in place before early December.  Now, the full “OfflineAutopilotProfile-55be23da-e32a-468e-a1b1-fe1833fc9b63” value should be populated.

While testing this, the usefulness of that ZtdCorrelationId became clearer to me.  If you looked at the JSON files being generated by the WindowsAutopilotIntune module, you might have noticed that it used a hard-coded GUID.  So if you didn’t manually change that, every device deployed by every customer ended up with the same OfflineAutopilotProfile value.  That’s harmless, but not terribly useful.  So I published a new version of the module (2.5) that sets the ZtdCorrelationId to the ID (GUID) of the Autopilot profile in Intune.  That way, there’s a 1:1 correlation between the Autopilot profile and the ZtdCorrelationId, which makes the above process (assigning a profile to all the devices in a dynamic group that uses the ZtdCorrelationId) work well.  So grab the updated copy and generate an updated JSON file (or at least copy in the new ID value).

Attachment:  AutopilotExistingDevices_Fast_v2

Whether you are evaluating Windows Autopilot for the first time, testing out new features and capabilities, or demoing it to new customers, you’re typically going through the same basic steps:

• Getting the hardware hash from an existing machine.  See https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/add-devices#collecting-the-hardware-id-from-existing-devices-using-powershell for the steps to do this using the Get-WindowsAutopilotInfo script.
• Uploading the device to Intune to register it with Windows Autopilot.  See https://docs.microsoft.com/en-us/intune/enrollment-autopilot#add-devices for the steps to do this (and yes, the import process via Intune is slow, sorry).
• Ensuring the device is in a group that has an Autopilot profile assigned to it, so Intune will automatically assign a profile to it.  See https://docs.microsoft.com/en-us/intune/enrollment-autopilot#assign-an-autopilot-deployment-profile-to-a-device-group for that.

Harvesting and Registering

Let’s dig in a little deeper to make sure you understand the intricacies, first with harvesting the hardware hash.  I typically do this with these steps:

• Boot up the device to the beginning of OOBE.
• Press Shift-F10 to open a command prompt.
• Run the Get-WindowsAutopilotInfo script (start PowerShell, set the execution policy to bypass, install the script or get it from somewhere [USB, network]) and copy off the resulting CSV file.
• Exit from the command prompt.
• Register the device with Windows Autopilot via Intune.

It’s important to understand the Windows Autopilot behavior for different Windows 10 releases, as those behaviors can cause frustration if you don’t understand them:

• With Windows 10 1703 and 1709, you can boot a machine up and be assured that it won’t try to talk to the Autopilot deployment service until you get further into OOBE, to the network connection screen (if wireless – if you have a wired Ethernet connection, you won’t see that screen, but rest assured Autopilot won’t talk until you get past where the screen would have been).
• With Windows 10 1803 and above, the OS will try to talk to the Autopilot deployment service as soon as it can.  If you have a wired connection, that means within seconds of OOBE starting (as soon as it has an IP address).  If you are using wireless, then the behavior will be the same as the earlier Windows 10 releases.

OK, so why does that matter?  It’s a matter of timing: If the device talks to the Autopilot deployment service *before* it has been defined to Autopilot (before you’ve uploaded the CSV), it will download settings that say “this is not an Autopilot device” – after it’s done that, it will always go through the standard consumer OOBE flow, not the Autopilot process.

Think about what would happen on Windows 10 1803 if you had a VM with an Ethernet connection, and you booted it up to harvest the hash.  Even before you grabbed the CSV, the OS would already have received the “this is not an Autopilot device” setting.  And if you had a wireless device and continued forward to establish a Wi-fi connection (e.g. so that you could install the Get-WindowsAutopilotInfo script from the internet), the same thing would happen.

So how do you get Windows to “forget” this “not an Autopilot device” setting?  As the documentation indicates, you can reimage the device, run “sysprep /generalize /oobe” (generalize is a requirement), or boot all the way into the OS and then initiate a reset (from the Windows Update recovery page).  Those work great, but take a while.  So we enabled another way in Windows 10 1809:  If you reboot the device, it will re-download the Autopilot settings when it boots back up.  So this process will now work on Windows 10 1809 or above:

• Boot up the device to the beginning of OOBE.
• Press Shift-F10 to open a command prompt.
• Run the Get-WindowsAutopilotInfo script to get the CSV file.
• Register the device through Intune, make sure it is in a group with a profile assigned (if using a dynamic group, wait for AAD to update the membership), and that the profile is assigned (done automatically by Intune in the background).
• Back at the command prompt, run “shutdown.exe /r /t0” to reboot the computer, knowing that it will now download the Autopilot profile again when booting up.  (Make sure that there is a profile assigned before rebooting, looking at the Autopilot devices list in Intune to confirm.)

I do typically take a slightly different approach with virtual machines because I like to reuse them without rebuilding, reimaging, or resetting them, leveraging checkpoints.  Here are the steps I typically use:

• Create a new VM using a Windows 10 VHD (you can create a VHD/VHDX using the Convert-WindowsImage script on the PowerShell gallery.
• Configure it for standard (not production) checkpoints.
• Do not connect any network to the Ethernet adapter (purposely leave it “not connected”).
• Boot the device to the beginning of OOBE.
• Create a checkpoint, e.g. “Start of OOBE.”  This is a convenient point to revert back to later.
• Connect the Ethernet adapter.
• Complete the hardware hash harvesting steps above (Shift-F10, Get-WindowsAutopilotInfo, upload to Intune, make sure it is in a group and an Autopilot profile is assigned).

Once you’ve gone through those steps, you can revert back to the original “Start of OOBE” checkpoint, knowing that it will remember nothing (never connected to the network at that point).  So what happens if you click through OOBE and don’t remember to again connect the network adapter?  No problem, it will prompt you to insert the (virtual) Ethernet cable to continue.  (That’s a good point to mention that a device with a wireless adapter would ask you to make a Wi-fi connection at that point.)  After you do that, the OS will download the Autopilot profile, and the process should continue from there.

Azure AD groups and Autopilot profiles

You shouldn’t assign Autopilot profiles to individual devices – that’s not a particularly scalable solution.  So it’s best to get in the practice of doing this via Azure AD groups, assigning the Autopilot profile to the group so that Intune takes care of assigning the Autopilot profile to all the members of the group.  You can do this with Azure AD dynamic groups, static Azure AD device groups, or a combination of the two.  My preferred mechanism:

• Create an “All Autopilot Devices” group that selects all Autopilot devices (see the blog I wrote on that topic), using a dynamic query like “(device.devicePhysicalIDs -any _ -contains "[ZTDId]").
• Create groups for any “exceptions” where you would want devices to have a different Autopilot profile.  For example, I typically use a “User-Driven Azure AD admin” profile for most demos, but I also demo self-deploying devices and Hybrid Azure AD Join, so I end up with three groups:
• All Autopilot Devices (dynamic, with the query above)
• Self Deploying Devices (static, devices are added manually through Azure AD after adding them to Autopilot – remember, importing a device into Autopilot causes an Azure AD object to be automatically be created for the device)
• Hybrid Azure AD Join Devices (static group, like above)
• Assign the three profiles to the appropriate groups, excluding the other groups as needed:
• “User Driven Azure AD admin” profile, assigned to the “All Autopilot Devices” group with “Self Deploying Devices” and “Hybrid Azure AD Join Devices” excluded
• “Self Deploying AAD admin” profile, assigned to the “Self Deploying Devices” group
• “User Driven Hybrid Azure AD Join admin” profile, assigned to the “Hybrid Azure AD Join Devices” group

Since your environment may differ, adjust accordingly.

Enrollment status page

Generally it’s fine to use the same enrollment status page configuration for all scenarios, so it’s easy to stick with assigning those settings to the All Devices virtual group.  Note that you can now specify what apps you want to wait on.

Make it do something useful

Provisioning a Windows device using Autopilot isn’t particularly interesting if you don’t also deliver settings and apps to the device.  I would suggest a few Win32 apps, Office 365 ProPlus, and the ConfigMgr client (if you want co-management).  It’s also useful to target some settings, like custom BitLocker settings (configuring XTS-AES-256 should work well with Windows 10 1809, even for non-admins), and automatically configuring OneDrive for Business (coming soon via ADMX-backed policies, but until then check out this blog for how to do it with custom OMA-URIs).

Have your IT manager or customer walk through it themselves

It’s one thing to talk about it, it’s another to see it.  Once things are working reliably, have someone who has never done it before walk through the experience, ideally with a physical device.  Hand them a box with the device in it, along with a simple set of step-by-step instructions (no more than half a page):

• Open the box
• Plug the device in and turn it on
• Choose a language, locale, and keyboard, then connect to a Wi-fi network
• Type in your e-mail address and password (provided in the instructions if it’s not their own account)

They can then watch the deployment progress (ideally projected for everyone else in the room to see) while discussing the scenario and asking questions.

I mentioned in my previous blog that I typically use an “All Autopilot Devices” dynamic group to assign an Autopilot profile automatically to most devices, while using two additional groups to let me manually assign devices that I want to deploy differently.  Given that there were several questions around that, I though it would be useful to provide some more details on how to do that.  So let’s recap the basic setup:

• I have three Autopilot profiles:
• User Driven Azure AD Admin
• Self Deploying AAD Admin
• User Driven Hybrid Azure AD Join Admin
• I have three Azure AD groups:
• All Autopilot Devices (dynamic group selecting all devices with a ZTDID, as described here)
• Self Deploying Devices (manually assigned group)
• Hybrid Azure AD Join Devices (manually assigned group)

As for assignments, the last two are obvious:

• Assign the Self Deploying AAD Admin profile to the Self Deploying Devices group
  
• Assign the User Driven Hybrid Azure AD Join Admin profile to the Hybrid Azure AD Join Devices group
   

So that brings us back to the primary Autopilot profile, the User Driven Azure AD Admin profile.  It should be assigned to the All Autopilot Devices dynamic group:

But then you need to exclude the other two groups, so click on the “Exclude” tab and specify those:

Now, if you manually add a device to one of those groups, it will then be excluded from this assignment.  Great, but what if the device had already been assigned the User Driven Azure AD Admin profile (because it had been in the All Autopilot Devices group for a while)?  Intune would notice that the device is no longer assigned to that profile and would then re-assign the profile corresponding to the group that it is in, so it automatically fixes things up (after a short while).

Notice the information bar in the above screenshot (which for some reason has no text in it)?  Click on it to go to the documentation page that talks more about this include/exclude logic. 

If you do lots of Windows deployments, you likely create USB media fairly frequently.  But if you are using Windows Information Protection (WIP), you could run into problems if that USB key is used on a Windows 10 device with WIP policies applied to automatically encrypt files based on their file type, you might find that your USB media no longer works – either it won’t boot, won’t run setup, generates odd errors (“access denied” is the one I’ve seen the most of), etc.

Obviously this happens when files on the USB media are encrypted – once that happens, they can’t be used on another machine or in Windows PE.

So, if you can’t convince your security team to leave your USB media alone, hopefully they at least let you override the files and change them to “personal” so that they are decrypted.  That’s not too hard to do from File Explorer by right-clicking on one or more of the files and choosing “Personal” under “File ownership”:

But there’s no simple way to do this for lots of subfolders in File Explorer.  Fortunately, there is a command-line tool that can help you out, and it’s really simple.  Here’s the command you need to make sure all the files on a USB device (D: in this case) are personal and not encrypted:

cipher.exe /d /s:D:\ *.*

That’s all it takes, it should finish in a minute or two.

A new version of MDT, build 8456, was released today.  You can read about all the changes here:

https://docs.microsoft.com/en-us/sccm/mdt/release-notes

and download it from here:

https://aka.ms/mdtdownload

From my perspective, the biggest change is a new feature that offers something ConfigMgr customers have had for quite a while: support for nested task sequences.  Support for Windows Server 2019 is quite useful too.  There are plenty of other small changes (read the full list in the release notes, which are very thorough), but overall it should be a low-risk upgrade.  (As always, make sure you back up your deployment share before upgrading, then re-integrate any script changes you might have made, if necessary.) 

I’ve already upgraded my deployment shares, looking forward to hearing stories of people using this new release in production