I did offer to let them discuss minimizing images since I get a lot of questions about those things. I personally don't think it's very safe for people who don't know what they're doing, but we never know what we could learn. I guess I'm kinda hoping one of these guys will figure out how to process the pending updates on an offline image so I can do resetbase on updated indexes
OK ... see the point. So far there's a lot of try 'n error testing i saw . Even nLite/vLite/RTLite mostly screwed the system in the times back i gave it a test. Would be nice to see this done properly . Always interested in learning new tricks .
Good question. Did it in my Audit-Mode ProWMC machine and did a componentcleanup before syspreping it. Did not check the size of the new WIM so far. EDIT: OK, ProfessionalWMC with Update 1, swapped Tokens and custom install folder for setupcomplete and a stage after: 4,29 GB .
I tested a before/after sysprep install.esd recovery compression end result. Strangely, the install.esd went up by like 200megs after sysprep. I would have figured on a 200meg decrease, but an increase was unexpected... I don't know about a wim file... Those might be smaller. I'm only interested in the esd files since that's primarily how I release my stuff...
Revised Windows 8.1 Spring 2014 update integration info: I have found that trying to apply all of the updates in one folder without specifying the integration order is problematic. It doesn't matter what you name them, if DISM has to decide how to integrate them because you didn't specify, it will fail. What works is actually very simple. Split them into 2 folders and integrate the servicing stack ones first. Integrate example: Folder1 \ KB2919442 Folder1 \ KB2939087 (unofficial?) Folder2 \ KB2919355 Folder2 \ KB2932046 Folder2 \ KB2937592 Folder2 \ KB2938439 (unofficial?) Then simply integrate them similar to this: Code: dism /image:c:\mount /add-package /packagepath:c:\Folder1\ dism /image:c:\mount /add-package /packagepath:c:\Folder2\ You get the idea...
It shouldn't affect it. The only key part is the 2919442 completion before 2919355. As long as dism doesn't give you any errors, you will be fine.
What feature add, remove how should be new Windows 8.1.1 already decided. Case closed. So it is final RTM release. Official public release is just some updates integrated iso. Updates which otherwise we wil be recieved by Windows online update channel. We saw it before. So anything surprising.
MS always does this sh**... 8.0 RTM, 8.1 RTM, 8.1 Spring2014... We always get a supposed RTM and then they patch the hell out of it... Like seriously MS, just take an extra 30 days and fix that sh** before releasing... Whoever is in charge of software quality assurance over there should be taken out back and flogged.
Well, that's what my friend (MS Hongkong guy) says, the KB's on the MS site is internal and is for the OEM's to test if the update process has problems, they could always revise the KB's, or add yet another KB. Naturally, the RTM itself is final, but we saw in last Aug, MS slipstreamed RollupA and post another edition in MSDN in the GA release.
Don't know... try deleting it, and see what happens. I personally wouldn't do it for anything but a curiosity. WinSxS folder is typically not something you want to butcher if you don't know what you're doing.
Yah... still though... install.esd compression on these is pretty decent compression. It's just a pity it's a pain in the ass to work with esd files. Yah, I finally wrapped my head around that boot wim and winre stuff thx to msmg I kept trying to integrate all the patches to the bootable index. apparently that's a big no-no unless you bring your own support files. I never really thought about including the updates in the boot.wim index 1 and winre.wim files because I've never run into the problem I've had with the 8.0 to 8.1 upgrade I tested today... Oh well, we live and we learn. Now I know to keep an eye out for those type of support kb files since they tend to affect upgrades...