With the release of Windows 10 version 1607 (a.k.a. the anniversary update), we’ve posted the volume license media on the Volume Licensing Service Center.  It’s not always easy to find what you’re looking for, so here are some tips:

• Search for “Windows 10” to get a list of products.  When you select a particular product, e.g. “Windows 10 Enterprise” or “Windows 10 Education”, you can then choose which release when you click the “Download” button and choose a language and bitness:

• Language packs are a little more interesting.  With Windows 10 1507 and 1511, you could select “Windows 10 Enterprise Language Pack,” click “Download” and then select “English” and “64-bit” to see the downloads.  But that doesn’t work with the Windows 10 1607 language packs.  Instead, you need to select “Multilanguage” from the drop-down list of languages to see the new ones:

• Features on demand (see https://blogs.technet.microsoft.com/mniehaus/2015/08/31/adding-features-including-net-3-5-to-windows-10/) are easy, search for “Windows 10 Enterprise Features on Demand” and you’ll see all three releases in the list:

• If you’re looking for Windows 10 Enterprise LTSB 2016, you won’t find it until October 1st.  (That was mentioned at What’s new for IT pros in the Windows 10 Anniversary Update.)  It should show up on MSDN soon though.

Note:  Consider this post obsolete and replaced by https://blogs.technet.microsoft.com/mniehaus/2016/08/16/windows-10-delivery-optimization-and-wsus-take-2/, which offers more detail and clarity around the behavior of Delivery Optimization in both Windows 10 1511 and 1607.

For those of you who have started deploying Windows 10 1607 (edit: and Windows 10 1511), you might notice a change in the behavior of the Windows Update agent for PCs that are configured to pull updates from WSUS.  Instead of pulling the updates from WSUS, PCs may start grabbing them from peers on your network, leveraging the Delivery Optimization service for referrals to other PCs that have already obtained the content.  This change should generally help reduce the amount of network traffic being generated for both quality (monthly) updates and feature updates, offloading that traffic from the WSUS server.  It will add some additional traffic between each client PC and the Delivery Optimization service on the internet, as it has to talk to this internet-only service in order to get a list of peers.

If the Windows Update agent can’t talk to the Delivery Optimization service (due to firewall or proxy configurations), or if there are no peers able to provide the content, it will then go ahead and grab the content from the WSUS server.

There is a new Group Policy setting available if you want to disable this behavior, e.g. because you are already using BranchCache for peer-to-peer sharing.  To do this, you need to set the “Download Mode” policy under “Computer Configuration –> Administrative Templates –> Windows Components –> Delivery Optimization” to specify “Bypass” mode, which will result in the client always using BITS to transfer the content from WSUS (with BranchCache jumping in to provide the peer-to-peer capabilities through its integration with BITS):

Of course to set this policy, you need the latest ADMX files, which can be downloaded from https://www.microsoft.com/en-us/download/details.aspx?id=53430 and are also included in Windows 10 1607 and Windows Server 2016.  (The “Bypass” setting wasn’t available in previous versions.)  See https://support.microsoft.com/en-us/kb/3087759 for details on how to update the Group Policy central store with these latest ADMX files, if you are using a central store.

I had posted an article about Windows 10 1607, Delivery Optimization, and WSUS last week at https://blogs.technet.microsoft.com/mniehaus/2016/08/08/using-wsus-with-windows-10-1607/, but based on conversations with the engineering team and more testing of my own using virtual machines, I thought it would be good to make a second attempt at it.

Let’s start off with some basic behaviors:

• Both Windows 10 1511 and Windows 10 1607 will talk to the Delivery Optimization service to find peers that can provide the content.  For devices connected to Windows Update, the peers are used in addition to the Windows Update content distribution servers on the internet.  For devices, connected to WSUS, the peers are used in addition to the WSUS server.
• Windows 10 1511 and Windows 10 1607 are configured by default for Delivery Optimization, but the download mode (used to determine what peers should be considered) is different depending on the SKU of Windows that is installed:
• Enterprise, Enterprise LTSB and Education SKUs are configured for “LAN” (download mode 1) so they will only use PCs on the corporate network as peers.
• Other SKUs default to “Internet” (download mode 3) so they will use a broader set of clients as peers.
• There are minimum requirements for a PC to cache and provide content to peers, with at least 4GB of RAM and 256GB of disk space needed.  There are also minimum requirements for clients to receive content from peers; those that don’t meet those requirements will download updates directly from the source (Windows Update or WSUS).
• Delivery Optimization presently will only use peer-to-peer sharing for larger updates like feature updates and cumulative updates.
• Windows 10 1607 adds two new download modes, “Simple” (mode 99) and “Bypass” (mode 100).  “Simple” is great for “closed” networks where PCs wouldn’t be able to get to the Delivery Optimization service on the internet.  And “Bypass” is useful if you are already using BranchCache and want all updates to be pulled from WSUS using BITS.  (Since Windows 10 1511 doesn’t have a Bypass mode, you can use “HTTP only” mode 0 to skip Delivery Optimization peer checks on closed networks.)
• Windows 10 1511 and Windows 10 1607 both also include a “Group” download mode setting (mode 2) that limits the population of PCs that can be considered peers to just those in a particular group.  With Windows 10 1511, groupings are based on the AD domain and an optional group ID that you can set via policy.  With Windows 10 1607, the groups are based on AD domain and AD site, and can also add in an optional group ID.

So let’s assume we have a Windows 10 1511 or Windows 10 1607 PC configured to talk to WSUS, and it checks for updates.  What happens?  Here’s the basic flow with the default settings:

• The PC talks to WSUS to determine what updates are needed.
• For each needed update, the PC checks with the Delivery Optimization service (on the internet) to find any applicable peer PCs that already have the needed content.
• If peers are available,, the PC will try to get the content from the peers.
• If some or all of the content isn’t available from a peer, or if no peers are available, the remainder will be retrieved from WSUS.

So overall Delivery Optimization is a good thing:  It enables PCs on your network to share feature updates (new Windows 10 releases) and quality updates (monthly patches) with other PCs on your network.  But you might want to tweak the behavior.  I already mentioned one key scenario:  If you are using Windows 10 1607 with WSUS and BranchCache.  Since Windows 10 1607 no longer uses BITS by default for downloading updates from WSUS, you may want to deploy a policy to change the download mode to “Bypass” when you are using BranchCache.

One other tweak to consider:  Instead of using the default “LAN” download mode, you may want to instead use the “Group” download mode.  The “LAN” mode identifies PCs that are on the same LAN by looking at their external IP address – all PCs going through the same internet IP (through a proxy server or router) are considered to be on the same “LAN.”  But if you’re a typical large enterprise, your “LAN” might be made up of a bunch of different LAN segments with WAN connections between them, with all internet traffic funneled back to a central location that has a connection to the internet.  In that type of an environment, you don’t necessarily want a PC in Anchorage sharing an update with a PC in Auckland through WAN links that pass through Chicago.  Instead, you want peer-to-peer sharing to happen locally.  The “Group” mode in Windows 10 1607 handles that nicely, as long as your AD sites are defined to correspond with physical locations.  If they aren’t, or if you are using Windows 10 1511, you can instead use the “Group ID” policy (delivered via site-specific GPOs) to segment PCs into more appropriate groups.

See https://technet.microsoft.com/en-us/itpro/windows/manage/manage-connections-from-windows-operating-system-components-to-microsoft-services#bkmk-updates and https://technet.microsoft.com/en-us/itpro/windows/plan/setup-and-deployment for more background on Delivery Optimization.

For those of you that have deployed Windows 10 1511, you’re probably already starting to work with Windows 10 1607, getting ready for initial pilot deployments so that you’re ready for broad deploying of Windows 10 1607 in the coming months.  As part of that work, you would notice that apps you had removed from Windows 10 1511, e.g. Xbox and Sports, come back as part of the feature update installation process (regardless of how you install it – WU, WSUS, ConfigMgr, MDT, media, etc. all behave the same).

We’re working on solving this particular issue in a future feature update.  But for now, there are some workarounds that you can use.  First, let’s look at the two main scenarios for feature updates:

• Those that leverage VL media, e.g. ISOs downloaded from VLSC.  These are the simplest, as you can modify the INSTALL.WIM file to remove the apps you don’t want, then use the modified image to do the upgrades.  This works well with ConfigMgr task sequences, MDT task sequences, and other installations where you run SETUP.EXE with command-line switches.
• Those that leverage update packages published via WU or WSUS.  These are harder, because you can’t modify the ESD files that are being used.  So as an alternative, you need to remove the apps (again) after the new OS is installed, but ideally before the first user logs into the device.  This works well with Windows Update for Business, WSUS, and ConfigMgr current branch Windows 10 Servicing deployments.

Let’s look at both of those in a little more detail.

Modifying the INSTALL.WIM

To make the needed modifications to the INSTALL.WIM, first you need to extract the contents of the .ISO file that you downloaded from VLSC and make sure that the files aren’t marked read-only (since you need to make changes to them).  That can be done by mounting the .ISO in Explorer (assuming you’re running Windows 10 already, since it supports that).  Then from an elevated PowerShell session, you can run the following commands (substituting your own paths):

Mount-WindowsImage -Path C:\Mount -ImagePath c:\media\sources\install.wim -Index 1
Remove-AppxProvisionedPackage -Path C:\Mount -PackageName Microsoft.XboxApp_2016.728.453.0_neutral_~_8wekyb3d8bbwe
Dismount-WindowsImage -Path C:\Mount -Save

In this example, C:\Mount is an empty folder where the WIM will be mounted.  Since I’m using a Windows 10 Enterprise 1607 WIM, there is only one image index, so I can specify index 1.  And I’m removing the Xbox app.  I can repeat the Remove-AppxProvisionedPackage command as many times as needed.  Use “Get-AppxProvisionedPackage -Path C:\Mount” to get a list of apps.  Or if you want to use something a little more dynamic, see the example script in the Removing Windows 10 in-box apps during a task sequence blog post.

Cleaning up apps after installing the feature update

So what options are available for after-the-fact cleanup of the apps, given that the goal is to remove the provisioned apps before a user first logs in (which would result in the apps installing for that user)?  There are probably a few, but there are two that stand out:

• Create a scheduled task that runs a PowerShell script that removes the unwanted apps at startup.  The simplest option is to try to remove the extra apps each time the computer restarts.  If the apps aren’t there, the script doesn’t need to do anything.
• Create a batch file that is run right after the upgrade successfully completes.  For that to work, you have to create a SetupConfig.ini file that specifies:[SetupConfig]
  PostOOBE=C:\Cleanup.cmd

  The SetupConfig.ini file, as well as the batch file itself, needs to be on the PC before running the upgrade.  The SetupConfig.ini needs to be placed at “%systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini.”  See https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/windows-setup-automation-overview for more information about this file, and https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/windows-setup-command-line-options for more details on the available command line options.

In either case, it would be good to run a PowerShell script that issues a command like:

Remove-AppxProvisionedPackage -Online -PackageName Microsoft.XboxApp_2016.728.453.0_neutral_~_8wekyb3d8bbwe

repeating that for each app that you want to remove.  (And again, see Removing Windows 10 in-box apps during a task sequence for more sophisticated scripts.)

Summary

Those are the high-level steps needed to remove the apps.  If you need more details, let me know and I can provide more complete examples.

Also remember that some apps aren’t in-box but are instead installed from the Windows Store when a user signs on for the first time.  See https://blogs.technet.microsoft.com/mniehaus/2015/11/23/seeing-extra-apps-turn-them-off/ for more details on that, and keep in mind that some of the policies related to this aren’t supported in Windows 10 Pro version 1607 and later; see https://technet.microsoft.com/en-us/itpro/windows/manage/group-policies-for-enterprise-and-education-editions for the specifics.

As you may be aware, the Nano Server installation option for Windows Server 2016 is unique – you don’t deploy it like you do with any other Windows OS.  (See https://technet.microsoft.com/en-us/windows-server-docs/get-started/getting-started-with-nano-server for more details.)  But that doesn’t mean you can’t use MDT to simplify some of the steps that are described at https://technet.microsoft.com/en-us/windows-server-docs/get-started/deploy-nano-server.

So where do you start?  There are four steps:

• Set up MDT with updated files to deploy a Nano Server OS.
• Use the Nano Server Image Builder tool to create a Nano Server WIM that MDT can deploy.
• Create the task sequence in MDT to deploy.
• Deploy (using PXE, media, etc.).

Updating MDT

There are several files that are provided as part of this Nano Server solution, using the zip file nano-server-with-mdt-1-0:

• Microsoft.BDD.DJoin.exe, a 64-bit C++ executable that generates an offline join blob on the fly, which is inserted into the unattend.xml file that is being used to deploy Nano Server.  This is the key piece of the puzzle with Nano Server – generating these blobs manually, one server at a time, would be rather tedious.  This executable runs in Windows PE, impersonates the provided join account, and then uses the NetCreateProvisioningPackage API call to generate the same offline blob that you get from DJOIN.EXE (not surprising, since it uses similar APIs).
• LTIOfflineJoin.wsf, a very simple script that wraps around the Microsoft.BDD.DJoin.exe executable (primarily to capture the console output from that executable).
• ServerNano.xml, a task sequence template for doing bare metal Nano Server deployments (applying the WIM directly to the hard drive).
• ServerNanoVHD.xml, a task sequence template for doing bare metal Nano Server deployments using boot from VHD (dynamically building the VHD at deployment time).
• Unattend_x64.xml.10.0.ServerDatacenterNano and Unattend_x64.xml.10.0.ServerStandardNanoNano, two (identical) unattend.xml templates used with Nano Server (either the Standard or Datacenter SKUs).

To set this up in MDT, follow these steps:

• Download the nano-server-with-mdt-1-0 zip file and extract the contents.
• Copy the files in the extracted “Scripts” folder to the “Scripts” folder on your MDT deployment share.  (If you have modified the default ZTIConfigure.xml file, make sure to integrate your changes into this modified file, or manually integrate the two changes in the included file in your copy.  Without these changes, the computer name and domain join logic won’t work.)
• Copy the single Microsoft.BDD.DJoin.exe file in the extracted “Tools” folder to the “Tools\x64” folder on your MDT deployment share.
• Copy the files in the extracted “Templates” folder to the “C:\Program Files\Microsoft Deployment Toolkit\Templates” folder (or an alternate path if you installed MDT somewhere else).

The task sequences are fairly simple, since they only need to support bare metal deployments.  The unattend.xml templates are also quite simple, since Nano Server doesn’t support nearly as many settings.

Note that this has only been tested with MDT build 8443; it may work with previous releases, but I haven’t explicitly tested it.  Also, this is an LTI-only solution at this point (although you could probably use the included files to create a ConfigMgr task sequence if you tried hard enough – just remember that the Microsoft.BDD.DJoin.exe executable looks at LTI variables, not OSD variables, and those variables need to be set in the global task sequence environment, e.g. via CustomSettings.ini or “Set Task Sequence Variable” steps.)

Creating a Nano Server Image

Well, first you need an image to deploy – the Nano Server media doesn’t include a deployable WIM, so you have to create one.  And sysprep isn’t an option either – all image creation steps are done offline.  So here are the steps to follow:

• Get a copy of the Windows Server 2016 media (Standard or Datacenter editions, available on MSDN or VLSC).
• Download and install the Nano Server Image Builder tool, which will help create the needed WIM file for MDT to deploy.
• Run the Nano Server Image Builder GUI wizard and choose “Create a new Nano Server image”:
  
• Specify the location of the Windows Server media (the path should not include the NanoServer folder itself, just use D:\ if using a mounted ISO):
  
• Specify that you want to use a “Physical machine image” (because that lets you create a WIM file that MDT can deploy, instead of a VHD/VHDX that it can’t) and then specify a path to save the WIM file:
  
• Select the components that you want to include in the image.  If you are going to use a physical machine, leave the “Server Core drivers” package selected; if you are going to use a VM, make sure to select the “Virtual machine deployment” component to get the Hyper-V drivers.  Including “Windows PowerShell Desired State Configuration (DSC)” is useful too (as you do need some way to configure the OS after it is installed), and having some sort of anti-malware is recommended too so include “Windows Server Antimalware” for Defender.  Beyond that, it depends on what you want the Nano Server to do.  In my case, I’ll use it as a file server, so I’ve selected the role for that:
  
• Specify a local Administrator account password and timezone, but leave the computer name blank.
  
• Don’t enable the Join Domain option, we’ll let MDT handle that later.  It is useful to enable WinRM and PowerShell remoting:
  
• You can specify advanced configuration options if you want (e.g. run a script after the installation completes), but we can skip that for this simple scenario and choose the “basic Nano Server image” option:
  
• Finally, click “Create” to generate the image.  (Notice that it shows you the PowerShell command that the wizard generated.)  The resulting WIM in my example case was 333MB.

Creating the Deployment Task Sequence

Now that we have the needed Nano Server WIM file, we shift over to MDT:

• Import the Nano Server WIM into an MDT deployment share, specifying a custom image file:
  
• Select the image you created in the previous activity (no setup files are needed):
  
• See the resulting operating system entry (with the SKU being “ServerDatacenterNano”):
  
• Create a new task sequence with whatever name and ID you want:
  
• Select either the “Nano Server Task Sequence” or “Nano Server (VHD Boot) Task Sequence” template (depending on whether you prefer a normal boot or boot from VHD server setup – the Nano Server team would recommend boot from VHD so that you could replace the OS at a later point in time):
  
• Select the Nano Server WIM that you imported previously:
  
• Complete the new task sequence wizard however you want.

Deploying

With the task sequence created, deploying Nano Server using MDT is really no different than any other OS – almost.  Because Nano Server does not contain the full set of Win32 APIs, the MDT task sequence engine doesn’t run in Nano Server.  That means there’s no way to have the task sequence continue once the new Nano Server OS is installed, so the task sequence actually completes in Windows PE, before the OS boots for the first time.  After you click “Finish” on the summary wizard screen, the computer will reboot into Nano Server, and quickly be ready to log on, where you can see the Nano Server Recovery Console.

To see what that whole process looks like, check out the video below:

This is an “almost” real-time video.  I did remove one section that added six minutes to the overall deployment time (quadrupling the overall length).  So what did that section do?  It was the “Apply unattend.xml using DISM” portion of the “Install Operating System” step, which performs the offlineServicing entries from the unattend.xml.  It took an extra six minutes because I had imported the latest Windows Server 2016 (Windows 10) servicing stack and cumulative update packages (KB3199986 and KB3213986) into MDT to test the patch injection process of the task sequence.  While it worked fine (as long as the VM has enough memory allocated to it – since the injection happens in Windows PE and Windows PE isn’t using a pagefile, virtual memory can’t be used), it took a long time.  As an alternative, you could inject these into the WIM using the Nano Server Image Builder Tool.

In a lot of cases, you can complete the configuration of the machine remotely (using management tools or PowerShell).  If you want to automate that as part of the deployment process, you can, but that’s a scenario for you to explore yourself.  Remember the advanced options mentioned above when creating the Nano Server WIM file?  You could use those to inject a SetupComplete.cmd file (which runs in the LOCALSYSTEM context before the OS installation completes) to configure the new OS, maybe running a PowerShell DSC script to do that configuration.  Or you could copy those files in place using a step in the task sequence (the reason why there is an empty “Post-Install” group – that’s where you would want to do the copies).

Summary

As always, these files are provided as-is, with no support offered by Microsoft Support.  Feel free to e-mail me at mniehaus@microsoft.com if you have any questions or issues, or post comments to the blog.  I’m looking forward to the first comment from someone saying they implemented this successfully and deploying their first Nano Server using MDT

It seems a lot of blogs start off as either e-mail or IM conversations – this one is included in that category (thanks to Justin Chalfant).  The question is fairly simple:  How do you remove the “Contact Support” app from Windows 10 1607?  If you remember back to the original Windows 10 releases, this wasn’t possible – the app was considered a system app and couldn’t be removed.  That changed with Windows 10 1607, although not quite in the way you would expect: you can now remove the app, but there is a different process needed to do it.

It’s first useful to see how to do it manually through the UI.  Open up the “Settings” app and search for the “Manage optional features” page.  On it, you’ll likely see “Contact Support” at the top of the list, and if you select it, you’ll see an “Uninstall” button:

OK, so what if you wanted to automate that?  Well, then you need to understand that these “optional features” are part of the “Features on Demand v2” setup introduced in Windows 10 and maintained using the “capabilities” commands provided by DISM.  So to remove “Contact Support” you just need to run:

DISM /Online /Remove-Capability /CapabilityName:App.Support.ContactSupport~~~~0.0.1.0

So where did that capability name come from?  From a list of all currently-installed capabilities:

DISM /Online /Get-Capabilities

The same thing can be done via PowerShell if you prefer:

Get-WindowsCapability -online

Remove-WindowsCapability -online -name App.Support.ContactSupport~~~~0.0.1.0

And since PowerShell supports piping the results of one command to another you could do this in a single command even if you don’t care to type the whole name:

Get-WindowsCapability -online | ? {$_.Name -like ‘*ContactSupport*’} | Remove-WindowsCapability –online

You can do this as part of an image (removing the feature before sysprep and capture, or even offline) or after the OS is deployed.  And if it’s been removed, it shouldn’t come back when a new feature update is installed.

A common request from organizations is to have a way to hide some of the pages inside the Windows 10 “Settings” app, like you could do before with the Control Panel applets.  There is a new policy available in Windows 10 1703 that now enables this.  It’s available in Group Policy at “Computer Configuration –> Administrative Templates –> Control Panel” with the name “Settings Page Visibility”:

It’s also available via MDM, https://msdn.microsoft.com/en-us/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#settings-pagevisibilitylist.  Even if you aren’t using MDM management (e.g. Intune) today, be sure to read the information at the MDM link above, because it explains how to specify what pages you want to show and hide in the Settings app.

At a high level, all you need to do is specify a list of pages to show (if you want to be really limiting) or hide (if you just want to get rid of a few).  To do this, you can specify string like this:

showonly:windowsupdate;bluetooth

hide:windowsupdate;bluetooth

So you specify a prefix of either “showonly:” or “hide:”, and then the short URIs (without the “ms-settings:” prefix) of the pages you want to show or hide; multiple pages are separated by semicolons.

Let’s look at each one of those to see exactly what it looks like, first starting with the “extreme” of showing only the two pages specified.  First, we need to set the policy:

To make sure the policy is applied and respected, close the Settings app (if it’s opened) and then update the policy on the local computer with the command “gpupdate /target:computer”.  If everything was done properly, this is what you should see as the result, showing just the categories containing the pages specified:

And if you click on either of those, you’ll see just the pages enabled, e.g.:

If you flip that policy around to just hide those pages:

And again do the “gpupdate /target:computer” (elevated), you should then see this:

Much more subtle – you have to drill into the categories to see that the pages are indeed hidden.  See under “Devices” that there is no “Bluetooth” page:

And that under “Update & Security” there is no “Windows Update” page:

That’s all there is to it – almost.  The only challenge then is knowing the URIs to specify.  Here’s a few of them (although you can probably find better lists through a Bing search), remove the “ms-settings:” prefix to specify them in the policy:

• ms-settings:about
• ms-settings:activation
• ms-settings:appsfeatures
• ms-settings:appsforwebsites
• ms-settings:backup
• ms-settings:batterysaver
• ms-settings:bluetooth
• ms-settings:colors
• ms-settings:cortana
• ms-settings:datausage
• ms-settings:dateandtime
• ms-settings:defaultapps
• ms-settings:developers
• ms-settings:deviceencryption
• ms-settings:display
• ms-settings:emailandaccounts
• ms-settings:extras
• ms-settings:findmydevice
• ms-settings:lockscreen
• ms-settings:maps
• ms-settings:network-ethernet
• ms-settings:network-mobilehotspot
• ms-settings:network-proxy
• ms-settings:network-vpn
• ms-settings:network-directaccess
• ms-settings:network-wifi
• ms-settings:notifications
• ms-settings:optionalfeatures
• ms-settings:powersleep
• ms-settings:printers
• ms-settings:privacy
• ms-settings:personalization
• ms-settings:recovery
• ms-settings:regionlanguage
• ms-settings:storagesense
• ms-settings:tabletmode
• ms-settings:taskbar
• ms-settings:themes
• ms-settings:troubleshoot
• ms-settings:typing
• ms-settings:usb
• ms-settings:windowsdefender
• ms-settings:windowsinsider
• ms-settings:windowsupdate
• ms-settings:yourinfo

Curious what pages these point to?  Try them out by pressing Windows-R to get a “Run” dialog, then type in the full string, e.g. “ms-settings:yourinfo” as the command line.  That will take you to the page you specified.  (And no, I didn’t test each one of these – if one doesn’t work, i.e. it takes you to the main settings page, then it must be invalid.  Some seem a little slow to open too, so be patient.)

Have fun

If you watched the Microsoft Mechanics video on MBR2GPT, the new tool for converting disks from MBR layout to GPT layout as part of the BIOS to UEFI conversion process, you may have spied an MDT task sequence being used.  I thought it would be useful to provide those as samples that you could use in case you want to perform this process using MDT.

First, it’s worth pointing out that there are a few different scenarios that you might want to do:

• Converting an existing Windows 10 installation.  If you have a PC running Windows 10 with BIOS emulation, you can switch it in two different ways:
  • If you are already running Windows 10 1703, the process can be initiated from within the currently running OS, converting the disk layout and modifying the firmware settings, followed by a reboot.
  • If you are running an earlier version of Windows 10, the process can be initiated from within Windows PE from the ADK 1703 release, requiring a little extra work:  Reboot from the full OS into Windows PE, convert the disk layout, modify the firmware settings, then boot back into Windows 10.
  • You could also boot to a Windows PE 1703 boot image, then run a simple task sequence that converts the disk and modifies the firmware, booting back into the OS when done.
• Converting as part of a Windows 10 upgrade.  This is actually very similar to previous processes:  Complete the upgrade, then convert the disk layout and modify the firmware settings.
• Converting as part of a Windows 10 wipe-and-load (refresh) deployment.  This adds a couple of steps to the task sequence, adding steps after the new OS image has been deployed but before it has booted for the first time, running steps in Windows PE to convert the disk layout and to modify the firmware settings.

So the attached zip file includes sample task sequences for all of these.  Extract the zip file, open it with MDT 8443 as a new deployment share, then look at the task sequences.  (Remember you can copy-and-paste between task sequences, if you want to copy the steps into your own task sequences.)  I’ve stripped this deployment share down to the bare minimum, so you don’t need to download gigabytes worth of stuff, so don’t expect it be usable as-is.  But it does contain all the pieces you need:

• Task sequences
  • Convert BIOS to UEFI (OS).  A task sequence designed to run in the full OS (modify firmware settings, convert disk layout, initiate reboot).
    
    A few comments on this one:  The “Convert” group has a condition that will only run if the machine isn’t presently using UEFI boot.  The “Lenovo” step has a condition that will only run it on Lenovo PCs; you would need to add similar steps for other OEMs.
  • Convert BIOS to UEFI (OS-PE-OS).  A task sequence designed to be initiated from Windows 10 (any version) that performs the conversion from Windows PE (boot to PE, modify firmware settings, convert disk layout, boot back to OS).
    
    Comments:  Similar to the previous task sequence, with extra steps to get from the current OS to Windows PE and then back again.  (This is the only task sequence that requires the modified ZTIBCDUtility.vbs script.)
  • Convert BIOS to UEFI (PE).  A task sequence designed to be initiated from Windows PE (boot from USB or PXE, modify firmware settings, convert disk layout).
    
    Comments: This is actually identical to the first task sequence, without the FinishAction that makes the machine reboot.  (It will reboot automatically after the task sequence completes and you click “Finish” on the summary wizard.)
  • Convert with Refresh to Windows 10 Enterprise 1703 x64.  A standard refresh task sequence with extra steps added (modify firmware settings, convert disk layout) before the new OS boots for the first time.
    
    Comments: The new steps are added right before booting into the new OS.  There might be other places that these steps could be placed, but these worked well for me.
  • Convert with Upgrade to Windows 10 Enterprise 1703 x64.  A standard upgrade task sequence with extra steps added (modify firmware settings, convert disk layout) after the upgrade completes.
    
• Scripts
  • Lenovo_UEFI.vbs.  A (very short) custom script to enable UEFI and Secure Boot on Lenovo PCs.  (I just happened to have Lenovo ThinkPad devices available for testing.  One thing that impresses me about these machines:  You don’t need any extra software to configure the firmware, the settings are exposed in WMI automatically.)
  • ZTIBCDUtility.vbs.  A modified version of the built-in MDT script to support the “OS-PE-OS” task sequence.  (In case you’re curious, check out the changes in the “AdjustBCDDefaults” function.  These changes make sure that MDT doesn’t make the Lite Touch Windows PE the default, which the MBR2GPT tool doesn’t like.  With the change, the PE boot image is set up as a one-time boot image.)
  • LTIBootback.wsf.  A new script designed to boot back into the current OS for the “OS-PE-OS” task sequence.  (This script removes the PE boot image BCD entry and deletes the boot.wim, before booting back to the full OS.)

I would suggest copying the task sequences (using Workbench) into your task sequence, then manually copying all the scripts from the “Scripts” folder of the downloaded deployment share into your own share’s “Scripts” folder (overlaying the ZTIBCDUtility.vbs file).  For the upgrade and refresh task sequences, you’ll then need to edit the copies to “reattach” a Windows 10 1703 OS to them.

As always, these are provided as-is, provided as samples.  They work for me

Download: bios2uefi

We’ve had a few Windows 10 releases now, and each release has its own set of language packs.  For organizations with Windows 10 Enterprise E3 or E5 subscriptions (formerly called Software Assurance) we recommend that you get your media from the Volume Licensing Service Center (VLSC).  Once there, you can access the downloads from the “Downloads and Keys” link.

Some have pointed out that it can be a little challenging to find the language packs corresponding to each release, so here’s a quick reference to point you to the right ones.

Windows 10 Enterprise 1511

This seems to be the one that people find most easily – even when it’s not what they’re looking for.  To find this one, search for “Windows 10 Enterprise Language Pack” (or just “Windows 10 Enterprise” and find it in the list).  When you click the “Download” link and then the “Continue” button, you’ll see one available ISO:

Notice the “Released Nov ‘15” text?  That’s how you can tell it’s for Windows 10 1511.  And notice that I selected “English” as the language, which then showed an ISO that contained every language pack.  That becomes more important on the next one…

Windows 10 Enterprise 1607

The Windows 10 Enterprise 1607 language packs are published with a “MultiLanguage” language, which is why people usually struggle to find them.  Change the “Language” drop down to “MultiLanguage” and then search to see this:

In this case “Released Jul ‘16” means Windows 10 1607.

Windows 10 Enterprise 1703

You won’t find any Windows 10 Enterprise 1703 bits of any kind on VLSC yet.  As we announced earlier in April, those won’t be available until May 1st.  But when they are published, the language packs should appear in the same list of results that you get when searching for “MultiLanguage” – you’ll then see two ISOs instead of one.

If you looked in WSUS or ConfigMgr recently, you may have noticed that the naming pattern for some of the most recent new updates has changed – there is now a definite, consistent pattern that looks like this:

[Release] [Update description] for [OS] [Version] for [Arch]-based Systems [KB]

So what are each of those components?  Let’s look at each one.

Release

Update names start off with the year and month that they were released, using a YYYY-MM format that makes it easy to sort the updates by their release date.  For example, updates released in May 2017 will start with “2017-05.”

Update description

There are various types of updates that are released.  Examples (which vary by OS and version) include:

• Cumulative Update
• Update
• Security Update for Adobe Flash Player
• Security Only Quality Update
• Security Monthly Quality Rollup

In most cases, these aren’t any different than what you saw on older updates – the only real difference is that the names are prefixed with the release date, as mentioned above.

OS and Version

Each update will indicate the OS and version that it applies to.  For example:

• Windows 10 Version 1703
• Windows 10 Version 1607
• Windows 10 Version 1511
• Windows 10 Version 1507
• Windows 8.1
• Windows 7
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2

Arch

Updates are architecture-specific.  In the past, the x86 updates weren’t qualified, but the x64 ones were, so you could identify x86 updates by the absence of an “x64” label.  Now they will be explicit:

• x86 (e.g. “for x86-based Systems”)
• x64 (e.g. “for x64-based Systems”)

KB

Finally, each released update is assigned a specific KB number.  This will be included in parenthesis at the end of the name, e.g. “(KB1234567)”.

Putting it all together

Here’s an example showing two updates in WSUS (related to the new update options blog post from last week) that use the new naming pattern:

Expect to see quite a few more of those very soon, in WSUS and in System Center Configuration Manager.

If you read about the issue with the ADK 1703 release that Aaron blogged about here, you know that there’s an issue installing the new ADK on Windows 10 and Windows Server 2016 if you are running Secure Boot (which you should be running and shouldn’t turn off).  This is due to an improperly signed WIMMOUNT driver included in the ADK; we’re working on finding a way to publish an updated driver that is signed.  There are two symptoms:

• A popup from the Program Compatibility Assistant during the ADK installation.
• A failure to mount any WIMs after ADK 1703 is installed.  That manifests itself in MDT like this:

The interesting part of this:  The driver included in the OS itself would work fine; it’s already properly signed.  So just use that one instead of the one in the ADK.  There’s probably several ways to go about this, but I’ll stick with simple:  Use REGEDIT.EXE, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WIMMount, and edit the ImagePath value.  It starts off like this:

Change the ImagePath to instead be:

And presto, now you can mount WIMs again:

Our goal overall with the changes that we made to the Windows as a service terminology was simple:  Make it easier to understand.  As for the old “Current Branch” and “Current Branch for Business” terms, just forget them and focus on these simple ideas:

• Windows 10 will have new features updates released to the Semi-Annual Channel twice per year, around March and September.
• Each feature update will be serviced for 18 months from the date of release.
• Office 365 ProPlus is doing the same thing.

If you understand those points, then you understand the terminology – the focus then should be on the process that you need to go through, the tools that are available to help, etc.  For that, start with the http://aka.ms/waas documentation, as well as the Microsoft Mechanics video on YouTube.

Shortest blog ever (and now fixed to be grammatically correct)

When you install Windows 10 using SETUP.EXE, or any time you install a new feature update either using SETUP.EXE from media or installing via the Windows Update agent, the installation process will attempt to grab a set of additional “stuff” to make the installation process go as smoothly as possible.

The simplest way to see all of this work:  Take a virtual machine running Windows (any applicable version or SKU).  Make sure the machine isn’t joined to a domain (you don’t want WSUS polices to get in the way).  Then make the task harder by installing some language packs manually using the Settings app.  Navigate to Time & language –> Region & language and then add one or more language packs.  (It’s best doing this before patching the OS, since installing a language pack will require reinstalling the latest cumulative update.)

It’s easiest to kick off an upgrade manually using Windows 10 1703 media.  Insert the ISO, or use an extracted copy, and run “SETUP.EXE /AUTO UPGRADE”.  Once the upgrade is complete, take a look at the C:\WINDOWS\PANTHER\SETUPACT.LOG file to see what happened.  Search for “DU Client Application Information” to find all the dynamic update checks.  Here’s an example, shortened some to remove some of the noise:

2017-09-29 21:05:31, Info                  SP     DU Client Application Information
…
2017-09-29 21:05:31, Info                  SP     Executing download operation: Download Language Pack Dynamic Updates
…
2017-09-29 21:05:31, Info                  SP     Searching for dynamic updates
2017-09-29 21:05:31, Info                  SP       Update types:
2017-09-29 21:05:31, Info                  SP         Component updates
2017-09-29 21:05:31, Info                  SP       Category IDs:
2017-09-29 21:05:31, Info                  SP         6111a83d-7a6b-4a2c-a7c2-f222eebcabf4
…
2017-09-29 21:05:31, Info                  SP     1 updates were found

You should see a few of them:

• Setup updates (category e4b04398-adbd-4b69-93b9-477322331cd3)
• Critical dynamic updates
  • Component updates (category e4b04398-adbd-4b69-93b9-477322331cd3)
  • Driver updates (category e4b04398-adbd-4b69-93b9-477322331cd3)
• OS updates
  • Component updates (category abc45868-0c9c-4bc0-a36d-03d54113baf4)
• Driver updates
  • Driver updates (categories 405706ed-f1d7-47ea-91e1-eb8860039715, 34f268b4-7e2d-40e1-8966-8bb6ea3dad27, 0ba562e6-a6ba-490d-bdce-93a770ba8d21, 06da2f0c-7937-4e28-b46c-a37317eade73)
• Language pack updates
  • Component updates (category 6111a83d-7a6b-4a2c-a7c2-f222eebcabf4)

That should raise at least one question:  What are those category IDs?  Well, it turns out that they aren’t really categories at all, at least not in WSUS terminology.  Instead, they map to “products.”  If we get a list of the products from WSUS using the “Get-WsusProduct” PowerShell cmdlet (available on Windows Server 2016), you can see these items for Windows 10:

Title                                                                               ID
-----                                                                               --
Windows 10 and later drivers                                                        05eebf61-148b-43cf-80da-1c99ab0b8699
Windows 10 and later upgrade & servicing drivers                                    34f268b4-7e2d-40e1-8966-8bb6ea3dad27
Windows 10 Anniversary Update and Later Servicing Drivers                           bab879a4-c1af-4b52-9617-0f9ae1286fb6
Windows 10 Anniversary Update and Later Upgrade & Servicing Drivers                 0ba562e6-a6ba-490d-bdce-93a770ba8d21
Windows 10 Creators Update and Later Servicing Drivers                              cfe7182c-14a0-4d7e-9f5e-505d5c3a66f6
Windows 10 Creators Update and Later Servicing Drivers                              f5b5092c-d05e-4eb1-8a6a-919770378ff6
Windows 10 Creators Update and Later Upgrade & Servicing Drivers                    06da2f0c-7937-4e28-b46c-a37317eade73
Windows 10 Dynamic Update                                                           e4b04398-adbd-4b69-93b9-477322331cd3
Windows 10 Feature On Demand                                                        e104dd76-2895-41c4-9eb5-c483a61e9427
Windows 10 GDR-DU LP                                                                6111a83d-7a6b-4a2c-a7c2-f222eebcabf4
Windows 10 GDR-DU                                                                   abc45868-0c9c-4bc0-a36d-03d54113baf4
Windows 10 Language Interface Packs                                                 7d247b99-caa2-45e4-9c8f-6d60d0aae35c
Windows 10 Language Packs                                                           fc7c9913-7a1e-4b30-b602-3c62fffd9b1a
Windows 10 LTSB                                                                     d2085b71-5f1f-43a9-880d-ed159016d5c6
Windows 10 S and Later Servicing Drivers                                            c1006636-eab4-4b0b-b1b0-d50282c0377e
Windows 10                                                                          a3c2375d-0c8a-42f9-bce0-28333e198407

I highlighted all of the matching items from the SETUPACT.LOG list – they line up nicely (well, except for one of the driver ones, but we’ll leave that mystery for another time).  Some of you asked what these categories were for when they showed up in WSUS – now you know.  Originally, if you selected these products in WSUS, you never saw any updates show up for them.  But that’s no longer the case – some of these will have something in them.

But before we enable those, it’s useful to do one more test:  Do another upgrade, but this time, point the machine at a WSUS server.  (You can do this via local GPO if you want to keep your AD domain out of the way.)  Afterwards, again look at the “DU Client Application Information” sections.  Here’s one example (again cutting out some of the noise):

2017-09-29 23:30:10, Info                  SP     DU Client Application Information
…
2017-09-29 23:30:10, Info                  SP     Executing download operation: Download Language Pack Dynamic Updates
…
2017-09-29 23:30:10, Info                  SP     Searching for dynamic updates
2017-09-29 23:30:10, Info                  SP       Update types:
2017-09-29 23:30:10, Info                  SP         Component updates
2017-09-29 23:30:10, Info                  SP       Category IDs:
2017-09-29 23:30:10, Info                  SP         6111a83d-7a6b-4a2c-a7c2-f222eebcabf4
…
2017-09-29 23:30:10, Info                  SP     No updates to download. Leaving...

And that illustrates the problem:  When your devices point to WSUS, they can’t get the needed packages for dynamic update to work, so it doesn’t do anything – no patches, no drivers, no language packs, no updated compatibility information, etc.

OK, so now let’s go back to WSUS and enable the categories highlighted above.  Once you do that and synchronize, you’ll see a bunch of new updates are found.  If you look at the “All updates” view sorted by the arrival date descending, you can see all of them in the list.  But I prefer to create a better view.  Right click on “Updates” and choose “New update view".  Choose “Updates are for a specific product”, and then select the products highlighted above:

Select the new view, and change the criteria at the top to “Any Except Decline” and “Any,” then refresh to see the full list.  These are all the updates that dynamic update could seek out.  If you add the “Classification” column to the list, you can see that there are critical updates, security updates, and updates, and there are lots of language packs and related language packages in the list.  Also notice that there are no drivers, as those aren’t published to WSUS.  (That’s probably a good thing, as there would be lots of them.)

Now let’s take the next step:  Select all of those items and approve them for “All computers” and for “install.”  Make sure your server has sufficient disk space, that’s a lot of language packs.)  That will take a while, first to approve the updates, and then to download all the needed stuff.  A good time for a lunch/dinner/weekend break, a stroll through the park, etc.

Once everything is downloaded, we’re ready to try again, upgrading from Windows 10 1607 (with an extra language installed) to Windows 10 1703.  Again, I’ll use media and kick off the upgrade using “SETUP.EXE /AUTO UPGRADE”.  After it finishes, the SETUPACT.LOG again provides a view into what happened, in this case for language packs:

2017-09-30 11:17:07, Info                  SP     DU Client Application Information
…
2017-09-30 11:17:07, Info                  SP     Executing download operation: Download Language Pack Dynamic Updates
…
2017-09-30 11:17:07, Info                  SP     Searching for dynamic updates
2017-09-30 11:17:07, Info                  SP       Update types:
2017-09-30 11:17:07, Info                  SP         Component updates
2017-09-30 11:17:07, Info                  SP       Category IDs:
2017-09-30 11:17:07, Info                  SP         6111a83d-7a6b-4a2c-a7c2-f222eebcabf4
…
2017-09-30 11:17:08, Info                  SP     1 updates were found

Yeah!  And we can confirm that with PowerShell by running “Get-WindowsCapability -online” to see what’s installed:

Name  : Language.Basic~~~en-US~0.0.1.0
State : Installed

Name  : Language.Basic~~~de-DE~0.0.1.0
State : Installed

Name  : Language.Handwriting~~~en-US~0.0.1.0
State : Installed

Name  : Language.Handwriting~~~de-DE~0.0.1.0
State : Installed

Name  : Language.OCR~~~en-US~0.0.1.0
State : Installed

Name  : Language.OCR~~~de-DE~0.0.1.0
State : Installed

Name  : Language.Speech~~~en-US~0.0.1.0
State : Installed

Name  : Language.Speech~~~de-DE~0.0.1.0
State : Installed

Name  : Language.TextToSpeech~~~en-US~0.0.1.0
State : Installed

Name  : Language.TextToSpeech~~~de-DE~0.0.1.0
State : Installed

Name  : Language.UI.Client~~~en-US~
State : Installed

Name  : Language.UI.Client~~~de-DE~
State : Installed

That looks good, two languages (English and German) with all the needed language pieces in place.  (That’s a separate conversation that I think I’ve blogged about before – you need several components to have full support for a new language.)

Another difference that can be seen:  Even though I’m using the original Windows 10 1703 ISO (build 15063.0), the upgraded machine has a later patch installed:

That’s not the absolute latest build (15063.540 installed, latest patch would be 15063.632 at the time of writing), but it is the expected result:  The dynamic update process doesn’t necessarily grab the latest update, it grabs the latest cumulative update tagged as a dynamic update.  So it should be no big surprise that when you check for updates after upgrading, it finds updates to install:

But that does illustrate one other important point:  All of those dynamic updates that I approved are only used by the SETUP installation process (again, whether initiated from media, from WSUS, etc.).  You’re not going to suddenly see all of your machines trying to install lots of language packs after you approved them in WSUS.

Thanks to Sudhagar Thirumoolan for getting the needed packages published to WSUS to make this work, and to former WSUS PM Steve Henry for repeatedly saying this was possible.

Some of you might be thinking “what about ConfigMgr.”  The challenge there is that you would need to go through the same WSUS steps to make this work with ConfigMgr (task sequences or Windows 10 servicing), and the ConfigMgr team doesn’t support that sort of manipulation.

In the future, we’ll be making some changes to the way these components are published, as part of the Unified Update Program work.  Once that’s done, then this will be much easier:  Everything needed will be part of the same package bundle.  As mentioned at Ignite this week, that bundle will be large (since it contains language packs, cumulative updates, features on demand, and more), but clients will be smart enough to only download what they need.  Stay tuned for more on that.

Some of you may have seen me do a demo at previous events showing how you could change from Windows 10 Pro to Windows 10 Enterprise, just by changing the product key – the change is immediate, no reboot is required.  That capability was added in Windows 10 1607.

Now in Windows 10 1709, we’ll add one more OS into the fold.  Now you can also change from Windows 10 Enterprise to Windows 10 Education, again just by changing the product key.  Here’s a short video showing how to do this:

In case you are wondering, the product keys shown in that video are publicly documented at https://technet.microsoft.com/en-us/library/jj612867(v=ws.11).aspx – they don’t actually activate the OS, they just cause it to try to find a KMS server that can activate it.

We announced a similar capability recently, Windows 10 Subscription Activation, which leverages the same technology behind the scenes, but today that only supports stepping up from Windows 10 Pro to Windows 10 Enterprise.  Check out the Ignite session that Kamal and I did on this topic, available at https://myignite.microsoft.com/sessions/53410.  The ability to support stepping up from Windows 10 Pro to Windows 10 Enterprise automatically through Subscription Activation is something we’re looking at for the future.

p.s. One of the questions asked at Ignite, and more recently on Twitter, was how to move from Windows 10 Enterprise LTSB to Windows 10 Education.  While you can’t upgrade directly from Windows 10 Enterprise LTSB to Windows 10 Education, you can instead upgrade from Windows 10 Enterprise LTSB to Windows 10 Enterprise 1709, then use the mechanism I described above to change the product key to Windows 10 Education – one additional step in the process.

Since we’ve started talking about Windows as a service (almost three years ago now), we’ve published a lot of good information.  And while most people know about the main set of documentation (http://aka.ms/waas) and the Microsoft Mechanics video (http://aka.ms/waasvideo), there are some other sources of information that are also useful to help connect the dots between the theory and the current state.  Here’s an overview of some key resources:

• The Windows lifecycle fact sheet.  This page includes an “Updates and Service Packs” section that provides the expected end of servicing dates for each Windows 10 feature update, so you’re never surprised by one of the dates.  For example, here you can see that Windows 10 1511 end of servicing date is October 10, 2017 (this week), the Windows 10 1607 end of servicing date is tentatively March 2018 (effectively no earlier than that, although it could shift a little later), etc.  And of course the "End of support” table contains a good reminder of the Windows 7 end of support date, January 14, 2020.
• The Windows 10 release info page, http://aka.ms/win10releaseinfo.  This page shows the status of each release, the date of release, and all of the cumulative updates that have been released.  This is a good reference site.  (It doesn’t include the end of servicing dates yet, but we expect this page to be reworked sometime next year to include this information.)
• The Windows 10 release notes page, http://aka.ms/win10releasenotes.  This page provides details on significant fixes included in each cumulative update.
• The Configuration Manager team publishes details to tell you which releases of Windows 10 and the Windows 10 ADK are supported by each Configuration Manager current branch release on their Support for Windows 10 for System Center Configuration Manager page.
• We publish an overview of new features in each Windows 10 feature update at https://docs.microsoft.com/en-us/windows/whats-new/.
• We publish (and recently updated) the Windows Roadmap page to talk about features recently delivered, ones in preview, ones in development, etc.
• For long-term servicing releases, the end of support dates can be found via the Support Lifecycle search page.

In one of the sessions that we did at Ignite around Windows 10 Subscription Activation, we included this slide that talked about the progression that has been made through the years in simplifying the process of changing the installed SKU of Windows, primarily between Windows Pro and Windows Enterprise:

Judging from the reaction to my other blog that talked about the one new path that we added with Windows 10 1709 to easily change between Windows 10 Enterprise and Education SKUs, it appears that there are lots of people that aren’t familiar the options that are available, or even how those options changed over the years.

To remedy that, let’s give you a history lesson, similar to what’s in the Ignite session recording:

• With Windows 7, if you wanted to change from Windows 7 Professional to Windows 10 Enterprise, you had to redeploy the operating system – a full wipe-and-load process.
• With Windows 8.1, we added support for a Windows 8.1 Pro to Windows 8.1 Enterprise in-place upgrade (considered a “repair upgrade” because the OS version was the same before and after).  This was a lot easier than wipe-and-load, but it was still time-consuming.
• With Windows 10 1507, we added the ability to install a new product key via a provisioning package or using MDM to change the SKU.  This would require a reboot, which would install the new OS components.  This took several minutes to complete, but it was a lot quicker than in-place upgrade.
• With Windows 10 1607, we made a big leap: Now you can just change the product key and the SKU instantly changes from Windows 10 Pro to Windows 10 Enterprise.  In addition to provisioning packages and MDM, you can just inject a key using SLMGR.VBS (which just injects the key into WMI), so it’s now trivial to do this via a command line too.
• With Windows 10 1703, we made this “step-up” from Windows 10 Pro to Windows 10 Enterprise automatic for those that subscribed to Windows 10 Enterprise E3 or E5 via the CSP program.
• With Windows 10 1709, we added support for Windows 10 Subscription Activation, very similar to the CSP support but for large enterprises, enabling the use of Azure AD for assigning licenses to users; when those users sign in to an AD or Azure AD-joined machine, it automatically steps up from Windows 10 Pro to Windows 10 Enterprise.

Enough history lesson then.  Let’s switch to “how-to” and focus on the most common scenarios today.

Scenario #1:  Using KMS for activation, just purchased Windows 10 Enterprise E3 or E5 subscriptions (or for some reason have had an E3 or E5 subscription for a while but haven’t yet deployed Windows 10 Enterprise), and you are using Windows 10 1607 or above.

All you need to do to change all of your Windows 10 Pro machines to Windows 10 Enterprise is to run this command on each machine:

cscript.exe c:\windows\system32\slmgr.vbs /ipk NPPR9-FWDCX-D2C8J-H872K-2YT43

In case you are wondering, that key came from https://technet.microsoft.com/en-us/library/jj612867(v=ws.11).aspx.  It causes the OS to change to Windows 10 Enterprise and then seek out the KMS server to reactivate.  (And yes, if you really want to, you can inject the Windows 10 Pro key from that page to step back down from Enterprise to Pro.)

Scenario #2:  Using Azure AD-joined devices or Active Directory-joined devices, with Azure AD synchronization set up (“hybrid join,” as discussed in the video above), and you are using Windows 10 1709 or above.

All you need to do is to follow the steps in https://docs.microsoft.com/en-us/windows/deployment/windows-10-enterprise-subscription-activation to acquire a $0 SKU to get a new Windows 10 Enterprise E3 or E5 license in Azure AD, then assign that license to all of your Azure AD users (which can be AD-synced accounts).  Then the device will automatically change from Windows 10 Pro to Windows 10 Enterprise when that user signs in.

Summary

If you have a Windows 10 Enterprise E3 or E5 subscription, but are still running Windows 10 Pro, it’s really simple (and quick) to move to Windows 10 Enterprise using one of the scenarios above.

If you’re running Windows 7, it can be a lot more work.  While a wipe-and-load approach works fine, it would be easier to upgrade from Windows 7 Pro directly to Windows 10 Enterprise (yes, that’s a supported path) which takes care of the move in one hop.  (That works for Windows 8.1 Pro as well.)

With the release of Windows 10, the Windows Update log changed from a text file to a binary file.  A new PoweShell cmdlet, Get-WindowsUpdateLog, was added to format the binary file, generating the equivalent text file that many of you were used to.  But there was one challenge:  The formatting process required access to Windows symbols.  As long as the corresponding symbols were available on the Microsoft symbol server (typically used by developers to debug Windows) and you were able to reach the symbol server (on the internet, potentially via a proxy), the formatting would work fine. 

But sometimes the formatting didn’t work fine, typically because the symbols weren’t available.  That was usually a temporary situation, waiting for the symbols to be uploaded to the server and indexed, but it seems it would always happen when people had a need to format the log.

With Windows 10 1709 (including in the current Insider Preview builds), the formatting process has changed.  You still need to use the Get-WindowsUpdateLog cmdlet to format it, but it no longer needs access to the symbols to do that formatting.  Notice this screenshot:

Even though the computer has no network connection at all (see the icon at the bottom right), the Get-WindowsUpdateLog worked successfully.  And more importantly, we end up with a usable log file:

Happy formatting

As discussed in the documentation at https://docs.microsoft.com/en-us/windows/deployment/windows-10-auto-pilot, you can harvest the hardware details from existing Windows 10 devices, then upload those to AutoPilot via the Microsoft Store for Business, the Partner Center, or Intune (coming soon).  I published a PowerShell script called Get-WindowsAutoPilotInfo to the PowerShell Gallery that helps with gathering that info and formatting it into a CSV-style file that can be uploaded.

In order to gather the hardware details, the device must be running Windows 10 1703 or later and the script needs to be run with admin rights (elevated when running locally).  It can’t run on earlier versions of Windows, nor will it run in Windows PE.

It is possible to gather hardware details remotely, accessing WMI over the network, but the remote machine still needs to be running Windows 10 1703 or later.  With the most recent script update published last week, you can optionally provide credentials for connecting to the remote machine (not supported for the local machine); just add the “-Credential” parameter (along with the -ComputerName parameter) and specify either a PSCredential object or a user ID (which would result in prompting for the password).

If you are trying to gather the hardware details remotely, you will need to make sure that the Windows Firewall enables access to WMI.  To do that, open the “Windows Defender Firewall” control panel and click on “Allow an app or feature through Windows Defender Firewall.”  Find “Windows Management Instrumentation (WMI)” in the list and enable for both Private and Public, then click OK:

Or you can do the same thing via Group Policy – nothing special about what the script is doing, it just needs remote WMI access to the classes that contain the details.  The script should also accept a piped-in list of computer names, so you could grab them from AD or ConfigMgr and do a whole batch at once.

Some have also asked if it’s possible to have ConfigMgr inventory these details.  Due to the length of the hardware hash (4KB), that doesn’t work.  You could use ConfigMgr to run the PowerShell script on each machine, then collect the resulting CSV files.

If you’ve watched the Microsoft Mechanics video or Ignite sessions (presented by Sidd or me) on Windows AutoPilot, you’ve seen what is supposed to happen:

• Manually choose language, region, keyboard
• Connect to a network (if not wired)
• Azure AD authentication using custom branding (org name, icons, etc.)
• The device is joined to Azure AD
• Automatic MDM enrollment (as configured in Azure AD)
• Automatic logon as the specified Azure AD user
• MDM configuration is applied (with progress display if configured)

But what if that isn’t what actually happens?  The following sections provide some troubleshooting suggestions.

Manually choose language, region, keyboard

If you don’t see these standard out-of-box experience (OOBE) screens, there is either something wrong with your OS image, an unexpected unattend.xml being used, or OOBE was partially completed before the computer restarted.  Either start from scratch with a good image, or complete OOBE the rest of the way creating a local account, then reset the OS from the Settings app to start over.

A tip:  If you are using a Hyper-V virtual machine, configure the VM to create standard (not production checkpoints).  Create a checkpoint before the VM is powered on for the first time.  Then start the VM and let it get to the first OOBE screen to choose a language before creating a second checkpoint.  These checkpoints give you an easy way to repeatedly test the process.  (The first one gives the full experience; the second just saves little time.)

Another tip (as covered in my Ignite session):  You can capture the hardware hash from the machine after it gets to the language screen in OOBE.  Press Shift-F10 to open a command prompt, then run PowerShell.exe.  From there, you can set the execution policy to a reasonable level (RemoteSigned or Bypass) and then install and run the Get-WindowsAutoPilotInfo.ps1 script to create a CSV file with the hardware details.  Copy that CSV file to a network location or USB key, then import it into the Microsoft Store for Business.  The machine is still early enough in the process that it hasn’t yet checked to see if it is known to AutoPilot.  Just exit out of PowerShell and the command prompt after you’ve uploaded the machine.  (See https://blogs.technet.microsoft.com/mniehaus/2017/12/12/gathering-windows-autopilot-hardware-details-from-existing-machines/ for more on Get-WindowsAutoPilotInfo.)

Connect to a network (if not wired)

If the machine doesn’t have a wired connection and it has a wireless adapter, you should be prompted to connect to an available wireless network.  If you don’t have any wired or wireless adapters, nothing is going to help – OOBE is going to short-circuit and end up creating a local account.  Assuming you have an wireless adapter, you should be able to connect to a wireless network, even if it requires a captive portal – if it does, you should see a browser window open.

So what can go wrong here?  Proxy servers can cause challenges if they aren’t automatically discoverable (e.g. WPAD) or if they require user authentication (there’s no user yet).  Wireless networks that require certificates likely won’t work as there will not yet be any certificates.  Firewalls might make Windows think that there isn’t a path to the internet.

We’re talking about basic network troubleshooting here, so you may want to use Shift-F10 to open a command prompt for further troubleshooting (IPCONFIG, NSLOOKUP, PING, etc.).

Azure AD authentication using custom branding (org name, icons, etc.)

After the network connection is in place, Windows will check with the AutoPilot deployment service (in the cloud) to see if the device is known.  If it is, then the customized branding can be displayed with the org name and logo.  The customizations you should see are highlighted in red:

If the device isn’t configured to AutoPilot, then you get standard choices (personal vs. work/school if running Windows 10 Pro, a generic Azure AD sign-in screen with Windows 10 Enterprise, OneDrive, Cortana, privacy, etc.).  What if you don’t get what you expect?  There are a few possible causes:

• The device really isn’t defined to AutoPilot.  A simple way to verify is to gather the hardware details again, then either search for the same machine in the existing list or just try to upload it again to see if you get an error about it being a duplicate.  (Note that significant changes to the hardware, e.g. swapping out the motherboard, can change the hardware hash.  Also, make sure that your device has a serial number, as the script expects that.  Some devices, e.g. Intel NUCs, don’t have a serial number by default.  See http://amicasto.com/2017/11/22/customizing-intel-nuc-bios-with-intel-integrator-toolkit/ for details.)
• The Azure AD tenant doesn’t have an Azure AD Premium license (or an equivalent suite license such as EM+S E3).  That’s required for customized branding.  (Interestingly, the license doesn’t have to be assigned to the user – at least not for this piece.  That’s required in the next step though.)
• You haven’t configured the company branding settings in Azure AD.  See the Azure AD documentation for information about that.

Assuming you type in a valid username (UPN, e.g. user@contoso.com) and password, you should continue to the next step.

Azure AD Join

Now that the credentials have been validated, the next step is to join the device into Azure AD.  This is usually the easy piece, but there are some gotchas that can get in the way:

• Have you enabled the user to join devices to Azure AD?  That is an obvious requirement – in order for AutoPilot to be used by end users, all of them need to be able to join devices to Azure AD.  The steps to enable that are covered at https://docs.microsoft.com/en-us/azure/active-directory/device-management-azure-portal#configure-device-settings.  If the user doesn’t have rights, you’ll get error 801C0003 (“Something went wrong”):
   
• Has the user reached the maximum number of devices that they can join?  There can be a limit, but if you configure it to “unlimited” then you don’t need to worry about this one.  If you do set a limit and the user reaches the limit, you’ll get the same 801C0003 (“Something went wrong”) error as above.

Automatic MDM enrollment

Once the Azure AD join completes, the MDM enrollment will happen.  This automatic MDM enrollment is an Azure Active Directory Premium feature.  If that doesn’t happen as expected, here are some things to check:

• Was automatic MDM enrollment enabled?  This needs to be configured in Azure Active Directory via the Azure Portal.  See https://docs.microsoft.com/en-us/intune/windows-enroll#enable-windows-10-automatic-enrollment for details.  If this isn’t configured, you won’t see any errors, but the machine will not be managed by Intune.
• Is the user in the group that was configured for MDM automatic enrollment?  If they aren’t, you won’t see any errors, but the machine will not be managed by Intune.
• Does the user have an Azure AD Premium license (or a suite that includes that license)?  (Azure AD Premium P1 or P2 both work fine.)  If not, they’ll see an 80180018 error (“Something went wrong”), indicating that the device could not be enrolled in MDM:
   
• Does the user have an Intune license (or a suite that includes that license)?  If not, they’ll see the same 80180018 error (“Something went wrong”) as above.
• Has the user reached the limit of devices that they can enroll in Intune?  This limit is configurable and can range from 1 to 15; see https://docs.microsoft.com/en-us/intune/enrollment-restrictions-set for more information.  (Interestingly, this is an issue that I’m not presently able to duplicate.  I just keep adding more and more devices…)

Automatic logon as the specified Azure AD user

This is the easy part – I’ve never seen this fail, since the credentials have already been verified and the device is already joined using the same credentials.  So there’s no reason why the third usage of those credentials shouldn’t work.  After the logon, you’ll see the pulsing status screen while apps are being installed, an MDM progress display (at least once that is enabled by Intune) showing what policies still need to be applied, and finally the desktop.

At that point, the whole AutoPilot-driven provisioning process is complete.  To see that the device is indeed being managed by Intune, launch the Settings app, navigate to Accounts –> Access work or school, click the “Connected to <tenant>” entry (which indicates the device is joined to Azure AD) and then click the “Info” button to see the MDM enrollment details:

This will show you information about the policies applied, server URLs, etc.  You can also generate an HTML diagnostics report from here, or manually initiate a sync with Intune.

One useful link I found while going through this process:  https://docs.microsoft.com/en-us/windows/client-management/mdm/azure-active-directory-integration-with-mdm has a table that is useful to look up the error codes that you might encounter (e.g. 801C0003).

In my last post, I talked about issues you might encounter with Windows AutoPilot.  But what if you still can’t figure it out?  Typically the support and development teams would want more information to see what’s going on.  While I’m sure most IT pros would like to see log files or event logs that show the step-by-step flow, you’ll have to dig a little deeper in order to get something that can be used for a “post-mortem” analysis.  What does that mean?

First, Windows AutoPilot uses Event Tracing for Windows (ETW) to capture events during the AutoPilot process.  Those events need to be enabled and captured so that they can be inspected and interpreted.  How do you do that?  Here are the basic steps:

• On the first OOBE screen where you select a language, press Shift-F10 to open a command prompt.
• Insert a USB key containing the AutoPilot.wprp file (attached to this blog, extract it from the zip file) that defines the events to collect, or map a drive to a network share that contains the file.
• Start the trace using the Windows Performance Recorder (WPR) tool that is built into Windows.  (I talked about that a few years ago in a different context, https://blogs.technet.microsoft.com/mniehaus/2012/09/13/using-the-windows-performance-toolkit/.)  The command line to use:wpr.exe -start <folder location>\AutoPilot.wprp
• Exit from the command prompt.
• Finish your AutoPilot process, continuing at least as far as you need to go to reproduce the issue.
• Stop the recording using WPR.EXE, specifying where to put the resulting trace (press Shift-F10 to open another command prompt if you are still in OOBE):
  wpr.exe -stop C:\AutoPilot.etl

That part is easy enough.  The next challenge is reading and interpreting that file.  There are some options for doing that:

• Windows Performance Analyzer, provided as part of the ADK.
• Microsoft Network Analyzer (formerly called Network Monitor).
• TRACEFMT.EXE, a command-line utility that can convert the binary ETL file into XML or other formats.

My personal preference is to use Windows Performance Analyzer (WPA).  To get started with this process, let’s look at an ETL file captured from a 100% successful AutoPilot deployment, which I captured using the process described above.  After opening the file in WPA, you will see this view:

Exciting, right?  Well, not until you dig in more.  First, click the triangle before the “System Activity” label to get to this view:

Then double-click on the “Generic Events” block to show the details:

Now we can at least see some data.  Let’s focus in on two specific providers:

• Microsoft.Windows.Shell.CloudExperienceHost.Common.  This is where you’ll find the AutoPilot-generated events.  Some of these are prefixed with “ZTD” (related to the old codename for AutoPilot), while others aren’t prefixed.
• Microsoft.Windows.Shell.CloudDomainJoin.Client.  Events that are part of the initial “is this an AutoPilot deployment,” the AAD join process, and MDM enrollment are from this provider.

So let’s expand those for two “normal” cases.  First, for a device that is configured for AutoPilot:

Compare that to a device that was not enrolled in AutoPilot, but was still joined to Azure AD and automatically enrolled in Intune:

Not surprisingly, there are fewer events for the non-AutoPilot scenario.  But let’s dig into those events a little more, first the “GetCloudAssignedAadServerData” event.  Click on the triangle to the left of the “GetCloudAssignedAadServerData” task name, then select the “win:Stop” opcode (which shows the result).  Scroll to the right to see the data for an AutoPilot-defined machine:

Notice the “wasConfigured” value is “True,” indicating that this device is indeed registered with AutoPilot.  Compare that with a device that isn’t:

And not surprisingly, that shows “False” for the device that isn’t registered.  OK, so back to the registered device.  To see what Azure AD tenant it is registered with, we can check the “LogTenantId” and “LogTenantDomain” tasks.  Expand the “win:Info” opcodes for each and again scroll to the right:

There, you can see the Azure AD tenant ID (a GUID, which you can also find in the Azure Portal in the Azure AD tenant’s properties) and the tenant name (in this case, “contosomn.onmicrosoft.com”).  (Do you see the “IsDevicePersonalized” task name?  That’s for a coming AutoPilot feature that enables a device to be assigned to a user to further customize the “welcome” experience.  That’s not enabled yet, so it always returns “0” today.)

Let’s look at one more item, the “GetCloudAssignedForceStandardUser” task name (with the same routine: expand, select win:Stop, scroll right):

This shows that it’s configured (wasConfigured is “True”) to not force the Azure AD user to be a standard user (forceStandardUser is “False”).

Now lets look at a different trace, this one showing a failure with Azure AD join, error 801C0003 (“Something went wrong”) covered in the previous troubleshooting blog.  We’ll take a different approach this time, just searching for a specific “Event Name” value.  Click on the magnifying glass at the top of the “Generic apps” (right-hand) pane to get a search box, and search for “CDJUIError”.  That will take you directly to the row that has the error, showing you the 801C0003 error code (which you can then look up, see the link at the bottom of the previous blog):

That same approach would work for any Azure AD join issue.  But what about MDM enrollment issues?  Let’s look at another error, the 80180018 error (“Something went wrong”) from the previous post indicating that the device could not be enrolled in MDM.  Guess what?  It shows up in the exact same “CDJUIError” field:

That leaves one key piece of information:  What are the actual profile settings (e.g. skip privacy settings, skip EULA, etc.) that were configured for the device?  Those are reported in a bitmap:

SkipCortanaOptIn = 1,
OobeUserNotLocalAdmin = 2,
SkipExpressSettings = 4,
SkipOemRegistration = 8,
SkipEula = 0x10

The first four were present in Windows 10 1703, while the last one was added in Windows 10 1709.  In my case, I know that I enabled all options except the “OobeUserNotLocalAdmin” one (I wanted the user to have admin rights), so the value should be 1+4+8+16 = 29.  If we look at the trace, we see that is shown in all the “ZTP_GetConfigActivity” tasks (again, expand the entries, expand the win:Stop opcodes, and then one more level with process “Unknown”):

Sure enough, each of those (which are checking individual settings given the complete bitmap value) shows the value 29 in the “Field 2” column.  If you configured different options, the value would be different in that column.

I won’t claim that I’m particularly good with ETW or Windows Performance Analyzer, but hopefully this will give you some hints on what to look for in the traces.  If you pick up any additional tidbits looking at these traces, let me know.  Also, in case you were to open a support case for AutoPilot, don’t be surprised if they ask you to recreate the problem with a trace running, using the steps described at the top of this blog, sending the resulting ETL file so that they can walk through it and look at what happened.

AutoPilot.wprp.zip