Post by Paul C on Jul 21, 2012 20:10:49 GMT 5.5
Impacts of Domain Rename on Exchange Server 2010
Nowadays of a lot of mergers and acquisitions companies who are running their own Exchange Server organization within their own Active Directory forest are planning to rename their Active Directory Domain to reflect the new name of a company or company group they belong to.
Exchange Server Database Technology and Active Directory Domain Name
Exchange Server Database Technology relies on Active Directory Services because it is its central directory. This means nearly each object in Exchange Server has a relationship to the domain name where Exchange has been installed in. Due to this complex design structure it is at present not supported to rename an Active Directory (using RENDOM.EXE) when Exchange Server 2007 or higher has been deployed. With Exchange Server 2003 this has been supported using a specific tool. This tool “XDR-Fixup” does not exist anymore. And if you try – even though it is unsupported – and rename your Forest, you will recognize that your Exchange Server environment is dead and cannot be enabled again.
Ways / Concepts to solve the “Naming Problem”
1. Do not rename your Active Directory
On first thought this idea seems to be a little bit crazy, but the concept is quite simple: The idea is that you really don’t need to rename your Active Directory to make your users think they work in another company or to fulfill the corporate identity (CI) of a company.
The domain name is generally internal and it is quite simple to allow users to logon using a domain name that is quite different: the solution is “UPN-Suffixes”. Theses suffixes can be defined in the properties of the top-level of “Active Directory Domains and Services” Snap In. There you can define as many UPN-Suffixes as you want.
Afterwards you will need to:
Create the new companies DNS-Namespace and make sure that each entry that needs to reflect the specific DNS-Namespace exists and is up-to-date.
Configure the logon DNS-Name for each user using PowerShell or “Active Directory Users and Computers” Snap In.
Configure a User Policy in Exchange that configures the email address of each mailbox user in its corresponding SMTP-Namespace.
Make sure that you configure the correct MX-Settings in the public DNS Namespace.
If needed configure a dedicated IIS Logon screen for Outlook Web Access (OWA)
This would lead all users (internal and external ones) to think that they are working in a specific Domain Name Space although the real one is just hidden and only available for administrators.
Pros and Cons:
“Old” domain name is still alive for administrative staff
Some more overhead for DNS reconfigurations in the future due to one more DNS namespace that needs to be administered
Project itself is quite easy to handle
User interruption is nearly 100%
The configuration of a hidden Active Directory Forest/Domain Name is alive in a lot of companies as soon as they are running the concept to use another Domain Name internally than externally
2. Active Directory Forest Cross Forest Migration
Another solution for this challenge could be to prepare and run an Active Directory Cross Forest Migration. This means that you will install, prepare and configure a new Active Directory Domain next to the existing one and migrate each mailbox account to this new domain.
The steps in detail would then be as follows:
Install new Exchange Servers in your new Active Directory Forest
Configure your complete Exchange Server Organization that it will completely meet your existing configuration except for the domain names. Some good PowerShell scripts might help to easily transfer the configuration to your new environment
Migrate each user account and the corresponding mailbox to the new environment
Decommission your “old Active Directory and Exchange servers” as soon as no resources have been left within.
This quite complex migration concept will “live” and only work properly if the project plan and project management is very detailed and the migration will be realized step-by-step with double checks to make sure that no step will be done before the step before has finished. Otherwise the project would lead to a complete mess and misconfiguration with a lot of user interruption.
3. Manually Move Mailboxes between Exchange Servers
A third concept and possible solution is to export all mailboxes before your Active Directory Rename process and afterwards reimport them to your new configured Exchange environment.
This concept would mean in detail:
Export all Mailboxes at one time using Exchange PowerShell CMDLETS
Decommission your Exchange Servers (by uninstalling them)
Rename your Active Directory Forest using RENDOM.EXE Tools
Reinstall your Exchange Server environment as it was existing before
Reimport all Mailboxes at one time using Exchange PowerShell CMDLETS
As you might have recognized this concept would mean:
A lot of downtime between the decommissioning and reestablishment phases of Exchange
Mailbox rules of users might not be transferred correctly
Each “Exchange cached profile” User needs a full resynchronization of its mailbox
If you choose this concept some good PowerShell Scripts for exporting and reimporting the Exchange Server configuration will help to solve your problem.
Which method to choose out of the three above
How to choose the right Concept?
As you have already seen above there are some good ways to fulfill the plan to rename your Active Directory even though you are not able to use the renaming tools. The one thing you need to remember is: a complete decommission of your “old” Active Directory Names might lead to a quite complex project which might lead to user interruptions that in general is not the best plan. You need to choose between complexity and user interruptions when you are choosing your best migration method.
Note: rename of your Active Directory Forest/Domain when having Exchange deployed is not as easy as it has been in the past. But if you think of the best way to solve this issue there are some good concepts to fulfill your challenge of a “rename procedure” of your domain after an acquisition or a merger
Nowadays of a lot of mergers and acquisitions companies who are running their own Exchange Server organization within their own Active Directory forest are planning to rename their Active Directory Domain to reflect the new name of a company or company group they belong to.
Exchange Server Database Technology and Active Directory Domain Name
Exchange Server Database Technology relies on Active Directory Services because it is its central directory. This means nearly each object in Exchange Server has a relationship to the domain name where Exchange has been installed in. Due to this complex design structure it is at present not supported to rename an Active Directory (using RENDOM.EXE) when Exchange Server 2007 or higher has been deployed. With Exchange Server 2003 this has been supported using a specific tool. This tool “XDR-Fixup” does not exist anymore. And if you try – even though it is unsupported – and rename your Forest, you will recognize that your Exchange Server environment is dead and cannot be enabled again.
Ways / Concepts to solve the “Naming Problem”
- 1.Do not rename your Active Directory
- 2.Active Directory Forest Cross Forest Migration
- 3.Manually Move Mailboxes between Exchange Servers
1. Do not rename your Active Directory
On first thought this idea seems to be a little bit crazy, but the concept is quite simple: The idea is that you really don’t need to rename your Active Directory to make your users think they work in another company or to fulfill the corporate identity (CI) of a company.
The domain name is generally internal and it is quite simple to allow users to logon using a domain name that is quite different: the solution is “UPN-Suffixes”. Theses suffixes can be defined in the properties of the top-level of “Active Directory Domains and Services” Snap In. There you can define as many UPN-Suffixes as you want.
Afterwards you will need to:
Create the new companies DNS-Namespace and make sure that each entry that needs to reflect the specific DNS-Namespace exists and is up-to-date.
Configure the logon DNS-Name for each user using PowerShell or “Active Directory Users and Computers” Snap In.
Configure a User Policy in Exchange that configures the email address of each mailbox user in its corresponding SMTP-Namespace.
Make sure that you configure the correct MX-Settings in the public DNS Namespace.
If needed configure a dedicated IIS Logon screen for Outlook Web Access (OWA)
This would lead all users (internal and external ones) to think that they are working in a specific Domain Name Space although the real one is just hidden and only available for administrators.
Pros and Cons:
“Old” domain name is still alive for administrative staff
Some more overhead for DNS reconfigurations in the future due to one more DNS namespace that needs to be administered
Project itself is quite easy to handle
User interruption is nearly 100%
The configuration of a hidden Active Directory Forest/Domain Name is alive in a lot of companies as soon as they are running the concept to use another Domain Name internally than externally
2. Active Directory Forest Cross Forest Migration
Another solution for this challenge could be to prepare and run an Active Directory Cross Forest Migration. This means that you will install, prepare and configure a new Active Directory Domain next to the existing one and migrate each mailbox account to this new domain.
The steps in detail would then be as follows:
Install new Exchange Servers in your new Active Directory Forest
Configure your complete Exchange Server Organization that it will completely meet your existing configuration except for the domain names. Some good PowerShell scripts might help to easily transfer the configuration to your new environment
Migrate each user account and the corresponding mailbox to the new environment
Decommission your “old Active Directory and Exchange servers” as soon as no resources have been left within.
This quite complex migration concept will “live” and only work properly if the project plan and project management is very detailed and the migration will be realized step-by-step with double checks to make sure that no step will be done before the step before has finished. Otherwise the project would lead to a complete mess and misconfiguration with a lot of user interruption.
3. Manually Move Mailboxes between Exchange Servers
A third concept and possible solution is to export all mailboxes before your Active Directory Rename process and afterwards reimport them to your new configured Exchange environment.
This concept would mean in detail:
Export all Mailboxes at one time using Exchange PowerShell CMDLETS
Decommission your Exchange Servers (by uninstalling them)
Rename your Active Directory Forest using RENDOM.EXE Tools
Reinstall your Exchange Server environment as it was existing before
Reimport all Mailboxes at one time using Exchange PowerShell CMDLETS
As you might have recognized this concept would mean:
A lot of downtime between the decommissioning and reestablishment phases of Exchange
Mailbox rules of users might not be transferred correctly
Each “Exchange cached profile” User needs a full resynchronization of its mailbox
If you choose this concept some good PowerShell Scripts for exporting and reimporting the Exchange Server configuration will help to solve your problem.
Which method to choose out of the three above
How to choose the right Concept?
As you have already seen above there are some good ways to fulfill the plan to rename your Active Directory even though you are not able to use the renaming tools. The one thing you need to remember is: a complete decommission of your “old” Active Directory Names might lead to a quite complex project which might lead to user interruptions that in general is not the best plan. You need to choose between complexity and user interruptions when you are choosing your best migration method.
Note: rename of your Active Directory Forest/Domain when having Exchange deployed is not as easy as it has been in the past. But if you think of the best way to solve this issue there are some good concepts to fulfill your challenge of a “rename procedure” of your domain after an acquisition or a merger