[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 621
  • Last Modified:

Splitting AD and Exchange organisation into 2

Hi,

Soon we will have to split our 2 Active Directory sites, and leave both running in a completely separate environment as we are selling the other business, and i am looking for the best way to do it without rebuilding the breakaway domain.
WF is the smaller site which is breaking away, and LDS is the current HQ and holds the majority of services, and will remain so.
WF currently has:
1 Exchange 2003 Backend RPC
1 2003 DC
All the Data, printers are on separate servers on each relevant site, and the user accounts are split into relevant OU's.
The Domain stuff i wouldn’t have thought would be 2 hard, as i thought i could remove the VPN between sites, force seize the roles and clean up using ADSiedit, unless there is a cleaner way of doing this.

The AD domain name can remain the same, as its pretty generic, and each will have its own mail domain, which currently resides in the Exchange 2003 organisation.
All servers are running the same and latest SPs as is Exchange.

Our current exchange setup is

Front end 2003 server running RPC over HTTPS (not in DMZ) in LDS
2 RPC backend 2003 servers (1 on each site)
1 routing group with 1default connector with the FE as the bridgehead
We will not be adding the RPC-HTTPS to the breakaway Exchange.

i have tried to get mail to route out of the WF local gateway using a new connector, but it still routes it through the FE in LDS.

Any ideas on the above would be great.

Cheers
0
deanwilsons
Asked:
deanwilsons
  • 6
  • 6
1 Solution
 
Mike ThomasConsultantCommented:
This can be done by simply picking up a domain controller and exchanger server and moving them to a seperate network then doing a meta data clean up on both remaining domains. If this hardware already exists at another site you would just have to kill the WAN link between the sites or firewall the sites off.

Doing it this way you are effectivly treating the disjointed sections as failed and just doing the required cleanups.





0
 
deanwilsonsAuthor Commented:
MojoTech,

yeah that was the plan, but was wondering if there was a more, shall we say ordered way of doing it.

But before i do anything, i need to sort out the Exchange, like getting the routing to go out locally and not via the FE.

Once i get it to route out locally, would i just treat (once we split) the 2 Exchange sites like failed sites as well?
What about any Public folders, i presume once in sync, these too can be be treated like orphaned objects.

cheers

phil
0
 
Mike ThomasConsultantCommented:
Yes just the mail flow is the tricky one out bound and inbound, but once that is sorted it really it is pretty straight forward. I had to do a similar thing for a company I was working at a few years ago, we sold of 4 parts of the group so had to do this 4 times.

Once split you just treat whatever is remaining in your site that was actually moved or cut off as failed, so if you have say dc1, dc2, ex1 and ex2 and you split off dc1 and ex1 then in the site where dc1 and ex1 are treat dc2 and ex2 like they have failed, and in the site where dc2 and ex2 are treat dc1 and ex1 like they have failed.

0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
deanwilsonsAuthor Commented:
Ok i get that, no worries there so far, and pretty much as i expected, so thanks for the second opinion.

what i dont get though, is why even when i create a new connector, then tell it to route via its local gateway (used local IP as smart host) it still goes out via the FE.

I cannot start this until i get that fixed.
this isnt something wierd to do with it being an RPC setup, or is it because there is only 1 routing group?

cheers
0
 
Mike ThomasConsultantCommented:
You should be able to force it out using the default smtp connecter settings for the server rather than the connectors for the organisation.

0
 
Mike ThomasConsultantCommented:
Sorry that meant to be the servers default smtp server properties not connector.

0
 
deanwilsonsAuthor Commented:
I have looked all through the Servers smtp server properties, and apart from the advanced delivery fields, i can see no where in there to force it to use its local gateway of 192.168.2.1.
do i add to the smart host [192.168.2.1] or do i put the exchange servers address in there?

if its none of the above, then im stumped.

The FQDN has the Orgs mail.domain.com address
0
 
Mike ThomasConsultantCommented:
Use the smart host field to force the mail outbound, having said that mind do you even use a third party smart host or do you rely on dns? If you use dns you will have to wait till you split before you can separate the outbound I think.
0
 
deanwilsonsAuthor Commented:
currently we dont use any smarthost, and all our, and this includes the WF domain goes via messagelabs.
we do rely on dns to route our mail, but i still dont understand why it should be so difficult for mail to be routed out via its local internet gateway, rather than having run up the vpn to the FE.

What i dont want is to split these up, and then find out that the previous admin, did some spooky stuff that makes it a headache to get mail working on the WF site.

cheers
0
 
Mike ThomasConsultantCommented:
Messagelabs is a smarthost, use the info they provided you  with and put that into the smarthost box on the default smtp server.
0
 
deanwilsonsAuthor Commented:
the messagelabs smarthost worked, but internal mail failed to be delivered as it tried to send it all via messagelabs.

cheers
0
 
deanwilsonsAuthor Commented:
Solution was aprtial correct in that it misses out a lot of steps required to remove dead eaxchanges servers, like how to rehouse mailboxes.
0

Featured Post

NEW Veeam Agent for Microsoft Windows

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

  • 6
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now