This topic contains 3 replies, has 3 voices, and was last updated by Anonymous 3 years, 2 months ago.
RicklesPParticipantAugust 2, 2016 at 1:02 pm #166520
I got a good one for ya. I maintain a customer system in a protected environment which does not directly touch the internet. We get updates made available monthly thru a filtered/scanned WSUS upline server. We hold our own WSUS server inside our environment. We get advertisements when updates are available, and approve/download/test/deploy as you would on any managed system.
We also use an MDT-based deployment system for x86 and x64 Win 7 images. We’ve not worried about ‘slipstreaming’ approved updates into the deployable images before, but time to deploy per client is now becoming an issue. We are currently testing a PS script to add all approved updates to the WIM files, but because our WSUS content store holds content for our mix of server and client OSs, Office, SQL, Sharepoint, etc., there’s a lot of updates to scan through, which takes a good deal of time (due to weak performance on the backbone we’re working with, we’re expecting well over 24 hours for the test pass currently running, as I write this.) Having gone thru step-by-step examination of our existing script steps, we can see that all the CAB files are being correctly listed by the query of the content store, but the first few fail to apply. Checking the DISM logs shows that the first few CAB files processed don’t include a specimen manifest, called ‘update.mum’. Since there are over 8,800 CAB files to be processed against the WIM files, we are trying to find some way of identifying which CAB files can be ignored because they don’t have that manifest. We realise that not all updates that do have the manifest file will apply to both images, we just want to speed the slipstream/merge process up.
If you open one of these CAB files in Windows Explorer, you can see all the contents without issue. But isn’t feasible for the size of our content store. So what we’re trying to do is work out a way to check the contents of each CAB file for the expected manifest file, before trying to apply it to the mounted image file. If we have some process which creates a listing of known-compliant CAB files, and we simply process that list against the images, so be it. If we can do it on the fly in the existing script as the recursive lookup collects all the CAB file names, even better. But we’re stumped. Our script executes just fine, it simply takes sooo llloooonnggg and takes over the server in the process. We only want to make the whole thing more efficient.
AnonymousAugust 5, 2016 at 12:44 pm #371946
Nobody?? Ended up suspending backups for a few days to let the DISM tool scan every CAB file in the WSUS store to try and apply any applicable ones to the mounted image we wanted updating. And it’s knocked over 90 minutes off of a deployment of that image. Now we just have to do it regularly to keep the image updated.
OssianModeratorAugust 6, 2016 at 12:22 am #191330
Have you the resources for a dedicated DISM server so you can process the updates separate from your backups?
AnonymousAugust 7, 2016 at 12:37 pm #371948
Not on my development system, sadly, at the moment. What I plan to do moving forward is to use a physical server or even a workstation as the mount host and run the merge over a weekend, on that client (original server tried on is a VM). Calling the update files from the maintenance server, which also run my MDT and backups, shouldn’t impact the backups if I start the image update late enough. The biggest issue I wanted to see about was cutting down the number of CAB files that need to be tried against the mounted image for applicability. But I can’t see any way to automate the examination of the CAB contents to see if a particular manifest file is present. If not, that CAB can be skipped before checking against the image. I can open each one in Explorer and look, but that is a seriously man-draulic process.
You must be logged in to reply to this topic.