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 months 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 Rollup
• 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)