Exchange 2003 and Windows Storage Server



Windows Storage Server 2003 is a dedicated file and print server solution built upon Windows Server 2003. There are a number of OEMs, such as HP, that build these appliances and they are becoming quite popular in the small to medium sized business infrastructure. Windows Storage Server 2003 integrates seamlessly into current Windows domains and offers simple file and print storage, backup and recovery options. It is the affordable alternative to expensive Fiber-Channel Storage Area Networks for the small to medium sized business (SMB).


Windows Storage Server 2003 Feature Pack 1 adds additional functionality by supporting the hosting of Exchange transaction logs and database files allowing administrators to consolidate all their file, print and Exchange data onto one reliable server, reducing administration, while increasing reliability.


The Catch-22


Typically, organizations have consolidated servers in an effort to reduce TCO. This meant implementing powerful servers and large Storage Area Networks (SAN). By consolidating many small servers into a few powerful servers with data hosted on an SAN, organizations have been able to increase reliability, decrease administrative overhead and reduce costs. Unfortunately not all organizations can afford to consolidate servers and install SANs, nor do they have the technical expertise to implement such solutions.


Because of this, small to medium sized businesses have relied on direct-attached storage (DAS) or inexpensive Network Attached Storage (NAS) devices. These NAS devices work well for file serving purposes, but have not been supported by Microsoft for Exchange file serving. This has left the SMB out, forcing them to live with DAS, or perform a costly SAN upgrade.


Windows Storage Server 2003 is Microsoft’s foray into the NAS device arena and allows SMBs to implement an affordable SAN solution that supports Exchange and offers good performance and easy administration.


Exchange Storage Requirements


From day one, Microsoft has recommended Exchange administrators separate the Exchange databases and transaction logs and put them on separate physical volumes. The EDB, STM and transaction log files all have different I/O behaviors and therefore have different requirements.



  • EDB files have a random read/write pattern with a 4KB page size
  • STM files have a mostly sequential read/write pattern and use a 64KB page size
  • Transaction log files are always written sequentially in 4KB pages. The only time they are read is when transactions are being replayed.


In a typical Exchange server using DAS, the transaction logs are on a mirrored RAID 1 array and the database files are on a RAID 5 or RAID 10 (1+0) array. This is a recommended configuration that takes into account the different I/O requirements of each and to provide redundancy. Figure 1 shows an example of a typical Exchange DAS storage system.



Figure 1: Typical Exchange DAS scenario


When using Windows Storage Server with Feature Pack 1, the log files can be left on a mirrored array in the server, and the database files can be moved onto the storage server. The example in Figure 2 shows the transaction logs on the Exchange servers RAID 1 while the Exchange database files have been moved to the storage server.



Figure 2: Exchange DAS/Windows Storage Server Scenario


You also have the option to move the transaction log files to the storage server as well, effectively moving all the Exchange data off the server (See Figure 3).



Figure 3: Exchange Storage Server Scenario


Hardware Considerations


The exact hardware requirements will depend on your data storage needs, the number of Exchange users and the size of the databases. Before you start planning you need to determine which size category you fall into, small, medium or large. Microsoft has recommendations for each of these workloads and they are as follows:


Small – Up to 250 Mailboxes on a single Exchange server with a single Windows Storage Server



  • 1GHz or faster CPU with 512MB RAM
  • 4 SATA or SCSI hard disks in a RAID 5 array on Windows Storage Server for Exchange databases
  • 2 SATA or SCSI hard disks in a RAID 1 array on the Exchange server for transaction logs
  • 2 Network cards, one for LAN traffic and one gigabit NIC for connection between Exchange and Windows Storage Server


Medium – Up to 750 Mailboxes on a single Exchange server with a single Windows Storage Server



  • Dual 1GHz or faster CPU with 1GB RAM
  • 6 SCSI hard disks, 4 in a RAID 5 for the Exchange database files and 2 in a RAID 1 array for the transaction logs.
  • 2 Network cards, one for LAN traffic and one gigabit NIC for connection between Exchange and Windows Storage Server


Large – Up to 1500 Mailboxes on one or two Exchange servers with a single Windows Storage Server



  • Dual 1GHz or faster CPUs with 2GB RAM
  • 10 SCSI hard disks, 8 in a RAID 10 array for the Exchange database files and 2 in a RAID 1 array for the transaction logs
  • 2 Gigabit network cards, one for LAN traffic and one for connection between Exchange and Windows Storage Server


The other main consideration is Input/Output Per Second (IOPS). One of the leading factors in increasing IOPS is to increase the number of physical disks. A RAID 5 array with 6 36GB hard disks will support more IOPS than a single 200GB hard disk. The goal here is to keep the Average Disk Queue Length, measured with Performance Monitor, below the number of physical disks. You can calculate an estimated number of IOPS using the following formula, or you can gather data with Performance Monitor to obtain a more accurate reading of your current IOPS numbers.


Estimated IOPS per User for User Type × Number of Users = Estimated IOPS required





User Load


Average IOPS


Mailbox Size


Daily Mail






Up to 50MB


10 Sent/50 Received






50 to 100MB


20 Sent/100 Received






More than 100MB


30 Sent/100 Received


For example, if you have 100 users that fall into the Medium user load category you will require a device that can support at least 40 IOPS (0.4 x 100 = 40). Because most SMB implementations will combine file server and Exchange workloads onto a single server, these requirements may need some fine-tuning.


Exchange will generate an I/O traffic pattern composed of frequent random requests in 4KB blocks, whereas normal file server traffic is more sequential in nature usually sending larger blocks of data. Windows Storage Server uses the Server Message Block (SMB) protocol for both file server traffic and Exchange traffic. This is good because the number of shares on the storage server will have no effect on the performance of the Exchange server, only the kind and size of the data being transferred will have an effect. The best way to combat this is to maintain file server data, Exchange database and transaction logs on their own separate disk array within the storage server.


Configure the Storage Server


The storage server itself is easy to configure. The first step is to install Feature Pack 1, which adds the functionality required to host the Exchange files. It also creates a share with the applications that you will be required to install on the Exchange server.


With Feature Pack 1 installed, open up the web management portal and you should see a new option under Shares called New Exchange Share (see Figure 4).



Figure 4: Storage Server Configuration


Enter the shares name, path and configure user and server access. Once complete click OK to save the configuration.


Now, from the Exchange server, connect to the share on the storage server and install the Exchange Feature Pack components. Two tools will be installed, Remote Storage Wizard and WSSExchMove.exe, which are used to configure Exchange to use the storage server. Also, a new service is installed called the Windows Storage Server Mapping Service (WSSExchMapSvc) which redirects the data requests made to Exchange to the storage server using Distributed File System (DFS). The benefit to using DFS is that it supports your existing Exchange backup tools so that they will continue to see the volume as a local disk.


You can use the Remote Storage Wizard to move the Exchange files from the local server to the Windows Storage Server (Figure 5).



Figure 5: Remote Storage Wizard


Alternatively, you can use WSSExchMove.exe to move the files.



WssExchMove.exe server storagegroup [/l location] [/s store location]



  • Server – the name of the Exchange server currently hosting the mailboxes



  • Storagegroup – the storagegroup that you wish to move



  • /l location – specifies the location of the transaction logs on the Windows Storage Server



  • /s store location – specifies the location of the database files on the Windows Storage Server


You can also view the current configuration with the /i switch.


The last step is to verify the move. If you used the Remote Storage Wizard, check the box next to View Detailed Report When the Wizard Closes. If you used WSSExchMove.exe, log files will be written to the My Documents\Windows Storage Server Logs directory. You should be aware that the stores will be dismounted during the move and users will not have access to their mailboxes during this time.




Windows Storage Server 2003 has allowed SMBs to implement cost effective storage solutions and Feature Pack 1 extends its functionality. By allowing Windows Storage Server to hold the Exchange data files, SMBs can now embrace a centralized storage solution not only for file and print serving, but for their Exchange servers as well.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top