With the release of the Windows 8.1 Update, there is a new mechanism available for running Windows called Windows Image Boot, or WIMBoot for short.  For details about what this is and how it works, see the Springboard blog.

Although MDT 2013 doesn’t include any specific support for WIMBoot (maybe something that could be considered for a future release), there’s nothing preventing anyone from following the instructions available in the ADK to create a task sequence that does it.  So I decided to try it.  Let’s walk through the process at a high level.

Step #1:  Create an image with Windows 8.1 Update

Because WIMBoot is a new feature with the Windows 8.1 Update, it makes sense that you first need to have a Windows 8.1 image that contains the Windows 8.1 Update.  The easiest way to do this is to download a pre-patched ISO from the Volume License Service Center on April 14th, but you can also inject the Windows 8.1 Update fixes into an existing Windows image.

Step #2: Get MDT 2013 to create a Windows PE 5.1 boot image

In order to deploy WIMBoot, you need to use a version of Windows PE that supports it.  That would be Windows PE 5.1.  But that’s not a version that you just download and use.  Instead, it’s a version that you (or ideally MDT) need to create.  The first step in that is to update the ADK to the latest version.  Download the new ADKSETUP.EXE and run it to install all the patches. 

After you’ve done that, the process for creating a Windows PE 5.1 image involves injecting the Windows 8.1 Update into Windows PE.  That’s not something MDT knows anything about, but since MDT includes the ability to run a script during the boot image generation process, it can be “taught.”  That means dropping in an updated UpdateExit.vbs script that injects the six Windows 8.1 Update fixes to the boot image.  And of course it needs to have those updates available to it, so you need to download those from the Download Center and place them where the script can find them.

After that’s done, update the deployment share, completely regenerating the boot image.  This will take quite a while, as the Windows PE generation process itself isn’t very fast to start with, but when you add in the patch installation process the time will easily double.  Maybe you want to try this in a lab :-)

Step #3: Teach MDT how to deploy using WIMBoot

The steps necessary to apply a WIM using WIMBoot are not surprisingly different than what MDT typically does, so the existing LTIApply.wsf script won’t do it.  So we need a new script.  Fortunately, because we can focus exclusively on this one scenario, the scripting needed to this, which follows the ADK steps documented at http://technet.microsoft.com/en-us/library/dn605112.aspx, isn’t too hard.  To add more flexibility and to solve some challenges, I added a few features:

• The script will dynamically determine the size of the “Images” volume needed to hold the WIM file, then shrink the OS partition by that size.  That way, you don’t need to modify the “Format and Partition Disk” step to specify an explicit size, which is nearly impossible to do anyway because you want a fixed-size partition after the OS partition, where the OS partition says “100% of the remaining free space”, an impossible combination in the UI.
• The script will export an existing WIM to make it ready for WIMBoot.  This export process, done using DISM.EXE /Export-Image /WIMBoot, ends up adding a lot of time to the deployment process though, because it ends up decompressing and recompressing the contents of the WIM in the process of exporting it.  As an alternative, you can do this once ahead of time (manually) and tell the script that you’ve done this.
• If for some reason you want to explicitly specify the size of the images partition, you can through a command line parameter.
• Ideally the machine would be set up properly so that the system recovery options (Reset My PC/Refresh My PC) work.  To do this, you need a Windows RE boot image that has been updated with the Windows 8.1 Update fixes, using the same basic steps documented at http://technet.microsoft.com/en-us/library/dn613859.aspx.  That part must be done manually, but the script will look for the WinRE.wim file in the same folder as the OS WIM and copy it to the same “Images” volume and register it as a recovery image.

The next piece is a task sequence.  Since WIMBoot is really only useful for bare metal deployments, I took the standard client task sequence template and chopped it down to the bare minimum needed to perform a bare metal WIMBoot deployment, while still supporting things like driver injection, app installation, Windows Update installation, etc.  The original “Install Operating System” is left in but disabled, since that’s the step that provides a simple way to associate an OS with the task sequence.  Instead of running this step, a new step was added to run “LTIApplyWIMBoot.wsf”, the new script discussed above.  The net result is something that looks like this:

Step #4:  Deploy

Find a machine that meets the requirements and you’re ready to do a bare metal deployment:

• 16GB or 32GB SSD or eMMC solid-state storage.
• UEFI 2.3.1 system (Windows 8 logo-certified).

Ideally these would be machines that come already configured for WIMBoot (since you know it meets the requirements and has been tested by the OEM to ensure good performance).  But if you just want to test it out, you can try it on Windows Server 2012 R2 Hyper-V or Windows 8.1 Hyper-V, since both support “type 2” virtual machines that use UEFI. 

What do you have to do?

Just complete the previous four steps.  OK, but those steps leave out the details, so let’s use a checklist instead.

1. Create a Windows 8.1 Update operating system image by injecting the Windows 8.1 Updates into an existing Windows 8.1 image, or download a new Windows 8.1 Update ISO already containing the updates from VLSC (available on April 14th).  Import the operating system into your MDT deployment share.
2. Download the updated ADKSETUP.EXE for the ADK for Windows 8.1 and use it to install the updated ADK components released with Windows 8.1 Update.
3. Download the Windows 8.1 Update prerequisite (a servicing stack update) for both x86 and x64 from http://support.microsoft.com/kb/2919442, and place them into the “C:\Program Files\Microsoft Deployment Toolkit\Samples” folder.  (Note that both x86 and x64 versions are needed because they will be used to update x86 and x64 boot images.)
4. Download the individual x86 and x64 Windows 8.1 Updates from the download center and place them into the “C:\Program Files\Microsoft Deployment Toolkit\Samples” folder.  (Note that both x86 and x64 versions are needed because they will be used to update x86 and x64 boot images.)  With the downloads from step #3 and these, you should have a total of 12 different MSU files in the folder.
5. Place the updated “UpdateExit.vbs” file in the attached zip file into the same “C:\Program Files\Microsoft Deployment Toolkit\Samples” folder, replacing the version that is already there.  (If you’ve made any other changes to this, you’ll need to merge your changes into the attached version.)  This script will be called during the deployment share update process to inject the Windows 8.1 Update into the boot images, which is what is needed to make Windows PE 5.1 boot images.
6. Update your deployment share by right-clicking on it and choosing the “Update deployment share” option.  Make sure you check the “Completely regenerate the boot images” option, as this is needed the first time to get Windows PE updated.
7. Check the results of the “update” process to make sure all the MSU files were injected successfully by making sure all the steps have good return codes.  Here’s an example:
   
   About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2919442-x86.msu"
   Return code from command = 0
   About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2919355-x86.msu"
   Return code from command = 0
   About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2932046-x86.msu"
   Return code from command = 0
   About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2937592-x86.msu"
   Return code from command = 0
   About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2938439-x86.msu"
   Return code from command = 0
   About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Add-Package /PackagePath:"C:\Program Files\Microsoft Deployment Toolkit\Samples\Windows8.1-KB2934018-x86.msu"
   Return code from command = 0
   About to run: DISM.EXE /Image:"C:\Users\mniehaus\AppData\Local\Temp\MDTUpdate.11324\Mount" /Cleanup-Image /StartComponentCleanup /ResetBase
   Return code from command = 0
   
   
8. Place the new “WIMBoot.xml” task sequence template from the attached zip file into the “C:\Program Files\Microsoft Deployment Toolkit\Templates” folder.
9. Place the new “LTIApplyWIMBoot.wsf” script into the deployment share’s “Scripts” folder.
10. Create a new task sequence, selecting the “WIMBoot Task Sequence” template and the operating system image that you imported.
11. Perform a bare metal deployment using the updated boot images (update WDS if using PXE, generate new boot CDs, etc.), selecting your new task sequence.

In this scenario, you’ll notice during the task sequence execution that the operating image is exported to make it ready for WIMBoot.  This export process takes a long time, because it changes the compression method used for the WIM.  It's the easiest option since it requires no additional steps on your part, but it’s not the quickest.  If you want to make the process faster, you can follow these steps:

1. Export the existing WIM image using this DISM command:
   DISM.EXE /Export-Image /WIMBoot /SourceImageFile:<original WIM> /SourceIndex:1 /DestinationImageFile:<new WIM to create>
2. Import the new WIM into your deployment share.
3. Update your existing WIMBoot task sequence to use the new image.
4. Modify the task sequence step “Apply WIM Boot Image“ to add a “/Optimized:TRUE” switch to the LTIApplyWIMBoot step to indicate that no export is required.

Note that this WIM image can still be used for non-WIMBoot deployments – it’s ready for WIMBoot, but not optimized for WIMBoot.  If you want to take it a step further, you can optimize that exported image (following the above three steps first) using these steps:

1. Mount the WIMBoot-ready image using DISM:
   DISM.EXE /Mount-Image /ImageFile:<WIM file> /Index:1 /MountDir:C:\Mount
2. Optimize the image for WIMBoot using DISM:
   DISM.EXE /Image:C:\Mount /Optimize-Image /WIMBoot
3. Commit the changes to the WIM file:
   DISM.EXE /Unmount-Image /MountDir:C:\Mount /Commit
4. Import the modified image into your deployment share.
5. Update your existing WIMBoot task sequence to use the new image.
6. Modify the task sequence step “Apply WIM Boot Image“ to add a “/Optimized:TRUE” switch to the LTIApplyWIMBoot step to indicate that no export is required.

And one more thing:  You need to perform some additional steps if you want Windows RE to work for recovering a WIMBoot system.  This is needed to ensure the refresh/reset my PC options work from PC Settings, that the machine can self-repair if something happens during the boot process, that BitLocker recovery can work properly, etc.  So it’s highly recommend that you do this.  To do this, follow these steps:

1. Mount your Windows image using DISM:
   DISM.EXE /Mount-Image /ImageFile:<WIM file> /Index:1 /MountDir:C:\Mount
2. Move the WinRE.WIM out of the image (since recovery can’t boot a WIM within a WIM):
   move C:\mount\Windows\Windows\System32\Recovery\winre.wim C:\winre.wim
3. Commit the changes to the WIM file:
   DISM.EXE /Unmount-Image /MountDir:C:\Mount /Commit
4. Mount the WinRE.WIM file:
   DISM.EXE /Mount-Image /ImageFile:C:\winre.wim /Index:1 /MountDir:C:\Mount
5. Inject the downloaded Windows 8.1 updates into the WIM image:
   DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2919442-x86.msu
   DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2919355-x86.msu
   DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2932046-x86.msu
   DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2937592-x86.msu
   DISM.EXE /Image:C:\Mount /Add-Package /PackagePath:Windows8.1-KB2934018-x86.msu
6. Cleanup the image as described in the ADK documentation:
   DISM.EXE /Image:C:\Mount /Cleanup-Image /StartComponentCleanup /ResetBase
7. Commit the changes to the WIM file:
   DISM.EXE /Unmount-Image /MountDir:C:\Mount /Commit
8. Export the contents of the WIM into a new WIM to reduce the size of the image:
   DISM.EXE /Export-Image /SourceImageFile:C:\winre.wim /SourceIndex:1 /DestinationImageFile:C:\winre-new.wim
9. Copy the resulting file into the same folder as the operating system WIM on the deployment share, e.g. “C:\DeploymentShare\Operating Systems\WIMBoot”.  Make sure the file is named “winre.wim” so that the LTIApplyWIMBoot.wsf script can find it; the script will take care of the remaining steps.

And that’s all there is to it. 

Well, almost.  I need to point out a few more things:

• I am providing these scripts and the task sequence template as-is.  It’s not supported by Microsoft, so don’t call support about it.  Feel free to e-mail me at mniehaus@microsoft.com, but I can’t guarantee a quick response – might take weeks or months before I get to the e-mail :-)
• When you use a non-WIMBoot image (one not exported using the steps above), the recompression process that happens when the image is exported causes the new image to be larger than the original one.  The LTIApplyWIMBoot script attempts to guess at how big, assuming it will be about one-third bigger, but that might not be accurate.  If you run into issues where the OS image and winre.wim won’t fit, you can either go through the export steps above (so no guessing needs to be done), or you can explicitly specify how big you want to make the images partition by adding an “ImagesSize” switch to the LTIApplyWIMBoot command line.  See the script comments for more information.
• If you choose to optimize the operating system image using the steps above, you might also want to export the image into a new WIM file to make it as small as possible.  It won’t be a huge difference, but on a 16GB system, every little bit helps.
• Remember, WIMBoot is intended for new hardware that has smaller (16GB or 32GB) SSD or eMMC disks, and requires Windows 8 certified UEFI systems.  I would only recommend using it on systems that originally shipped from the manufacturer configured for WIMBoot.  For example, let’s say you purchased a new 16GB tablet that was configured with WIMBoot and the Windows 8.1 “core” SKU, and you wanted to deploy Windows 8.1 Enterprise to it.  You could use the provided task sequence to completely wipe the device (no data migration) and reload it.
• If you want to try this in a VM, feel free – but remember it needs to be a UEFI virtual machine (e.g. Hyper-V on Windows 8.1 or Windows Server 2012 R2).  But this isn’t intended for virtual machines, VDI, or other scenarios.
• If you’ve set everything up correctly, you should be able to see in the Disk Management tool that the C: drive is using WIMBoot.  And more importantly, the refresh and reset recovery options should work.  Try them out at least once to make sure.
• I included steps in the task sequence template to restore user state (useful for a “replace” scenario), to inject drivers, to inject updates, and to install apps.  But there is nothing to capture state.  That’s because this is a bare metal-only scenario.
• Make sure you have a lot of free disk space, as the Windows PE generation process will likely require at least 3GB of available space to inject the Windows 8.1 Update files (before the cleanup process shrinks it back down again).
• You won’t see any progress reported while the updates are being injected into Windows PE, as the UpdateExit.vbs script doesn’t have the ability to provide any real-time status information back to Workbench.  Just be patient – you can see via Task Manager that the DISM commands are still running.

Please try this out when you have some spare time, and post some comments indicating if it worked or not.  Most of the validation of the steps in this blog was done in hotel rooms, airports, and airplanes…

As we were going through our TechEd North America deployment pre-conference today, we showed a lot of links for pages of interest.  Here is a list of those (at least the ones I remembered):

• Windows 8.1 deployment all-up
  • http://technet.microsoft.com/en-us/windows/hh974336
  • http://blogs.windows.com/windows/b/springboard/archive/2014/04/21/windows-8-1-deployment-labs-now-available.aspx
  • http://www.microsoftvirtualacademy.com/training-courses/windows-8-1-deployment-jump-start
• Windows 8.1 Update
  • http://blogs.msdn.com/b/ie/archive/2014/04/02/stay-up-to-date-with-enterprise-mode-for-internet-explorer-11.aspx
  • http://blogs.technet.com/b/mniehaus/archive/2014/04/13/experimenting-with-wimboot-using-mdt-2013.aspx
  • http://blogs.windows.com/windows/b/windowsexperience/archive/2014/04/02/windows-8-1-update-important-refinements-to-the-windows-experience.aspx
  • http://blogs.windows.com/windows/b/springboard/archive/2013/10/18/windows-8-1-update-the-it-pro-perspective.aspx
  • http://blogs.windows.com/windows/b/springboard/archive/2014/04/03/windows-8-1-sideloading-enhancements.aspx
  • http://support.microsoft.com/kb/2919355
• Dynamic deployment
  • http://deploymentbunny.com/2012/04/21/back-to-basic-customsettings-ini-explained/http://blogs.technet.com/b/deploymentguys/archive/2009/09/10/using-and-extending-model-aliases-for-hardware-specific-application-installation.aspx
  • http://blogs.technet.com/b/mniehaus/archive/2012/06/27/encoding-sensitive-information-in-customsettings-ini-and-bootstrap-ini.aspx
  • http://mdtcustomizations.codeplex.com/
• Driver management
  • http://blogs.technet.com/b/mniehaus/archive/2013/09/16/grabbing-out-of-box-drivers-from-a-windows-8-system.aspx
  • http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx
  • http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-2.aspx
• MDT and ConfigMgr issues
  • http://www.deploymentresearch.com/Research/tabid/62/EntryId/76/Uber-tips-for-the-MDT-2012-Update-1-Task-Sequence-template-for-SCCM-2012-SP1.aspx
  • http://www.deploymentresearch.com/Research/tabid/62/EntryId/76/Uber-tips-for-the-MDT-2012-Update-1-Task-Sequence-template-for-SCCM-2012-SP1.aspx
  • http://keithga.wordpress.com/2013/09/17/osdpreservedriveletter/
• Image Factory
  • http://deploymentbunny.com/2014/01/06/powershell-is-king-building-a-reference-image-factory/
• PowerShell
  • http://gallery.technet.microsoft.com/ScriptCenter
  • http://blogs.technet.com/heyscriptingguy
  • http://www.microsoftvirtualacademy.com/training-courses/getting-started-with-powershell-3-0-jump-start

If I missed any, or if there are any follow-up questions from the day, please add them to the comments for this blog, e-mail me at mniehaus@microsoft.com, or ping any of us via Twitter:  @mniehaus, @benhunter, or @mikael_nystrom.  Also, be sure to look for the session slides on http://deploymentbunny.com.

For those of you who put up with us all day, thanks.

With the release of Windows 8.1 Update, enterprises have a new tool at their disposal for addressing issues with older web sites.  This new feature, called Enterprise Mode IE, effectively enables IE 11 to run web pages that otherwise would only work in IE 8. 

And this isn’t just for Windows 8.1 – you can get the same functionality on Windows 7 by installing the latest IE 11 cumulative update (e.g. http://www.microsoft.com/en-us/download/details.aspx?id=42463 or http://www.microsoft.com/en-us/download/details.aspx?id=42471).  So even if you aren’t planning on deploying Windows 8.1, you can still use this to fix your browser issues with Windows 7 SP1.

I’ve been surprised by the number of people at TechEd North America this week who weren’t aware of Enterprise Mode IE.  Fortunately, Fred Pullen did a great session on this and you can watch the video here:

http://channel9.msdn.com/events/TechEd/NorthAmerica/2014/WIN-B320

Read more about Enterprise Mode at these links:

http://blogs.windows.com/windows/b/springboard/archive/2014/04/09/internet-explorer-11-now-helps-customers-stay-up-to-date.aspx

http://blogs.msdn.com/b/ie/archive/2014/04/02/stay-up-to-date-with-enterprise-mode-for-internet-explorer-11.aspx

In case you missed it at http://blogs.technet.com/b/msdeployment/archive/2015/03/02/microsoft-deployment-toolkit-2013-update-1-preview-now-available.aspx, the new preview of MDT 2013 Update 1 is now available for download from the Connect website.  This new release works with the new ADK preview for Windows 10, which is available on the download center at http://www.microsoft.com/en-us/download/details.aspx?id=45522.

While this new release adds support for Windows 10 deployment, it also supports deploying Windows 7, Windows 8, and Windows 8.1 (and their server equivalents).  But at this point, there’s no support for ConfigMgr – that comes later.

So what’s changed in this new release?  Let’s go through it exhaustively by looking at the individual files:

• Credentials_ENU.xml.  Fixed an accessibility issue in the pane.
• DeployWiz_Definition_ENU.xml.  Fixed the condition on the BitLocker pane so that it displays for all supported OSes, including Windows 10.
• DeployWiz_Initialization.vbs.  Fixed OS version logic to handle Windows 10.
• DeployWiz_Roles.vbs.  Fixed OS version logic to handle Windows 10.
• LiteTouch.wsf.  Updated to handle the new task sequence engine from ConfigMgr 2012 R2.
• LTIApply.wsf.  Fixed OS version logic to handle Windows 10.  Added logic to handle split WIM files (SWMs).
• LTICleanup.wsf.  Fixed OS version logic to handle Windows 10.
• ServerManager.xml.  Added Windows 10 (client) features to the list.
• Summary_Definition_ENU.xml.  Fixed accessibility issues in the pane.
• WelcomeWiz_Choice.xml.  Fixed an accessibility issue in the pane.
• WelcomeWiz_Initialize.xml.  Fixed an accessibility issue in the pane.
• Wizard.hta.  Fixed an accessibility issue in the pane.
• ZTIApplyGPOPack.wsf.  Fixed OS version logic to handle Windows 10.
• ZTIAppXmlGen.wsf.  Fixed OS version logic to handle Windows 10.
• ZTIBde.wsf.  Fixed OS version logic to handle Windows 10.
• ZTIDisableBDEProtectors.wsf.  Fixed OS version logic to handle Windows 10.
• ZTIDiskpart.wsf.  Fixed OS version logic to handle Windows 10.
• ZTIDiskUtility.vbs.  Fixed OS version logic to handle Windows 10.
• ZTIGather.wsf.  Fixed OS version logic to handle Windows 10.
• ZTIOSRole.wsf.  Fixed OS version logic to handle Windows 10.
• ZTISupportedPlatforms.xml.  Added entries for Windows 10.
• ZTIUserState.wsf.  Fixed OS version logic to handle Windows 10.
• ZTIUtility.vbs.  Added new function and properties to handle modified OS version logic.
• ZTIValidate.wsf.  Fixed OS version logic to handle Windows 10.
• ZTIWindowsUpdate.wsf.  Modified logic to only set detailed Windows Update Agent logging registry entries when debugging.
• ZTIWinRE.wsf.  Fixed OS version logic to handle Windows 10.

So to summarize that, here are the changes:

• Fixed the OS version logic to handle Windows 10 in all scripts.
• Fixed accessibility issues in all wizards.
• Added support for applying a split WIM.
• Updated the task sequence engine from an older ConfigMgr 2007-based version to the latest ConfigMgr 2012 R2-based version.
• Removed undesired Windows Update Agent (WUA) logging entries that could cause WUA to write excessive logging information.
• Added new Windows 10 features to the “role and feature” list.

Other changes in Workbench:

• Removed the “Getting Started” node, as documentation like this can be found on the web.
• Removed the obsolete “Components” node.
• Modified the Windows PE template in LiteTouchPE.xml to add new task sequence engine DLLs.

And in the task sequence templates:

• Sysprep and Capture.  Removed the condition from the “Apply Windows PE (BCD)” step so that it always runs (since all supported OS versions need this).
• Standard Server Task Sequence.  Removed the condition from the “Apply Windows PE (BCD)” step so that it always runs (since all supported OS versions need this).

Given the extent of the changes, it should be a fairly safe and minor upgrade from MDT 2013, but of course do your own testing first, make a backup, and don’t do this in production until the MDT 2013 Update 1 release later this year.  If you’ve made any changes to any of the MDT scripts, be sure to back those changes up so that you can compare your changes to the new scripts and reintegrate those changes if needed.

For those looking planning to do in-place upgrades to migrate from Windows 7, Windows 8, or Windows 8.1 to Windows 10 using System Center Configuration Manager task sequences (described here), you might be interested in doing a “trial run” with existing systems to identify machines that may have issues.  To support this, SETUP.EXE includes a command line switch that tells it to “check for compatibility” but not actually perform the upgrade.  The full command line would typically look something like this:

SETUP.EXE /Auto Upgrade /Quiet /NoReboot /DynamicUpdate Disable /Compat ScanOnly

It’s that last part, highlighted above, that does the trick.  (You may or may not want to specify /DynamicUpdate Disable.  Disabling it causes SETUP to not download the latest compatibility information from Windows Update, but it would be better if you could do this.  That gets more interesting in ConfigMgr, but that’s a longer discussion.)

When you run this ScanOnly execution, the results are returned via return codes from SETUP.EXE itself.  Here are the possible values:

• No issues found:  0xC1900210
• Compatibility issues found (hard block):  0xC1900208
• Migration choice (auto upgrade) not available (probably the wrong SKU or architecture)· 0xC1900204
• Does not meet system requirements for Windows 10: 0xC1900200
• Insufficient free disk space: 0xC190020E

(You’ll see these return codes as large negative numbers, but they are much easier to look at in hex.)

So all you have to do is deploy a simple ConfigMgr package or task sequence to all your devices, with the full Windows 10 source media.  It’s probably not a good idea to use download and execute or download on demand with ConfigMgr in this case – make sure you run SETUP.EXE from the network.  It’s rather unproductive to download the INSTALL.WIM when you aren’t actually going to use it.  But it does have to be there, SETUP.EXE will complain if it isn’t.

Once you’ve run this, you can create a report that shows the devices with each of the statuses.  The first obviously requires no further action, and the last has an obvious course of action (try to free up some more space).  But for the others you’ll probably want to review the SETUPACT.LOG or SETUPERR.LOG generated by SETUP.EXE to see what the specific error was.

Four blogs in a week.  In case you haven’t noticed yet, my team has started blogging to http://blogs.technet.com/WindowsITPro, so be sure to check that location too.  (We announced the release of MDOP and MDT last week.) 

For those using HideShell with Windows 8.1, you can continue to use it with MDT 2013 Update 1 and Windows 10.  It will continue to work well, leaving you with the final summary screen, without being able to interact with the shell, once the task sequence completes:

To enable that, just specify “HideShell=YES” in CustomSettings.ini.  But it’s important to point out that there is a change in behavior in Windows 10 that requires some undoing to make this work.  The default behavior for RunOnce registry entries, which is what MDT uses to implement HideShell, has changed from being synchronous (meaning all must complete before the shell is visible) to asynchronous (the shell shows up before they are done).  That change breaks the MDT HideShell behavior.  To work around that, we have to change a registry entry to get the RunOnce behavior to revert back.  This is done through an entry in the Unattend.xml template provided with MDT:

<RunSynchronousCommand wcm:action="add">
    <Description>disable async RunOnce</Description>
    <Order>4</Order>
    <Path>reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer /v AsyncRunOnce /t REG_DWORD /d 0 /f</Path>
</RunSynchronousCommand>

(If you don’t see that entry in the Unattend.xml associated with your task sequence, maybe you didn’t create a new task sequence after you installed the MDT 2013 Update 1 final release?  That would be a bad thing…)

But there’s one other issue that you can run into, especially if your task sequence doesn’t run for very long in the new Windows 10 OS.  The initial “first run animation,” which is supposed to display while apps and other “one-time” operations are going on, ends up waiting for the RunOnce entries to finish too – and with HideShell in place, that never happens.  Eventually, the animation process gives up, but in the meantime, you have to stare at this screen for a long time:

To fix that, you can disable the first run animation via another registry tweak.  Add this to your Unattend.xml right after the command above that disables the async processing:

<RunSynchronousCommand wcm:action="add">
    <Description>disable animation</Description>
    <Order>5</Order>
    <Path>reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableFirstLogonAnimation /d 0 /t REG_DWORD /f</Path>
</RunSynchronousCommand>

(Sure, you can use WSIM to do this, but Notepad is easier.  If you use Notepad, make sure the “Order” value is unique, e.g. change it to 5 like above.)

With that change in place, you’ll see a different screen:

But sadly, it still takes just as long.  So that by itself didn’t accomplish much.  But there is one more tweak that can be made:

<RunSynchronousCommand wcm:action="add">
    <Description>disable animation</Description>
    <Order>6</Order>
    <Path>reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v DelayedDesktopSwitchTimeout /d 0 /t REG_DWORD /f</Path>
</RunSynchronousCommand>

With that in place, you’ll see Windows switch immediately to the desktop once the local Administrator account signs in, showing the task sequence progress – very quickly.  Mission accomplished.

Changing these policies does affect subsequent user logons, so I would suggest running a script later to remove the registry keys added by the commands above.  Once they are removed, the typical behavior will return.

Windows 10 has created a new way of installing features that aren’t included in the operating system image, kind of like the situation with .NET Framework 3.5 in Windows 8 and Windows 8.1.  Similar, but different.  This enables us to keep the operating system smaller for those that don’t need these features.

To read more about this new “Features on Demand v2”, see the documentation on MSDN (which is where all the ADK documentation can be found now, by the way) at https://msdn.microsoft.com/en-us/library/windows/hardware/mt171094(v=vs.85).aspx.

So if the pieces for these features aren’t included in Windows, where can they be found?  At the moment, in two places:

• On Windows Update.  As a result, machines connected to the internet can download the pieces that are needed automatically.
• On MSDN Subscriber Downloads (for those with MSDN subscriptions) and the Volume Licensing Service Center (for those with VL agreements).  There is a “Windows 10 Features on Demand” ISO available for download that can be used for machines that can’t reach the internet.  (There are separate x86 and x64 ISOs.)

(At the moment, these aren’t available in WSUS, but that’s something we’re working on.)  Let’s look at these one at a time.

From the Internet

So how do you add these features?  There are two approaches, manual and automated.  For the manual approach, use the Settings app and navigate to “System –> App & features –> Manage optional features” and click the “+” sign to add a new one.

If you noticed that the list took a while to populate, with the spinning progress wheel, that’s because it’s building this list from Windows Update – that can take some time.

For the automated approach, you can use DISM.EXE or PowerShell, take your pick.  To list the available “capabilities” (a rather arbitrary name to separate them from features), just use one of these:

DISM.EXE /Online /Get-Capabilities

Get-WindowsCapability -Online

Both will show the same results, but here’s an example from the PowerShell command (the second one, if you didn’t guess):

Notice in that list of couple of items of interest:  NetFx3 (.NET Framework 3.5) and the Insider Hub.

Adding them from the GUI is obvious enough.  From the command line isn’t too bad either:

DISM.EXE /Online /Add-Capability /CapabilityName:NetFx3~~~~

Add-WindowsCapability –Online -Name NetFx3~~~~

Yes, the tilde characters are required, they are part of the name.

From the Media

So back to the other mechanism, the Windows 10 Features on Demand ISO that you can download.  How do you use that?  The basic steps:

1. Download it.
2. Extract the contents into a folder, either on the local system or at a network path that the computer can access (open up permissions for domain-joined computers and users).
3. Tell Windows to use that location.

All you should need to do is tell DISM.EXE or the PowerShell Add-WindowsCapability the path with the Source switch:

DISM.EXE /Online /Add-Capability /CapabilityName:NetFx3~~~~ /Source:C:\Features

Add-WindowsCapability –Online -Name NetFx3~~~~ –Source C:\Features

And as you could do with Windows 8/8.1, you can also specify a “LimitAccess” switch to say “never use anything but the specified source”, if you want to keep it from trying the internet as a fallback.  Unfortunately this isn’t working at the moment, if the machine doesn’t actually have internet access (which kind of defeats the purpose of doing this) – still investigating that.

So that leaves one more question:  What if you wanted to enable the GUI to add these features?  How do you tell it where the extracted features are?  Well, you can’t. The GUI will only talk to the Internet, so you have to use DISM.

From the Media:  A Convenient Workaround

Remember that I said the media isn’t working when you don’t have internet access?  Well, there is a workaround.  The files on the media are CAB files, and those CAB files are actually Windows packages that can be added using:

DISM.EXE /Online /Add-Package /PackagePath:C:\Features\Microsoft-Windows-NetFx3-OnDemand-Package.cab

If you didn’t read through my last post at http://blogs.technet.com/b/mniehaus/archive/2015/09/01/adding-features-including-net-3-5-to-windows-10.aspx, read through that for some background. 

At the bottom of that post is a discussion about adding these “Features on Demand v2” packages to Windows using the DISM /Add-Package command. 

But if you are using MDT 2013 Update 1, there is an even easier approach:  Import the CAB files that you want to add into your deployment share using Workbench, and then MDT will inject them automatically, offline before the OS boots for the first time.  Here’s a sample deployment share that I’ve been using:

That includes the latest (well, latest at the time) Windows 10 cumulative update package, as well as the .NET 3.5 “OnDemandPack” package, in both x86 and x64 flavors.  These will be automatically installed as part of the Windows 10 task sequences.

You can do the same thing with MDT integrated into ConfigMgr using the MDT-provided “Install Updates Offline” feature.  To use that, you would need to create a ConfigMgr package containing the .NET CAB files (one per folder), then point the “Install Updates Offline” step (which you need to add manually to the task sequence sometime before the TS boots into the new OS) to that package.

That’s much easier than the Windows 8/8.1 mechanism, as you don’t need to worry about the “\sources\sxs” folder, very long file paths, etc.

An Overview

A while back, a blog post at http://blogs.windows.com/bloggingwindows/2015/03/16/how-windows-10-achieves-its-compact-footprint/ talked about the things that Windows 10 does differently in order to reduce the total disk footprint. 

Part of these savings come from the fact that Windows 10 systems no longer need or use recovery images, so you can get back 4GB from that.  Instead of using a recovery image, the reset process used by Windows 10 reconstructs the operating system using the components in the \Windows\winsxs folder structure.  (This also has the added benefit that the OS is almost fully patched after the reset.  All but the most recent 30 days of components updates are automatically used.  That’s by choice: you might be resetting to deal with a problem with components that were upgraded in the last month, which would be counter-productive.)

The remaining disk space benefit comes from an optional compression mechanism called Compact OS.  This works by taking many of the OS files and putting them into a single hidden container (basically a WIM file), where they are compressed and all the disk sector waste is eliminated. 

See https://msdn.microsoft.com/en-us/library/windows/hardware/dn940129%28v=vs.85%29.aspx for more information about Compact OS.

This is an evolution from the WIMBoot capabilities provided in Windows 8.1.  It’s easier to set up and deploy, and can even be done after the OS has been installed. 

WIMBoot with Windows 8.1:  Revisited

WIMBoot can still be used with Windows 8.1.  If you want to do that, it is easier than it used to be because all the needed pieces are included in the Windows PE images provided in the ADK for Windows 10.  So the steps to do this using MDT are easier:

• Copy the LTIApplyWIMBoot.wsf script from my WIMBoot blog post into your MDT deployment share.
• Modify your task sequence to add a condition to the existing “Install Operating System” to cause it to be skipped (don’t disable it, as that affects the wizard), e.g. task sequence variable “NOTEXIST” equals “NOVALUE”.
• Add a new “Run command line” script after the “Install Operating System” step and configure it to run:
  
  CSCRIPT.EXE %ScriptRoot%\LTIApplyWIMBoot.wsf

Then you’re ready to deploy.

Compact OS with Windows 10

With Windows 10, the compact OS setup does not require any special images or additional partitions.  It doesn’t use a WIM file, and the compressed files are stored on the normal OS volume.  So there are no special steps needed to configure a machine for compact OS.  You just need to specify that this should be enabled.  There are different ways to do this, depending on how you are deploying (or have deployed) Windows 10.  These are covered in the following sections.

Compact OS manually

If you want to try the new compact OS capability, you can do this directly from Windows PE.  Here are the steps:

1. Format and partition the disk as required.
2. Apply the OS image to an NTFS partition using DISM:
   
   DISM.EXE /Apply-Image /ImageFile:INSTALL.WIM /Index:1 /ApplyDir:C:\ /Compact:ON
   
3. Run BCDBOOT C:\WINDOWS to set up the OS to boot.
4. Reboot.

Compact OS with MDT 2013 Update 1

With MDT 2013 Update 1, MDT moved from using ImageX.exe to apply images to instead use DISM.EXE.  That’s convenient, because it makes it easy to tweak MDT to add the /Compact:ON switch.  To do this, open up LTIApply.wsf in Notepad and find these lines and add the three highlighted ones:

' Apply the image

sCmd = " /Apply-Image /ImageFile:""" & sImagePath & """"
If sRWMPath <> "" then
    sCmd = sCmd & " /SWMFile:""" & sRWMPath & """"
End if
If sSWMPath <> "" then
    sCmd = sCmd & " /SWMFile:""" & sSWMPath & """"
End if
sCmd = sCmd & " /Index:" & sImageIndex & " /ApplyDir:" & sDestinationDrive
If UCase(oEnvironment.Item("OSDCompact")) = “TRUE” then
    sCmd = sCmd & " /Compact:ON"
End if

With those new lines in place, any time the “OSDCompact” variable is set to TRUE, it will add the DISM command line option to set up the compact OS while the image is being applied.  (You might want to set this variable conditionally, e.g. only on systems with 32GB or smaller hard drives.)

Compact OS with ConfigMgr

In theory, you can do something similar with ConfigMgr, replacing the built-in “Apply Operating System” step with a script that does the same thing.  But that’s quite a bit of work, for a couple of reasons:

• The script needs to set the same variables that the built-in step does, otherwise the task sequence will fail.
• The script can’t be used from a “Run command line” step because you can’t use an OS image package with such a step.  To work around this, you need to create a new custom step and add that to the task sequence editor via a MOF file.  (You can cheat and reuse the “Apply Operating System” step’s UI, since the script needs the same inputs anyway.  That just ends up looking rather weird.)

Fortunately, there is an easier way.  You can allow the OS to be deployed without initially configuring it for compact OS, then convert it afterwards, as part of the task sequence.  This will temporarily take up more disk space (about 3GB on a 64-bit system), but I’ll take that for the simplicity of it.

To make this work, set up a new “Run command line” step somewhere in the “State Restore” phase of an MDT-generated ConfigMgr task sequence for Windows 10.  For this step, specify the following command line:

COMPACT.EXE /CompactOS:always

This uses one of the new compact OS switches that have been added to COMPACT.EXE in Windows 10.  This will take 15-20 minutes to compact the OS files, but that’s all there is to it.

Compact OS manually, take 2

You can probably guess from the ConfigMgr section above that the exact same COMPACT.EXE command line can be used on any Windows 10 system to enable (compress) or disable (decompress) compact OS.  Feel free to try it on your system:

COMPACT.EXE /CompactOS:always

knowing you can turn it back off again with:

COMPACT.EXE /CompactOS:never

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 and the DISM 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 can be some oddities with running PowerShell offline if MDT uses the boot.wim from a Windows 10 OS instead of using the winpe.wim from the ADK.  To work around this, change the “UseBootWim” entries in the deployment share’s Settings.xml file to specify “False” and then completely regenerate your boot images.

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.)

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 async RunOnce</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.

An Overview

A while back, a blog post at http://blogs.windows.com/bloggingwindows/2015/03/16/how-windows-10-achieves-its-compact-footprint/ talked about the things that Windows 10 does differently in order to reduce the total disk footprint. 

Part of these savings come from the fact that Windows 10 systems no longer need or use recovery images, so you can get back 4GB from that.  Instead of using a recovery image, the reset process used by Windows 10 reconstructs the operating system using the components in the \Windows\winsxs folder structure.  (This also has the added benefit that the OS is almost fully patched after the reset.  All but the most recent 30 days of components updates are automatically used.  That’s by choice: you might be resetting to deal with a problem with components that were upgraded in the last month, which would be counter-productive.)

The remaining disk space benefit comes from an optional compression mechanism called Compact OS.  This works by taking many of the OS files and putting them into a single hidden container (basically a WIM file), where they are compressed and all the disk sector waste is eliminated. 

See https://msdn.microsoft.com/en-us/library/windows/hardware/dn940129%28v=vs.85%29.aspx for more information about Compact OS.

This is an evolution from the WIMBoot capabilities provided in Windows 8.1.  It’s easier to set up and deploy, and can even be done after the OS has been installed. 

WIMBoot with Windows 8.1:  Revisited

WIMBoot can still be used with Windows 8.1.  If you want to do that, it is easier than it used to be because all the needed pieces are included in the Windows PE images provided in the ADK for Windows 10.  So the steps to do this using MDT are easier:

• Copy the LTIApplyWIMBoot.wsf script from my WIMBoot blog post into your MDT deployment share.
• Modify your task sequence to add a condition to the existing “Install Operating System” to cause it to be skipped (don’t disable it, as that affects the wizard), e.g. task sequence variable “NOTEXIST” equals “NOVALUE”.
• Add a new “Run command line” script after the “Install Operating System” step and configure it to run:

  CSCRIPT.EXE %ScriptRoot%\LTIApplyWIMBoot.wsf

Then you’re ready to deploy.

Compact OS with Windows 10

With Windows 10, the compact OS setup does not require any special images or additional partitions.  It doesn’t use a WIM file, and the compressed files are stored on the normal OS volume.  So there are no special steps needed to configure a machine for compact OS.  You just need to specify that this should be enabled.  There are different ways to do this, depending on how you are deploying (or have deployed) Windows 10.  These are covered in the following sections.

Compact OS manually

If you want to try the new compact OS capability, you can do this directly from Windows PE.  Here are the steps:

1. Format and partition the disk as required.
2. Apply the OS image to an NTFS partition using DISM:

   DISM.EXE /Apply-Image /ImageFile:INSTALL.WIM /Index:1 /ApplyDir:C:\ /Compact:ON

3. Run BCDBOOT C:\WINDOWS to set up the OS to boot.
4. Reboot.

Compact OS with MDT 2013 Update 1

With MDT 2013 Update 1, MDT moved from using ImageX.exe to apply images to instead use DISM.EXE.  That’s convenient, because it makes it easy to tweak MDT to add the /Compact:ON switch.  To do this, open up LTIApply.wsf in Notepad and find these lines and add the three highlighted ones:

' Apply the image

sCmd = " /Apply-Image /ImageFile:""" & sImagePath & """"
If sRWMPath <> "" then
    sCmd = sCmd & " /SWMFile:""" & sRWMPath & """"
End if
If sSWMPath <> "" then
    sCmd = sCmd & " /SWMFile:""" & sSWMPath & """"
End if
sCmd = sCmd & " /Index:" & sImageIndex & " /ApplyDir:" & sDestinationDrive
If UCase(oEnvironment.Item("OSDCompact")) = “TRUE” then
    sCmd = sCmd & " /Compact:ON"
End if

With those new lines in place, any time the “OSDCompact” variable is set to TRUE, it will add the DISM command line option to set up the compact OS while the image is being applied.  (You might want to set this variable conditionally, e.g. only on systems with 32GB or smaller hard drives.)

Compact OS with ConfigMgr

In theory, you can do something similar with ConfigMgr, replacing the built-in “Apply Operating System” step with a script that does the same thing.  But that’s quite a bit of work, for a couple of reasons:

• The script needs to set the same variables that the built-in step does, otherwise the task sequence will fail.
• The script can’t be used from a “Run command line” step because you can’t use an OS image package with such a step.  To work around this, you need to create a new custom step and add that to the task sequence editor via a MOF file.  (You can cheat and reuse the “Apply Operating System” step’s UI, since the script needs the same inputs anyway.  That just ends up looking rather weird.)

Fortunately, there is an easier way.  You can allow the OS to be deployed without initially configuring it for compact OS, then convert it afterwards, as part of the task sequence.  This will temporarily take up more disk space (about 3GB on a 64-bit system), but I’ll take that for the simplicity of it.

To make this work, set up a new “Run command line” step somewhere in the “State Restore” phase of an MDT-generated ConfigMgr task sequence for Windows 10.  For this step, specify the following command line:

COMPACT.EXE /CompactOS:always

This uses one of the new compact OS switches that have been added to COMPACT.EXE in Windows 10.  This will take 15-20 minutes to compact the OS files, but that’s all there is to it.

Compact OS manually, take 2

You can probably guess from the ConfigMgr section above that the exact same COMPACT.EXE command line can be used on any Windows 10 system to enable (compress) or disable (decompress) compact OS.  Feel free to try it on your system:

COMPACT.EXE /CompactOS:always

knowing you can turn it back off again with:

COMPACT.EXE /CompactOS:never

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>