A service of Multiverse Enterprises Inc.
Managing Your Server's Boot Drive
a.k.a. Managing Your Server's C: Drive
I strongly recommend you read through the long version for details on how and why to move things, etc. However, if you want the brief version, see the Summary Table.
If you discover any links that no longer work or have questions, comments, suggestions, or additions about this page, my site, or me, please contact me.
This article is intended for use with Windows 2000 Server and Windows Server 2003-based operating systems. While there are some things here that can apply to 2000 Pro or XP, especially when some of these applications are installed, the article is MEANT for Servers.
Before I get started, I want to make sure you understand that Boot and C: are used synonymously here. It is possible that your boot drive is not the C: drive, but for most of us, it will be C:. Regardless of what drive letter your boot drive is, the recommendations here will still be applicable.
One question I see asked frequently is how to extend the boot drive because it's full or nearly full. In many cases, this is a problem caused by inexperienced systems administrators or lazy consultants.
So what, you might be thinking. Hard disk space is CHEAP by comparison nowadays... why not just make one big 80 GB C: drive. Well, you could do this. But to me, this is a huge waste of space. Further, this question is often enough asked with regards to OEM installs and preconfigured RAIDs.
Still, there are instances where you may legitimately need to increase the size of the boot drive.
Final word of advice - NEVER DELETE - MOVE INSTEAD. It's very easy to restore moved files - it can be a huge pain in the you-know-where to restore deleted files. Move files today... delete them in a month or two - or at least archive them to an external hard drive or DVD.
I'm not going to go in depth here about planning partition sizes right now because your reading this because your partition sizes are already established and in production. Instead, let's consider what an appropriate size is.
The Windows Server 2003 base install takes up about 2-4 GB on average. Of that, the dllcache folder uses about 600 MB or more and you can expect patch and service pack backup folders to use another 200-500 MB or more. You can expect this folder to grow over time, but with a proper configuration and some occasional management, growth will be very, very slow.
Then you have to take into account the various programs and services the system will be needing to run - as well as possible future upgrades to these programs. Ideally, your servers will run only one task or one major task each. In a budget free world, this would be ideal as it allows you to restart a single service/server without affecting other aspects of your network. But we know that very few people live in a budget free world. So add up the typical install sizes for all the services you need to run. If the machine will act as a database server, determine the amount of space needed for the database server application component. The data should live on another partition and not be factored in. In most circumstances, you will likely find that the total size of the Program Files folder is 2-4 GB and does not grow much at all.
The last major folder you need to take into account is the Documents and Settings folder. This is where all your user profiles are stored. Downloaded an ISO image of Windows with the service pack slipstreamed in and saved it to your desktop? It's stored in here. Lots of web browsing results in a large cache of temporary internet files. And don't forget your temp folder is located here too. Then consider if you have more than one admin who logs in to the server, this will create a separate profile for each user and use even more space. If you manage things cleanly, not doing things like web browsing or downloading directly from the server, you will find these profiles typically do not occupy more than .5 to 1 GB of space. Now, add in some miscelleneous files and folders - say 1 GB, and what do you have?
On the low side, this adds up to 5.5 GB and on the high side, 10 GB. So depending on exactly how large the original drive was, you're looking at a drive that should be 8-12 GB. And I'll be more generous and recommend you make it 16-20 GB.
So now, some people like to throw out there the big upgrade question. Here's my big upgrade answer: Most systems are 32 bit and so are not upgradable to 64 bit operating systems even if they have 64 bit hardware. The only way to upgrade a Microsoft OS from 32 bit to 64 bit is through a clean install. Even if you are thinking you want to go with 32 bit for the next version of Windows, my question then becomes, don't you want a stable system? Sure, there's an upgrade path and in theory it should work... but there's nothing more stable than a CLEAN install and I've even heard Microsoft reps suggest that, even though it's technically possible, the upgrade should not be done if at all possible - use a fresh install.
Ok, but what about Small Business Server (SBS)? That's got a lot of stuff in it... I definitely need more than the 12 GB partition Dell (or some other) OEM gave me... right? Again, no. BUT, you do need to make some initial modifications to your OEM preinstalled version of SBS to ensure you don't get into trouble later. Exactly what will be covered below.
Of course, there is one common circumstance where a much larger C: drive makes sense. A Terminal Server. Such servers typically have many users logging in to them at the same time (or even at separate times) and can have a number of different applications installed. For Terminal Server systems, I would typically recommend the C: drive be as large as the disk will allow. Indeed, Terminal Servers should not typically have anything datawise on them so there's little reason to have anything other than a C: partition.
One last note - if you are using SBS 2003, you might want to review the Microsoft TechNet article, Moving Data Folders for indows Small Business Server 2003. This article discusses the various processes for moving data files off C: on an SBS server. It does not include everything I include below, so you might still find it useful to keep reading.
There are many things in a default install, both of the operating system and the server applications you can install, such as Exchange and SQL.
The Windows Pagefile is the file that contains your virtual memory. On a server, this file should be equal to 1.5-3x the amount of RAM in the system, However, the maximum size of the pagefile is a hair under 4 GB, so even if you have 4 GB of RAM or more, the pagefile on the C: drive will not be over 3.99 GB or so. You can have separate pagefiles on different logical and/or physical drives (it's best to have one on a separate set of disk spindles for the best possible performance). Windows by default puts the pagefile in the root of the C: drive with an initial size of 1.5x RAM. If the average server has 2 GB of RAM installed, then the pagefile is using 3 GB of RAM - on a 12 GB boot drive, that's 25% of your total space.
Fortunately, the pagefile CAN, and in my opinion SHOULD be moved to another logical drive (again, if available, another physical disk or RAID volume). Instructions on how to move and better still, optimize your pagefile settings can be found in Daniel Petri's article, How can I optimize the Windows 2000/XP/2003 virtual memory (Pagefile)?
Is there any problem with moving the pagefile off the boot drive? In general, no. Technically, yes. When a stop error occurs (BSOD - Blue Screen of Death), Windows dumps the contents of RAM to the hard disk so that, in theory, you can debug what happened and correct the problem. In reality, the high-level skills required to do such a thing are not common place and since I started working professionally in IT in 1994, I have not once used these dumped files or been asked to supply one for troubleshooting (by Microsoft of anyone else). Indeed, if you have a reproducable problem, you can always reconfigure appropriately so that you can create this file and debug things. So in short - move your pagefile, leaving a 2 MB file on the C: drive to allow "minidumps" - which I have used to get a clue as to what went wrong and are typically only 64K in size.
Especially if you use a preconfigured Small Business Server installation, you can expect to find your Exchange databases stored on the C: drive. For a variety of reasons, including performance and reliability, these databases should be moved to other locations. Complete instructions on moving the Information Store for Exchange 2000 and 2003 can be found in Daniel Petri's article, How can I move Exchange Databases and Logs from one disk to another in Exchange 2000/2003?
While I'm not going to go into detail on Exchange disk optimization, best practices and for performance improvements, you should place the Log files on one set of spindles in a RAID 1 and the Databases themselves on another set of spindles, RAID 5 or better still RAID 10. Best, a high-performance SAN system - but now your costs are rising.
Microsoft SQL Server (7.0, 2000, and 2005) databases can be moved to a different drive (assuming, of course, that you didn't setup SQL to start with pointing to a drive other than C:). Depending on the contents of your databases and how many you have, this can return signficant space to your C: drive.
For instructions on moving databases using the Detach and Attach functions, reference the Microsoft KB article How to move SQL Server databases to a new location by using Detach and Attach functions in SQL Server.
The process of moving MSDE/SQL Express Databases is a different. You will need to backup and then restore the database to a different path. There are two Microsoft KB Articles you can use to reference this process:
Other database applications can usually be moved as well. For example, this forum thread discusses how to move a MySQL database (though it's likely referring to an older 3.x or 4.x version, it likely will still work in newer versions). If you use a different product, consult your manual or do a simple google search for "change location <database brand> database"
Other Data Files
It's impossible to list every application that might want to, by default, store data on the C: drive. However, the vast majority will be able to store their data on another disk. Be sure to review any third party applications to ensure they are not using valuable space on your C: drive.
This does not include your event log files. This is generally referring to the log files of IIS and third party applications that may create and store logs in their program files folders.
For IIS, it's best to archive the logs every so often - there's little use in most environments to have logs that are 6 months old sitting around the logs folder. If you have a frequently visited site with large logs, you should move the logs to another drive. This is a relatively simple process that just requires a little checking of each web/ftp/smtp server properties pages in IIS. This TechRepublic article, Protect IIS log files by moving them to a secure location, discusses how and why moving these logs is a good idea (besides reclaiming space on the C: drive).
Third party applications may or may not allow you to change the location of their logs (if they even have logs at all). However, most third party applications I've encountered do not create excessively large logs. Still, it can be worth investigating if you application can have it's log files changed.
Webs and Other IIS Services
These don't usually take up much space on a server's boot drive, but if you have large downloads available, many graphics, or just lots and lots of text, it could get surprising large. Check the size and if it seems significant, you should relocate the webs to another logical drive. To do this, stop all the web services and then copy (do not move) the entire InetPub folder off the root of C to the new location (or pick and choose and move only the webs/services you want to). Restart IIS and in the properties of each service, change the Home Directory local path.
Shadow Copy Data
Volume Shadow Copy, the new drive snapshot feature of Windows Server 2003 is a fantastically useful technology. Unfortunately, its settings set the default drive to store the copies on to be the same drive as is monitored. If it's enabled on C: it could be using a significant percentage of your drive for its copies. Worse, someone COULD have configured the service to store data from other drives on C:. In either case, you should move the data off C:. The process is simple, but you will lose all previous copies. For each drive you want to change the Volume Shadow Copy settings for, you must first disable it, then re-enable it. Then, before any copies are created, you must change the path for where they are stored. I often setup a drive for this - a logical partition or if possible it's own spindle or set of spindles for increased performance.
To move the data, go to the properties of any hard drive letter and then go to the Shadow Copies tab. Disable the shadow copies for the C: drive (this will ERASE all previous copies but otherwise not affect the drive). Then, re-enable it on the drive and immediately change the location of where you want to save the copies (make it another partition or disk, preferrably). I usually create a separate partition JUST for Shadow Copy data, though for performance it would be better to use a separate physical disk.
Most people know better than to create shared folders on the C: drive. But that doesn't stop Microsoft and many OEMs from configuring Small Business Server 2003 with the Users folder on the C: drive. And it also places the ClientApps folder there as well. These should be moved to new locations on other partitions. Moving these shares is generally a simple task - make sure no one is connected to them, stop sharing them, move the data to the new location, reshare them. Though you should remember to note the share permissions for any shares you move and when moving the files, use a program such as XCOPY or ROBOCOPY that can preserve NTFS permissions. Even a backup and restore of the individual directory tree will suffice.
Virtual Machine (VM) systems, such as VMWare, Virtual PC, and Virtual Server, are great ways to add servers to your network without adding hardware, helping to keep overall server cost low and allowing you to get a little closer to the idea of one server per service. But the VMs hard drive images can be huge and occasionally you may not realize these files might be stored on your server's C: drive. If they are, they are easy to move in the configuration of the virtual machine (shut the VM down - that's a "power off" - a saved state, at least in Virtual Server and Virtual PC will not suffice), move the file, then change the file location in the VM's properties).
The Windows Server Update Services (WSUS) should typically be configured to store updates on a drive other than the boot drive. However, some OEM installations may default the update repository to your C: drive, especially for Windows Small Business Server 2003 R2. If you are using the default configuration of SBS R2 - that is, WSUS 2.0 - then you can reference this TechNet article, titled Managing WSUS from the Command Line. Specifically the Movecontent section - for instructions on how to move the WSUS files to another logical disk. The same command should work for WSUS 3.0. You can also run wsusutil help movecontent from the C:\Program Files\Update Services\Tools folder.
DLL Cache & ServicePackFiles
The DLL Cache helps ensure that any accidentally deleted or possibly corrupted files that are important to Windows are near instantly replaced or repaired. Unfortunately, this cache of backup files can use more than half a gig of space. To reclaim this space, move the DLL Cache to a new drive.
ServicePackFiles contains updated files for Windows to help ensure current versions of important Windows files remain easily found and accessible if you change Windows configuration by adding services.
For details on moving the DLL Cache folder, reference this Windows IT Pro Article, How can I move the DLL cache?. For details on moving the ServicePackFiles, reference this Microsoft KB Article, Files and Folders Are Added to Your System After Service Pack Is Installed. (Interesting to note, the KB Article notes that you can redirect ServicePackFiles to a network share, consolidating many servers into one location... but be cautious - you don't want a 2000 server to point to the ServicePackFiles for a 2003 server or an incorrect Service Pack version).
Certificate Server Data
Microsoft Certificate Server stores its data and log files on the C: drive, but this information can be relocated to another drive. For instructions on doing so, reference Microsoft KB article, HOW TO: Move the Certificate Server Database and Log Files.
So you moved all your data but your still not comfortable with the disk space you have left. Well, there's still a few things you can do to free up some space.
Remove Old NTBackup Catalogs
When you create backups on a regular basis, it creates catalogs of the files backed up. All the retained backups that are listed in the restore tab are collected from the saved catalogs. Over time, you can accumulate a large number of these files with varying sizes depending on what you backup and how often. You can typically find these catalogs in %userprofile%\Local Settings\Application Data\Microsoft\Windows NT\NTBackup\Catalogs. Because they are stored in the local profile, it's possible that if you have multiple users, you could have multiple sets of catalogs (from different backups) all taking up space. These catalogs are largely unnecessary as they are also stored on/in the backup media, but for quick restores of recently created backups, they are also retained in the profile. Older backups, as they are less likely to be used, can have the catalogs deleted.
You can find additional information on Backup Catalogs and the Windows Backup Utility in Microsoft KB Article 249120 (Windows 2000).
Remove Old NTUninstall Folders
When a Windows Update is applied, Windows creates a backup of the files and registry entries that were changed so that, if necessary, the update can be removed. These backups are stored in folders within the %windir% folder, typically labeled $NtUninstall... - ending in a number which corresponds to the KB article related to the update. For example, the folder C:\Windows\$NTUnInstallKB936357$ is the original files that were replaced when the patch described in Microsoft KB Article 936357 was applied. In general, I like to keep 9-12 months of these files handy. There have been occasions where I needed to replace a corrupt/incompatible file and having a relatively recent version of it on the disk has made things easier. That said, TECHNICALLY, you don't need to keep any of them unless you intend/expect to have to remove them. If you really want to be safe, burn these folders to a CD or DVD before deleting.
A couple of notes - these old files are typically compressed so they may not recover quite as much space as you are hoping for. Also, as noted in the more information link below, Do NOT delete the $hf_mig$ folder!
For more information, please read What are the $NTUninstall folders? Can they be deleted?
When Windows crashes, depending on your system settings, you might end up with memory dump files that are between 64 MB and the total amount of RAM installed on the system. If your system is configured so it saves a complete memory dump, if could cause files up to almost 2 GB depending on how much RAM is installed. Unless you are a serious debugging person, these files will usually prove useless to you. With regards to full memory dumps, in my years of professional experience (since 1994) I have never seen an instance where the larger memory dumps have been analyzed or even requested. The smaller ones can be analyzed fairly easily for a "suggested" cause to your crash, but that's another topic. The point here is, any memory dump that is not recent and you don't expect to try to debug can be deleted. Again, if you really want to be safe, burn them to a CD or DVD, otherwise, just delete them and recover the space.
For more information, please review Microsoft KB Article 254649.
Microsoft isn't the only company that can have programming issues. Some versions of Backup Exec have been known to leave behind large temporary files used during backups. While this is one of the more significant problems (given the installed base of BackupExec users), other developers and companies can also have problems - so you might need to hunt down the problem software. For help doing this, see the section below titled I'm Still In Need of More Space! below.
For more information regarding the BackupExec issue, please review this forum posting (while this was not the problem for the poster, it is illustrated by a Microsoft Support Engineer).
Check User Profiles
When a user logs on to Windows, a local profile is created for them - even for Domain Users, a local copy of the profile is setup. If you have a system that is administered by many different people (not advisable) you might find you have many profiles - each profile takes up space. To recover some space, remove profiles for users that do not regularly log in or for users who have left your organization.
Sometimes, admins download large files - service packs, ISO images of Windows, Linux, or other programs, or other large files. From an administration standpoint, this should be done on workstations, not on servers. Nevertheless, if you find such files on your server, you should, move them to another location, burn them to DVD/CD, or delete them outright.
Especially for ISO images, be conscious that another admin might be mounting them as virtual CD-ROMs, so if you have ISO images on your system, consider moving them so they are still available should they be stored on your C: drive.
Also, check your application data folders and My Documents and related folders on the server.
There are some additional locations to take note of under Check Temp Folders immediately below this and instructions for summarizing folder contents with tools and utilities below in the section titled I'm Still In Need Of More Space.
Check Temp Folders
It's not uncommon download large service packs for SQL, Exchange, or Windows, and extract the files to a temporary folder. It's also likely that the original packed version of said service packs could be stored in your temporary internet files folders.
There are three locations you should focus on -
Change Print Spool Folder
By default, when a document is printed, the "print" version of the document gets stored temporarily (permanently if you enabled Keep printed documents in the Advanced tab of the printer Properties) in the Print Spool folder. This folder is, by default, C:\windows\system32\spool\printers. This can be changed easily and placed on another disk. Especially on a print server, this can be an intermittent or even frequent cause of disk full errors. This Microsoft article, How to Move the Windows Default Paging File and Print Spooler to a Different Hard Disk discusses how to move the print spool to another disk (note - it also includes rudimentary instructions for moving the pagefile - I suggest using Danial Petri's article, referenced above, instead. Also, the article indicates it is for Windows XP versions, however, it should still work for Windows Server 2003).
Most admins would recommend having hibernation disabled on a server - and given the negligible benefits, I agree. However, if hibernation has ever been enabled or is currently enabled (perhaps because of an inexperienced admin), you should disable it and then delete the hiberfil.sys file in the root of the boot drive (if it's still on the disk). This one file is equal to the size of RAM and on systems with large amounts of RAM, this can easily eat up 10-20% of the disk or more.
Move/Empty the Software Distribution Directory
This folder contains the various updates Microsoft pushes to your computer through the Windows Automatic Updates service. While its location is hard-coded into the Windows Automatic Update Service, you may be able to move it to another disk using the Junction trick mentioned under Creative Alternatives. This may leave your system in an unsupported state (where neither I nor Microsoft will help you), but if you are in dire need to do this, now you know it may be possible (you would have to stop the Windows Automatic Updates service prior to attempting to implement the Junction).
Move the WinSXS Directory
This folder contains Side-by-Side DLLs, which allow multiple versions of the same DLL to exist "Side-by-Side". Windows links the applicationto the right DLL, allowing multiple applications to share them and always have the requested version available. An excellent description (written for Vista, but should apply to XP and 2003) can be found here: http://www.vistax64.com/general-discussion/169800-winsxs-folder.html#post786771
Moving this folder may leave Windows in an UNSUPPORTED state. That does NOT mean Windows will not work or will crash, but the method of moving it may result in Microsoft refusing to provide support if something does not work correctly. Thus, moving it should only be done in circumstances where there is truly no other reasonable option.
In order to move this folder, you must employ the Junction trick plus some utilities from Microsoft. The following blog post by Matt Wade should likely work for 2003 and XP. It also contains links to necessary utilities to complete the move. http://aspoc.net/archives/2007/12/05/how-to-move-the-winsxs-directory-in-vista/
Move Active Directory
There's a reason this is last. I wouldn't generally recommend touching Active Directory data files out of space concerns, but OCCASIONALLY, a large organzation could end up with a large number of users and in turn a large Active Directory. The following Microsoft KB Article provides instructions for How to relocate the SYSVOL tree on a domain controller that is running Windows 2000 Server or Windows Server 2003. Again, this should only be done as a last resort for needed disk space and frankly, I'd probably look into new servers before moving the AD data.
Ok, so you've done all this and you STILL find you are using more space than seems reasonable. I have on rare occasions seen instances where Windows misreports partition information. This could be caused by several things:
There are a couple of tools you can use to track down what and where your space is used on your server. My favorite tool is the Windows 2000 Resource Kit utility, DIRUSE.
Aother frequently mentioned tool is TreeSize. While a nice tool in general, it lacks the ability to include the contents of folders and files that it does not have access to. You might be able to get around this by running it as a user with Backup Operator abilities. Because of this inaccuracy, I prefer DIRUSE myself, though by comparison, DIRUSE is much more difficult.
Lastly, while no one wants to admit being hacked, it's always a possibility. I once saw a system that was hacked to allow others to download from it - the hacker simply used it as remote storage for warez that others could download.
NT-based operating systems, such as Windows NT, 2000, 2003, XP, and Vista, when using the NTFS file system, have the ability to dynamically compress files. This can help save some space, but is generally not done or recommended. Windows will automatically compress some less used files, such as backups from the installation of patches and service packs and the DLL Cache folder.
The built in compression is done through software and can, in some circumstances, reduce your servers performance. So use it sparingly and only on files and folders where it will really make a difference - for example, IIS log files on light to moderately used web servers are generally all text and will compress quite well. It wouldn't be too inappropriate to compress these. But on a heavier used server, such compression might cause a performance hit and should therefore be avoided. Of course, you might be better off making periodic backups of the IIS logs and removing them entirely - and of course, change their default location to another logical drive letter as discussed earlier.
If you've exhuasted yourself with reconfiguring services and settings and you are still low on space, you may need to resize or reinstall. There are some instances where you just don't have much of a choice. Perhaps you have an upgraded system from Windows NT 4.0 (which had a max C: drive size on install of 4 GB and even with clever installation techniques still maxed out at 7.8 GB). Or maybe the previous admin just under estimated things and made the drive too small.
My personal preference and feeling is that a reinstall using a new set of disks is a better solution than a resize. By using a new set of disks you have a fresh set of spindles handling Windows and your data - this is no guarentee against disk failure, but it's reasonable to assume that newer drives will last longer than the drives currently in your system. A reinstall of this kind also allows you to test your backup plan. By reinstalling on new disks, you have the old ones available should the install/restore have problems, and you get a refresher of how to rebuild and restore a system in the event of a disk failure. If your business relies on it's server, you should be refreshing this at least once a year - it will help most of you sleep better and reduce your actual recovery time since you'll know what to expect.
If you're still stubborn and want to resize, be aware that resizing a disk can take a while. It can also cause data/partition corruption and make getting back into Windows nearly impossible. You also need software that will allow you to resize server volumes - your standard copy of Partition Magic won't cut it. Most server-capable partition resizing tools will be expensive - $300 or more. Sometimes this will be licensed per server, sometimes there will be a Technician's license. When possible, obtain the Technician's license as this will often be the better deal, allowing you to legally use it to resize partitions on an unlimited number of servers. Below is a partial list of tools you can try using to resize your partitions - most if not all can be purchased online and downloaded immediately.
You might also try using Disk Imaging software to create an image of your installation, then install new disks (or wipe the old ones) and restoring to a larger partition size. Though I have not tested this, I believe Acronis Disk Director Server offers this ability.
Sometimes, if moving the data isn't enough and resizing isn't an option, you may need another solution. Fortunately, Windows (since 2000 was released) allows for junctions. A junction is like a unix mount point. Instead of giving a partition a drive letter, you designate it a folder within an existing drive. For more information on junctions/mount points, review the Wikipedia article on NTFS Junction Points.
You can either mount a newly created and formated partition or your can mount an existing partition. A single partition may have both a drive letter and a junction point. (I've done this for games, creating a Games drive and mapping it to C:\Program Files\Games - then I install all my games there so they don't actually take up any (significant) space on C:.
For example, you have application x that is hard coded to store data in C:\Program Files\Application X\Data. You can't move the folder, but you can map a logical disk to this point. Follow the summary steps below:
Ok, so you want the brief version... details on HOW to do these things can be found above - you can consider this something of a checklist...
|Item||Action on Boot Drive||Recommended?||Probable Returned Disk Space||Comments|
|Pagefile||Move and Reduce||Yes||.5 to 3.5 GB||Move the pagefile to it's own spindles if possible, otherwise, another logical partition. Leave a 2 MB min and max size pagefile on the C: drive.|
|Exchange Databases & Logs||Move||Yes||1 to 10 GB
(potentially up to
150 GB or more, but
most likely 1-10)
|If possible and for performance and recovery, put the Database and Logs on different spindles. In an ideal performance config, the database will be on a RAID 10 while the logs on a RAID 1.|
|SQL Databases||Move||Yes||.5 to 10 GB
(depends significantly on database sizes)
|Same as Exchange above.|
|Other Data Files||Move||Yes - but verify with vendor||Varies widely and depends on products|
|Log Files||Move and/or
Archive and Delete
|Yes||Depends on IIS activity||Systems that do not expose IIS services to the internet will not see much space returned, those that do, could see large amounts of storage freed.|
|Webs and Other IIS Services||Move||Only for Servers where IIS services are heavily utilized||Depends on the content stored in the IIS services||Space recovered varies widely depending on server usage and content.|
|Shadow Copy Data||Move (by reset)||Yes||1 to 10 GB or more, depending on original configuration||You can't "move" the shadow copy data, but by disabling it you'll remove the existing copies and then you can re-enable it, specifying another drive to store the copies on. Ideally, it's own set of spindles.|
|Shared Folders||Move||Yes - for any share that has more than 100 MB||Depends on what is stored in the shares||Don't forget to use appropriate tools to copy NTFS permissions and make sure users are not connected when you want to move them.|
|Virtual Machines||Move||Yes||1 to 10 GB or more, depending on VM hard drive number and sizes||Most people using them will know not to put them on C:, but if you have them there, power them off (not saved state), move the file, then change the setting in the config file to point to the new virtual hard disk location|
|WSUS Updates||Move||Yes||1 to 10 GB or more, depending on how you have WSUS configured and what updates you download.||It's probably unlikely you have updates stored on C:, but some OEM installs might. You can reference the Technet article Managing WSUS from the Command Line for information on using the movecontent function of WSUSUtil to move these files.|
|DLLCache & ServicePackFiles||Move||Only if space is an issue||.5 to 1 GB||I only recently learned how to alter the location of these items so while there would likely be little cause for concern, I still won't recommend it unless truly necessary.|
|Old NTBackup Catalogs||Archive and/or Delete||Yes - but only old catalogs, NOT all catalogs||.1 to 1 GB||In theory, the logs are in the backup itself, these just allow for a quicker browsing of their contents and in turn, restore.|
|Old $NTUnInstall... Folders||Archive and/or Delete||Yes||.1 to .5 GB||Recommend keeping folders dated within the last 9 months|
|Memory Dumps||Archive and/or Delete||Yes - for large dumps only||Depends on the type and frequency of dumps||Unless your trying to discover a pattern, old dumps can usually be deleted. Archiving them to CD will never hurt anyone and leave them available for later reference.|
|Bad Applications||Disable, Patch, or Upgrade,
|Yes - but only if it does not affect your business||Depends on the application and problem||Finding a bad application can be difficult, but once found, it should be dealt with appropriately.|
|Check User Profiles||Clean (Delete/Move)||Yes||0 to 10 GB or more, depends on the number of users and what they do||Look for downloaded files on the desktop and in the My Documents and related folders. Also check the web browser temporary files folders and empty them.|
|Check Temp Folders||Delete||Yes||Depends on installed software||In theory, everything can be deleted, but I like to be certain and will usually rename the temp folder and create a new one - if no problems, delete the renamed folder a few days or weeks later.|
|Change Print Spool Folder||Move||Yes - for print servers only||None immediately but should prevent random disk full errors on tight C: drives.||Especially for print servers and environments that print often and/or have large documents, this should be done.|
|Hibernation||Disable||Yes||Equal to your server's RAM||Hibernation on a server is generally not recommended as it has very little benefit and may not be available depending on the memory configuration.|
|Move Software Distribution||Move and/or Delete||
|Depends on the age of the system and downloaded updates. Dozens to hundreds of MB.||It's location cannot be changed without using the Junction trick mentioned in the Creative Alternatives section, but you can temporarily empty it out (but as new updates are downloaded and installed, it will grow again).|
|Move WinSXS||Move||NO||A few MB to several GB||WARNING: DO NOT DO THIS UNLESS YOU HAVE NO OTHER CHOICE. This may leave your system in an unsupported state!!! (unsupported by Microsoft, me, and the author of the instructional blog post below).|
|Move Active Directory||Move||NO||Depends on the size of your domain (users, computers, etc)||Unless you run a VERY large network, moving AD to another drive will not likely return much space.|
You don't have to move data or configure everything suggested here... but these are the typically larger culprits when it comes to what's eating up the space on your hard drive.
For the vast majority of installation a boot (C:) partition of at least 12 to 16 GB is typically sufficient. I might go to 20 before I called it an excessive waste of space for larger partitions. Partitions of 8-12 GB can be sufficient with dilligent efforts to ensure nothing unnecessary is stored on the C: drive. Anything smaller and for SBS or 2003, you might want to seriously consider some method of expansion - my preferred backup and restore - or even a resizing tool, if that is really something you see as a solution.
The information provided here is as accurate as possible, but still may contain errors. Use of the information provided is entirely at your own risk.
You may copy the content of the page in whole or in part provided you include a link directly back to this page.Last Modified: September 6, 2009 - Version 1.3
|11/22/2012 7:38:09 AM - Anonymous|
|very comprehensive, good information, thanks a lot
|11/22/2011 12:02:21 PM - Michael|
|Thanks for the extensive information!
A quick note regarding hibernation: APC PowerChute software can't perform a graceful shutdown of the system unless hibernation is enabled.
|11/8/2011 4:03:14 AM - Ben Helder|
|Lee, you did a very great job on collecting and sharing this info.
Thanks a lot,
|8/25/2011 8:05:14 AM - Chris|
|This is great information. Nice job Lee!
|3/24/2011 7:20:44 AM - Meghal|
|This information is very useful. Thanks for the same.
|12/30/2010 7:13:59 PM - A grateful Google user|
|I'm chiming in to say thank you for two things: taking the time to write this, and for keeping it up online. Keep up the great work helping.
|10/13/2010 7:08:41 AM - Andrew Brent|
|Thanks. Very useful and informative. I have saved this to my favorites.
|9/22/2010 4:18:54 PM - ATD|
|Very informative article. Thanks again! Save my bacon after change logs started chewing through small partition on older server. Moving the servicepackfiles folder freed up lots of space.
|8/24/2010 10:20:46 AM - Shep|
|Very informative! Helped us gain a much needed 3Gb!
|8/3/2010 12:04:07 AM - zenzen|
|Good article summarising a lot of info.
Suggestion - add a paragraph at the top about what can happen if the drive fills up.
|7/5/2010 4:14:28 PM - Andrew|
|I appreciate you making this available. It has helped me.
|3/17/2010 5:21:30 PM - Anne|
|Thanks - this has been very informative.