Preparing large Exchange 5.5 Environments for Migration

A pre-migration process to cleanse and normalize your Exchange 5.5 environment for a migration to Exchange 2000 or 2003.

Imagination Edge Inc. Business and Technology Consultants

Visit our website at: http://www.imedge.net By: Craig Borysowich Craigb@imedge.net Chief Technology Architect

Normalization of the Exchange 5.5 environment

Introduction

The X.400 hierarchy within a large multi-site Microsoft Exchange 5.5 implementation is typically managed by pockets of decentralized IT administrators that do not always follow a common set of standards. This decentralized management of Exchange sites usually means that the data has not remained optimal. This documents aim is to deal with some of the normal non-standard objects existing in the replicated X.400 hierarchy on a macro scale without manually editing any Exchange store files outside the application layer interface. Specifically this document aims to accomplish all of its goals through the application layer of the Microsoft Exchange enterprise environment using the native Exchange administration interface.

General Assumptions

This document assumes that all Exchange servers in the hierarchy are running a minimum service pack level of SP3 or later. Microsoft states that ideally all servers in the organization should be running SP4 for Exchange 5.5. If any servers are patched to a level lower than SP3, they must be upgraded for schema compatibility. When the first Active Directory Connector (ADC) goes in, Microsoft states that all servers in the organization should be on the same service pack. While the preference would be to have all servers at SP4, all servers at SP3 will work out fine. Strange anomalies may occur if you try to normalize 5.5 and migrate with a mix of SP3 and SP4 in you Exchange org. While initial migrations apply to user objects, distribution lists and custom recipients, the process outlined in this document will apply to all objects in the X.400 hierarchy. Many of the procedures in this document apply to a particular type of object that might be encountered in only some of the sites in the hierarchy. This process will effectively invoke a global cleanup of an X.400 hierarchy, which is highly recommended before any migration.

Site Naming Standardization

Syntax is generally not an issue with objects that are not corrupt when being migrated into Active Directory. An exception to this rule is that non-standard characters may not appear in the Microsoft Exchange site display names. Microsoft states the characters allowed are the standard alphanumeric characters plus dashes and spaces. So, only the following characters are accepted:

Valid Site Name Characte rs Alphanumeric: ABCDEFGHIJKLMNOPQRSTUVWXYZ 1234567890

(Both upper and lowercase alpha characters are valid) Symbols: - .

NB: Observe that the hyphen or dash is a valid symbol but the underscore character is not! While other characters and symbols may be valid within the Exchange 5.5 environment, all other characters must be removed from the site names before migration to allow ADC Connection Agreements (CAs) to run successfully. These non-standard characters will

2

not impact the FORESTPREP process unless it is run connecting to an Exchange 5.5 Site with these characters still in the site display name. To remove non-standard characters from the site display name focus on the site in question and edit the display name through the standard Exchange administration utility. Another issue regarding syntax in display names concerns the Organization name. If the organization’s site display name does not match that of the first Exchange server installed in Active Directory your Exchange 2000 install will fail. You must change the Organization’s Display Name with the Administrator to match the current 5.5 Organization name.

Global Address List Object Count

Administrators of sites should confirm that there are no replication issues occurring between their site and the Global Address List (GAL) aggregation server. Confirm that the number of objects in your site matches the number of objects represented for your site in the GAL. Any mismatch in the totals should be fixed before migrating. Cleaning out extra entries from the GAL is good practice, but should not affect migration if this is not done. However, objects in the site directory that are not being replicated into the GAL may not get replicated through the CA either. Finding these objects and correc ting the problems that are blocking their replication is critical.

Providing Credentials for the CA

The ADC’s CA requires an account with ‘service account’ permissions in the Exchange 5.5 site to populate the data from Exchange 5.5 into Active Directory correctly. This is an absolute requirement for using the ADC to integrate Active Directory with Exchange 5.5. This account should not be the existing production service account for Exchange 5.5 for security reasons. The service account does the same rights to the site, configuration container, and organization from the site’s perspective as the Exchange service account. All sites that are to be connected via a CA on the ADC must provide these credentials to the administrator of the ADC during the creation of the CA. The service account should also be limited to a single login so that the account will be locked so long as the CA is operational on the ADC. Also to be supplied are the connecting Exchange 5.5 server’s name, IP address, NT domain name plus an Active Directory Domain Controller in the domain to be populated. A contact to be utilised for issues should also be supplied. NB: The Active Directory Domain Controller supplied must be a Global Catalog role holder. The Connection Agreement also requires an account in Active Directory for the CA to write and update the directory content from Exchange 5.5. This can be the same account for all CAs however, I would recommend creating a specific account for this purpose.

Hidden Mailboxes and Accounts

The ADC will respond to hidden accounts in one of several ways depending on how it is configured. It is highly recommended to determine the status of the hidden mailbox or object and deal with it before migration. Determining the mailbox’s desired Active Directory status after migration is recommended.

3

Hidden objects come across via the ADC, and should retain their hidden status, although they will be visible through the Active Directory Users and Computers MMC snap-in. When inspecting their properties, they should have a check box selected that hides them from the GAL. With this box checked, they will not be visible to Outlook users when they search the address book. Back up any mailboxes that are not to be migrated before migration in preparation for deleting them. Export the mailboxes out to a .PST file along with either a brick-level or a full Exchange information store backup that is kept in a safe location before deleting the undesired mailboxes. This will make it a lot easier to recover a spec ific mailbox if it is determined that it should not have been deleted at a later date. Making the mailboxes visible and allowing NTDSNoMatch to be run against it should clarify everything. Once NTDSNoMatch has been run against the server upon which the object resides a decision can be made as to whether or not to allow it to be imported with Custom Attribute 10 set with NTDSNoMatch or to allow it to be generated into the E2K environment with an inactive but visible account.

Removing the Hidden Attributes

In order to run NTDSNoMatch against hidden users they must be made visible. This is done by reversing the selection of hidden on the objects’ advanced tab. Manually removing the hidden attribute from several hundred users is extremely time consuming. An easy way to quickly accomplish this task is to use the export function that is part of the exchange administration interface. Using the Directory Export function located under the Tools menu, export the selected recipient container to CSV including hidden objects. Once generated you might consider using this list to make decisions as to the migration status of objects and their desired outcomes. By searching on the ‘Hide from AB’ column you can easily isolate the hidden accounts as they have a value of ‘1’ (without the quotes). Once isolated you might consider doing a global removal of the 1 or a global replacement of the syntax “cn=Recipients, 1” with “cn=Recipients,” (no quotes) in WordPad. If you import this edited CSV back into exchange using the integrated Directory Import utility the hidden accounts will become visible. Once visible NTDSNoMatch may be run against the previously hidden accounts. You need to stop the Exchange services on your site’s bridgehead server before making these accounts visible. This will prevent them from being replicated as visible objects to all Outlook users in the organization. Once the cleanup work is completed, re-hide all previously hidden accounts that will be kept as hidden objects and allow this change to replicate through your Exchange site before reactivating the site bridgehead server. This will prevent the accounts from becoming visible in the GAL even for a short period of time.

NTDSNoMatch and Custom Attribute 10

In Exchange 2000/2003, each mailbox is associated with a single Active Directory user account. In Exchange Server 5.5, multiple mailboxes can be associated with a user account, and multiple user accounts can share a common mailbox. This structural difference can make it difficult for the ADC to match Exchange mailboxes to Active Directory user accounts. In Exchange 5.5, if multiple mailboxes are associated with a user account, the primary mailbox is the only correct match to an Active Directory user account. However, the ADC processes Exchange 5.5 mailboxes alphabetically and might associate one of the resource mailboxes with the Active Directory user account. If you identify each resource mailbox by setting ‘Custom Attribute 10’ (which is located in the DS Site Configuration

4

Custom Attributes properties) to NTDSNoMatch, Active Directory Connector does not match the mailbox to a user account; instead it represents the mailbox as a new disabled user account in Active Directory. It is very time consuming in a large organization to manually identify resource mailboxes and manually set Custom Attribute 10. Microsoft has a tool that can automate this process called NTDSNoMatch on your Exchange 2000 server. NTDSNoMatch identifies user accounts that have multiple mailboxes and determines whether a mailbox is the primary mailbox or a resource mailbox. For each Exchange Server site, it creates a comma-separated value (.CSV) file that contains a list of the resource mailboxes that NTDSNoMatch identifies. You can import the .csv file directly into the Exchange 5.5 directory to set Custom Attribute 10 to NTDSNoMatch for each resource mailbox in the list. You should review the content of the .CSV file to ensure that the primary mailboxes were correctly identified by NTDSNoMatch and that only the resource mailboxes are captured. Some organizations may have already used Custom Attribute 10 in Exchange 5.5 to hide entries from X.500 directories or whatever else. This will require the generation of another .CSV file to move the contents of Custom Attribute 10 to another Custom Attribute location for the objects affected. You should also ensure that your Exchange 2000 servers at a minimum have SP2, but preferably SP3 and the post-SP3 roll-up patches to correct any issues with NTDSNoMatch not being able to use the SID history properly. NTDSNoMatch has no service pack requirements on Exchange 2003. For best results all exchange servers should be running the same service pack level otherwise strange anomalies may occur.

Running Consistency Adjuster

Run a DS / IS consistency adjustment from one server within each site in the Exchange organization. Before running a DS / IS consistency adjustment it is critical that you identify all Exchange Servers that are replicating data, such as the contents of public folders, and ensure that all of those servers are online and able to connect during the consistency process. You do not need to include all the servers involved in globally replicated directory objects for this process.

The Consistency Adjuster configured with the options identified below will validate the health of the security descriptors on exchange objects. If configured differently it could pose a serious risk to the structure of your exchange directory and the corresponding data. Microsoft recommends the following options as they marginalize any risk to your environment.

To run a DS / IS Consistency check, open the Exchange 5.5 Administrator program. Next, select an Exchange 5.5 Server that contains a populated public information store. Now, select the Properties command from the File menu. When the server’s properties sheet appears, select the “Advanced” tab. Click on the Consistency Adjuster button.

Once clicked you’ll see the DS / IS Consistency Adjustment dialog box. The default box appears as follows :

5

Once it has popped up, clear every check box in the DS / IS Consistency Adjustment Dialog box.

After the boxes have been cleared, select the “Remove unknown user accounts from mailbox permissions” and also the option to “Remove unknown user accounts from public folder permissions”. Finally, click the “All Inconsistencies” radio button and click “OK”. When you’re done, remember that you must repeat this procedure on one server in each Exchange site in the organization and that the server that you use must contain public folders. Your dialog box should be configured as follows before clicking ‘OK’

6

The options selected above perform an NT security descriptor verification and cleanup with regards to both mailboxes and public folders.

The “Remove unknown user accounts from public folder permissions” may be deselected and run at a later date if the migration of public folders from Exchange 5.5 to Exchange 2000/2003 is going to be done separately from the user/mailbox migrations. There is no reason that it cannot be included in this process, but keep in mind that this check will need to be re-run right before the public folder migration is going to actually happen.

Click “OK” in response to the following prompt:

The Consistency check may take upwards of an hour to complete depending on your configuration and amount of data. Click “OK” once consistency has been verified: The final dialog will tell you that the adjustments made have been stored in the Application Event Log. Export the NT application log from the server using the Event Log Viewer on the server where the adjuster was run and save the file for reference. Running Consistency Adjuster with the selections specified above is completely non-destructive to Exchange and the NT Domain. It will remove dead NT account associations from objects within the site only. All of these objects can be reclaimed using the standard exchange administrator interface so long as a service account or administrative account exists. Consistency Adjuster is more critical to Public Folder migration. When unknown account ACL entries are migrated into Active Directory the distinguished name becomes the new ACL. The public folder cannot be accessed in this state as Active Directory cannot assess the validity of the credentials and the user is treated as not having security clearance to access the resource. Thus it is very important to delete obsolete entries. More information on the DS/IS Consistency Adjuster and it’s functions have been provided by Microsoft here: http://support.microsoft.com/default.aspx?scid=kb;en-us;q182979

Custom Recipients with foreign SMTP namespaces

The ADC will list this type of object as a contact available to all Exchange 2000/2003 users once migrated. To minimize the migration of undesired objects into Active Directory, remove all recipient objects used for blocking and administrative purposes and prune those objects that will be migrated. Most of these likely exist for administrative purposes

7

and can be noted and deleted. The rest are probably used by distribution lists or for ease of user access and should be removed, possibly to be added into the Exchange 2000 environment later, if still required. You should Inform the users directly of these changes before migration. Zombie Users

A zombie user is an exchange mailbox with no NT domain account or a non-existent domain account assigned to access it. Consistency Adjuster should be run before migration to prevent mailboxes or folders being replicated into Active Directory with a non-existent domain account. Once consistency adjuster has been run, these objects will be treated as per the process listed in ‘Mailboxes with NT SID Issues’ described below.

Mailboxes with NT SID Issues

Once all of the above issues have been addressed in the manner deemed appropriate you are ready to run NTDSNoMatch. The ADC processes the Exchange 5.5 mailboxes alphabetically, from A to Z. By default, the ADC will generate a new inactive directory account for the mailbox being migrated if it determines the mailbox to be the non-primary email account for the NT SID. These accounts must be identified using the Microsoft NTDSNoMatch tool or a site export to CSV and sorting on the NT account parameter before migration. All mail accounts sharing NT domain accounts should be identified before migration and dealt with either by granted them their own NT accounts or have them removed from service. The ADC will generate a new inactive directory account for the migrated exchange 5.5 mailbox if no NT domain account is linked to the mailbox. Use NTDSNoMatch to generate a list of mailboxes in your site that meet these criteria and fix them before migration. Many of these will likely be unused accounts awaiting deletion and a policy decision needs to be made before migration on how to deal with these mailboxes. NTDSNoMatch utilises certain parameters to determine an Active Directory account’s mail status. Using NTDSNoMatch, if the alias of the mailbox matches the Security Accounts Manager (SAM) account name, then NTDSNoMatch considers the mailbox to be the primary mailbox, and NTDSNoMatch is not entered into the CSV with a corresponding entry. If the alias does not match the SAM account name, or no SAM account name is present then NTDSNoMatch exports the mailbox’s information to CSV. This CSV should be inspected and each entry must be researched to determine which of the following resolutions will be used:

n Will the mailbox be exported from exchange 5.5 into .PST file and deleted from the mail store

n Will the mailbox be kept and allowed to migrate into a new inactive directory security identifier (which is mailbox enabled)

n Will the mailbox be set to use the NTDSNoMatch function of the ADC using the generated CSV.

If the latter option is chosen, each mailbox’s Custom Attribute 10 will be set to “NTDSNoMatch” using an import of the generated CSV. NTDSNoMatch needs to use custom attribute 10. Once NTDSNoMatch has generated the CSV and it has been pruned this CSV may be imported thus setting custom attribute 10 on each relevant mailbox to ‘NTDSNoMatch’. This facilitates the ADC creating new Active Directory accounts that are login disabled and mailbox enabled for these selected

8

mailboxes. To apply this functionality to the hidden mailboxes remove the check mark classifying the object as hidden in exchange administrator before scanning the server in question with the NTDSNoMatch utility. For more information about installing and using the NTDSNoMatch utility please refer to the following Microsoft article for documentation on the tool: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q274173&sd=tech. NB: The NTDSNoMatch utility must be run on a Windows 2000 or Windows 2003 Server.

Deleting Inactive Data

Although dealing with inactive accounts and unused folder data can be political/policy issue for administrators, Microsoft recommends strong measures be taken. Microsoft recommends cleaning up all unused and retired objects where possible, so as not to replicate any legacy issues and data into the Active Directory environment. In general, it simplifies and potentially cuts down on the number of objects that may require replication between Active Directory and the Exchange 5.5 directory. The nature of Active Directory must be considered. All account information is replicated to some extent. The larger the number of objects present the larger the consumption of resources required by Active Directory. Organizations are urged to use this opportunity to deal with inactive data in an efficient and clear manner. This will improve the efficiency of their entire Active Directory implementation.

System Folders

Before proceeding with a migration all ‘System Folders’ associated with the servers belonging to the sites should verify where any replicas of their system folders are being replicated to. The first server in each site generates these folders along with their associated GUID. Microsoft indicates that any corrupt, duplicate or missing system file issues must be dealt with before migration. Unless a strong argument exists for replicating exchange server system folders to multiple locations, all system folders should be verified as only being housed in their native sites context. Microsoft indicates that orphaned objects are a problem and could negatively impact the functionality of the ADC. The following types of folder replication locations should be investigated and possibly redirected within their native site:

1) Offline Address Book; Holds the sites Offline Address Book

2) EventConfig; Installed on a exchange 5.5 server running the event service

3) SCHEDULE+FREE/BUSY; Installed in a sites first exchange 5.5 server with GUID.

If any of these folders are located on a remote site and cannot be brought back home contact the administrators of the other site to release the replica. Although these are core exchange system folders, a surprising number get incorrectly homed to other sites within the org, and many of these come from retired servers. Verify that all folders in these system folder directories that have names indicating they were once from your respective sites were generated by existing servers and are correctly homed. If these folders are from retired servers, then these folders will likely only respond to the process titled “Unmanageable Orphans” below. If other sites’ system folders are

9

located in your site or system folders from retired servers are still present you must follow the procedures outlined in Orphaned Objects below. NB: In order to determine which object is the invalid object under system folders you need to go into RAW mode and examine the properties of each object. Remember the unique properties related to each type of System Folder.

System Folder Type Issue Eforms Not relevant to migration unless forms need to be

retrieved Events_Root 1 per production server running the event service

Offline Address Book Exists at site level, should be on at least 1 server within associated site

Schedule+Free Busy Exists at site level, should be on at least 1 server with associated site GUID.

These types of objects should only be located under the appropriate heading in System Folders. If they are not listed there, but are present else where, then they must be removed from the environment before migration. These types of objects would likely be classified as ‘Unmanageable Orphans’ – they would not respond to RAW inspection or deletion. An example of the response received from an object that will no respond to inspection with RAW mode follows:

These objects are either orphans or corrupted objects. Event_Config folders that do not respond to inspection through the administrator utility in RAW mode will likely be the legacy folders requiring deletion. As a rule, if two objects with the same name and class exist and only 1 responds to being inspected regarding its RAW properties the other unresponsive object will be the invalid object requiring deletion. RAW deletion should be attempted followed by attempting an export. If the folders cannot be deleted through RAW mode, investigate using the “events” utility that is integrated into exchange 5.5 for duplicate Event_Config folders. The following Microsoft article details the use of this tool: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q187/5/23.ASP&NoWebContent=1 For the Offline Address Book, one copy should exist in each site for which it is native to, unless special circumstances exist, it should not be exported outside the native site. The Schedule+Free Busy folders contain each sites calendaring information. They must have a GUID in their GUID field under RAW properties. This should match that of the GUID for the first server in the site. Do not delete these folders unless they are orphaned. They need to be returned to their home site, this site should be the only site housing a copy of these core system folders. If no GUID is present, Microsoft suggests running GUIDGEN to generate a new GUID before migration.

10

NB: Running GUIDGEN does have some negative impact on the calendar functionality within the environment for Exchange 5.5, but will not carry over to Exchange 2000/2003.

Public Folders

Inspect public folders for folders replicated to other sites. Use the tool PFINFO for this task. PFINFO is a Microsoft resource kit tool that provides an easy way to list replicas of public folders on a macro scale. To use PFINFO.exe you must have a MAPI profile pointing at an exchange server within the site that contains the public folders. This MAPI profile must have service account permissions for optimal results. Clicking on PFINFO.exe, which runs on Windows 2000/2003 or Windows NT presents this interface:

Select comma separated. Click the Options button and select options so that your dialog looks like the following:

11

Return to the initial PFINFO screen by clicking OK and then click the Start button. Once the job is complete, the tool will generate a dump of all of the public folders in the hierarchy and their respective replicas. Now you can inspect the information using the following steps: 1) Using the text file generated, manually search for foreign server’s names in your

public folder tree using NotePad or other text editor

2) Once your are satisfied that you have verified your tree, save the file as Entire_Public_Folder_Dump.txt

3) Open Entire_Public_Folder_Dump.txt and save it as Other_Site_Public_Folfers.txt and then remove your public folder trees’ data from it

4) Now search Other_Site_Public_Folfers.txt using NotePad or other text editor for your namespace, also investigate any namespaces formerly used by your org

5) If you locate your site’s namespace, elsewhere try returning it to its native store

If security information is required from the public folders utilize the PFADMIN tool provided by Microsoft. This standard exchange resource kit tool uses a MAPI profile to access and possibly reset security access control lists on public folders and homing of replicas. Microsoft has made the readme file for PFADMIN.exe available here: http://support.microsoft.com/default.aspx?scid=kb;EN-US;261093 More detail on Extracting Public Folder Permissions Using PFADMIN available here: http://support.microsoft.com/default.aspx?scid=kb;EN-US;199319

12

Orphaned Objects

Microsoft indicates that ‘Orphaned Objects’ can have a serious but hard to predict impact on your migration. Consistency Adjuster must be run before migration to prevent orphaned objects from being migrated into Active Directory. Consistency Adjuster essentially takes objects in the directory that are in the local site and makes sure they can be administered using local security accounts if applicable. If successfully reclaimed by Consistency Adjuster, deletion or RAW deletion should remove any unwanted objects. If there are public folders from which data must be recovered, then the exchange administration utility will enable resetting the associated accounts using the ‘apply security rights to all subfolders’ option. This will however mimic the rights of the folder from which it was pushed down directly. If an object is not successfully claimed for local administration by Consistency Adjuster, then these folders will either have to be RAW deleted if it responds to RAW mode or moved to another server located in the org that is designated for these exceptions. The latter is the last option for removing these objects from your site before migration – these undeletable objects get classified as “Unmanageable Orphans” for the purposes of this process. Microsoft offers further information on Orphaned Objects in Exchange 5.5 here: http://support.microsoft.com/default.aspx?scid=kb;en-us;179573

Unmanageable Orphans

These objects are those that are found to have one or many of the following conditions:

n Are housed in sites’ whose namespace they share but are not native to

n Cannot be removed using consistency adjuster

n Cannot be deleted using RAW mode

These “artifacts” of the hierarchy should be listed by each site administrator and modified so as to push them to a central repository before the objects are aggregated onto a single Exchange server in the org and can then be dealt with by the head administrators. This will effectively remove the object from the context of the originating sites and once all participants “unmanageable orphans” have been aggregated on the server, it can be gracefully retired. Retiring this server will permanently remove these objects from the hierarchy.

13

Checklist for Exchange Clean-up & Normalization

Issues to be addressed Why ? Completed ? 1.Standardise Syntax Allow FORESTPREP & CA’s to be initiated

2.Global Address List Count Determine if replication issues exist

3.Provide CA Credentials Allow CA to be created for a site

4.Import the CSV for moving the Custome Attribute

Copy custom attribute 10 to another custom attribute for objects that require it.

5.Run consistency adjuster after hours as detailed above, keeping related application log files

Cleanup issues falling within standard exchange X.400 framework

6.Unhide all hidden mailboxes using a modified CSV

Allows NTDSNoMatch to be run against hidden mailboxes

7.Remove all custom recipients with a foreign namespace

Remove them from becoming global contacts in AD unless required as such

8.Run NTDSNoMatch against each production server holding users

Generate a CSV listing all mailboxes with issues related to their NT domain accounts

9.Prune the CSV generated by NTDSNoMatch

Only allow NTDSNoMatch to mark those accounts you wish to be active in Exchange 2000/2003/Active Directory. Be wary of the criteria that NTDSNoMatch uses.

10.Import the NTDSNoMatch generated CSV into the site in question

Import the NTDSNoMatch CSV through the exchange administrator interface.

11.Make decisions regarding those accounts not to be included in the list with NTDSNoMatch activated for the ADC

Export and delete those accounts that are not desired as being populated into Active Directory. Alternatively allow them to be exported as inactive.

12.Inspect system folders for duplicates, legacy folders, and incorrectly homed folders

Verify core functional folders are accessible and ready for use and that no erroneous objects are present.

13.Inspect public folders for incorrectly homed folders Using PFINFO

Verify where each sites’ public folders are being replicated to using PFINFO. Deal with issues as prescribed.

14.Deal with any “orphans” encountered

Eliminate artifacts

15.Deal with any “unmanageable orphans” encountered

Eliminate artifacts through central repository