Windows updates and recovery: smooth and seamless for IT and end users

STEVE DIACETIS: Hello, and thanks for joining this Ignite 2020 session on Windows updates and recovery I’m Steve DiAcetis, a program manager in the Azure Edge and Platform team In this session, I’ll cover the latest set of capabilities we’ve introduced in Windows 10 version 2004 to make the Windows update and recovery experiences smooth and seamless for you as IT pros and for your users These capabilities are based on feedback many of you have shared with us Over the last few releases and as we plan for future releases, our team is looking to bring the commercial users the same set of improvements we’re bringing to home users This includes improvements in the update platform as well as improvements in the update experience By “platform,” I mean the infrastructure Windows uses to scan, download, and install updates By “experience,” I mean what the end user will see- everything from learning an update is available to the install experience Next, I’ll share guidance on how to manage features on demand and language resources during and after a Windows feature update This includes reviewing what options you have today and a deeper look and demo of one approach using Windows Setup custom actions Let’s get started by looking at changes in the update platform As a quick refresher, let’s look at the content needed to perform Windows 10 feature and quality updates The core OS content includes the base media setup files and the core OS image Next, we have regular updates to this media, including the latest cumulative update, or LCU; servicing stack updates, or SSU; updates to the setup files themselves; and updates to the Windows recovery environment In addition, there are other optional components, including features on demand, language resources, and OEM-provided driver updates Before I forget, check out the Ignite 2020 deployment session titled “What’s changed and what you need to know about on-premises Windows update management.” This session will describe work we’re doing now to combine the LCU and SSU into a single package to make deployment easier As you can see, where this content is acquired from varies based on the workflow For media updates, content comes from several sources, including the volume licensing servicing center, dynamic update, the Microsoft Update Catalog and from OEMs With today’s servicing flow via WSUS, the content comes from similar sources Servicing via the Unified Update Platform, or UUP for short, is a much simpler story Today, with Windows Update for Business, the content comes from Windows Update. In the future, when UUP on-prem ships, the content will come from WSUS You can think of UPP as a one-stop shop for Windows 10 update content For more information on Windows Update for Business, check out the Ignite 2020 deployment session titled “Optimize monthly Windows update delivery for remote work and business continuity,” and see the demo, “How to use the Windows Update for Business deployment service to enable cloud-driven monthly servicing while remaining on a specific version of Windows.” For home users connected to Windows Update and for commercial users connected to Windows Update for Business, UUP is enabled by default for all use cases, including migrating and acquiring optional content It is the most complete delivery of UUP content UUP on-prem will provide IT pros the ability to use WSUS and Config Manager to approve and host update content on premises for the critical use cases, including feature updates, quality updates, optional content migration in an acquisition UUP on-prem was in private preview However, we hit a design issue that caused us to adjust the implementation We are looking to resume the private preview as soon as we can finish coding and testing this adjustment Lastly, contrast UUP-based updates to media-based updates Optional content, for example, is not on the media Language Five resources ship via separate media Dynamic Update, however, is enabled by default and will acquire content from Windows Update Speaking of Dynamic Update, with 2004 we’ve added support for delivery optimization of DU content And we’ll be back-porting to 1903 and 1909 We’ve also included additional Dynamic Update options

to control which subset of content to acquire Let’s move on to the 2004 improvements that tie into the update experience Minimizing user disruption has been an area we’ve been focused on for several releases As you can see, we’ve made significant improvements to reduce feature update offline time With 2004, we have a slight reduction, down to 22 minutes at the 50th percentile, while early numbers for our next release are looking good at 13 minutes I’ve included a testimonial from an IT pro I work with He is seeing “huge reduction in offline time” as his organization moves to the 1909 release and moves from task sequences to the pre-UUP servicing model The 1909 feature update offline time is very low- about 5 minutes for those users coming from 1903- and we expect the same for the 20H2 release We’ve also added new setup parameters to control when feature update offline time begins Our recommendation is to separate the feature update into two phases: First, call “skipfinalize” so the feature update can run silently in the background without interrupting the user This will also ensure that if the user restarts the PC, the restart will not force the update Then, you can call the “finalize” step so you can reboot and commit the update This allows you to set a maintenance window just for this last phase instead of the 2 or more hours you may be using today Also new in 2004 are commands to help manage reserved storage These commands are available via the DISM command-line tool DISM PowerShell cmdlets, and the DISM C API With these commands, reserved storage can be used on devices that did not ship with 1903 or later Once reserve storage is enabled or disabled via these commands, the state is preserved across the OS update See my blog “Managing reserved storage in Windows 10 environments” for more details Starting in 1803, we’ve added the capability to allow IT professionals to customize a feature update by running their own custom scripts during and after a feature update We call this “custom actions.” With 2004, we’ve extended custom actions to support executing scripts after a user uninstalls a feature update and after a successful feature update Later in this session, I’ll show a demo showing how custom actions can be used to migrate FODS and language resources for pre-UUP feature updates Let’s switch gears and talk about device health Specifically, when you install a feature update, we want to be sure you have the necessary capabilities to get devices healthy if the unexpected happens In the rare event that a feature update fails, we have the capability to bring you back to a good state on the Windows 10 version you started from We call this “rollback,” and it is automatic We continue to work to reduce the reasons for rollback As you see from the graph, we brought this down to about 1.4% in Windows 10 version 2004 I know many of you are already familiar with SetupDiag SetupDiag is a stand-alone diagnostic tool that can be used to obtain details about why a Windows 10 update was unsuccessful With the release of Windows 10 version 2004, SetupDiag is included with Windows Setup If there is an issue with the update, SetupDiag will automatically run to determine the cause of the failure Please see the documentation for more details on how it is integrated and where the output is logged We are also working to integrate SetupDiag output directly into Config Manager, showing the top setup errors by device counts and easily allowing you to drill in to see individual devices that are impacted Also new in 2004 is a capability we call “Cloud Recovery.” With Cloud Recovery, we now support downloading OS content from Windows Update to recover devices where the on-device system files have severe corruption This new capability complements the existing on-device recovery capability, which is an image list reinstall of Windows leveraging the existing OS files Both recovery capabilities support the option to keep one’s files or to remove everything Now that we’ve taken a brief look at some of the new update and recovery capabilities in 2004, let’s look at a demo of migrating FODS and languages

using custom actions. To help frame the problem, recall the slide I presented earlier One of the top challenges I hear from commercial customers is how to preserve languages and features on demand during an in-place feature update Let’s take a look at some of the options available The first option is to adopt UUP via Windows Update for Business These devices will automatically preserve FODS and language resources during an update This is device specific: Devices get only the content they need, but of course the content is acquired from Windows Update The second option is to enable Dynamic Update Dynamic Update is the acquisition of update content that is not on the installation media This makes it easier for Setup to complete as it has the latest servicing stack updates, for example It also ensures FODS and language resources are successfully migrated This is an option for both media-based feature updates and pre-UUP WSUS-based feature updates Like option 1, devices get only what they need but will acquire via Windows Update instead of an on-prem source The third option is to customize the Windows image before deployment- for example, adding additional FODS and language resources into a mounted offline Windows image, then using this image for the in-place update This works well if all devices have the same content needs and thus the same image can be used for everyone, but it requires some scripting to perform the customization I have a blog that covers this in detail titled “Updating Windows 10 media with Dynamic Update packages.” The fourth option is a partial solution This approach uses the Windows 10 setup option “/installLangPack” to add language packs and language capabilities, such as text to speech, from a folder that contains the packages This approach lets an IT pro take a subset of optional content and stage them within their network The fifth option is to add optional content after the new OS is deployed IT pros can extend the behavior of Windows Setup by running their own custom scripts during and after a feature update Let’s take a look at the scripts to make this happen There are three scripts I’ll walk you through The first script is to create a FOD and language pack repository for only those FODS and languages I’m interested in This repository will be used as the source to install optional content after the in-place update has completed This script will run once on a back-office machine, not on the Windows 10 device that is being updated The second script will run on the device before installation begins It will save the state of languages and features on demand that are installed but will also copy a subset of the repository locally to use for installation This will reduce the network traffic to the device The third script will retrieve the state from the source OS and install missing languages and FODs Lastly, it will install the monthly update and restart, if needed Let’s take a look at the code for creating the FOD and language pack repository I start by declaring the location of the FOD ISO and the language pack ISO I then mail the Windows OS image from our setup/sources folder I’ll use this mounted image shortly to perform an export Next, I mount the FOD and language pack images and capture the drive letters for each Then, I use the DISM “export-source” command to export only those FODs that I’m interested in, exporting them to the target folder Note that in this code, I’m only showing four capabilities The blog has full code and all capabilities, making it easy to comment out those that you don’t need Next, I copied all language packs to the root of the repository This lets me have a single repository folder that I can host within my network instead of one for FODs and one for languages Now, let’s look at the first script that we’ll run via Setup’s custom action It is called “Preinstall” and will be called by Setup before OS installation starts This script will save state from the source OS and use it to determine what new content should be installed in the new OS I’ll save the language installed, the capabilities installed, and the OS version Also note that my repository path is a network location- in this case, the Z:\Repo The “isLangFile” function is simple Given a path, it’ll return true if it contains one of the two character language codes,

such as en, de, or fr. I’ll use this function later when copying from the optional content repository to a local repository To get started, I saved the installed languages using DISM “Get-International” command From the output, I can save all languages and capture the default system UI language, or “system language,” for short After saving these languages, I use “Get-WindowsPackage” to save in my log file the installed packages This is useful for debugging Then, use “Get-WindowsCapability.” I’ll save all installed capabilities The next step is to create a local repository of FODs and languages To do this, I start by looping through the files that are part of the remote repository that I created earlier and stored on the network share Remember the “isLangFile” function? I use it here to check each file, and if it is a language-specific file, I copy it locally only if it matches a language in use by the source OS This step significantly reduces the number of files that I’ll copy locally Otherwise, if the file is language neutral, I’ll copy it Now, let’s look at the second script that will run via Setup’s custom actions It’s called “Postinstall” and will be called by Setup after Setup completes successfully Like the first script, I’ll declare some variables for storing the source OS state that I saved earlier Also note I’m declaring the path of the monthly update that I’ll apply at the very end After a few basic checks, I retrieve the languages that were used in the source OS Then, I’ll loop through these languages and install the language pack for each I’ll skip the system language as this will match the source OS and thus already be installed Next, I retrieve the source OS capabilities that I saved earlier and save the capabilities that are currently installed in the new OS For each capability installed on the source, I’ll check to see if it’s installed on the new OS And if not, I’ll add it via “Add-WindowsCapability,” using my local repository folder as the source location Next, now that I’ve updated the new OS with FODs and languages, I’ll install the latest monthly update. Why am I doing this? This is necessary to ensure that quality and security updates to the RTM FODs and languages are applied Finally, I’ll restart the device if I have pending updates due to installing the latest monthly update Note that I use “Start-Process” to schedule the restart in 10 seconds, giving the main setup process time to exit cleanly Let’s see Windows Setup custom actions in action I’m starting on Windows 10 version 1809 Let’s confirm via Settings Next, let’s see what languages I have installed As you can see, my system language is en-US, and I have German installed as a second language Next, let’s look at optional features installed I have some supplemental fonts installed, the German language experience FODs, the Routing Information Protocol Listener, along with some remote server administration tools and XPS Viewer To integrate my scripts with Setup, I’ve created a folder under System32\Update\Run, with a folder that is named from a recently created GUID The preinstalled command file will launch my “Preinstall” PowerShell script And similarly, the success.command file will launch my “Postinstall” PowerShell script Both of these scripts are in my C:TEMP working folder along with the LCU I’ll be installing and the Windows 10 version 2004 Setup media Before I launch Setup, let’s look at how I have updates configured You’ll see, I have set up this device to point to a WSUS server, although in this case, it actually doesn’t exist OK, let’s launch Setup Note that I’m disabling Dynamic Update as they want to showcase installing languages and FODs via an on-prem location Setup is now running and before installation, performing initial checks, including disk space requirements Now you can see our “Preinstall” command script executing

This is before installation starts Now that the script completed, installation will start Note that I ran Setup without using the “skipfinalize” nor the “finalize” option I wanted to run it interactively to better show when the “Preinstall” script ran and when installation started Typically, this installation would be happening quietly in the background Now that we’ve rebooted, this is when offline time begins Although we continue to work to reduce this time, it is not this fast I did speed up my demo video At 100%, we’re executing the “Postinstall” script, adding any missing optional content and languages as well as the LCU And of course, a final reboot given we installed the LCU OK, we should now be in the new OS Let’s take a look in Settings again We are now on Windows 10 version 2004 Let’s check out languages As expected, we see English, but we also see German along with the German language experience FODs That’s a good sign Let’s see if optional features migrated I see supplemental fonts, the Routing Information Protocol Listener, RSAT tools, and XPS Viewer It is easy to see these via the date installed Let’s take a look at the log file that these scripts wrote to I see the “Preinstall” script captured the install languages, English and German I also see the packages and capabilities that are installed, including the German language experience FODs And I see the Listener, RSAT tools, and XPS Viewer are installed Next, I see the local repository being created, the files copied from the remote repository Looking at Notepad, only the English and German files were copied That’s also good Now we see the output of the “Postinstall” script I see German was installed along with the German language experience FODs Lastly, I see the packages installed and pending after the LCU is installed Notice the pending state of the rollup fix This is the newly installed LCU prior to the final reboot If you haven’t already, check out the new capabilities we’ve introduced with 2004, including Cloud Recovery, controls for storage reserve, controls for managing feature update offline time, and Dynamic Update improvements Remember, UUP is one-stop shopping for update content and will be integrated with WSUS soon Until then, there are multiple ways to handle optional content migration, including extending Windows Setup via custom actions Have any questions? Contact me at, and as always, thanks for watching