Documenting Your Exchange Server 5.5 Systems

As an Exchange Server administrator, you've surely heard that your most important job is keeping accurate and up-to-date documentation about your Exchange servers and your Exchange organization. Documenting any server is important, but documenting an Exchange server is vital. Disaster recovery for Exchange Server 5.5 is difficult enough without needing to guess about the organization name, what containers you had, or where you told the Exchange Performance Optimizer to put the log files.

To make the recovery process—and your life—easier, thoroughly document such details as the Exchange service account's name and password; the Exchange server's role; the Exchange organization, site, and server names; the Exchange edition, version, and installed service packs and hotfixes; and which disks and drive letters Exchange uses. Additional server- and organization-related information can also be useful. (Some vendors, such as Ecora, offer Exchange Server—documentation applications. Depending on the size of your organization, you might find such products helpful, but they might not document everything you want them to. With a little elbow grease, you can get exactly the documentation you want without spending additional money.)

Service Account Information
In Exchange 5.5, Exchange services require a service account. You must know the service account's name and password so that you can change the account (e.g., when an Exchange administrator leaves the company or your company's Exchange organization merges with another) and so that you have the information at hand during disaster recovery. Otherwise, you might invalidate all sorts of permissions (especially on public folders) and cause even more problems.

To determine the account's name, open the Control Panel Services applet on the Exchange server, right-click System Attendant Service, and select Properties from the context menu. The name appears in the Service dialog box's This Account text box, which Figure 1, page 2, shows. The password, however, is encrypted, so if you haven't documented it, you'll need to change it.

When you need to change the service- account password, you must first stop all the Exchange services. After you change the password (through the Windows NT User Manager or the Windows 2000 Microsoft Management Console—MMC—Active Directory Users and Computers snap-in), you must change the password in all the Exchange services, then restart the services. If you're in a multiserver site, you need to stop all the services for the site, change the passwords on all the servers in the site, then restart all the services. Obviously, when you write down a password or record it in an electronic file, you need to securely store the document or file to protect that information.

The Exchange Server's Role
You can configure an Exchange server to fit one or more of five roles: Private Store, Public Store, Connector/Directory Import (i.e., bridgehead server), Multiserver (i.e., general-use server), and POP3/IMAP4/Network News Transfer Protocol (NNTP) only. A dedicated Private Store server is one that you use primarily for user-mailbox storage. A dedicated Public Store server is one that you use primarily for public-folder storage. A bridgehead server serves essentially as an email router and therefore contains various connectors. A general-use server is often the only Exchange server in an Exchange site. A dedicated POP3/ IMAP4/NNTP server provides newsgroup connectivity, as well as email for email clients that aren't Messaging API (MAPI)—compliant. Each role has different configuration requirements.

You need to know an Exchange server's role so that you can properly set up a recovered or new server before you restore data during disaster recovery. For example, when you restore a bridgehead server, you don't need to configure it with all the extra information necessary for a general-use server. Or if you configure a restored dedicated Private Store server as a dedicated Public Store server, the system won't have the proper underpinnings. As an added benefit, when you document your Exchange server's role, you'll have the information at your fingertips for use in planning expansions to your Exchange site or organization.

To determine an Exchange server's role, run the Performance Optimizer (perwiz.exe). In the Type of server section, which Figure 2 shows, the Performance Optimizer displays a selected check box next to the chosen roles for that server. Note that a server can fulfill more than one role. For example, if you have only a few clients connecting through MAPI and a POP3/IMAP but you have a large public folder store, you might want to place two Exchange servers in the site. Assign one server the roles of a Private Store and a POP3/ IMAP4/NNTP server, and assign the other server the role of a dedicated Public Store server.

Organization, Site, and Server Names
Exchange is picky about the Exchange organization's name, the Exchange site's name, and the Exchange server's name. Because the Exchange 5.5 server communicates through the X.400 protocol, those names are written into the X.400 address of nearly every Exchange object. Organization and site names are case sensitive. Therefore, if during a restore you transpose one letter of the organization name or incorrectly capitalize the site name, the restored server builds a Directory Store that ends up looking for different information than the backup-tape data that you restored to the machine. As a result, the Directory Service (DS) can't start because it can't reconcile the information it thinks it should have with the information it does have, and you get plenty of errors that tell you The private store could not be updated. Reason: DS_E_COMMUNICATIONS_PROBLEM. Because you can't run Isinteg unless the System Attendant and DS are running, you can't clean out any possible corruption or integrity problems in your data and the data you restored is inaccessible. As a result, you must uninstall Exchange, reinstall it by using the proper information, and restore your data from backup again.

To determine the Exchange organization, site, and server names, open Microsoft Exchange Administrator. The organization name is the first name in the displayed directory structure. The site name is under the organization object and in bold, and the server name is under the site's Configuration\Servers object and also in bold. (For example, in the organization that Figure 3 shows, the organization name is Bag End, the site name is MIDDLEEARTH, and the server name is HOBBITON.) You can also find this information in any edb*.log file. Copy—don't move—the file to a convenient location, then open it in Microsoft Notepad or another text editor. Search for the characters o= and ou=. As Figure 4 shows, the organization name is the word or words that immediately follow the o= characters; the site name is the word or words that immediately follow the ou= characters. (You can also find the server name in this file; the name is located near the organization and site names.)

Edition, Version, Service Pack, and Hotfixes
You need to know which edition (i.e., standard or enterprise) and version of Exchange your server is running, as well as which service packs and hotfixes you've installed on the server. Each new service pack or hotfix changes your Exchange installation in some way—anything from making one change in the schema to disabling the server's ability to serve as an open relay. To perform a successful disaster recovery of Exchange, you must restore an identical server configuration. Don't perform any additional updates during restoration; you must wait until your restore is complete before you change the server's configuration in any way.

To determine which edition of Exchange the restored server is running, restart the machine and open the Application log in the Win2K or NT Event Viewer. If you find an instance of event ID 1217 with a source of MSExchange IS and a Description that reads Information store with unlimited capacity started, the machine is running Exchange 5.5 Enterprise Edition. If you find an instance of event ID 1216 with a source of MSExchange IS Private and a description field that reads Information store with limited capacity enabled, the machine is running Exchange 5.5 Standard Edition. (This event displays twice: once with a source of MSExchange IS Private and once with a source of MS Exchange Public.)

If you didn't document your Exchange server's version and the installed service pack when you built the server, or if you've lost that information, you can find it through Exchange Administrator. In Exchange Administrator's left pane, select the server for which you want the information. Choose File, Properties from the menu bar. As Figure 5 shows, Exchange Administrator displays the version, build number, and any installed service packs. (Keep in mind that when you select Help, About from Exchange Administrator's menu bar, you get information about the Exchange Administrator version on the system you're logged on to, not information about the Exchange Server version on the system you're inquiring about.)

To determine which hotfixes you've installed on an Exchange 5.5 server running Win2K, you can use the qfecheck.exe tool. The Microsoft article "Qfecheck.exe Verifies the Installation of Windows 2000 Hotfixes" (http:// support.microsoft.com/support/kb/articles/q282/7/84.asp) describes the tool and how to obtain it. For a multi-OS hotfix checker, see the Microsoft article "Microsoft Network Security Hotfix Checker (Hfnetchk.exe) Tool Is Available" (http://support.microsoft .com/support/kb/articles/q303/2/15 .asp). The Control Panel Add/Remove Programs applet might also show you a list of installed hotfixes.

Disks and Drive Letters
I recommend that you document the locations of certain Exchange Server files. This information isn't technically necessary for a disaster recovery, but when you recover to an identically configured server, you should also create an exact duplicate of your previous system's file structure so that, for example, you don't accidentally put a 10GB Information Store (IS) on an 8GB disk. I suggest that you document the original locations of the following files:

• Default Exchange Server installation (the default location is usually C:\exchsrvr)
• Private IS database (i.e., priv.edb), which contains user mailboxes
• Public IS database (i.e., pub.edb), which contains public folders
• IS transaction log files
• Directory database (i.e., dir.edb), which contains the directory structure
• Directory transaction log files
• Message Transfer Agent (MTA), working directory, and log file locations

If you didn't document this information when you built the original server, or if you've misplaced the information, you have several methods of locating it. You can run the Performance Optimizer, which will display the files' current locations (or you can read the log file that the Performance Optimizer generated after its most recent run). From Exchange Administrator, you can open the Properties dialog box for the Exchange server and select the Database Paths tab, which displays the information, as Figure 6 shows. You can also look in the server's registry to find the following information:

• For the DS log path, look under the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\MS ExchangeDS\Parameters\Database log files path subkey.
• For the DS database path, look under the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControl Set\Services\ MSExchangeDS\Parameters\DSA Database file subkey.
• For the Information Store service log path, look under the HKEY_LOCAL_ MACHINE\SYSTEM\Current Control Set\Services\MSExchange IS\Param-etersSystem\DB Log Path subkey.
• For the Private Store database path, look under the HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControl Set\Services\MSExchangeIS\ParametersPrivate\DB Path subkey.
• For the Public Store database path, look under the HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControl Set\Services\MSExchangeIS\ParametersPublic\DB Path subkey.

Additional Server and Organization Information
When you restore an Exchange server, you need to type in a lot of miscellaneous information. To simplify that chore, I suggest that you also document which connectors you've installed on the server (e.g., Site, X.400, directory replication connector—DRC, Internet Mail Service—IMS) and how you've configured them. Keep track of configuration information for third-party gateways and enhancements. Document any storage limits and deleted item—recovery time that you set for mailboxes and public folders on the server. Document any other specifics that you can think of, such as routing table configuration and Offline Address Book (OAB) configuration if you have offline, remote users.

You can find information about connectors and other components through Exchange Administrator's Configuration, Connector window; simply drill down through the information in the window's left pane. You can find information about storage limits and deleted item—recovery time in the Exchange Administrator Private Information Store Properties and Public Information Store Properties dialog boxes, which Figure 7 and Figure 8, respectively, show. You can view routing information and delivery restrictions on the Connections tab of the IMS Properties dialog box. You can't view all the IMS and Internet News Server (INS) settings through Exchange Administrator: Exchange stores many of these settings in the registry. However, you probably won't need to access the registry-stored settings, which generally aren't meant to be modified.

I also recommend that you track certain information about your Exchange organization. Document any custom attributes or names that you've added to the organization's site-level Details templates. Keep track of any changes you've made to the Schema Site messaging connector, such as how each site connects to other sites. Record site-addressing information (e.g., default SMTP and X.400 addresses). Document any changes you've made to default site-maintenance functions (e.g., routing recalculation, OAB generation). Keep detailed information about connectors, including public-folder synchronization between servers in a site or organization, and directory processes. When you use multiple connectors, document what each connector is for and which servers are connected to one another.

An exported list of your mailboxes, distribution lists (DLs), and custom recipients can be useful. To create this type of list, you can use Exchange Administrator's Directory Export tool to create a Comma Separated Value (CSV) file that you can view and manipulate through Microsoft Excel. For details about how to use Exchange Administrator's Directory Export and Directory Import tools, see Paul Robichaux, Getting Started with Exchange, "Export and Import Mission: Possible" (http://www.win2000mag .com, InstantDoc ID 9669) and "Super Export and Import Tools" (http:// www.win2000mag.com, InstantDoc ID 9074). You also might want to document mailbox and connector limits and quotas.

Other information that you might decide to keep on hand includes non-Exchange—specific data such as the server's amount of RAM, disk size, BIOS versions, RAID configurations, and controller-firmware levels. Although these details aren't strictly necessary for a successful Exchange restore, documenting them is a good idea.

Planning Ahead
If your servers explode, all your nicely documented information will be completely useless if you've stored it in electronic format on the servers. Therefore, be sure to print out all your Exchange server and organization documentation. Keep duplicates of the printout in either a fireproof safe or a secure offsite location (e.g., the same place that you keep the offsite copies of your backup tapes) so that you can still restore your servers if your office burns to the ground.

And of course, to maintain the value of your documentation, you need to keep it up-to-date. A good rule of thumb is to document every change that you make to the structure of your server. In other words, you don't need to document the addition of a mailbox, but you should document the addition of a container or a connector.

Establishing good documentation of your Exchange servers is a vital part of disaster recovery. Just ask anyone who has ever needed to comb through a log file in search of an organization, site, or server name during a restore.