We recently began installing Exchange Server 5.5 Service Pack 3 (SP3) on some servers in our site. After doing so, I noticed that some DLLs on other servers in the site appear to have been updated, even though I never touched those servers. What happened?
You didn't just imagine this phenomenon. Exchange Server 5.5 uses three mechanisms to update organization and site configuration data when you make a change. The first mechanism is directory replication. When you make a change to the directory within any site, Exchange uses the ordinary replication mechanisms to replicate the change throughout the organization. The second mechanism handles schema changes. (Remember, the schema defines the physical layout and format of the directory database.) Exchange Server 5.5 replicates schema changes by realtime remote procedure call (RPC) connections; servers establish these communications to inform peer servers of the changes directly. The final mechanism gets the credit for the change you noticed. When you update Exchange-related DLLs on one server, corresponding servers receive the update because the original server copies the files to shares on the other servers.
Our Exchange Server 5.5 server has recently begun logging event ID 201, which claims that we don't have enough Exchange Client Access Licenses (CALs), even though we do. How can I stop this event from appearing?
This problem comes about because Exchange Server 5.5 can use the License Manager to track the number of licenses you think you have versus the number in use. Sometimes, however, the License Manager guesses wrong, usually because Exchange clients might have multiple logons at once. Having multiple logons occurs by design, but apparently no one told the licensing developers. Anyway, Microsoft recommends using the License Manager application to verify that you have the correct number of licenses. My preferred alternative is to just stop the License Manager service, making sure that you have the correct number of licenses by the old-fashioned manual method of counting noses.
How can I consolidate all my users' Contacts folders into one big public Contacts folder?
You can consolidate your users' Contacts folders in several ways. The easiest way is to make a Contacts public folder and make the users drag their contacts there and leave you out of the process. However, this suggestion might not go over well with your users. Option two is to export each user's contacts to a Personal Folders (PST) file, then reimport the PST file. Although you can perform this task manually, it isn't much fun. Instead, you can use the most recent version of Exmerge, which you can get from Microsoft's Product Support Services (PSS). That version (build 6.0.4417.0 or later) requires Windows 2000 to run, however, which might render it useless for your purposes.
What's the difference between a user and a contact in Exchange 2000 Server?
This question is interesting because in Exchange Server 5.5, accounts and contacts are two completely different entities that Exchange stored in different places. The biggest difference is simple yet subtle: Users are security principals, and contacts aren't. In Win2K parlance, a security principal is any object that has security credentials that someone can use to log on to a resource. A user object has such credentials, but a contact doesn't. In particular, user objects have four attributes that aren't present on contacts: objectSID, SAMAccountName, userAccountControl, and userPrincipalName.
Now, let's talk about users' and contacts' similarities. Both users and contacts can exist in two configurations: mail-enabled and mailbox-enabled. Mail-enabled objects have email addresses associated with them. However, the mere presence of an address doesn't do much, because it's just a directory attribute. Mail-enabled user objects might also be mailbox-enabled, which means that an associated mailbox is attached to the user. Contacts are a little different, because they never have associated mailboxes; instead, you can give them target addresses, which are just external addresses.
What does the Esefile utility do?
Esefile is a relatively new tool. In Exchange Server 5.5 SP3, Esefile is in the CD-ROM's support folder; in Exchange 2000, it's in the support\utils\i386 folder. Esefile has limited functionality: It can calculate page checksums for Exchange 2000, Exchange Server 5.5, and Exchange Server 5.0-format databases (using the /s and /x switches), dump the contents of a page (the /d switch), or copy a database file from one location to another (the /c switch). The copy operation is the most interesting because it's the operation you're most likely to need. When you use /c to copy a file, Esefile opens the database file with no caching, which means that you can copy very large files. However, you can copy only one file at a time, and you can't copy files to a network drive. Apart from those limitations, Esefile is a useful tool to have if you need to copy a private or public database file from one server to another.
How does Exchange 2000's multiple-database support work?
Microsoft designed Exchange Server 5.5 to store public and mailbox data in two different databases; in addition, Exchange Server 5.5 has a separate directory database. In Exchange 2000, the directory database is in the OS and is called Active Directory (AD). You can still have public and private databases on the same machine, just as you can in Exchange Server 5.5, but the Exchange 2000 public and private databases differ from their Exchange Server 5.5 counterparts several ways.
The first difference is the presence of a streaming (STM) file associated with each database. Whereas in Exchange Server 5.5 each database has an EDB file and a set of associated logs, in Exchange 2000 each database has an EDB file and an STM file. The STM file stores message data in the Internet-native MIME format, avoiding the resource-intensive conversions required to go between MIME and Transport-Neutral Encoded Format (TNEF).
The STM file isn't the biggest change, though: Exchange 2000 supports multiple databases on one server. In Exchange 2000 Standard Edition, you can have up to six private or public databases; with Exchange 2000 Enterprise Server, you can use up to four storage groups (SGs), each of which can contain up to six databases. However, Exchange 2000 needs one database slot to perform database restores, so in practice, you don't want to have more than five databases per SG.
With regard to transaction logs, Exchange 2000 now maintains a log for each SG. Therefore, Exchange 2000 Standard still has only one set of transaction logs. However, if you use multiple SGs with Exchange 2000 Enterprise Server, each SG has a set of logs. Losing one SG's log set means you lose the ability to play back transactions for the entire SG—not a happy situation.
Because of these differences, the Exchange 2000's log-file replay process differs slightly from that in Exchange Server 5.5. Here's what happens when you restore a database from any SG on your server:
- You start the backup program and begin the restore. As part of this process, you specify which database you want restored and whether you want the store to automatically mount the database after the restore.
- The Extensible Storage Engine (ESE) copies the restored database back to its original location, and it copies any restored transaction logs to a temporary folder.
- The ESE checks the log files and warns you if any are missing from the disk or the tape. If you're missing logs from the disk, playback will include only those logs from the tape that are necessary to restore the database to a consistent state; you're not guaranteed to have a full recovery.
- The ESE replays the log files from the temporary folder. Unlike Exchange Server 5.5, the ESE can't just play back all the transactions, because some will be for other databases—the databases that aren't being restored. Accordingly, the ESE checks each transaction in the logs and applies only those pertinent to the database that you're restoring.
- If you chose to have the database mounted automatically, the ESE will remount it; otherwise, you'll have to mount it yourself.
I strongly recommend that you test your backup and recovery procedures on a test or nonproduction server before you need to do it for real—several differences from Exchange Server 5.5 can ruin your recovery if you're not prepared.