Easy way to update (slipstream) a WIM image?

Is there an easy way to apply windows updates to a .wim image? This is specifically for win10.

The best way that I found online to figure out all of the updates needed, was said to build an example system and wait for it to get all the updates, then copy them out of the downloaded software folder, then go through and script each and every one to apply through DISM…

If I’m going to go through that much work, I might as well apply all of them, make sure the example machine is working correctly, sysprep, and capture a new image. It would be a lot shorter to get to the result doing this.

I bring this up because I need to clean and re-image the machines in my classrooms. I wanted to do this during the summer, but summer kind of got cancelled this year. I also need to cough up some budget to get some SSD’s for one room to speed up machines that are overdue to be replaced and probably run them until they really drop. My next target time for this may be our Winter break where I may have a week to accomplish some of this task (hopefully the SSD change).

1 Like

I would use WDS on Windows Server or WDK from a desktop and deploy your installs via PXE boot. Both have a way of managing the images you will be deploying, but then you can also do the install across the network.

1 Like

I am using WDS to deploy things, but is there an easy way to update an already existing .wim image?

1 Like

Both of these look promising:
https://www.infrastructureheroes.org/windows-10/update-maintain-and-use-windows-image-files-wim/

I used WDK in the past, but both of these look like better options.

1 Like

Thanks, I read that one but it still leaves a lot of fixes out by just putting the cumm. update into your .wim. Think I’ll have to continue with the build up a new one and update, then sysprep and create a new image.

I don’t recall if it was you who commented on one of my posts previously but I currently have a stock win10 1909 image that I snapshot(1), update, snapshot(2), sysprep & shutdown, capture, revert to snapshot(2). I use clonezilla to do the imaging and windows 10 seems to cope fine without drivers being included in the image.

Whilst I’m sure there must be a simpler way I spent days trying to work out the new MS deployment stuff 3 or so years ago and got fed up. I think if you only ever use stuff that comes with “proper” .msi installers then you are probably fine using the MS method. Just be aware that (from memory here, not 100% sure) sysprep starts to fail if you apply any feature updates.

I haven’t seen an issue with feature updates, but I also don’t get many because I’m using LTSC. There are some stupid things about activation rearms and stuff that needs to be edited.

One thing to remember, if your example machine gets activated, then you may have an issue with machine count when using Cloning software. This is especially prevalent with MS Office and normally only noticed if you are using KMS. You need at least 5 Office to make KMS work. This is largely negated with the (almost) requirement to go with O365. I still need to work out my next upgrade, building an image with O2016 right now because I can’t be bothered to chase down all the other oddities needed for a newer version. They do not make it easy.

I often need to mess with OS rearm or skiprearm to pull off a correct sysprep. I’ll normally clonezilla a copy of the machine just before I try to sysprep so I have a fix for the work I’ve just completed. Once I get the .wim image created, I’ll normally dump the clozezilla image.

As to what I decided to do with my current project, I went back to the OS install disk and started from scratch. Working on the hours of updates right now. It’s also a high touch image, meaning that I have lots of stuff that won’t deploy through group policy, and won’t survive the image process. Normally takes me about 2 hours after image to get one of these configs back online. It’s better when I have a whole classroom I can just rattle through with 5+ machines all doing the same thing and roll my chair back and forth to each machine. Sometimes the long way just gets the work done, especially when it only gets done every couple of years (or longer).