I've received a couple of emails asking when I would be writing about the changes in servicing in Windows 8.1 and Windows Server 2012 R2. The quick answer, when the product releases. However, to tide you over with some material on some of the changes, I wanted to make you aware of some of the material our product teams have released for the 8.1 Preview. The material is located here: http://technet.microsoft.com/en-us/library/dn251569.aspx
A couple of snippets that I'm sure will interest some of you include:
For fun, here’s one of my machines at work running the preview. First, I analyzed the store on my machine and got the following results
Next, I ran the /StartComponentCleanup switch, which completed successfully and my new analysis reported:
So, my hard linked files didn't change and my backups directory went down about 15MB. There was no appreciable change in the cache. Lastly, I ran the /StartComponentCleanup with the /ResetBase command as well. Here are those results:
Again, size of the backups folder shrank by about 13MB. All in all, the reported explorer size of my component store went from 5.3GB when I started to 5.26GB when I was done. Obviously, these parameters will vary greatly as more and more updates, features, roles, etc are installed as there is the possibility of more files available to remove.
More on interpreting the /AnalyzeComponentStore output
Let’s talk a little more about what is actually happening with the /AnalyzeComponentStore command when its run. As many of you are aware (or have commented here in the past), a very common complaint is regarding the size on disk of the component store. We’ve talked about it other posts regarding how hard links work, what explorer’s doing, etc. Well if you wondered about this stuff in the past, this command was built for you.
I know many of you have used tools in the past that are hard link aware to tell me about how the true size of your component store was only fractionally smaller than what Explorer was reporting and asked why we bother mentioning hard links. The problem with those tools is they are only discounting “duplication” caused by hard links internal to the component store. That represents only a small portion of the misreporting due to hard links because it also needs to account for the files that are hard linked external to the component store. Those files make up Windows and are required with or without the component store.
Given that, when we look at the example below, here’s how to read what /AnazlyeComponentStore is reporting back to you:
The green boxes above show that 100MB of files exist between the Windows Explorer reported size on disk and the actual component store size. This is what was being reported by the hard link aware tools that some of you ran on your systems (this accounts for the hard links internal to the component store). The orange box shows a “Shared with Windows” size of 4.69GB. This represents the files that would be part of Windows whether or not the component store existed (this accounts for the hard links external to the component store). The actual overhead of the component store is the sum of the Backups and Disabled Features and Cache and Temporary Data, or in this case ~480MB.
NOTE: The Backups and Disabled Features also includes component store metadata and true side by side components but that was a little too long to include in an output :)
Hope this is interesting, let me know if there are any questions.
What's exactly the difference between /StartComponentCleanup and /StartComponentCleanup /ResetBase ???
And.... it looks like the .manifest files in WinSxS is now encrypted, how can I view the content of manifests for some manual analyzing ??
We cover that in the article: technet.microsoft.com/.../dn251565.aspx
Basically /resetbase removes all superseded components from the component store, similar to what we used to call 'pinning' for service packs. It makes it so that the fixes installed for a particular component cannot be rolled back.
As for the manifest encryption, they're no longer viewable.
Thank you for the reply, but forgive me for my ignorance, since I'm still not very clear about the difference.
In the article you linked, I found these two sentences:
/StartComponentCleanup: "previous versions of updated components will be immediately deleted"
/ResetBase: "removes all superseded versions of every component in the component store."
They sounds similiar to me. I mean, I think I know what /ResetBase does, but what exactly does /StartComponentCleanup do ? whats the diff between 'delete previous versions' and 'remove superseded versions' ??
Sorry maybe I'm too stupid :-(
The differentiation is updated vs. every. In the case of /resetbase, we do everything in the store, not just components that were previously updated. Updated isn't inclusive of every, whereas every == everything. Hope that clears things up.
And btw, you're not stupid, I agree its confusing verbiage. I'll see what we can do to make that more clear.
ah.... thank you very much ! now I get the diff ...... in theory.
unfortunately, I think maybe I'm really uninformed here, sorry, but under what circumstances a component is 'superseded' or 'updated' ? say I get a KBxxxx from Windows Update automatically, and it creates a new folder in WinSxS, is the old folder considered 'updated' or 'superseded' ? for example, now I have 3 folders:
in my Win 8 (not 8.1) WinSxS, and after I ran /StartComponentCleanup they are all still there, no one was deleted. in fact, no folder was deleted at all, but files in Backup and ManifestCache was cleaned, apparently.
I guess /ResetBase should delete the first 2 folders right ? but why they are not considered 'previously updated' component ??
ResetBase makes the last update as base for new updates. in your case it would remove the version 6.2.9200.16384 which is the RTM files. After doing this you can't uninstall the update which installs version 6.2.9200.16653 because this is now the base for all newer updates.