9. Some things to think about:
• Training / Time to practice migrations
• Scheduled outages
• Company cultural differences
• Network Connectivity
• Network differences between the two sites
• Network/Active Directory/Exchange
“anomalies”
• Customer communication
• Employee communication
• Licensing
31. Disable SID Filtering
netdom trust old /domain:new
/quarantine:No /UserD:Administrator
/passwordD:P@ssword
• If SID filtering has been disabled properly, you will
receive a message similar to this one:
Setting the trust to not filter SIDs.
The command completed successfully.
41. Queue Method
(Companies with few users/small IS)
• Disable email forwarding and let the email
queue up on the gateway
• Copy the mailboxes from the old Exchange
server to the new Organization
• Enable email forwarding and let email flow to
the new email server
42. Prep Method
• Copy the mailboxes from the old Exchange server
to the new Organization. Use a date range and
only copy email from today. This step creates a
mailbox in the destination email server, and
configures the user account for email.
• Point the email gateway to the new server.
Internet email will now flow to the new server.
• Run a second email migration, and this time, do
not specify a date range. This will bring the
remaining email messages over to the new server
You cannot overstate the need for detailed planning on a project as complicated as a company merger. A famous Special Forces Navy Seal, Richard Marcinko has a saying that he calls The Five P’s, “Proper Planning Prevents Piss Poor Performance”. This is just as true in a company merger as it is when you are attacking the enemy. If you shortcut the planning process, you will pay for it eventually.
The first step is to create a two-way trust between the domains. You may have already done that earlier, but if not, you need to do it now as it is a requirement for domain migration. In order to create the trusts, both domains must be able to resolve Fully Qualified Domain Names (FQDN’s) in the other domain. Use the “Forwarders” TAB in the DNS Server Properties to do this. Have each DNS Domain point to the other. Figure 3 shows the configuration to setup DNS so that machines in the New.local domain can resolve machines in the Old.local domain. When complete, you should be able to ping “server1.old.local from any machine in the New.local domain. In order to ping a host name in the other domain without using the Fully Qualified Domain Name (FQDN), add both domains (new.loca & old.local) in the Advanced TCP/IP settings on each machine. This can be a tedious task, so do yourself a favor and use a Group Policy to do this.
Use AD Domains and Trusts to create two-way trusts between the Domains. This can be accomplished by visiting one DC on one of the Domains (it doesn’t matter which). Log onto a Domain Controller on one of the domains and open Active Directory Domains and Trusts.Right click on the domain and choose Properties.Click the Trusts TAB and choose “New Trust”. Click Next.Enter in the FQDN of the other Domain. (this is why you need to have the DNS Forwarders setup properly above)Choose “Two-way” trust (the default)Choose “Both this domain and the specified domain” on the Sides of Trust page. This will save you from having to connect remotely to the other domain’s DC and run through this wizard again.Enter in the other Domain’s Administrator & password. NextReview your settings and click Next.Click “Yes, confirm the outgoing trust”. This is just a good check to ensure that everything is working correctly.Click “Yes, confirm the incoming trust”. Click OK to confirm the message about SID filtering. We will disable SID filtering in a later step.
In order to make the transition to a new domain easier for the users, you can migrate their password for them. Otherwise, ADMT can create a complex password for you. But, you will then have to distribute that password securely to the user. In my experience, migrating the password from the old domain to the new domain is easier for everyone involved. If you are concerned about passwords being transmitted across the network, take some comfort in the fact that the passwords are encrypted on the wire, and by default, the user is required to change his password on first logon. Log on as a domain administrator or equivalent to the computer on which ADMT is installed. At a command prompt, use the ADMT command to create the .pes fileExample: C:\\WINDOWS\\ADMT>admt key /opt:create /sd:old /kf:c:\\Copy the .pes file you just created to a Domain Controller in the source domain (old.local). Install the Password Migration DLL on the Password Export Server by running pwdmig.msi. PES can be downloaded here: http://www.microsoft.com/downloads/details.aspx?familyid=F0D03C3C-4757-40FD-8306-68079BA9C773&displaylang=en The PES installation is quick and will prompt you for the .pes file that you created earlier.Specify that the Password Export Server Service runs as a user with Domain Administrator privileges. You must use the “domain\\account” format. Installing the PES Service requires a reboot of the domain controller, so be sure to plan for this downtime. The PES Service is set to “Manual” by default, so it will not start when the server is rebooted. In addition, you need to change the following DWORD registry key to “1”. For security reasons, Microsoft recommends that you keep the PES Service off, and the Registry key set to a value of “0” until you are ready to migrate passwords. If you have additional questions, see Knowledge Base Article: http://support.microsoft.com/kb/326480 for more details.
To allow the user’s SID from the Old.local domain to migrate to the SID History of the New.local domain (see fig 2 for an example), we need to disable a security feature called “SID Filtering” on the source domain. From a domain controller on the old.local domain, type the following command: netdom trust old /domain:new /quarantine:No /UserD:Administrator /passwordD:P@ssword[this command should be on one line in the article if possible ebr] If SID filtering has been disabled properly, you will receive a message similar to this one: Setting the trust to not filter SIDs.The command completed successfully. Note: NetDom is not installed on a Windows 2000/2003 server by default, but can be found on the Server CD under Support, Tools.
I have found it easier to perform the migration from a dedicated server. It does not need to have a lot of power; a simple Virtual Machine running Windows Server Standard is sufficient (ADMT will not run on XP). Be sure to make the migration server a member of the new, “target” domain. Even thought you have a “trust” between the two domains, always log into the new domain when migrating objects from the old directory to the new one.
There is also a small, but very important step that must be completed on the old domain to allow you to migrate objects to the new domain: Add a target Domain Admin user account to the built-in Administrators group in the source domain as figure 4 shows:
The last step in preparing the environment for migration is to ensure that computers themselves are ready for migration. Newer versions of Windows have a firewall that will block connection attempts by the Active Directory Migration Wizard (ADMT). The ports that are used by ADMT are not well documented, and if you use my method below, you can just briefly disable the XP firewall just long enough to perform the migration. To do this, link a Group Policy that will “open up” the firewall to an Organizational Unit called “MigrationPrep” and move the computer to this Organizational Unit (OU) right before you are ready to migrate.
Second, the user that will be performing the migration needs to have Administrator privileges on each computer that will be migrated. Again, this can be done with a Group Policy that is linked to the MigrationPrep OU. I describe how to do this in this article: Adding a Global Group to the Local Administrators Group [InstantDoc #100759] [Pls link to: http://windowsitpro.com/article/articleid/100759/adding-a-global-group-to-the-local-administrators-group.htmlebr]
Last, the domain itself (new.local) must be in Native mode before you can migrate any objects to it. This process is irreversible, so be sure you understand the consequences before raising the domain functional level. There are a few ways to raise the domain level to Native. One way is to open up Active Directory Users and Computers, right click on the domain (new.local) and choose “Raise Domain Functional Level”. Choose “Windows Server 2003” on the next screen, then click OK. That’s it!
Unlike the user’s computers and the backoffice servers, you will not want to migrate the Exchange server(s) to the new domain. This is because modern versions of Exchange are deeply integrated with Active Directory. If you migrated the Exchange server to the new.local domain, there would be no way for you to “connect” the mailboxes in the mail store to the user objects in Active Directory. Instead of migrating the Exchange server, you will want to copy the individual mailboxes from the old Exchange Organization to a brand new Exchange Organization in the new.local domain. Newer versions of Exchange have a built-in Migration Wizard that does a great job of copying multiple mailboxes from one Exchange Organization to another – even if it is in another AD Forest. Here’s the simple procedure for copying from an Exchange 2003 Organization to another Exchange 2003 Organization: Log onto an Exchange server in the New.local domain Click Start > Microsoft Exchange > Deployment > Migration WizardChoose “Migrate from Microsoft Exchange”Choose the destination server and Information StoreDeselect “Exchange 5.5 server”, and enter in the information for the source Exchange serverNote that you must enter in the Administrator account as “Domain\\User”Specify a date range (if applicable)Choose one or more mailboxes that you want to migrate. You can select all, or some individually using the Ctrl key The mailboxes will then start to copy from the old domain to the new one. Depending on the size of each user’s mailbox, this can take anywhere from a few minutes to a couple of hours. I’ve also noticed a big difference in a defragged Information Store, versus a fragmented one. For example, if you take an empty mailbox and send 3000 emails to it, it will migrate in just a few minutes. However, a “seasoned” mailbox that has 3000 emails that it has received over the past year will take significantly longer as the emails are not contiguous (written one after the other). Other factors such as system and network performance can also greatly affect the speed of the mailbox copy, so be sure to run a few tests with a mailbox or two so you’ll have an idea of how long it will take.
Slight of hand…A fast way to show the rest of the world that you are now one company is to make sure everyone has the same email suffix (eg: new.com). Microsoft has a detailed article (pls link to: http://support.microsoft.com/kb/321721) that explains in detail how to setup the Recipient Policy, a new SMTP virtual server in your Exchange Organization, and Contacts so that it appears to your customers and internal users that you have one email system. In reality, email flows as shown in Figure 1. Email for “New.com” still flows to the existing email server at New.com’s headquarters. If an email comes in for an employee of Old.com to their New.com address, the exchange server forwards it to (via the Internet) to the Old.com email server. When an employee of Old.com sends out an email, the primary address (aka: reply-to address) is New.com. You will eventually want to move all email into one Exchange Organization, but this sleight of hand will help buy you some time to finish your detailed migration plan.
(Companies with few users/small Information Stores)
(Companies with large Information Stores or mail gateways that can’t hold that much email in queue)
As was discussed earlier, you can use the InterOrg Replication Tool to migrate the Public Folders from one Exchange Organization to another. Another option is to simply export each one to a PST, and then import them into the new Organization. Whichever method you choose, be sure to allow enough time for the migration as these can take a long time to migrate. Identify which ones you want to migrate early in the migration project, and do not put it off until the last minute.
While the email in the mailboxes will copy over with little difficulty, the configuration of the SMTP addresses can be a bit more problematic. For example, if you have user called ITCalendar, and a Public Folder called ITCalendar, one probably had an SMTP address of ITCalendar.old.com and the other was ITCalendar2.old.com. When you migrate these objects over, whichever one if first gets migrated first gets the address without the number “2”. If you migrate the Public Folder first, and the user second, the user will have the “wrong” SMTP address. When you try to correct the address, Exchange will inform you that it is already in use. This will no doubt drive you nuts as you try to find WHERE these addresses are used. To find the “rogue” address and who is using it, use Active Directory Users and Computers and perform a Custom Search:
When you move Exchange mailboxes within an Exchange Organization, then Outlook and Exchange communicate in the background and the user’s Outlook Profile is updated automatically. However, when mailboxes are moved out of an Organization to another one….then Outlook has no way of knowing where you moved the mailbox to. This is where Exprofre.exe comes in. This free, handy utility will help you fix your user’s Outlook Profile via a Logon Script. To use Exprofre, create a Group Policy with a LogOn Script. Copy the Exprofre.exe file to the GPO, and create a simple CMD script with the following command:
I said it before at the beginning of this article, but I’ll mention it again: A project of this size takes a lot of planning and practice in a lab environment. Document every hiccup that you come across, and write clear How To documents that anyone in your IT department could follow. Many of the step-by-step guides in this article are from my own documentation, so I know that they work. Set up a lab for yourself and write down everything that you learn. Before a SCUBA diver jumps into the water, he maps out a detailed plan for the dive. This keeps him safe, and alive for another day. Just like a SCUBA diver, you need to Plan Your Dive, and Dive Your Plan: That’s the key to success.
Slight of hand…A fast way to show the rest of the world that you are now one company is to make sure everyone has the same email suffix (eg: new.com). Microsoft has a detailed article (pls link to: http://support.microsoft.com/kb/321721) that explains in detail how to setup the Recipient Policy, a new SMTP virtual server in your Exchange Organization, and Contacts so that it appears to your customers and internal users that you have one email system. In reality, email flows as shown in Figure 1. Email for “New.com” still flows to the existing email server at New.com’s headquarters. If an email comes in for an employee of Old.com to their New.com address, the exchange server forwards it to (via the Internet) to the Old.com email server. When an employee of Old.com sends out an email, the primary address (aka: reply-to address) is New.com. You will eventually want to move all email into one Exchange Organization, but this sleight of hand will help buy you some time to finish your detailed migration plan.
A company merger takes a lot of communication from everyone on both sides, and this means meetings. The easiest way to setup meetings is to use Outlook’s Calendaring function to ensure that the other party is available during the desired meeting time. Unfortunately, when a Vice President tries to schedule a meeting with someone from the other company he will be met with grey hash marks in Outlook instead of the distant user’s schedule. This is because separate Exchange Organizations do not share Calendaring (called Free/Busy) by default.
Another “Easy Win” is to share your Free/Busy information between Exchange Organizations so that it appears to your users that they are on the same email system. Microsoft provides a free tool called the InterOrg Replication Tool [Pls link to: https://www.microsoft.com/downloads/details.aspx?familyid=e7a951d7-1559-4f8f-b400-488b0c52430e&displaylang=en] that can replicate Public Folders, and the Free/Busy information. This tool can be difficult to setup if you don’t follow the included directions exactly. In addition, it does not appear to understand host names (resolved via DNS or a hosts file). It only understands NETBios names (resolved via WINS or an LMHosts file). This tool is also not cluster aware and gets confused when installed on a cluster node. If you are running an Exchange cluster, you will need to use or setup a standalone Exchange server that you can use for replication. Also, when you set the username and password settings, be sure to preface the username with the domain name like this: DOMAIN\\USERNAME Free/Busy information that is replicated between Exchange Organizations can be up to 30 minutes old [need to verify this ebr], so be sure to communicate this to your users.If you are just going to replicate the Public Folders, then you only need to setup one server as it can be both a Publisher and a Subscriber. However, if you want to replicate the Free/Busy information, you will need to setup the service on both ends (on the New.com side, and the Old.com side). The application comes in two parts: Configuration File setup tool, and the Replication Service itself. Use the following KB article to walk you through the process: http://support.microsoft.com/kb/238573
Beyond email, the business leaders will also want to start sharing data files such as documents, spreadsheets, presentations, etc., and they will need to do it securely. This will be simple once the domains are merged into one, but to satisfy the immediate need, you need a solution now, and you need it fast. In order to grant a user from one domain permission to use a resource on another domain, you need to setup a Forest Trust. If you are not familiar with this concept, then it will take a little getting used to. It will also be complicated for your users, so be ready to hold their hand as they attempt to grant users from Old.com to New.com’s data, and vice-versa.We’ve all seen the triangle and circle visio pictures from Microsoft showing Domain and Forest trusts. Let me just show you what the end result is:
There may be other “easy wins” that you can quickly deploy. Take time to listen to the needs of the business and try to come up with temporary solutions that will buy you time to properly plan the rest of the migration. These will help the rest of the company with their transition duties, and will give you additional time to properly plan The Big One. Next month we’ll continue with the actual mechanics of migrating users, computers and email from one domain to another using Microsoft’s Active Directory Migration Tool (ADMT).
As soon as you have taken care of the immediate needs of the company, it is time to document a detailed plan for the Domain and Exchange migration. If you only have a few users, computers and servers, then you may be able to get away with simply adding those objects to your domain using scripts and other home-grown methods. But if you have a larger Domain that will take more than a few hours to migrate, then it will be worth your time to investigate the tools that are available to help you. Vendors such as Quest and NetIQ have products that can help you assess and even model your migration. Depending on the size of the domains that you want to migrate, these may provide a good Return On Investment (ROI). In addition to these products, Microsoft provides a free migration tool called, “Active Directory Migration Tool (ADMT). The rest of this article will be centered around ADMT and how it works, but the concepts will be similar for any product that you choose.
What happens if you delete a user account, and then recreate it with the same name? Will the user have the same access that they had before?If you can’t migrate everything in a few hours, then the users and system processes will have to continue working in both domains while you perform the migration. If you used a script to export the users from the old.com domain and then import them to the new.com domain, (employing the LDIFDE utility from Microsoft, for example) the users would not be able to use the resources in their old (old.local) domain. Even though their logon names would be the same, the SID of the user object would be totally different and would not match anything in the new domain. When a migrated user from the new.com domain tried to access a file share, for example, the fileserver would deny access because that particular user was never granted access to the folder [need to rewrite that] Figure 2 shows a user in the New.local domain that was migrated from the Old.local domain. This user has two SIDS; the newly generated one for the New.local domain, and the one from the Old domain, now an attribute in SID History. When the user accesses a resource on the old.com domain, the fileserver will be able to match the SID from the old.com domain, and the user will be granted access. Later in this article, I’ll show you how to disable SID Filtering between the domains so that it can be migrated to the new domain.
