One of the new features mentioned in the What’s new in Windows 10 1803 documentation is a new ability to perform a feature update without suspending BitLocker.  This is what it says:

New command-line switches are also available to control BitLocker:

Setup.exe /BitLocker AlwaysSuspend 
    – Always suspend bitlocker during upgrade.
Setup.exe /BitLocker TryKeepActive 
    – Enable upgrade without suspending bitlocker but if upgrade, does not work then suspend bitlocker and complete the upgrade.
Setup.exe /BitLocker ForceKeepActive 
    – Enable upgrade without suspending bitlocker, but if upgrade does not work, fail the upgrade.

For more information, see Windows Setup Command-Line Options

And if you look at the Windows Setup Command-Line Options page, it confirms the same thing: there are new command line options that affect how BitLocker is handled during feature updates.  Let’s dig a little deeper though to understand the requirements.  In order to successfully use this feature, the device needs to meet the following requirements:

• It needs to be running Windows 10 1709 or higher, and needs to upgrade to Windows 10 1803 or higher.  (So this is a “going forward” change, not one that goes back into the Windows 10 stone ages.)
• The Windows device needs to be using Secure Boot and have a TPM.
• BitLocker needs to be using a TPM protector only (yet another good reason to not have a PIN).
• The user profile folder can’t be on a separate volume that is also BitLocker protected.  (If you are doing something like this, we really need to talk.)

You could add a command line option (through a ConfigMgr task sequence variable, MDT script edit, SetupConfig.ini file, etc.) to explicitly make your choice, but if you don’t, what’s the default?  The easiest way to find out (since the documentation doesn’t say) is to try it.  First, let’s look at a device that was updated from Windows Update.  The SETUPACT.LOG clearly shows the default behavior:

2018-05-01 19:36:53, Info                  SP     Client requested to suspend BitLocker unconditionally

Now, a second device updated using media (SETUP.EXE /AUTO UPGRADE):

2018-05-01 19:22:27, Info                  SP     Client requested to suspend BitLocker unconditionally

OK, also off, so both mechanisms (servicing and media) are acting like /BitLocker AlwaysSuspend was specified, so that’s the default (at this point at least, that could change in the future).  Interestingly, if you have a device that is enrolled in Insider Preview, you might see a different default as new Insider builds are installed.  I can see that TryKeepActive is the default for my Insider laptop:

2018-04-19 15:28:08, Info                  MOUPG  SetupManager: No BitLocker command line option specified, will try to keep active but suspend on errors, because this is a WU scenario

…

2018-04-19 15:28:08, Info                  MOUPG  ImageDeploy: Initializing BitLocker Mode:        [Keep Active (Best-Effort)]
…
2018-04-19 15:28:15, Info                  SP     CNewSystem::PreInitialize: Velocity feature state for BitLocker auto-unlock is enabled

2018-04-19 15:28:15, Info                  SP     Client requested to keep BitLocker active on a best-effort basis, and the device supports it. Will try to keep BitLocker on, and fall back if needed.

(That’s the cool thing about Insider Preview, you can be trying out new features that are behind the scenes without really even being aware of them.)

Alright, so we’ve established that the default is presently /BitLocker AlwaysSuspend for both servicing (WU, WUfB, WSUS, ConfigMgr Windows 10 Servicing) and media-based (SETUP.EXE, ConfigMgr task sequence, MDT task sequence) upgrades, while the default is /BitLocker TryKeepActive with Insider Preview devices (well, at least for mine).  So how do we change it to TryKeepAlive?  It depends:

• For ConfigMgr task sequences, add a step to set variable OSDSetupAdditionalUpgradeOptions to /BitLocker TryKeepActive
  
  
• For MDT, edit the LTIApply.wsf script, changing this line:
  
  

sCmd = sCmd & " /compat IgnoreWarning"

to instead be:

sCmd = sCmd & " /compat IgnoreWarning /BitLocker TryKeepActive"

• For servicing-based approaches (WU, WUfB, WSUS, ConfigMgr Windows 10 Servicing), create a SetupConfig.ini file (roughly as described at https://blogs.technet.microsoft.com/mniehaus/2016/08/23/windows-10-1607-keeping-apps-from-coming-back-when-deploying-the-feature-update/), with a line that specifies:
  
  

[SetupConfig]
BitLocker=TryKeepAlive

Of course only make those edits/changes if you are upgrading exclusively to Windows 10 1803, since earlier versions of SETUP will have no idea what to do with that command line switch and will most definitely fail.  (But hey, we’re all upgrading to 1803 now, right?)

I wrote a couple of blogs (the basics and the more advanced scenarios) about troubleshooting Windows Autopilot late last year, which focused on the capabilities that existed at that point in time.  But there have been some enhancements since then:

• Registry entries, so you can see the Autopilot-related activity after the fact.  This was introduced in Windows 10 1709.
• Event log entries, to show the Autopilot-related activity in a more friendly form.  This was introduced in Windows 10 1803.

Of course you can continue doing ETW traces if you like, but the registry and event log entries are nice because they don’t require reproducing the scenario with a trace running.  Let’s look at each of those in more detail.

Registry information

There are some key pieces of information stored in the registry on Windows 10 1709 and above.  These can be found at HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\AutoPilot.  Here are the properties you will see:

• AadTenantId – The GUID of the Azure AD tenant the user signed into.  This should match the tenant that the device was registered with, since you’ll get an error if they don’t match.
• CloudAssignedTenantDomain – The Azure AD tenant the device has been registered with, e.g. “contosomn.onmicrosoft.com.”  If the device isn’t registered with Autopilot, this value will be blank.
• CloudAssignedTenantId – The GUID of the Azure AD tenant the device has been registered with (the GUID corresponds to the tenant domain from the CloudAssignedTenantDomain registry value).  If the device isn’t registered with Autopilot, this value will be blank.
• IsAutoPilotDisabled – If set to 1, this indicates that the device doesn’t believe it is registered with Autopilot (but this could happen if there were network connectivity issues, timeouts downloading the Autopilot profile settings, etc.).  This is a good place to start troubleshooting, since the value must be 0 (not disabled) for the standard Autopilot behaviors to happen.
• TenantMatched – This will be set to 1 if the tenant ID of the user matches the tenant ID that the device was registered with.  (If this would be false, the user would be shown an error and forced to start over.)
• CloudAssignedOobeConfig – this is a bitmap that shows which Autopilot settings were configured.  From the previous level 300/400 blog, bit values include:
• SkipCortanaOptIn = 1,
  OobeUserNotLocalAdmin = 2,
  SkipExpressSettings = 4,
  SkipOemRegistration = 8,
  SkipEula = 0x10

So first, let’s look at a device that wasn’t deployed using Autopilot, running Windows 10 1709 or above.  Here’s what you should expect to see:

Notice the numbered subkeys?  Those correspond to different pages in OOBE.  Each of those keys will contain a value named “ConfigName” that says what Autopilot setting it is tied to (e.g. page 0 is the “personal or work” question, configured by a ZTP_CONFIG_AAD_JOIN_ONLY flag that really means “you don’t need to ask”) and a second “Enabled” value that indicates whether the page was displayed (value 1) or skipped (value 0).  (You might notice that the subkeys are different in Windows 10 1709 and 1803, as there are new things in 1803 that need to be skipped.)

Now, let’s look at a device that did use Autopilot (in this case on a Windows 10 1803 device, so there are some more subkeys and a few other properties that we’ll skip over for now):

So I can see that my device was enrolled, what tenant it was enrolled with, that the user signed in with the right tenant, and that the bitmap config is 28, which translates to

SkipExpressSettings (4) + SkipOemRegistration (8) + SkipEula (16) = 28

And if we click into each of the subkeys, we can see all of the different OOBE pages that were skipped.

Event Log

Windows 10 1803 takes diagnostics to the next level with event log entries.  To find the events, open Event Viewer and navigate to “Application and Services Logs –> Microsoft –> Windows –> Provisioning-Diagnostics-Provider –> AutoPilot”.  If the device isn’t registered, you will only see two events (basically indicating that the device is not registered).  If the device is registered and deployed with Autopilot, you’ll see a lot more:

Let’s look at some of the event IDs, in the order that you might typically see them:

• Event 100, warning.  “AutoPilot policy [name] not found.”  This is typically a temporary problem, while the device is waiting for an Autopilot profile to be downloaded.
• Event 160, info.  “AutoPilotRetrieveSettings beginning acquisition.”  This shows that Autopilot is getting ready to download the needed Autopilot profile settings.
• Event 164, info.  “AutoPilotManager determined Internet is available to attempt policy download.”  Pretty obvious.
• Event 161, info.  “AutoPilotManager retrieve settings succeeded.”  A good sign, we were able to download the settings (and you can see how long it took).
• Event 153, info.  “AutoPilotManager reported the state changed from [original state] to [new state].”  Typically this should say “ProfileState_Unknown” to “ProfileState_Available” to show that a profile was available for the device and downloaded, so the device is ready to be deployed using Autopilot.
• Event 171, error.  “AutoPilotManager failed to set TPM identity confirmed.  HRESULT=[error code].”  For now, you can ignore this error as it’s related to a future scenario.  
• Event 172, error.  “AutoPilotManager failed to set AutoPilot profile as available.  HRESULT=[error code].”  Ignore this one too, it’s related to the previous one.
• Event 163, info.  “AutoPilotManager determined download is not required and the device is already provisioned.  Clean or reset the device to change this.”  This is just telling you that there is now a profile on the device, it’s not going to go away on its own and there won’t be any attempts to download it again.  So you can ignore this one.
• Event 111, info.  “AutoPilotRetrieveSettings succeeded.”  This means that the bitmap settings stored in the Autopilot profile have been retrieved successfully, so Autopilot now knows how to tell OOBE to behave.
• Event 109, info.  “AutoPilotGetOobeSettingsOverride succeeded:  OOBE setting [setting name]; state = [state].”  This shows Autopilot retrieving and processing various OOBE settings.
• Event 101, info.  “AutoPilotGetPolicyDwordByName succeeded: policy name = [setting name]; policy value [value].”  This is very similar to the previous one, just for a slightly different type of setting, an integer.
• Event 103, info.  “AutoPilotGetPolicyStringByName succeeded: policy name = [name]; value = [value].”  Also similar to events 101 and 109, but for string values (e.g. the tenant name).

So definitely check those out, they are very useful to follow the process, to see any errors that might have occurred (e.g. timeouts), and to confirm that the device is configured the way you expect it to be.

More to come

If you remember the errors shown in the previous blogs, it’s quite possible that you’ll see a screen that says “Something went wrong” with a typical error code, e.g. 80180018.  While we haven’t yet fixed those, we do understand that something more descriptive would be more helpful.  So we’re working on those, especially for common enrollment and join issues.  Stay tuned for future feature updates.

Starting with Windows 10 version 1703, you can now remove provisioned in-box apps like Xbox using the MDM platform capabilities built into Windows.  (If you think you need to use this to remove Candy Crush, Pandora, etc., stop and read this blog before continuing.)  See https://docs.microsoft.com/en-us/windows/client-management/mdm/enterprisemodernappmanagement-csp for the description of the “RemovePackage” method.  While ideally this would be available via Intune, it isn’t at this point (and no, you can’t use an OMA-URI for it either because it uses an Exec method, which isn’t presently support by OMA-URI custom policies).  But fortunately, it is supported by the Set Up School PCs app (which has a hard-coded list of apps that get removed when you create a provisioning package with this tool) and by Windows Configuration Designer (at least in the version from the ADK for Windows 10 1803).

So let’s set up a sample provisioning package using Windows Configuration Designer.  To do this, create a new provisioning package in “advanced” mode, then navigate to “UniversalAppUninstall –> RemoveProvisionedApp.”  Once there, you can specify the apps you want to remove using the “package family name.”  I specified two that I wanted to remove: the Xbox app and the “Get Office” app‘

So how do you come up with those PackageFamilyName values?  That’s where PowerShell comes in handy.  For some strange reason, the obvious mechanism of using “Get-AppxProvisionedPackage –online” doesn’t return the PackageFamilyName, but the “Get-AppxPackage” cmdlet does.  So use that to get a list.  Here’s an example for the Xbox app:

Copy and paste that value into Windows Configuration Designer, click Add, and then you can generate your provisioning package.  To install it, you can included it in your image (DISM can be used from Windows PE to stage the package for Windows to process automatically on first boot) or you can install it directly using “Install-ProvisioningPackage C:\Project_1.ppkg”.  But if you try it, you’ll find that it does absolutely nothing – because your package doesn’t have any details in it.

Alright, why not?  Simple: there is a bug in Windows Configuration Designer, it doesn’t save the values that were entered in the UI for that setting.  So on to plan B:  Let’s see what the Set Up School PCs app does.  Install it from the Microsoft Store, launch it, and specify all the defaults.  Eventually, you’ll be asked to insert a USB key; it will create a provisioning package on that USB key.  Take that provisioning package (the name of which will start with SetUpSchoolPCs) and copy it to your computer.  Rename it from “.ppkg” to “.wim”  Then mount it using DISM.  From the mounted folder, open the “Multivariant\0\customizations.xml” file with Notepad or your favorited editor.  You should see a section called UniversalAppUninstall that is populated with a list of apps to remove (even though the Set Up School PCs app never asked – it always removes these):

Cool, so now how do we get that into our provisioning package without the rest of the Set Up School PCs stuff?  Copy and paste of course.  But first, make a copy of that customizations.xml file, because it’s easier to remove stuff you don’t want.  First, edit it to look something like this:

We could just overwrite our own customizations.xml file with this one, but then it would have the same GUID and other details, so instead just copy the “Settings” section into the WCD customizations.xml file (at whatever location you saved it, typically inside the documents folder), overwriting the existing Settings section.  You should then have something that looks the same as the edited SUSPCs file:

(Notice that I shortened the list of apps to be removed, back to my original two sample apps.  The SUSPCs list was longer, removing everything that schools want to keep away from students.)  Save the changed file, then open it back up in Windows Configuration Designer:

So at least it *reads* the values in, even if it won’t write them.  So *now* you can create a provisioning package that will actually do something, then install it using PowerShell:

And presto, the provisioned apps are removed. But they aren’t removed from any existing user, so while the above PowerShell command works fine, it won’t completely eliminate the apps.  So it’s better to use the “add to the image with DISM” approach.  While you can inject it into your image, it’s better to add it just in time.  Assuming you are using MDT or ConfigMgr, you can add a step to the task sequence that runs in Windows PE after the OS has been applied/installed, that runs a command similar to this:

DISM /Image=C:\ /Add-ProvisioningPackage /PackagePath:Project_1.ppkg

Of course you should be more dynamic about it, specifying the path to the OS (which might not be C:\) and to the provisioning package (which could come from a ConfigMgr package and be in the working directory, e.g. “.\Project_1.ppkg”, or could be on an MDT deployment share and referenced via “%ScriptRoot%\Project_1.ppkg”).  There are other blogs out there that talk about those approaches, so take your pick.

In today’s Tech Community blog, we talk about a variety of new Autopilot features.  For the Autopilot self-deploying mode, I thought it would be useful to get into more of the specifics of how to deploy a kiosk with Autopilot, where the end result is a device that is configured to automatically log in and run a specific kiosk app (in this case, the new Kiosk Browser app configured to automatically load a specific web page).

Let’s start with some specific requirements before you get too far:

• The device must have a physical TPM 2.0 chip.  Devices with virtual TPMs (e.g. Hyper-V VMs) or those with TPM 1.2 chips won’t work with self-deploying mode.
• The device must be running an Insider Preview build of Windows 10, build 17672 or later.  (If you try this with Windows 10 1803, it won’t work very well – it’s only supported with these later builds.)

With that out of the way, let’s get into the specific steps.

Step 1:  Create Autopilot profile

Let’s start off on the Autopilot side.  We first need to create an Autopilot profile for “Self-deploying” mode.  So let’s navigate in the Azure Portal to “Intune –> Device Enrollment –> Windows enrollment –> Deployment Profiles.”  From there, you can create a new profile that specifies “Self-deploying”:

Configure the appropriate settings on that profile:

Notice that you can specify a “Language (Region)” setting that can automate the initial prompts in OOBE – this only works for wired Ethernet connections though, because the Autopilot settings can’t be downloaded until there is a network connection in place.

Step 2:  Assign Autopilot profile

Intune now uses Azure AD groups to assign Autopilot profiles to devices.  So to use the Autopilot profile that we just created, we need to first create an Azure AD group that can be used for that assignment.  Navigate to “Azure Active Directory –> Groups” and create a new group.  In my case, I created a “Kiosk Devices” group:

Now go back to the Autopilot profile that you created before, and click on “Assignments.”  Click the “Select groups” button and find the group that was just created:

Click “Select” then “Save.”  Now, any device added to the group will automatically get this Autopilot profile.

Step 3:  Add a device

To do a “Self-deploying” device, we need one that meets the requirements:  It must have a TPM 2.0 chip (and it must be a physical device, a Hyper-V VM won’t work), and should be running a current Windows 10 Insider build (e.g. 17686).  You can gather the hardware hash from it using the Get-WindowsAutoPilotInfo script, then import it via the "Intune –> Device enrollment –> Windows enrollment –> Devices” node.

After that import completes (it will take a few minutes), not only will there be an entry in the list of Autopilot devices, but there will also be a new Azure AD object created for the device.  If you go to “Azure Active Directory –> Devices” you’ll see the device in the list.  The device will be named using the serial number of the device, and will be shown as disabled.  When the device is actually deployed, you’ll see the object renamed to reflect the computer name (instead of the serial number) and it will then be enabled.

Now let’s add the device to the Azure AD group that was created earlier.  Find the group (“Azure Active Directory –> Groups”), click to see its details, and then click “Members.”  Click “Add members” and select the device you imported:

Then click “Select” to add it.  After a few minutes, Intune will assign the Autopilot profile to the device; you can confirm that the assignment is complete via the Autopilot devices list (“Intune –> Device enrollment –> Windows enrollment –> Devices”).

Step 4:  Get and deploy the Kiosk Browser app

To have a kiosk that runs a single app, you need a single app.  Fortunately, we now publish a Kiosk Browser app that works nicely, and more importantly it can be easily configured via Intune as well.  But first, we need to get that app.  It’s available in the Microsoft Store for Business, so you need to acquire it from there.  (If you haven’t yet integrated the Microsoft Store for Business with Intune, see the Intune docs for setting that up.  And make sure you have enabled offline licenses via the “Show offline apps” slider on the Setting page in MSfB.)

Sign into the store via http://businessstore.microsoft.com.  Search for “Kiosk Browser” and make sure you choose the right one.  Specify “Offline” for the license type and then click “Get the app.”  (If you already have the app with an offline license, the button will say “Manage” – that’s fine, it just means you’ve done this step already.  And if you don’t see the “Offline” choice see the previous note about enabling offline licenses.)

Now that the app has been added to your collection, you can go back into Intune and initiate a sync with the Microsoft Store for Business to get it to show up quickly.  Navigate to “Intune –> Mobile apps –> Microsoft Store for Business” and then click the “Sync” button.  That might take a couple of minutes, but after the sync completes, you’ll see the app in the list at “Intune –> Mobile apps –> Apps.”  Select the app to see its details (it should show “Yes” under “Supports device licensing”), then click “Assignments.”  Click “Add group” and change the assignment type to “Required.”  Click “Included groups” and then “Select groups to include” and choose the kiosk device group that you created in Azure AD earlier:

Then click “Select.” In the “Licensing Type” drop-down, choose “Device licensing" then click OK:

Then click “OK” again to add the group, and “Save” to save the new assignment.

Step 5: Create and deploy the kiosk configuration

Now we need to specify how the kiosk should be configured.  To do that, navigate to “Intune –> Device configuration –> Profiles” and click “Create profile”.  Give it a name (e.g. “Kiosk Configuration”), choose a platform of “Windows 10 and later” and a profile type of “Kiosk (Preview)”.  You will then see the available setting categories:

Click the “Kiosk” setting to see the “one” setting.  As you can see, there’s a little more that needs to be done:

So click “Add” to create a kiosk configuration.  Give it a name (e.g. “Kiosk Browser”) and choose “Single full-screen app kiosk” from the drop-down, which then shows additional options:

If you’ve ever configured a kiosk on Windows 10, you might remember that you need to specify an AUMID for the app, which is a UWP concept that combines the app package family name with an entry point – basically, a gibberish string that you should never have to type.  Fortunately, Intune will let you pick an app from a list instead, which is much easier.  So under the “*Managed Intune app to use for kiosk mode” click the “Select a managed app” link to choose an app:

Search for the Kiosk Browser app and then click on it to accept it.  (Notice that I have two:  one is an online license, one is offline.  Either will work here, since we’re just using the app to get the AUMID.  But in the previous step when we acquired and deployed the app, it needs to be an offline app for this scenario to work.)  Then click OK.  Next, select “Autologon” as the user account type.  This will automatically create a local account on the device and configure it to automatically log on and run the specified app.  Click “OK” to create the configuration, and then “OK” again to complete that settings category.

Next, click on the “Kiosk web browser” category to see the available Kiosk Browser settings:

At a minimum, fill in the “Default home page URL” setting to point to an appropriate web page.  Depending on that page, you may want to populate other settings (e.g. restrict where you can navigate to from that page).  You can also control the UI in the browser app itself, e.g. show or hide navigation buttons, and configure when the browser should automatically refresh.  Click “OK” to commit these settings, “OK” to commit both categories, and “Create” to create the configuration profile.

Next, click on “Assignments” for that newly-created profile.  Then click “Select groups to include” and select the same kiosk devices group that was created earlier:

Then click “Select” to confirm that group selection, and “Save” to save the assignment.

Step 6: Deploy

Reset the device that you used in step #3.  When it starts OOBE, what you see depends on the device.  If it has an internet connection, it may skip the language, locale, and keyboard selection screens (if you configured a language/locale in the Autopilot profile).  If it needs a Wi-fi connection, you’ll have to do that manually.  It will then get to a screen that requires clicking OK to continue:

and a second screen for “Activities”:

As we mentioned in the TechCommunity blog, these extra clicks are temporary and will not be necessary in later Insider preview releases.

When the Autopilot provisioning process completes, you should see the device automatically log on and run the Kiosk Browser app, which will navigate to the configured web page.

We’ve had questions over the past several months, as customers scale up with Autopilot, about how to assign an Autopilot profile to new devices, as it can get kind of tedious to have to do this manually each time you add a new batch of devices (either by uploading them yourselves, or having an OEM do it for you).  Fortunately, the Intune team has been busy working on a mechanism to do this.

Let’s start with a basic premise:  Instead of doing things to individual devices or users (which is tedious), you instead want to do things to groups.  And as those groups get new members, those new members should be handled automatically.  That’s the mechanism that Intune uses today for lots of things: apps, policies, settings, etc.  You assign those to a group, and members of that group get whatever is assigned to them.  See this article for an example.

Now, if you think about an Autopilot profile, it’s really just a group of settings that control how the device should behave when it is being set up.  So it makes sense to assign an Autopilot profile to a group so that all devices that are members of that group automatically get that profile assigned.

The Simple Case

In the simplest case, you can do this using a group containing static members.  Let’s walk through an example from my Intune tenant.  First, I have an Autopilot profile called “Kiosk” that is configured with the settings I want:

And I have an Azure AD group with a number of devices that are members:

So, all I need to do is assign the Autopilot profile to that group.  Select the profile, click on Assignments, click “Select groups” and choose the appropriate group (or groups) that the profile should be assigned to:

Click “Select” and then “Save” (don’t forget that step).  In the background, the assignment will be processed.  If you watch carefully, you can see each Autopilot-registered device in that group change from “Not assigned” to “Assigning” to “Assigned” without you doing anything.  (Give it a few minutes.)

Where did the Azure AD device come from?

You might think “how can I add a device to an Azure AD group before it’s joined to Azure AD.”  If so, you’re on the right path.  What happens when you add a new device to Autopilot (via Intune, Microsoft Store for Business, or any other path)?  An associated Azure AD object is automatically created.  That object is named using the serial number of the device, and it is not enabled until the device actually completes the Azure AD join process.  When that happens, the device is renamed to have the “real” computer name from the device.

So these pre-created devices enable you to place the devices into Azure AD groups and use them for Intune assignment purposes.

It’s also worth mentioning that there are multiple properties automatically “tagged” onto those pre-created Azure AD objects; the usefulness of those will become apparent later.  For those that are technically inclined, you can you look at these using the Graph Explorer website.  Here’s an example from my tenant:

The key part is the “physicalIds” values (a multiple-value property, basically an array of values):

"physicalIds": [
"[ZTDID]:7ab8b9a0-b753-4598-94dc-ec885e6bdc11",
"[OrderID]:123456",
"[USER-GID]:eff992e4-f88f-4a2b-bf6f-3197add5c88a:6825770233125750",
"[GID]:g:6825770233125750",
"[USER-HWID]:eff992e4-f88f-4a2b-bf6f-3197add5c88a:6896134161355432",
"[HWID]:h:6896134161355432"
]

There are three values that you should be aware of:

• ZTDID.  This is a unique value (a GUID) assigned to all Autopilot-registered devices.  So you can use this value to easily determine which devices are registered.
• PurchaseOrderID (not set in my sample above).  This value is set by OEMs when processing an order for new devices; when they upload those devices to the Autopilot deployment service, they will set the PurchaseOrderID value to the purchase order number for the order.  That makes it easy to identify all the devices from a particular order.
• OrderID.  This value is actually more of a “tag.”  When you upload devices to Intune, you can specify an optional “OrderID” column that is used to arbitrarily group devices.  For example, you could set the OrderID value to “Kiosk” and use that to easily tag all kiosk machines.

All three of these values can be used as part of a dynamic membership rule for an Azure AD group, which leads to all sorts of interesting scenarios.

Assign a profile to all Autopilot devices

If you have simple requirements, e.g. all devices will use the same Autopilot profile, this gets even easier:  You can create an Azure AD dynamic group that automatically selects all devices that are registered with Autopilot.

How do you do that?

Here’s the step-by-step:

1. 1. Navigate to “Azure Active Directory –> Groups” and click “New group”.
   2. Specify “Security” for the group type, and provide an appropriate group name.
   3. Select “Dynamic Device” as the membership type.
   4. Click “Add dynamic query” and then “Advanced rule” and paste in this exact string (yes, including the parenthesis):

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

1. Click “Add query” and then “Create.”

After a period of time (think minutes, not seconds), the group will be populated with all the Autopilot clients defined to your Azure AD tenant.  You can then take the next step of assigning an Autopilot profile to that group.

Assign a profile to a purchase order ID

This is the same basic process, but with a different dynamic query:

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

Put in your own purchase order ID value (instead of the “333000” value in the sample above) and you’re all set.

Assign a profile to an order ID

Again, just a different dynamic query:

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

Put in your own order ID value (instead of the “123456” value in the same above) and you’re all set.

Got any other interesting scenarios?  Leave comments with the details.

It’s been a busy day for new Windows Autopilot resources.  First, we launched a new Windows Autopilot landing page, with high-level details about Windows Autopilot capabilities and feature (with more to be added in the future, stayed tuned).  Visit https://aka.ms/WindowsAutopilot to check it out.

Next, we published a (nearly completely) new set of documentation at https://aka.ms/WindowsAutopilotDocs to help you learn more about Windows Autopilot requirements, scenarios and capabilities, administration, troubleshooting, and more.

If you have feedback on the docs, click the “Feedback” link at the top of the page to let us know.  Or, if you are particularly adventurous, you can edit the doc yourself by clicking the “Edit” link, then submit your proposed changes to our documentation team – if they agree with your changes, they’ll approve them for publishing.  (As an added bonus, your small picture can appear as a contributor to the article.)

Another Ignite conference has been completed, and I’m on my way back home to sleep for as long as possible.  For those that weren’t able to attend, or for those that did attend but weren’t watching the video wall showing 12 sessions simultaneously, you can catch up via the session recordings that are available through http://myignite.microsoft.com.  Here are a few that I recommend (click the link to get to the video):

• GS004 - Simplify your IT management and level up with Microsoft 365.  In this packed general session, Brad Anderson kicks off with an overview of Microsoft 365 modern management, including announcements around Windows Autopilot, Microsoft Intune, System Center Configuration Manager, Desktop Analytics, and much more.
• BRK3035 - What’s new in System Center Configuration Manager.  In this huge and full room, Rob York and Dune Desormeaux present and coordinate with several other members of the ConfigMgr team to talk about what’s new with ConfigMgr, and to dispel (finally?) the notion that ConfigMgr is dead.
• BRK3039 - Windows 10 and Microsoft Office 365 ProPlus lifecycle and servicing update.  Did you hear about the changes to the Windows 10 servicing timelines for Windows 10 Enterprise and Education, with 30 months now (instead of 18) for the fall releases?  John Wilcox and Bruno Nowak cover these changes and more in this session that explores Windows and Office servicing.
• BRK3036 - Managing devices with Microsoft Intune: What's new and what's next.  Paul Mayfield and Terrill Cox talk about what’s new with Microsoft Intune, which includes cool stuff like installation of Win32 apps using Intune Management Extensions, ADMX-backed policies to support GPO policies via Intune, support for security templates for Windows 10, Windows Autopilot capabilities, and some stuff about other platforms too.
• BRK3014 - Modern deployment with Windows Autopilot and Microsoft 365 (Part 1 of 2) and
  BRK3015 - Modern deployment with Windows Autopilot and Microsoft 365 (Part 2 of 2).  Tanvir Ahmed and I had so much to share about Windows Autopilot we needed two sessions to do it.  (Sorry if you couldn’t get into the rooms – even with rooms that were 2-3 times bigger than the ones we used last year, there still weren’t enough seats.)  Check out the videos to learn more about the latest Autopilot scenarios, including self-deploying devices, user-driven deployments with Active Directory join (Hybrid Azure AD Join), and Windows Autopilot for existing devices which can be used for Windows 7 to Windows 10 migrations.
• BRK3099 - Microsoft OneDrive deployment deep dive.  In this session, I make a guest appearance to show how Windows Autopilot for existing devices can leverage OneDrive for Business for data migration and Intune for automatic configuration.  Tony East, Gaia Carini,and Katy Erlandson talk about all the enhancements being delivered with OneDrive.
• BRK3019 - Delivery Optimization deep dive: How to reduce internet bandwidth impact on your network.  Narkis Engler and Kerim Hanif talk about Delivery Optimization (DO) for peer-to-peer content distribution, and talk about what’s coming, including support for using DO with ConfigMgr and Intune content.
• BRK3016 - Shared devices for kiosk and Firstline Workers with Windows 10 and Intune.  Kellie Eickmeyer and Ariel Netz explore how to set up shared devices, kiosks, and digital signage using Windows 10, Intune, and related technologies.
• BRK3027 - Deploying Windows 10: Making the update experience smooth and seamless.  Suma SaganeG0wda and Patrick Siu talk about the platform improvements being made to the Windows 10 deployment process, reducing the amount of time that it takes to install updates and reducing the size of those updates too.

There are plenty of other interesting sessions once you finish these 11 hours, but you can discover those on your own…

At Ignite 2018, we announced Windows Autopilot for existing devices, a new feature designed to migrate devices from Windows 7 (or any other version of Windows, i.e. 8.1 or 10), Active Directory-joined and ConfigMgr-managed, to Windows 10, Azure Active Directory-joined and Intune-managed (with co-management with ConfigMgr if you so desire) leveraging the Windows Autopilot user-driven deployment process to drive the Windows 10 configuration process.

Rob York published a blog that describes the implementation steps, and we’ve also published “official” documentation that walks through it.  If you look at those solutions, here are the high-level steps that they go through:

1. Boot to Windows PE (no data migration steps, we assume OneDrive for Business already has the data in the cloud).
2. Format and partition the drive (so this is clearly a wipe-and-load process, not an in-place upgrade – all data, apps, settings, etc. are cleaned from the drive).
3. Apply the new Windows 10 OS image.
4. Inject drivers into the applied Windows 10 installation.
5. Copies an Autopilot configuration file into the proper location in the Windows folder structure (this enables an Autopilot user-driven experience without harvesting and uploading the hardware hash in advance).
6. Boot into Windows 10.
7. Install the ConfigMgr client.
8. Sysprep the Windows 10 OS.
9. Reboot into Windows 10 OOBE.

This takes quite a while – about 20 minutes to get into Windows 10 the first time, then another 20 minutes to generalize (sysprep) and re-specialize the device.  And that’s before the time it takes for the Autopilot configuration (Azure AD join, Intune enrollment, pushing policies and apps, etc.).

So how can we make that faster?  Simple: Only boot into Windows 10 once, and don’t sysprep it.  (The OS image being applied initially, straight from the Windows 10 media, has already been sysprepped and captured.  What’s the downside?  Well, you can’t customize the Windows 10 OS, but I would argue you don’t really want to do that anyway; the goal is to treat these existing devices just like new devices, which would probably be configured via Intune exclusively, or Intune + ConfigMgr in a co-management configuration.

So let’s look at what that task sequence can look like:

Apart from the removed steps from above (6, 7, 8), there are two other changes:

1. A new step to remove the unattend.xml that the “Apply Operating System” step automatically creates (this gets in the way of Autopilot).
2. A PowerShell script (“Copy adjusted JSON”) to copy an edited AutopilotConfigurationFile.json into the right location (more on that later).

The net change: 20 minutes or so removed from the process.  You can find an exported version of my task sequence attached to this blog.

Now here’s a little more detail on that “Copy adjusted JSON” task sequence step.  The official docs have you create an AutopilotConfigurationFile.json, with a step that copies the file without any changes to the correct location.  In my PowerShell version of that step, I make one edit before writing the file to the correct location, inserting the existing computer name so that the “new” Windows 10 OS ends up with the exact same name as the “old” Windows 7 installation.  Here’s the script in its entirety:

# Read the current config
$config = Get-Content .\AutoPilotConfigurationFile.json | ConvertFrom-Json

# Get the computer name
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
$computerName = $tsenv.Value("_SMSTSMachineName")

# Add the computer name
$config | Add-Member "CloudAssignedDeviceName" $computerName

# Write the updated file
$targetDrive = $tsenv.Value("OSDTargetSystemDrive")
$null = MkDir "$targetDrive\Windows\Provisioning\Autopilot" -Force
$destConfig = "$targetDrive\Windows\Provisioning\Autopilot\AutoPilotConfigurationFile.json"
$config | ConvertTo-JSON | Set-Content -Path $destConfig -Force

To use the script, save it as AdjustJSON.ps1 and put it in the same folder as the AutopilotConfigurationFile.json that you created following the official documentation.  (And make sure you have PowerShell and .NET included in your Windows PE boot images.)

Try it out, see how it works for you.

Attachment:  AutopilotExistingDevices_Fast

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 (but 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 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 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 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