It's not uncommon to find big drives in new servers. Some people might suggest to format it with one NTFS based C:\ drive, but I suggest you don't listen to them. Not placing dynamic data on your C:\ drive is a best practice. This practice requires you to make other disks, volumes or partitions. When implementing new Windows Server boxes this practice usually raises two big questions:
- What data should I place on different drives?
- What size should I make my C:\ drive?
I answer the first question in this post. You'll find my view on the second question in part 2 of this series.
A little while ago I wrote a post on volume, partition and disk recommendations to store your Active Directory files. This post is about 'the other stuff' you want on your server. I won't go into details on how to remove unwanted clutter from your servers. You can find too many tips and tricks by other people explaining how to clean up your drive from unwanted data…
What data should I place on different drives?
In my opinion all data on your hard disk that changes fast or can change fast is dynamic data. Data that you make available to others through an unmonitored external interface can be considered sensitive data. One of the things you might hear me say regularly is:
If it can flood or compromise your C:\ drive, you don't want it there.
This means you got to move this data to a different disk, volume or partition. Typical data that can flood or compromise your C:\ drive is:
Microsoft Small Business Server places shares for your users on the C:\ drive by default. You can move the Client Programs. If your colleagues have access to share folders, moving these is also very beneficial, especially the Users Shared Folder.
Moving their files to a different partition also allows you to set quota without buying additional software, even if you don't have Windows (Small Business) Server 2003 R2. Quota can warn your colleagues when they are using disk space which was reserved for other colleagues.
Shares where groups, departments or divisions can share data are as challenging to control as shares with user data, although there's more social control on the data on these shares. You won't find many people storing their pr0n or gospel collection on departmental shares…
If you plan to make user shares and departmental shares available think about putting them on different partitions. Before the arrival of Windows Server 2003 R2's you could only set quota per drive. (which means partition or volume)
Another thing you might want to do is put your databases on a different drive. After you install Microsoft SQL Server it tends to put databases in its own folders. You can move SQL databases quite easily fortunately.
Databases can become very big very suddenly. I have seen Microsoft Exchange databases that became incredibly big all of a sudden. Because I put the Microsoft Exchange database on a different volume the Information Store exited gracefully and no real harm was done…
Some programs install a database as well. You might think Windows Server Update Services is a perfect example, but MSDE databases don't pose much of a challenge. Programs like your backup program, some difficult accounting bytes and perhaps even the odd ERP application might have their own databases that get installed in the folder of the application. Installing the application on a different drive as a whole might be your only key to success…
Your logs can become large files. Your Windows logs (the ones you access using eventvwr.exe) won't by default because they are typically limited and overwritten. This behavior might not suit your situation in terms of compliancy and you can change these settings if you need to.
IIS Logs and backup logs don't offer the same granular control. The most messed up server I ever encountered had trouble with a 7,1 GB ntbackup.log file residing on the C:\ drive…
Websites are places which in the past have been subject to numerous attack vectors. It's been a couple of years since we had a big issue with Internet Information Services (IIS) within Windows Server. One of the big issues in the past was directory traversal using "..\" commands. IIS checks for this now, but placing websites on your C:\ drive still poses a threat to your system health.
If you place your websites on your C:\ drive, someone gains access to it and places a lot of files on the system your C:\ drive might get cluttered, possibly resulting in loss of data or functionality. Move your Default Website.
If your server is a print server you might want to consider placing the Spool folder on a dedicated volume or on the same volume as userdata. One of the things to remember with Windows 2000 Server is to change the Spool folder before adding the first logical printer. From Windows Server 2003 onwards you don't have to worry about that anymore: When you change the spool folder it moves the files accordingly.
Moving the Spool folder might not sound like a big deal but it might just be in a little while from now. Your company might still be using a lot of black and white printers but is gradually moving towards color network printers. Spool files for color printers are significantly bigger that spool files for black and white printers.
The Windows pagefile is a different story. While the pagefile itself isn't really dynamic data I still suggest moving it to a different drive (meaning volume or partition) unless you use BitLocker Drive Encryption (available from Windows Server 2008) to encrypt the files and folders on your system volume.
Windows moves the pagefile automatically if it finds a different drive is more suitable to store the pagefile. This behavior is triggered by a simple registry key called the PagefileOnOSVolume key. You can change it if you want to disable this behavior. You can read here how to move your pagefile if it's stored on your C:\ drive.
If you have a hiberfil.sys on the C:\ drive of your server you might want to reconsider your career as a systems manager. A server is typically a host servicing other hosts. Going into hibernation does not fit that definition for a production server. You can disable hibernation and standby through powercfg.cpl.
Dynamic data of different types
Of course dynamic and sensitive data of different types tend to bite each other as well. Placing the log files of your backup program on the same partition as your Active Directory doesn't sound like a good idea to me. Arguably you won't be using the Active Directory much during the hours you make backups, but backuplogs tend to become big. Active Directory has some builtin mechanisms to cope with scarce disk space, but you don't want your Active Directory ESE database running out of disk space…
Don't place dynamic or sensitive data on your C:\ drive. Just don't. 🙂
Active Directory on separate volumes
Overview of Active Directory files
A too small of a partition
So how big is your C: Drive?
How to move WSUS MSDE database files to another drive using OSQL
How to Move the Default Web Site to a Different Drive in IIS 5.0
Default Windows Spool Directory and Permissions
How to Move the Windows Default Paging File and Print Spooler to a Different Hard Disk
BitLocker Drive Encryption (BDE) enables the PagefileOnOSVolume registry setting in Windows Vista
How to troubleshoot hibernation and standby issues in Windows XP