Microsoft's Feature Pack deployment guide (shipped by the OEMs who sell Windows Storage Server systems) specifies three baseline configurations. (You need to ask your vendor for performance data to determine whether the vendor's recommended configurations will work for your environment.) The baseline configurations are
- one Exchange server, with up to 250 mailboxes hosted on a single-CPU Windows Storage Server computer that has four physical disks in a RAID-5 set;
- one Exchange server, with up to 750 mailboxes hosted by a dual-CPU Feature Pack server with eight physical disks: four in a RAID-5 array for the databases, plus one mirrored pair each for the logs and OS; or
- one or two Exchange servers, with up to 1500 mailboxes split between two storage groups (SGs). In this configuration, Microsoft recommends six physical disks: four for a RAID-5 set containing the databases, plus one mirrored pair for the SGs' transaction logs.
Setting Up the Feature Pack
When you install the Feature Pack (which you need to get from the OEM that sold you your Windows Storage Server machine), it makes some changes to the storage server. The Feature Pack adds a new task (New Share for Exchange Files) to the Web UI. You'll use this task to create Exchange-specific stores on the Windows Storage Server machine. The Feature Pack also creates a new share to hold the software that you need to install on the Exchange server. Thus, you don't need a separate installation for your Exchange 2003 servers.
You do need to install the Exchange server components of the Feature Pack, however. When you do, you get a pair of tools to help you move your Exchange databases to their new home, plus a Windows service that redirects requests for pages in the Store to the databases at their new location. The service uses Dfs to consolidate all the individual database locations into one Dfs root, which the Feature Pack mapping service then maps as a drive; the Feature Pack mapping service can take requests from the Store for individual database pages and turn them into Dfs paths. Exchange 2003 doesn't accept a Universal Naming Convention (UNC) path as a database location, but it does accept a Dfs path that just happens to resolve to a UNC path.
After all the software is installed, your next task is to move your databases. Begin by using the New Share for Exchange Files task to create a share on Windows Storage Server to hold the databases and log files. All the databases from one server must go in the same folder; the Feature Pack supports up to four SGs from two Exchange servers. After you create these shares, you use the database-moving tools to move your Exchange data to the storage server.
You can choose between two tools that have different capabilities but work the same way. The Remote Storage Wizard lets you use a simple GUI to move your databases. WSSExchMove.exe is a command-line tool that lets you duplicate your databases instead of moving them and gives you a way to script moves so that you can perform them as part of an unattended installation. Whichever tool you use, you must run it from the Exchange server. Note that you can only move databases; you can't create a new database directly on the Windows Storage Server computer. The Remote Storage Wizard and WSSExchMove.exe do the following:
- Dismount the databases that you're moving. If you're moving log files, the tools dismount all databases in the SG that you're moving.
- Check the databases for consistency. This check is similar to the one that the Exchange Store does at start-up. The tools won't move inconsistent databases.
- Set the read-only attribute on the original databases and logs, then copy the databases, log files, or both to their new location.
- Create a new Dfs link for each moved EDB and STM file. If you moved the transaction logs, they get new links, too.
- Update the local server with information about the location of the Dfs link targets (which are, of course, on Windows Storage Server).
- Remount the stores.
If you use the Remote Storage Wizard, it deletes the original databases after these six steps are finished. If you're safety-minded, you might prefer to use WSSExchMove.exe with the /n switch, which keeps the original files in their original locations. (It should go without saying that you need to make a full online backup of your server before you move the files.) For maximum safety, you can create a new, empty mailbox database on your Exchange server and move it to the Windows Storage Server machine, then use Exchange System Manager (ESM) to move your users' mailboxes to the new database. This method is slower than using the built-in tools but lets you move mailboxes in small groups until you're satisfied with your setup.
Operation and Maintenance
In typical day-to-day operation, an Exchange database that's hosted on a Feature Pack server should work just as it would if it were hosted locally. (The exception, of course, is if network latency or the load on the storage server is excessive, both of which you can ascertain by using Performance Monitor to watch the disk and network I/O counters.) However, maintaining your server is somewhat different because most maintenance tasks need to run where the databases are.
Maintenance tasks fall into four categories: backup and restore, running Eseutil, tasks that use the Recovery Storage Group, and those that use Microsoft Volume Shadow Copy Service (VSS). Let's look at each category.
Prev. page
1
[2]
3
next page 
