UPromote and Microsoft Exchange Server
This page provides additional information for users of Microsoft Exchange Server versions 4.5, 5.0, and 5.5.
The Exchange EDB Files
Microsoft Exchange stores all mailbox information in three large files:
- \exchsrvr\dsadata\DIR.EDB - Directory information store
- \exchsrvr\mdbdata\PUB.EDB - Public information store
- \exchsrvr\mdbdata\PRIV.EDB - Private information store
Collectively these are called the "EDB files".
Individual mailboxes within the EDB files are indexed based on the user's Security Identifier (SID). The SID index is stored within the EDB files. When authenticating a mailbox password, Exchange looks up the SID value in the EDB files and forwards your password (in encrypted form) along with the SID to the domain controller for authentication.
The Security ID and the EDB Files
UPromote does not modify SID index (or any other data) within the EDB files in any way.
When UPromote promotes/demotes the computer, it changes the SID prefix of the computer in the registry. Because UPromote does not change the SID prefix of the SIDs stored in the EDB files, users will not be able to access their mailboxes if you move the computer to another domain. For example:
- If the computer was a BDC and you demote it to a standalone
server, and you do not rejoin it back to the same domain as
a member computer, users will no longer be able to authenticate
their mailbox passwords.
UPromote will clone
the user accounts from the domain and make them local accounts.
They have the same names and
passwords, but the
SID prefixes in
the SAM are different.
Exchange will try to authenticate the mailbox password by
sending the original domain SID from the EDB files to the Local Security
Authority (LSA). The SID will not match the new SID prefixes
in the local SAM database in the registry.
Therefore authentication will always
fail and users will not be able to access their
mailboxes.
- If the computer was originally a member server
and you move it to another domain as a BDC,
users from the original domain will not
be able to authenticate their mailbox passwords.
Exchange will try to transmit the old domain SID from
the EDB files to the new DC, which does
not match any SID in the new domain's SAM database.
(You will also need to reconfigure the Exchange service account,
see below.)
As a workaround you can establish a Trust Relationship with the original domain. Exchange will transmit the old domain SID to the new DC. The new DC will recognize that the SID prefix belongs to the trusted domain. It will forward the request (via the Trust Relationship) to the old DC. The old DC will look up the SID its SAM database and authenticate successfully. Users will be able to access their mail as before.
In summary, users will not be able to authenticate their Exchange mailbox passwords if you remove the computer from the domain. The only exception is if Exchange can continue to access the old domain for authentication via a Trust Relationship.
If you keep the computer in the same domain, e.g., by rejoining it back to the domain as a member computer, the authentication will continue to work normally.
Exchange Service Accounts
Windows stores all user accounts in the registry as SIDs, not text names. However there is one important exception: the service accounts for running services. They are stored in the registry as text names, not as SIDs. The names are managed by the Service Control Manager (SCM); they are not changed by UPromote.
A service account name can be stored in several different formats. This is best explained with an example. Assume the domain name is MyDomain, the computer name is MyComputer, and the Exchange logon user name is MyAccount. The account name can be stored in the registry in one of 4 formats:
- MyAccount
- .\MyAccount
- MyComputer\MyAccount
- MyDomain\MyAccount
When the service wants to start, the SCM looks up the account name and translates it to the matching SID. The formats 1 and 2 will search the local SAM database for the account name. If not found, the SCM will then search the domain for the account name. Format 3 will search only the local SAM database for the account name. Format 4 will search only the domain SAM database for the account name. Exchange always uses format 4. The default installation of Exchange will use the domain administrator account (MyDomain\Administrator).
User Rights Are Stored Locally
When you demote a BDC to a standalone server, UPromote will change the SID prefix in the local SAM database. This has the effect of cloning the user accounts with the same names and passwords.
User Rights are a special exception to the clone rule. An unusual feature of Windows is that the domain controller does not authorize the User Rights for a member computer. User Rights for domain accounts are stored locally. The User Rights are always stored in the local SAM database of the member computer, even for domain accounts. This quirk means that when the SID prefix is changed, the User Rights are effectively moved from the domain accounts to the new cloned local accounts.
Exchange requires special User Rights to operate. The User Rights include "Act as Part of the Operating System", "Restore Files and Directories" and "Log on as a Service". Without the required User Rights the Exchange services will fail to start.
Before you run UPromote, the BDC has the correct User Rights in the local computer for the domain account. When you run UPromote to demote the computer it will change the SID prefix for all registry keys. This includes the User Rights in the local SAM database. The result is that the new (cloned) local service account has the correct User Rights, but the original domain service account no longer has the User Rights to run Exchange. The cloned local service account (format 3) now has the User Rights formerly owned by the domain service account (format 4). Because the domain service account no longer has the correct User Rights the Exchange services may fail to start.
(For reasons beyond scope of this discussion you should not run Exchange under the cloned local service account - format 3. This is because many configuration parameters embedded within the EDB files contain dependencies on the original domain service account. If you must change the service account see KB152808.)
After running UPromote you must manually restore the User Rights for the Exchange domain service account using the User Manager for the local computer.
To restore the User Rights for the domain service account use the following procedure: Run USRMGR.EXE. Click on User, and then click on Domain. In the Domain box, type the name of the local computer. (You will see the name of the local computer appear in the title bar.) Click on the Exchange domain service account (e.g., MyDomain\Administrator), and then click User Rights from the Policies menu. Click Show Advanced User Rights. Check the User Rights "Act as Part of the Operating System", "Restore Files and Directories" and "Log on as a Service" and press OK.
The User Rights for the domain account are stored on the local computer so it is important that you add the User Rights on the local computer not the domain controller. It is easy to confuse them. Look at the title bar to make sure you are adding the User Rights on the local computer.
Moving Domains
If you move Exchange to new domain (and do not have a Trust Relationship with the original domain) you will need to change the domain service account for Exchange. This can be difficult because many configuration parameters that are embedded in the EDB files depend on the original domain service account.
The EDB files contain both the text name of the service account and its SID. See KB152808 for the details how to change the domain service account within the EDB files.
The procedure in KB152808 omits an important step: You need to update the Default Windows Domain Name in Exchange Administrator. Select Tools, select Options, and then click on the Permissions tab. Change the default domain name to match the new domain name.
Because of the complexity and difficulty of changing the service account, we recommend that you do not attempt to move Exchange to a new domain. In almost every case it is easier and faster to simply re-install Exchange