When discussing a specific .NET framework issue a few months back, several people commented that they were unable to uninstall an update as the new /resetbase command was run against the image after the update was already installed.
So what is this command? Why were they unable to uninstall this update? What other new servicing enhancements were added to Windows 8.1 and Windows Server 2012 R2? Keep reading to find out.
Let’s start by discussing the latter question in the title of this blog. Do we still need to clean up the WinSxS directory?
In short, maybe.
The operating system will now automatically do it for you and you do not have to do anything, but if you want to, you still can. What do I mean by automatically doing it for you? Check out this greatness:
Yes, you are seeing things correctly. That is a scheduled task built in to Windows Server 2012 R2 and Windows 8.1 to automatically cleanup the component store.
What’s the component store? It’s that “pesky” and “misunderstood” WinSxS directory everyone on Windows Server 2008 R2 and Windows 7 complained about that took up too much space. For background information on WinSxS and the need to cleanup the WinSxs directory to free up disk space in previous versions of Windows, see my prior posts:
30 days after installing an update or hotfix, we automatically kick off this bad boy to remove previous versions of the updated files. Is that greatness or what? And so easy! You could literally just let Windows do its job and safely know that the WinSxS directory isn’t going to chow down on all your free disk space! We automatically clean things up for you!
You can kick it off manually anytime by running the scheduled task. By default, it runs for an hour. However, what if it doesn’t complete? Well, it will pick back up where it left off the next time or you could also kick it off via command line by running the following command from an administrative command prompt:
For those of you with the Desktop Experience installed or on Windows 8.1, you can still use the Disk Cleanup Wizard as well and select the Clean up system files button.
If you run this and check the scheduled task afterwards, you’ll notice that the last run time for the StartComponentCleanup task was approximately the same time clean up system files was kicked off from the Disk Cleanup Wizard.
So that’s a start, but what else has Microsoft done?
Compression of Unused Binaries
Well, for starters, we now compressed any unused binaries in the component store. That means that we compress all those features and roles you haven’t installed, but are there in case you decide to install them at any point in the future. You can still remove these in Windows 8.1 or Windows Server 2012 R2 using Features on Demand .
Want to reduce the size even further and cleanup even more?
This is a great command added with Windows 8.1 and Windows Server 2012 R2. Essentially, it’s the mother of all commands. It cleanups and removes all the old superseded stuff from every component in the component store.
Knowledgeable engineers focusing on reducing the size of their images often run this command to tidy up prior to rolling the image into production. It’s a great thing and really does have an impact. However, after running the /resetbase command, all existing updates cannot be uninstalled. It doesn’t block the uninstallation of future updates that are installed after running this command, but all prior updates are made permanent and cannot be removed. The command is as follows:
What all does this mean? Most of it is self-explanatory, but here’s a quick rundown:
Windows Explorer Reported Size of the Component Store – As you may have guessed, this shows the File Explorer reported size. As seen above, it’s not completely accurate. This is due to the use of hard links by the operating system.
Actual Size of the Component Store – This is the true size of the component store.
Shared with Windows – This is the size that the component store would be just per Windows install whether or not the component store actually existed.
Backups and Disable Features – This is the size of the previous versions we store in the component store as well as the binaries of any roles or features you may wish to install in the future
Cache and Temporary Data – Just as it sounds.
As shown above, as part of the analysis, it will even tell you whether component store cleanup is recommended. In this case, it is recommended.
Now that we know the true size, let’s run the cleanup and check our results. For this first run, we’re going to use the following command which is what Windows does automatically behind the covers for you with the scheduled task:
It does take a while. Be patient. But the good news is, it doesn’t require a reboot. After it completes, check it again:
A little over 2GB smaller! Nice!
Now what if we reset the base.
A little bit more, but nothing drastic.
Now, if you don’t want to go to this degree and make all your hotfixes, security updates, etc. permanent, you can simply let the scheduled task do its job or run the /StartComponentCleanup without the /resetbase switch. This will cleanup previous versions of the updates installed, but still allow you to uninstall a security update or hotfix, if needed. Just keep in mind when you uninstall the update after the cleanup, you don’t have the prior version to roll back to, but instead will rollback further, even back to RTM potentially.
In my .NET post , if you’ve read through the comments, several users ran the /resetbase before encountering problems. What options do they have at this point? In short, they need to use an updated source. Check back in a couple weeks when we’ll discuss all the available options for sources and how to keep that source up to date.