Some people noticed that during an OS deployment task sequence, performed either by MDT 2008 Lite Touch or by ConfigMgr, could capture sensitive information (from unattend.xml, variables.dat, etc.) as part of the automatic System Restore snapshot process that happens whenever a new driver, application, security update, etc. is installed.

To address that issue, we added some logic in MDT 2010 to disable System Restore by configuring the default unattend.xml template:

<component name="Microsoft-Windows-SystemRestore-Main" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <DisableSR>1</DisableSR>
</component>

We then added logic to re-enable that at the end of the deployment process – but only for Lite Touch.  (You can see that logic in LTICleanup.wsf.)  We discovered later that this was left out of the ConfigMgr scripts.  So as a result, machines deployed using ConfigMgr and an MDT 2010 task sequence template ended up with System Restore disabled.

In MDT 2010 Update 1, we added logic to address this.  Now, System Restore will be re-enabled at the end of the deployment even with ConfigMgr.  (Because we don’t have the equivalent of LTICleanup.wsf in a ConfigMgr task sequence, the logic was added to ZTICopyLogs.wsf, the last script to run during an OSD task sequence.)

(10527)

I gave a presentation today at the TechEd New Zealand conference on “Customizing the User State Migration Tool 4.0” – something I’ve talked with customers about back from my consulting days (way back when, probably with USMT 2.6 at that point – remember that one and its INF-style configuration files?), but haven’t presented in public for a very long time.  Needless to say, it was somewhat nerve-wracking.  For those in attendance, I hope it was worth your time.  (I thought it was only OK.  I’ll do better the next time.)

The next few blog postings will likely be related to USMT 4.0 – it’s always good to write about things that are freshly in your mind.

First off, I wanted to take the opportunity to pass along some of the troubleshooting items that I mentioned in the slide deck, consolidating various issues that you might run into while using USMT 4.0.  Here they are:

• USMT 4.0 isn’t migrating Office 2010 settings
• Make sure you install the USMT 4.0 update that adds Office 2010 support.  See http://blogs.technet.com/b/mniehaus/archive/2011/02/02/usmt-4-0-support-for-office-2010.aspx for more information.
• http://support.microsoft.com/kb/2023591
• USMT fails with some half-hour time zones
• Install the USMT update for Office 2010 (see above), as it fixes this too.
• Bad user profiles (usually a ProfileList registry entry that points to a non-existent folder) can cause state capture issues (delays, failures)
• Clean them up or tell USMT to ignore them with MIG_IGNORE_PROFILE_MISSING=1
• See http://blogs.technet.com/b/deploymentguys/archive/2010/03/28/usmt-failures-due-to-bad-profile-list-entries.aspx for a script that can help identify these and clean them up so that they don’t cause any issues.
• See http://blogs.technet.com/b/askds/archive/2011/04/14/usmt-pauses-at-quot-starting-the-migration-process-quot-for-many-minutes-then-works.aspx for more details about the problem.
• Setting MIG_IGNORE_PROFILE_MISSING is rather challenging in ConfigMgr (you can’t set it as a process environment variable because it goes away before the “Capture User State” step runs, so you need to set it as a system variable, reboot, and then capture state).  See Michael Murgolo’s blog posting at http://blogs.technet.com/b/deploymentguys/archive/2011/08/03/setting-environment-variables-in-a-task-sequence.aspx for details on how to do this.  (You could do a shorter way with MDT Lite Touch by modifying ZTIUserState.wsf to set the variable.)
• OS settings don’t migrate with ConfigMgr
• This happens because USMT can only find the “DLManifests” folder necessary to do OS setting migration in the working directory, and ConfigMgr doesn’t set the working directory to the location that contains this.  See http://support.microsoft.com/kb/2018593 for more information.
• MDT 2010 Update 1 includes a workaround for this problem, although the USMT 4.0 fix for Office 2010 (see above) breaks the workaround, requiring a script change (also described in the blog above).
• USMT migrates user data from removable drives even with /localonly
• It migrates USB disks even with /localonly, use an unconditional exclude to exclude undesired USB disks.
• See Michael Murgolo’s blog posting at http://blogs.technet.com/b/deploymentguys/archive/2009/04/29/excluding-usb-firewire-and-other-drives-from-usmt-capture.aspx for a scripted approach of doing this (taking into account that the drive letters can be different on each system, so you might need a different exclude list for each PC).
• Shortcuts to files on network drives don’t migrate
• Known issue, you can modify MigUser.xml to remove section with IgnoreIrrelevantLinks (but then all links are retained, even invalid ones).
• USMT doesn’t exclude the users that I want when I specify /UE and /UEL
• These two parameters don’t work together the way you would expect them to, acting like an “or” instead of an “and”.  See http://blogs.technet.com/b/askds/archive/2009/11/30/understanding-usmt-4-0-behavior-with-uel-and-ue.aspx for more information.

Any other good troubleshooting tips for USMT 4.0?

A couple of years ago, Ben Hunter posted a script on the Deployment Guys blog that showed how to remove the in-box modern apps from a Windows 8.1 installation.  That exact same approach works with Windows 10 as well.  But there’s more that can be done, especially since the list of apps is different for Windows 8.1 and Windows 10 (and potentially changes with each Windows 10 feature upgrade), and since apps can be removed offline as well as online.

Attached to this blog (below) is the next generation of that script, designed to dynamically determine the list of apps if you don’t specify a list yourself.  It’s designed to run inside a task sequence (although it could be run manually if needed), either while in Windows PE to remove apps offline, or in the new OS to remove apps online.

Why would you want to remove apps offline?  A couple of reasons:

• It’s faster.  By removing the apps offline, the provisioned apps won’t install when the OS boots up for the first time, so the first logon is faster and there’s no need to remove the installed apps either.
• It avoids potential issues with the installation of provisioned apps.  All apps provisioned in the image install asynchronously on Windows 10 with the first logon.  So it’s possible that the task sequence starts removing apps while they are still being installed.  As a result, a script may fail to remove the app because it’s not there yet, and removing the provisioned app may not prevent the pending install from completing.  It’s a timing issue – your results may vary based on what happens in your specific task sequence.
• It avoids potential issues with Windows Update.   Sometimes while building an image, the Windows Update agent can update the apps while you’re trying to remove them.  That can cause the removal to not work, and later if you try to sysprep and capture the image, that can fail.  (This is not a problem if you build your image on an isolated network with no internet access.)

Let’s talk about pre-requisites.  First, you need to use PowerShell to do this.  Online (within the running OS) that’s no big deal, since Windows 8.1 and Windows 10 include PowerShell by default.  But with Windows PE, it’s an optional component that needs to be added.  In addition to PowerShell, make sure you add the .NET Framework, the DISM Cmdlets, and the Storage Management Cmdlets components, as the script uses all of those.

Note that there can be some challenges with the original Windows 10 ADK when adding .NET and PowerShell to the boot image.  Those issues should be fixed in the November 2015 version of the ADK.  (We think that a separate problem with PowerShell failing in Windows PE with an exception at startup is also fixed in the new ADK, but you’ll need to verify that, we’re still trying.)  Also note that there are some issues with the November 2015 version of the ADK related to the use of the DISM component after MDT launches an HTA. See http://blogs.technet.com/b/mniehaus/archive/2015/12/31/updated-remove-apps-script-and-a-workaround.aspx for more details.

Next, you need to modify your task sequences.  Online, it should look something like this (with the steps running in the new OS):

Offline, it will look similar but the steps will be in a different location:

In either case, the “Set-ExecutionPolicy Bypass” step looks like this:

I also mentioned that the default behavior is to remove all apps.  What if you don’t want to remove all apps?  With previous scripts, we suggested modifying the script to change the list of apps that needs to be removed, but that can be rather tedious and requires knowing how to query the list (using Get-AppxPackage and Get-AppxProvisionedPackage).  So this script will write out an XML file, RemoveApps.xml, when it runs.  That contains the full list of apps.  So if you want to do a subset, just edit that file to remove the apps that you don’t want removed, then save the resulting file in the same location as the RemoveApps.ps1 script.  The script will find it and use that list instead of the full list.  (Note that if you use this with different OSes, you’ll want to use different lists.  So you may need multiple RemoveApps.xml files.  The script should pick up the file from the working folder specified in the task sequence.)

But what about the apps that can’t be removed?  There are several provisioned apps that Windows 10 won’t allow you to remove, so the script won’t even see those when it queries for the list.  So there will be apps remaining even if you say to remove “all” apps.  There’s no way around this.  (If there are some apps that you want to remove but you can’t, submit feedback via the Windows Feedback app.)

NOTE:  The attached script has been updated to version 1.1 as of 2015/12/30.

RemoveApps.zip

A few weeks ago, I published a script to help remove the in-box apps from a Windows 10 image.  Some people have reported after running this script they are still seeing apps on the machine, things like Candy Crush, Twitter, and similar apps (which can vary based on your location).  So why is this happening?  It’s a feature.

The latest Windows 10 feature upgrade released this month (1511) includes a new feature that automatically installs a few apps from the Windows Store.  These apps are installed for the signed-on user, not provisioning on the machine.  So the script ignores them, as it’s only looking at provisioned apps.

So how do you get rid of these?  The simplest way is to keep them from installing in the first place.  There are two ways to do that:

1. Don’t create reference images on a computer that is connected to the internet.  (This can be problematic for other reasons too, as OS and app updates can install while the reference image is being created.)
2. Tell Windows to disable these features.

To disable the features, there is a group policy provided under “Computer Configuration –> Administrative Templates –> Windows Components –> Cloud Content” called “Turn off Microsoft consumer experiences”:

The same thing can be configured using MDM (e.g. Intune).  See https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962(v=vs.85).aspx, where it talks about the “Experience/AllowWindowsConsumerFeatures” policy. 

There doesn’t appear to be an unattend.xml entry to turn this off, but given the Group Policy above, it’s easy enough to track down the associated registry key, located at “HKLM\Software\Policies\Microsoft\Windows\CloudContent,” value “DisableWindowsConsumerFeatures.”  Set that value to 1 and you won’t get the extra apps.

To do the same thing via unattend.xml, you can add a “RunSynchronous” command to set the registry value.  Something like this (make sure the <Order> value is unique and one greater than the previous RunSynchronousCommand entry):

<RunSynchronousCommand wcm:action="add">
    <Description>disable consumer features</Description>
    <Order>5</Order>
    <Path>reg add HKLM\Software\Policies\Microsoft\Windows\CloudContent /v DisableWindowsConsumerFeatures /t REG_DWORD /d 1 /f</Path>
</RunSynchronousCommand>

I’ve updated the script attached to http://blogs.technet.com/b/mniehaus/archive/2015/11/11/removing-windows-10-in-box-apps-during-a-task-sequence.aspx to address a couple of issues:

• Fixed a bug that prevented the script from working properly offline when no RemoveApp.xml file was present (requiring the script to dynamically generate the list offline).  Thanks to Osama Altawil for reporting that issue a few weeks ago.
• Modified the logic that located the RemoveApps.xml file.  It now loads the file from the current PowerShell working directory.

I also updated the blog and script comments to indicate that the Storage Management Cmdlets are also required.

One other issue that has been reported by a variety of people:  When running the script offline in Windows PE 1511 as part of an MDT Lite Touch task sequence, the script is unable to load the DISM PowerShell module, and as a result the script fails.  We did figure out how to reproduce the problem with a generic Windows PE boot image:

• Load a web page or HTA using MSHTA.EXE, then close MSHTA.EXE.
• Run PowerShell.exe, try to “Import-Module DISM”.

The module import command fails with error 0x80131515.  We’re still investigating exactly what’s going on with that, but in the meantime, there is a simple workaround, described at http://stackoverflow.com/questions/19957161/add-type-load-assembly-from-network-unc-share-error-0x80131515 for a similar problem.  (For whatever reason, after running MSHTA.EXE, PowerShell thinks that the DISM module isn’t local.)  Just add a step to your task sequence that copies a file named powershell.exe.config into X:\Windows\System32\WindowsPowerShell\v1.0 folder (or embed it in your boot image), with the following content:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
   <runtime>
      <loadFromRemoteSources enabled="true"/>
   </runtime>
</configuration>

If you do that prior to the step that runs RemoveApps.ps1, then the DISM module will load fine and the script will work. (With any luck, there will be a permanent solution in a future ADK release.)

The Windows Store for Business was made available to everyone back in November, corresponding to the Windows 10 version 1511 feature upgrade that was released at the same time.  For those that aren't familiar with the Windows Store for Business capabilities, it provides organizations the ability to acquire apps for use throughout their organizations, and in some scenarios, also to distribute those apps.

There are two types of licenses that are available through the Windows Store for Business:

• Online, tied to an Azure Active Directory account.  This only supports per-user installation of the apps, and licenses are tracked and managed by the Windows Store for Business.
• Offline, where no Azure Active Directory is needed or used.  This supports per-user installation (regardless of the account type) as well as per-machine provisioning (where the app automatically installs for each user when they log onto the PC), and there is no license tracking.

In the case of MDT, it supports per-machine provisioning of apps, and as of MDT 2013 Update 1 it understands how to provision apps from the Windows Store for Business.  The main difference between store apps and sideloaded apps: a license file provided by the Windows Store for Business, allowing the app to be installed or provisioned on a machine, without even needing to enable sideloading.

For those of you who aren’t familiar with MDT’s ability to sideload apps, this has been in MDT since the Windows 8 timeframe, but the documentation is lacking.  To summarize, you need to have the app files, including dependencies, in the needed folder structure.  For example, you could import this folder structure into MDT as a new application, specifying the name of the main .appx file as the command line for the app:

• MyApp
  • MyApp.appx
  • Dependencies
    • x86
      • MyDependency.appx
    • x64
      • MyDependency.appx

After importing this into MDT (creating an app with source files, specifying the location of the MyApp folder, and specifying a command line of “MyApp.appx”), you could then select that app for provisioning during a task sequence; MDT would automatically create the needed DISM command line to provision the app so that you don’t need to work out that very long command line yourself.

So where does this folder structure come from?  Simple, it’s what Visual Studio creates when you build an app.  So your developers can just provide you with a copy of that output folder and you’re set.  But there’s a little more work needed with the Windows Store for Business:  It will provide you all the files that you need, but you need to download them individually and then place them into the needed folder structure manually, before adding the result to MDT.

Let’s look at a real example.  Once I sign into the Windows Store for Business from http://www.microsoft.com/business-store, I can mange my inventory of apps and filter it to just the “offline” licensed apps, since these are the ones I could put into my MDT image:

Let’s assume I want everyone to have Onefootball when they first log into Windows 10.  (It could happen, maybe they work for a European football club.)  When you select that app, you can see the individual files that you need to download, including a license file:

So download the package itself (selecting the x64 architecture, so that you get the files for x86 and x64), an unencoded license (XML file), and each of the required frameworks.  Arrange them into a folder structure like I described above:

with three .appx dependency files in each of the x86 and x64 folders.  Then import that into MDT as a new app with source files:

specifying the name of the .appx file as the command line (the rest of the name scrolls off the left side for this app):

Then when deploying you can select the app:

Then once I log on as a normal user (not the Administrator) the app shows up on the Start menu:

and launches just fine:

So you can do that with any offline app available in the Windows Store for Business, just like you can do it with any line of business app.  (MDT will enable sideloading automatically for the LOB app, but that isn’t necessary for the Windows Store app, as the license file means sideloading isn’t needed.)

To make this process easier, the Configuration Manager and Intune teams, as well as other management tool vendors, are working on leveraging the Windows Store for Business APIs to make this whole process as easy as checking a few boxes, so stay tuned for that.

Looking at a comparison of the files in MDT 2013 Update 2, here’s a quick overview of the changes in the scripts when compared with those in MDT 2013 Update 1:

• DeployWiz_Initialization.vbs.  Change the task sequence filtering logic to only display upgrade task sequences from a running OS (not bare metal).
• DeployWiz_UserData.vbs.  Fixed a bug that would blank out the user data location if UDDir and UDShare aren’t specified.
• LiteTouch.wsf.
  • Fixed a bug that causes static IP settings to not be restored for media-based deployments.
  • Modified the upgrade handling logic.
• LTIApply.wsf.
  • Only reboot when upgrade succeeds, not when it fails.
  • Modified progress reporting logic when applying unattend.xml using DISM.
• LTIBootstrapUpgradeSummary.vbs.  New script for in-place upgrade.
• LTICleanup.wsf.  Added logic to copy new scripts for in-place upgrade.
• LTISysprep.wsf.  Added logic to re-arm Office 2013 or Office 2016 activation, if either version is present.
• SetupComplete.cmd.  Modifications to upgrade logic.
• SetUpgradeStatus.wsf.  Removed no-longer-used script.
• SetupRollbackup.cmd.  Modifications to upgrade logic.UpgradeSummary.wsf.  Removed no-longer-used script.
• LTIApplyGPOPack.wsf.  Added logic to apply a Windows 10 GPO pack (although there is no such thing).
• ZTIBde.wsf.  Fixed bug with Windows 10 version checking.
• ZTIExecuteRunbook.wsf.  Fixed bug with XML handling that prevented runbooks from being invoked or monitored.
• ZTILangPacksOnline.wsf.
  • Fixed bug with Windows 10 version checking.
  • Fixed bug with the handling of language pack CAB files with spaces in their path.
• ZTIUtility.vbs.
  • Fixed progress reporting logic to handle new DISM progress output in the ADK for Windows 10 version 1511.
  • Fixed issue where Pro SKU wouldn’t display high-end SKU features (changes in Windows 8 and above).
• ZTIWinRE.wsf.  Fixed Windows 10 version checking.

So overall that’s fairly minor – primarily lower-impact bug fixes, and some desired improvements to the Lite Touch in-place upgrade process mentioned at http://blogs.technet.com/b/msdeployment/archive/2015/12/22/mdt-2013-update-2-now-available.aspx.  A few other key fixes called out in that blog:

• Fixes to the task sequence logging.  In MDT 2013 Update 1, the task sequence log went from very verbose to almost non-existent.  With MDT 2013 Update 2, it’s back to very verbose.
• Fixes to default deployment share permissions – maybe still a little more secure that you would like, but at least the new security is functional.
• A better in-place upgrade experience.

Overall, this is a highly recommended upgrade for anyone using earlier versions of MDT (well, as long as you’re not still working with Windows Vista, or heaven forbid Windows XP).

Remember, before upgrading to MDT 2013 Update 2 make sure you have a backup of your existing deployment share.  And if you are concerned about the potential impact, first upgrade a copy of your deployment share before upgrading the production one.

I’m sure you’ve noticed that when building a new Windows 7 SP1 image that there are a lot of updates that need to be installed.  And these installations can take a while, whether pulling those updates from Windows Update directly or from WSUS.  But the performance can be improved.

First, see Justin Chalfant’s blog post at http://blogs.technet.com/b/jchalfant/archive/2016/02/10/updating-windows-7-update-agent-in-a-mdt-or-sccm-task-sequence-prior-to-installing-updates.aspx to see the results of testing with newer Windows Update agents, which offer improved performance.  The TL;DR summary is that you should inject https://support.microsoft.com/en-us/kb/3112343 (or eventually, any newer versions that supersede it) into Windows 7 prior to updating from WU or WSUS.  There’s a really simple way to do that with MDT:

• Download the https://support.microsoft.com/en-us/kb/3112343 hotfix.
• Import the hotfix into the MDT deployment share’s “Packages” node.
• Build your Windows 7 image.

MDT will automatically inject the new Windows Update agent into Windows 7 as part of the initial installation, so by the time it gets to any Windows Update steps the new agent will be in place.

Next, if you are using WSUS, there are some “best practices” for keeping things clean.  See a few links for that:

• http://blogs.technet.com/b/configurationmgr/archive/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance.aspx 
• http://social.technet.microsoft.com/wiki/contents/articles/8528.wsus-administration-best-practices-recommended-to-ease-system-center-endpoint-protection-and-fepfcs-deployment.aspx
• http://deploymentbunny.com/2016/02/03/working-in-the-datacenter-keeping-wsus-happy-using-powershell/
• http://blog.configmgrftw.com/wsus-cleanup-for-configmgr/

Also note that MDT 2013 Update 1 and later include logic that cause an automatic reboot after 100 patches before continuing on with the rest of the batch.  This was done because of issues with the Windows Update agent when it tried to install hundreds of patches at once.  With the new agent, that logic might not be needed any more – I haven’t tried it, but if you want to cut out a couple of reboots, you could experiment with changing the MAX_UPDATES constant at the top of the ZTIWindowsUpdate.wsf script to a larger value.

When I first started in IT, I worked with a team of people to do very repetitive tasks as a DBA.  Fortunately, a few of those people had the right idea:  With enough automation, we can eliminate the need for our jobs.  Now that might sound like a career mistake, but what you quickly realize is that if you get rid of the mundane, you can move on to something more interesting – and there’s always something more interesting.  After a few years, we were to that point, and then we started bringing order to PCs.

Fast forward a few years and the same idea was applied to MDT:  There’s no such thing as too much automation.  And even now, I still have to remind myself of that.

Case in point:  I needed to do some larger-scale testing, which is great with virtual machines.  And since it’s very simple to create fully-functional VMs from a ready-to-go, patched VHDX file using PowerShell, I created those VMs in just a few minutes and let them churn for a while after they started out.  But it seemed like “too much work” to also automate the configuration of those VMs – all I needed to do after all was rename and join a domain.  But instead of a little more PowerShell to inject a configured unattend.xml into each VM, I thought “no, I’ll do it manually later.”  Well, that was a bad idea:  I spent hours configuring the VMs, connecting to each one, completing OOBE, logging in with a local account, opening up the computer settings, changing the computer name, joining the domain, and rebooting.  All because I didn’t want to spend an hour or so on a little more scripting.

In any case, I thought someone might be interested in the PowerShell script to create a batch of VMs, which I cobbled together from various other samples on the web:

$parentpath = "E:\VMs\10240.x64.ClientBase.vhdx"
$path = "E:\VMs\"

foreach ($i in 1..20)
{
  $suffix = $i.ToString("000")
  $vmname = "CLONE-$suffix"

  #create a VHDX – differencing format
  $vhdpath = "$path\$vmname Disk 0.vhdx"
  New-VHD -ParentPath $parentpath -Differencing -Path $vhdpath

  #Create the VM
  New-VM -VHDPath "$vhdpath" -Name $vmname -Path "$path" -SwitchName "Lab" -Generation 2

  #Configure Dynamic Memory
  Set-VMMemory -VMName $vmname -DynamicMemoryEnabled $True -MaximumBytes 2GB -MinimumBytes 1GB -StartupBytes 1GB

  #Start the VM
  Start-VM $vmname
}

You might need to tweak it (with proper paths, the name of your Hyper-V network switch, etc.  But that’s the easy part.

Next time, I’ll add the logic to inject an unattend.xml to automate OOBE, name the computer, and join the AD domain…

With Windows 10 Mobile, we’ve released a new SKU called Windows 10 Mobile Enterprise that has a few extra features.  This SKU is available as a benefit to customers with Software Assurance for Windows.  But how do you take a phone or other mobile device running Windows 10 Mobile and get it to run Windows 10 Mobile Enterprise?  Simple, use a provisioning package.

First, you need to download an XML license file that is used to change an existing Windows 10 Mobile installation into Windows 10 Mobile Enterprise.  This is available for development and testing for those with an MSDN subscription:

The same license file is also available on the Volume Licensing Service Center. 

After downloading the ISO file, you can mount it in File Explorer to see that it contains one small XML file.  (Don’t ask me why it’s in an ISO – not the most convenient.)  You can then take that XML file and use it to create a provisioning package.  For that, you need the ADK for Windows 10, available at https://msdn.microsoft.com/en-us/windows/hardware/dn913721.aspx#adkwin10.  Once you’ve installed that, you can use the Windows Imaging and Configuration Designer, a.k.a. Windows ICD, to create the provisioning package.  For simplicity, specify that you only want to see Windows 10 mobile settings:

In the provisioning package settings, expand the EditionUpgrade node and select the UpgradeEditionWithLicense item.  Click the browse button to select the XML file you downloaded earlier:

Then you can build the provisioning package (from the “Export” menu) and transfer it to the device (e-mail, NFC, web download, OneDrive, etc.).

The same EditionUpgradeWithLicense setting is available via MDM as well, so if you use Intune or other MDM products, you can use the XML file contents to push this license to files that way too.

The team responsible for creating Windows documentation was very busy, creating new documentation and updating existing documentation for the functionality in the Windows 10 1511 feature update.  If you haven’t yet found these documentation updates, here’s a handy list that they compiled for all the new stuff:

• Security content
  • Windows Defender in Windows 10 (4 topics)
  • Why a PIN is better than a password
  • Device Guard deployment guide
  • What’s new in Bitlocker
  • What’s new in Credential Guard
  • What’s new in security auditing
  • What’s new in TPM
  • Protect domain credentials with Credential Guard
  • What’s new in Windows 10: Microsoft Passport
  • Manage identity verification using Microsoft Passport
  • Implement Microsoft Passport in your organization
  • Prepare people to use Microsoft Passport
  • Windows Hello biometrics in the enterprise
• Management content
  • Customize and export Start layout
  • Customize Windows 10 Start with mobile device management (MDM)
  • Lock down Windows 10 to specific apps
  • Configure telemetry and other settings in your organization
  • Windows Store for Business overview
  • Windows Store for Business (23 topics)
  • What’s new in AppLocker
  • Applocker
• Deployment, provisioning and servicing content
  • Windows Update for Business (3 topics)
  • Manage Windows 10 Start layout options
  • Customize Windows 10 Start with Group Policy
  • Customize Windows 10 Start with ICD and provisioning packages
  • Set up a kiosk on Windows 10 Pro, Enterprise, or Education
  • Configure devices without MDM
• Other content
  • Chromebook Migration Guide
  • What’s new in Windows 10: Windows spotlight on the lock screen
• Browser content
  • Remove sites from a local Enterprise Mode site list
  • Remove sites from a local compatibility view list
  • Microsoft Edge requirements and language support
  • Available policies for Microsoft Edge
  • Use Enterprise Mode to improve compatibility
  • Add sites to the Enterprise Mode site list using the Windows 10 Enterprise Mode Site List Manager tool
  • Collect data using Enterprise Site Discovery
• Windows 10 Mobile content
  • Set up a kiosk on Windows 10 Mobile or Windows 10 Mobile Enterprise 
  • Configure Windows 10 Mobile using Lockdown XML
  • Settings and quick actions that can be locked down in Windows 10 Mobile
  • Product IDs in Windows 10 Mobile 
  • Reset a Windows 10 Mobile device 

I’ll be at the Microsoft office in Times Square presenting on Windows 10 and Windows as a service at the IT Pro Con NY event, http://www.itproconny.com/.  Registration is still open, with content on Windows, PowerShell, Azure, SharePoint, and Exchange presented throughout the day.  Sign up here:

http://itproconny.eventbrite.com/

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