Nathan Ziehnert

4 minute read

Well, we’re T-7 days from MMSMOA - I’ve been radio silent for a number of weeks for this exact reason. One of the presentations I’ll be giving surrounds the new cumulative updates that started in Windows 10 version 1809 (you can read about it here). One of the things that I talked about in that post is what to do if you block access to Windows Update in your environment. The answer is to create a Windows Repair Source (WRS). However a WRS is only as good as the files it contains (and their versions). So we need a way to make sure we have a copy of every Windows file that might exist on a particular version of Windows.

You could create a copy of WinSxS for every cumulative update that you apply.

Really?

Yeah. I thought the same thing. So I did something about it.

Build-WRS

I like PowerShell. I write a lot of scripts to support the things that I do and quite frankly I’m really lazy. If I have to do something more than three times manually, you can bet I’ll write a script to do the work. This is one of those cases where laziness actually saves a decent bit of time.

The script essentially does the following:

  1. Mounts and image and index of a WIM file.
  2. If not already done, it copies off the WinSxS folder to a designated location.
  3. Applies an update to the mounted image.
  4. Copies off the WinSxS folder to be merged in that designated location from earlier.
  5. Repeat steps 3-4 through all available updates which have not been applied.

What you’re left with is a folder containing all the files necessary to repair your Windows 10 1809 installation (in theory).

Getting the Script

As always…

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

You can download the most up-to-date copy of the script here

Setting things Up

You need the following items:

  1. A copy of the “install.wim” file from an RTM ISO.
  2. Downloaded copies of all updates released for the version of the OS you’re creating a WRS for.

You’ll want to create the following structure:

ROOT (wherever you would like to store the script)
|--Build-WRS.ps1
|--XXXX (a folder to house the version of Windows you're building the WRS for - e.g. 1809)
   |--image.wim
   |--update1.msu
   |--update2.msu
   |--...
   |--updateX.msu

Additionally you will want to create a folder where you will store your WRS(es). You can create a single folder and the script will handle creating a version folder for each OS you’re building a WRS for.

Running the Script

The script accepts a number of parameters detailed here:

  • -FileLogging: a switch to enable logging to file.
  • -LogFilePath: the full path to where you want to log (including filename). It defaults to %TEMP%\Build-WRS.log
  • -ImagePath: the XXXX folder we created above (or you can point to the ROOT if you have multiple)
  • -ImageIndex: the index of the image you want to mount (e.g. 3 for enterprise in 1809)
  • -WRSPath: the path where you want to store WRS(es). The script converts the OS to a version based on RTM.
  • -Verbose: a switch to enable verbose console output
  • -Debug: a switch to enable debug console output

Call the script as you would any other PowerShell script and watch the fun happen. The script creates an XML file to track what updates have been applied so that the script doesn’t redo work on future runs, saving you time.

The Results

Well, you get a lot of data. From 1809 RTM to the March cumulative update, the SxS folder ended up containing about 12.5 GB of data. So make sure you make room for these WRSes you’re creating. In my testing in the lab the process has worked splendidly and has allowed me to continue patching even when there are corrupt files - which is exactly what this script intends to do.

Deploying the Result

You’ll need to create a Group Policy to point your clients to this WRS. The details on how to do this are available here.

Closing Thoughts

Hope this has been helpful. I have some thoughts out to Microsoft on how it could improve this process, but I’m guessing we won’t see these changes made until 19H2 or even 20H1.

Until next time - Happy Admining!

P.S. See you at MMSMOA! (some of you at least)

comments powered by Disqus

Table of Contents