Wednesday, January 08, 2014

How we separated our two office’s AD and Exchange

Our company sold off a branch office last year, and we have been working on the separation of our business and our IT infrastructure. We are a Windows environment. Each office used to be a redundancy of each other, which means that each office has a full Active Directory forest, which contains domains controllers for root domain and all of its sub domains. Users in each office are in its dedicated site sub domain, with its own Exchange servers(in mix environment of Exchange 2007 and Exchange 2003). From the very beginning we came to an agreement with passive cleanup by having an identical AD forest and Exchange organization on each site, and when the cutoff time comes, we turn off the VPN network completely and start to clean up AD and Exchange by removing the objects in the other sites. It needs to be done at Exchange level, Domain level, and User level. We will use these names to in our case. I know, Microsoft doesn't support these type of removal, but to us, it is cheaper, less time, and sounded more straight forward. During the separation, we did learn a lot in a hard way.

root of the domain:
Site North: NorthDC, NorthEX(Exchange server), external email domain is
Site South: SouthDC, SouthEX(Exchange server), external email domain is

We are in the south, so I will state the steps that I took from the point of SouthEX, SouthDC’s view. But in Site North, it needs to have the same things done to the SouthDC and SouthEX objects.

  1. Before the disconnection, make sure you have redundant domain controllers in your forest. For example, if you have a single root domain controller in your site, you might want to create a second one before the disconnection. Never have a single domain controller in your organization.

  1. After the disconnection, the first issue we found was that users in each sites won’t be able to email each other, and all the emails will get stuck in the unreachable queue. This should be expected, since and are still under the same Exchang organization.
    1. Exchange Level: We will need to remove the orphaned Exchange objects that is meant for NorthDC and NorthEX
      1. Remove Recipient Policies. Remove any policies that has anything to do with the other office’s domains. In SouthEX, we removed policies that applied to NorthEX. Otherwise it won’t let you remove from Accepted domains in SouthEX Exchange server.
      2. Removed from Accepted Domains in SouthEX Exchange server,
      3. Remove any connectors and routes to NorthEX
      4. Remove NorthEX Exchange servers in SouthDC via ADSIEDIT.msc.
        1. Exchange servers are under:
      1. Remove Exchange attributes for users in NorthDC
        1. How to Use the Remove Exchange Attributes Option
      2. There might be some emails already got stuck in an unreachable queue. You may issue the retry-queue PowerShell command to resubmit those emails:
        1. retry-Queue -Identity "ServerName\Destination" -Resubmit $true

    1. Domain Level: We need to remove the orphaned Domain Controller completely
      1. Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
      2. You may need to configure a new authoritative timerver in the domain.
      3. Remove old computer account by using "Active Directory Sites and Services" tool.
      4. Remove old DNS and WINS records of the orphaned Domain Controller.
      5. Use "ADSIEdit" to remove old computer records from the Active Directory:
        1. OU=Domain Controllers,DC=domain,DC=local
        2. CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
        3. CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=domain,DC=local
      6. Force Active Directory replication by using "Repadmin.exe" tool:
    2. User level: Most of the users are ok at this time, however, certain users might see a NDR when sending emails to with the following error:
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

This happens when Outlook use email address auto-complete cache for, which was stored with X.500 address format when under the same Exchange organization. This old X.500 address was causing Exchange to reject the emails. Since Exchange 2000, the X.500 address has been stored in the leGacyExchangeDN attribute in AD. This value was set when a mailbox was created in Exchange 2003, includes the name of the Exchange administrative group where the mailbox belongs. The fix to it is either create a X.500 proxy address for users, or clear the Outlook email address auto-complete cache.

It has been a month after the separations of two offices, we haven’t seen other issues yet. Drinking a cup of coffee, and crossing my fingers now ...

No comments: