Introduction
The architecture of Exchange was dramatically changed from Exchange 5.5 to Exchange 2003. In Exchange 5.5 each server had a copy of the directory which had references to the Windows NT 4 limited directory which had the list of users. In a sense the user owning the mailbox was a property of the mailbox. You could have several mailboxes with the same owner, a group owning a mailbox and even mailboxes with no specific owner.
In Exchange 2000/3 the mailbox became the property of a user. This means each user can have only one mailbox. Groups cannot own a mailbox and you cannot have accessible mailboxes that have no user.
This article will evaluate the ways of making changes in the Exchange 5.5 directory before installing the Active Directory Connector (ADC) tool that synchronizes Exchange 5.5 with Active Directory to ease matching of users and mailboxes.
Manual Labor
In small Exchange deployments it is best to go user by user and find out what the problems are.
It is best to begin with mailboxes which are Administrative owned or resource mailboxes. Regular mailboxes usually match a user in the NT directory, but special mailboxes, typically fax, antivirus, meeting rooms, a lot of the time, are owned by Administrator accounts
A regular user
Typical Fax Mailbox
The primary Windows NT Account in this case is the Administrator of the domain so this means that the user Administrator is the Primary Windows NT Account for more than one mailbox.
There are two ways to resolve this. The first one involves uninstalling the fax application which usually does not migrate well to Exchange 2000/3 esepcially if it’s an Exchange integrated fax application. Then you can just delete the Fax mailbox.
The other method is to create a new Fax user and associate it with the mailbox. To do this double click the user in the Exchange directory. On the General tab click “Primary Windows NT Account”.
After creating the users you should go to User Manager for Domains and enter a complex password for the user.
This method should work for administrative mailboxes because the Administrator account in my example has inherited permission on all mailboxes so access to the mailbox is retained.
However, let’s say you have a library projector mailbox so that users could send e-mails to it requesting to borrow it. The Librarian maintains the mailbox calendar and is the Primary Windows NT Account for the mailbox.
So in this example when the Primary Windows NT Account is changed the librarian loses his permissions over the mailbox.
To fix this, first go in the Exchange 5.5 Administrator to Tools -> Options -> Permissions and make sure that “Show Permissions page for all objects” and “Display rights for roles on Permissions page” are selected.
Now go to the mailbox’s property pages and on the Permissions tab add the mailbox’s owner.
You might have to go through the same procedure for mailboxes with NT groups as Primary Windows NT Accounts such as this one:
The Exchange 5.5 administrator does not display hidden mailboxes with the non-hidden ones so it’s sometimes easy to forget about them. This might be the reason why you can sometimes find retained mailboxes for which the user was deleted that are hidden.
Menu option View -> Hidden Recipients will show you hidden mailboxes.
When you open one you might get the following dialog box:
You will also see the entry “\Unknown Account” as the Primary Windows NT Account because Exchange cannot match the stored SID to a valid account.
To resolve this, if the mailbox contents are still needed, export it to PST and delete it or create a new user for it.
Though going through a list of mailboxes in a large environment might seem like a great burden, sometimes it is the best route since in some companies mailboxes are not deleted properly when they leave or sometimes a second mailbox is created for all kinds of purposes for someone and then forgotten. Editing out the junk and deleting obsolete mailboxes can be one of the great benefits of Exchange migration project.
Bulk Fixes
You can use the Exchange 5.5 Administrator Directory Export option under Tool to export the entire directory to Excel where you can mark which mailboxes need which kind of solution.
Microsoft also provides a tool first known as NDTSAtrb, initially released through PSS channels, then re-released as NTDSNoMatch through Exchange 2000 service packs (in the Server\Support\Utils\I386 folder) and included in the Exchange 2003 deployment tools that you can download here:
This tool goes through the Exchange 5.5 directory analyzing it and looking for users with more than one mailbox.
It does not run on Windows NT 4 but you can it from any workstation with Windows 2000 SP3 and above installed. The Exchange 2003 version also, for some reason, requires a working Windows 2000/3 Global Catalog server and therefore cannot be run before Active Directory is deployed. If you don’t have Active Directory installed yet there is still the option of running the version included in the Exchange 2000 SP3 service pack..
The tool is run from the command prompt. The syntax for the Exchange 2000 SP3 version is simply “ntdsatrb <servername>”. For the Exchange 2003 version the syntax is “exdeploy.exe /s:<servername> /t:ntdsnomatch”. You can add “:<port>” after the server name if you need to change the Exchange LDAP port you’re connecting to.
Examples of Running NTDSNoMatch
The Exchange 2000 version of the tool generates a single CSV file for each site containing the problematic mailboxes and once unified CSV file for all the mailbox problems found.
It also marks all the mailboxes it assumes are resource mailboxes with extension-attribute-10 NTDSNoMatch which lets the Active Directory Connector (ADC) know later on that these mailboxes should be disabled, assuming you did not correct the problems by yourself beforehand.
My test lab contained all the possible problems that were listed before but this version was only able to detect users with more than one mailbox. It cannot detect mailboxes that belong to groups, hidden mailboxes or mailboxes with no primary user.
I ran the Exchange 2003 version against the same Exchange 5.5 directory as follows:
C:\Exdeploy>exdeploy /s:ex55:390 /t:ntdsnomatch
Results of these tools will be logged to ‘exdeploy.log’. Exchange Deployment Tools documentation provides information on how to solve encountered issues.
Calling NTDSNoMatch…
NTDSNoMatch detected a problem.
The Exdeploy utility creates the log files in the “c:\ExDeploy Logs” directory. The main file now has the extension “log” for some reason though it is essentially the same and my hidden mailbox with no account is now found out.
The mailboxes that have a group as a primary user are still not detected in this version.
Conclusion
Though Microsoft provides a tool that can help ease the transition from Exchange 5.5 based directory to Active Directory / Exchange 2000/3 one, going manually over a list of users is sometimes required and is worthwhile. Though theoretically the Exchange 2003 ADC tool can now effectively resolve most of these problems I find better to make sure it does not need to and weed out the problem in the most suitable way beforehand.
