Everything, Everything

2024: January February March April
2023: J F M A M J J A S O N D
2022: J F M A M J J A S O N D
2021: J F M A M J J A S O N D
2020: J F M A M J J A S O N D
2019: J F M A M J J A S O N D
2018: J F M A M J J A S O N D
2017: J F M A M J J A S O N D
2016: J F M A M J J A S O N D
2015: J F M A M J J A S O N D
2014: J F M A M J J A S O N D
2013: J F M A M J J A S O N D
2012: J F M A M J J A S O N D
2011: J F M A M J J A S O N D
2010: J F M A M J J A S O N D
2009: J F M A M J J A S O N D
2008: J F M A M J J A S O N D
2007: J F M A M J J A S O N D
2006: J F M A M J J A S O N D
2005: J F M A M J J A S O N D
2004: J F M A M J J A S O N D
WinSxS And DISM
Wednesday 13th March, 2019 11:04 Comments: 0
A long time ago in an Azure location not very far away, I built a VM in the cloud. This became a "Classic VM" that I mostly left alone as it was set to automatically install patches. I recently decided to check on my very little VM to make sure it was still running okay. After struggling to connect over RDP, I restarted the VM through the Azure Portal and when it came back up the RDP service was happy again (this has happened in the past, and is quite odd because there are IP restrictions that limited access to RDP to a handful of IPs). I tried to connect and got an error. The good news is there's a relatively easy workaround or modifying group policy to let the Remote Desktop client connect to an unpatched server:

Execute gpedit.msc and browse to Computer Configuration / Administrative Templates / System / Credentials Delegation. Then change the Encryption Oracle Remediation policy to Enabled, and Protection Level to Vulnerable.

The bad news is that means the server was missing that patch. Which means it was likely to be missing other patches. A silver lining is that I'm not aware of any security updates for DNS (or TCP/IP) so the VM never exposed any vulnerable services.

I launched Windows Update and it confirmed that patches hadn't been installed in 11 months. I tell it to install patches and watch the single CPU run flat out as the VM very slowly downloads updates. As I let them download in the background, I then notice that I've run out of disk space on the C drive.

The C drive is 126GB and Windows Server 2012 R2 with the DNS Server role really shouldn't use that much disk space. I start poking around various places such as log files and the SoftwareDistribution folder, but nothing looks unusual. Then I watch as the WinSxS folder grows in size as the underpowered VM tried to work out how much disk space the folder takes up. It's definitely the cause.

Unlike 2008 R2, 2012 or 2016, there isn't a Disk Cleanup Tool for 2012 R2 that I can use to help clean things up. I have to get my hands dirty with DISM (I've played around with it in the past, but not in over a year). Thankfully there's a good blog entry that gave me the commands to run:

dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

I had planned on running this to completion, but the disk space on the VM dropped to 0 bytes so I killed this and deleted a couple of setup files in my Downloads folder to make a tiny bit of room (about 50MB). I then ran the actual command to clean things up:

dism.exe /Online /Cleanup-Image /StartComponentCleanup

I left this going overnight and in the morning discovered that I had 114GB free disk space. I then gave the VM a reboot for good measure, and reverted the Group Policy change on the jump box.

I try to like Microsoft products, but I don't really understand how the WinSxS folder can grow that much.

Anyway, after all that, I'll be decommissioning the VM as I no longer need it. I only looked into this in case I need to do something like this again in the future. I can understand why some admins may create a Scheduled Task to periodically run the DISM command, but it does feel like a dirty hack.
© Robert Nicholls 2002-2024
The views and opinions expressed on this site do not represent the views of my employer.
HTML5 / CSS3