- This topic has 3 replies, 3 voices, and was last updated 4 years, 1 month ago by Anonymous.
RicklesPMemberAug 02, 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.
You must be logged in to reply to this topic.