The Windows Servicing Guy

Tips and tricks from a Windows support engineer on issues related to servicing

General guidance on disk provisioning for WinSXS growth

General guidance on disk provisioning for WinSXS growth

  • Comments 24
  • Likes

Seems like this question has come up a lot this past week at work:

How much space should I plan to provision for my new Vista, 2008, Win7, R2 installs? 

This questions comes up in one of two forms.  Either an admin is planning a new deployment and is just curious, or more likely, machines that were provisioned previously are now running out of disk space because the intial disk roll out was too small (usually these systems are under 20GB). 

My answer to this question is always the same: 40GB

Why 40?  Well it gives you good space growth for the servicing directory, which should be in the range of 7-15GB on most machines.  Keep in mind that as you patch your systems and add new roles and features, the WinSXS directory will grow in size.  Also, 40GB allows you to properly keep a reasonable page file on the system.  We see more and more client systems with 6+GB of physical RAM these days in workstation class machines and if you ever encounter an issue such as bugchecks on those systems, you want to be able to make sure you can properly capture a memory dump so we can look at it.  On server class machines, page files are typically moved from the root, so 40GB is a nice enough number to just secure space for growth without too much worry about space concerns

I know I am also asked a lot about what causes the growth in WinSXS and I've written about it in the past on my teams site: http://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx .  If you have to reclaim space, your options are fairly limited.  On Vista and 2008 machines with SP2, you can use the COMPCLN utility to make the service pack permanent and reclaim some space.  If you've already done that, you can force scavenging on the servicing directories by adding/removing a component (I usually use TelNet client because its small and quick).  On Win7 and R2 machines, we auto scavenge at specific intervals, so this isnt necessary and your WinSXS directory is probably correctly reflecting its size.

Hope this helps

--Joseph

Comments
  • I have a question. Suppose I install Windows 7 then I install lots and lots of pre-SP1 patches. Then WinSxS size will obviously grow. Then later when Windows 7 SP1 comes up, I install that and later run Compcln. Will it clean only the files to make SP1 permanent or will it also clean all the space used by pre-SP1 patches which will be anyway part of SP1? Or does installing SP1 clean up the disk space used by pre-SP1 patches?

  • Good question.  I cant comment on what scavenging tool might be in Win7 SP1, but to answer the crux of the question.  When the utility is run, we look at any binary that is a part of SP1 and then remove all of those entries aside from the version thats included with SP1.  So, let's say you've had three patches to NTFS.SYS (v1.0, v1.1, v1.2) and you install SP1 which contains v2.0 of NTFS.SYS.  When you run the utility, the only version of NTFS.SYS left on the system would be v2.0 and the Service Pack would no longer be available for uninstall.  

  • Now that Windows 7 SP1 is going to beta, can you try to get an answer to this question?  In particular, can we finally recover some of the WinSxS bloat once we install SP1?  I have three NetBooks in the family that are basically unable to run Windows update any longer because they're more or less out of space.  I'll probably have to uninstall Office on all of them just to get SP1 installed...Grrrrrr....

    It should be an option to clean out EVERY patch and service pack, at the expense of doing an uninstall, which in almost two decades of using Windows, I've never had to do once...

  • No, there are switches in DISM for SP1 that will allow you to make the service pack permanent, thereby recovering the space somewhat (similar to VSP1CLN and COMPCLN in Vista/2008).  I'm under the assumption that you're using a netbook with a 16GB SSD, otherwise, if you're running out of space there might be another problem.  I could see a 16GB SSD with Windows, Office, other apps and data becoming confined for disk space.

  • So VISTA forces a re-install after time... It is a shame with all the money they get, for making nothing but code and a plastic disc, that they can't get the OS to empower the user and be quicker, each time it's revamped.

    I guess it's time for me to setup my Windows client as a VM, get it to the state I can do what I want, then never save the changes. Of course files would have to be saved onto another drive but that could be done.

    I built my own PC and purchased VISTA 64 and have now re-installed about 5 times. At least the clean installs are easier than xp (can run unattended). The company that sold it were OK about my complaints and sent me a 32 bit version for nothing.

    I wouldn't have known about all this if it wasn't for the Win7 upgrade advisor telling me I was low on disk space, which is odd as only Windows resides on my SSD. Temp folder, recycle bin and everything else removed to another drive. So this was odd. I remembered when I had 30Gig (half) of my SSD free.

    So I used treeview and found what was eating my SSD and now know the only way to deal with it is to not deal with it, and certainly not upgrade to 7. That would make things much worse!

  • Richard;

    I'm not sure if you're just venting or pointing to something else.  If you have an issue with the component store being exponentially larger than normal (7-10GB on Vista) then I'd need more information because you might have another issue going on.  I can tell you that my wife has had Vista running on her machine since release and has never rebuilt the machine due to slowness or other performance issues.  In fact, she wont let me upgrade the machine to Win7 because of the stability of her machine (true story, not MSFT employee B-S).  My guess would be that there is fragmentation on your SSD due to the lack of trim support in Vista.

    --Joseph

  • Slightly off topic: If i were going to build a system and move the profiles directory to D:\Users, i would have to estimate a size for C:, that was not going to either limit growth or waste too much space. So based on this post i would have to make;

    C: = 40GB + %Program Files%

    I wonder if there is any handy data or MS telemetry on the typical size of %ProgramFiles% or \Users, on both 32 and 64bit platforms?

    Btw, has seperating user data from %windir% and %ProgramFiles% ever been seriously considered at Microsoft, as say an Advanced option in Windows Setup?

  • Drew;

    Most enterprises do indeed move the user profiles and I think that the 40GB estimate is a good place for both the OS and ProgramFiles.  Where I personally see people running into issues with space is when they provision 20-30GB for their virtualized environments and then mistakingly install and application or something that allows space to grow past their boundaries.  40GB gives you room for that and also allows for you to do things like take a memory.dmp on the machine without running out of space (in most cases, memory dependent)

    To be  clear here, the 40GB recommendation is not to allow for component store growth.  I get asked that a lot and that was never the intention.  The 40GB recommendation is to allow for component store growth, users, application installations and the proper functioning of the operating system in times of failure (like bugchecks).  Can you get away with less space if you redirect all of these things, yes you can.  Should you?  It depends on the environment.

    --Joseph

  • "...the 40GB estimate is a good place for both the OS and ProgramFiles."

    I would have thought 40GB might be cutting it a bit fine. For example, my %systemdrive% is currently using 37.5GB, none of that is personal stuff, and while there are quite a few programs installed, a lot of them are small utilities. That's just me, but in discussions and reviews of SSDs, i often hear people saying that 64GB drives are not quite enough (for OS and programs), so they go for 128GB drives, or larger.

    Presumably, %systemdrive% would have to be somewhat larger on x64 systems. Is your 40GB recommendation a general one, or for x86 only?

    "Most enterprises do indeed move the user profiles..."

    Is that a reference to the FolderLocations unattend setting, or just roaming profiles & folder redirection? Either way, could you comment on the use of Microsoft-Windows-Shell-Setup | FolderLocations and its implications for servicing? I ask because the online documentation for this setting still links to this page:

    support.microsoft.com/.../929831

    "If you use the FolderLocations unattend settings to move user data to a location other than the %systemdrive% volume some servicing components may not install including but not limited to Critical Updates, Security Updates, Hotfixes and Service Packs."

    However, this page indicates that the servicing issues have been resolved as of Vista SP1:

    support.microsoft.com/.../949977

    If so, why does other Microsoft documentation still refer to the previous article?

  • Drew;

    40GB should be fine, again, this assumes that you arent installing a ton of applications into the system directory.  The recommendation stands for x64 or x86 architectures.

    The KB you mention above is still valid for people not running the latest service packs but isnt as relevant for Vista SP2 and Win7 systems.

  • I'll adopt 40GB as part of my baseline configuration and see how it goes. However, i'll remain conscious of slighly disconcerting stories like this:

    www.shdon.com/.../windows-update-woes

    "The update function had gone haywire, having stored close to a hundred thousand files, making the C:\Windows\SoftwareDistribution\Download folder a ridiculous 22GB in size, accounting for some 40% of all allocated disk space." (55% of 40GB).

    Ok on your second point, although to repeat myself, Windows 7 doco still refers this pre-Vista SP1 relevant article:

    technet.microsoft.com/.../ff715936(WS.10).aspx

    Again, slightly disconcerting. At least it was.

  • The softwaredist story mentioned above is rare and easily solved by renaming the folder and deleting the contents.  What that tells me is that something was either stuck in a pending state or the user had another issue going on.

    The TechNet article is still relevant, specific updates may not apply if you move the users or program directories, thats true.  However, that doesnt mean you cant have applications installed to a different location using the specific apps installer, for example, to alleviate the pressure that would bring to an image.

  • "The softwaredist story mentioned above is rare and easily solved by renaming the folder and deleting the contents."

    Yes, your right. Rare problems like that should be dealt with directly, not indirectly by adding 'error space' to %systemdrive%.

  • 40 gigs is great if you're not going to use it. Or if you want to spend lots of time moving folders from their default locations,   I have a laptop dual booting xp and 7. Use xp all the time; rarely use 7, and i don't even update it that often.  The 7 partition is about 43 gigs.  its windows folder is over 10 gigs, of which 4.4 gigs is winsxs.  

    This installation will be pretty much useless for anything except looking over windows 7.  If you are going to use your documents folder and your libraries as other than links, if you are going to install a lot of progs and are are going to check out a variety of other progs, you will need at least 200 gigs.  The net is littered with complaints from  40-64 gig ssd users who are running out of space under win7.

  • @Mike;  This entry isnt targetted towards consumers.  It's meant as a guideline for admins looking to conserve their provisioned storage in virtual environments (for the most part).  If you're going to utilize the Win7 installation as a full installation and store everything on that local volume then drive space considerations exponentially increase with installed applications/data.