Learn how to a build a cloud-first strategyRegister Now

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

Splitting a 2003 domain into two separate domains

Hello.. I have a challenging task. I have never seen this kind of request before, but we were just asked to spit our Windows 2003 Active Directory domain so that legacy data can be reviewed in a read only mode.

What we have is five sites, with a domain controller in each. They want to disconnect the WAN, but still have users who are local to their site log into the domain there and still read their old email or shared files.

We plan to make a copy of each share to each server and make it read only. Plus, we will make sure each user's Exchange mailbox is on their local Exchange server.

The question is, how do we make each domain controller think it's the only one and how do we prevent any kind of tombstoning of our systems?

Thanks in advance for your help!
0
reesejl
Asked:
reesejl
  • 8
  • 5
  • 3
  • +1
2 Solutions
 
KCTSCommented:
This seems to be a strange way to go about things - why not just archive data and make the archive r/o ? I don't see the need for another domain.
0
 
reesejlAuthor Commented:
Our company is disconnecting all of the sites. There will no longer be any connectivity between them.
0
 
KCTSCommented:
If you really must duplicate the other domains (I'm still not convinced), then why not use a couple of local only virtual machines.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
reesejlAuthor Commented:
We only have one domain, but they need it to exist at each site after we tear down the WAN connections.  How would we duplicate domain controllers to VMs at each site? I have to think that there would be an easier solution.
0
 
MSE-dwellsCommented:
Are you saying you want to take this single Active Directory and "clone" it at 5 distinct non-communicating locations that will operate as entirely disconnected entities from this point forward?
0
 
reesejlAuthor Commented:
MSE-dwells.  Yes.  We have one domain in our AD.  There is a DC at each site. We simply need to sever the WAN connection and have them continue functioning as before without any of the systems tombstoning because they cannot contact the FSMO holders.  We have already worked out the part where we need to mirror data and move mailboxes to where they belong...
0
 
MSE-dwellsCommented:
OK, so let's focus on the answers to the AD piece - you will need to promote (DCpromo) enough DCs to fulfill each site's requirements, i.e.

- you have 5 sites
- if you want 2 DCs per site then we'll need 10 DCs
  * if you already have 3, promote 7 more
- verify that replication has succeeded end-to-end
- make each DC a GC and a DNS server
- configure each DC to resolve (DNS resolver) against itself
- move the DCs to their respective sites
- on 1 DC at each site, seize all FSMO roles
- use 'ntdsutil' and its 'metadata cleanup' submenu to remove all DCs from the other sites

... this is the basic means of achieving what you're asking but lacks possible specifics since I don't have a great deal of detailed configuration information to hand ... perhaps you could provide a little more regarding the current setup.

NOTE - these steps assume you have a single domain forest!!!

Now, as to some personal comments on what you're doing - this approach isn't advisable unless AD and all AD-aware applications remain isolated from their clones for the rest of their lives.  I'm uncertain as to the specifics that motivated this but it's certainly an odd move.  Any future connectivity or roaming of users between sites will cause technical issues ... not insurmountable by any means, but frequent, time consuming and annoying.
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
If you do this, reconnecting them again if you change your minds may simply be impossible - or EXTREMELY COSTLY and DIFFICULT.

That said, I would suggest the following:

Create ONE Virtual Machine using VMWare or Virtual Server and make it a DC in your environment.  Transfer ALL the FSMO roles to that system.  Distribute a copy of the VM to EACH site via DVD or secure download from one site and then DISCONNECT EVERY SITE so there is no more connectivity.  Then Have each site boot up the VM.  (Change the IPs at each site if necessary).  Now each site has the FSMO master for the domain and OTHER DCs that are not in the site can be removed using the NTDSUTIL.  Once that's all done, you transfer the FSMO roles from the VM to the local DC and get rid of the VM (or better still, keep it as a backup).
0
 
reesejlAuthor Commented:
MSE-Dwells... Thank you... In talking to other admins here, we agree that this would be the best solution.  I understand everyone's concern that the domains can never be joined back together. That's not a problem. They plan on retiring the data at some point anyway.

Thanks all!
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
What about my suggestion with the virtual machines did you not think would work well?

Overall, I feel it's cleaner as there is no FSMO seizing that need be done.
0
 
reesejlAuthor Commented:
leew - We would be required to set up a VMWare server at each site, create the VMs, configure them, test  them, etc.  It would require hardware we just don't want to dedicate to this purpose.  It's easier for us to just kill the connections and grab the FSMO roles and be done with it....  Thank you for your suggestion though.
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
Huh?  That really doesn't make much sense.  You're talking about a TEMPORARY setup for one VM that can have 256 MB of RAM.  You could even use virtual PC.  Sorry, but I don't like seizing FSMO roles when you don't have to and using my suggestion, you don't have to.  You don't NEED to keep the VMs, but it's CHEAPER to do that than to buy a SECOND DC for each site.  Sure, you need the licenses for the servers in each location, but you could even break each location away step by step. Do what you think is best, but I think the method you have selected is unnecessarily time consuming.
0
 
reesejlAuthor Commented:
leew - I read over your solutions/comments and agree that it may be a cleaner solution. But I doubt that the company would expend the money required to install a second DC at each site, much less the equipment to set up a VMWare server.  In fact, both your solution and MSE-Dwells would work; and yours would permit us to rejoin everything if we ever needed to.
I am new to the community and am trying to become familiar with the way it works. I should have waited a day until I saw all of the solutions and could mull them over and award points appropriately.  
I have posted the following query to the Community Advisor in hopes I can get some points your way too:  
--------------
Hello. I recently submitted a question for which I received a quick answer. I accepted the answer as the solution before I realized that a second member had posted a different, although just as correct solution.  How can I award points for this second solution after the fact?  The URL of the question is: http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_2003_Active_Directory/Q_22893854.html#discussion
--------------

Thanks again....
Can you let me know what I can do?
Thanks!
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
Again, I'm not sure where I see a cost here.  The only potential cost is the Windows License.  VMWare Server is FREE.  Virtual Server is Free.  Virtual PC is Free.  Virtual PC, if you've never set it up, is a 5 minute install.  Distribute the .vhd and .vmc files via DVD to the office and install Virtual PC then open them up.  You can let it run a day... or a month.... or forever - it doesn't matter.  If ALL you're servers are so loaded down they can't spare 256 MB of RAM, then they really need to be upgraded.

I admit, I'm not giving you EXACT, DETAILED, STEP BY STEP information, but you seem to have some knowledge, so I didn't think it was necessary.  If you'd prefer I'll to go into greater detail.

To me, the Virtual Machine idea is the absolutely the cheapest, fastest, most resilient solution you could use.  

Though I don't think you could use my idea to rejoin things to the domain later - it's just a cheap, safe, fast solution, in my opinion.
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
I'm not trying to suggest the solution MSE-dwells posted was "wrong", just that it's not what I consider the best, cheapest, fastest option.

From a licensing standpoint, this is good because you COULD simply buy ONE copy of Server 2003 and migrate it around, using it on the VM.  For example, install it on one VM at one site, ship the DVD to another site and have them disconnect from the company network.  Then boot up the DC on the VM at the remote site.  Transfer the roles, run NTDSUtil to clean up the metadata (this part would get progessively longer as more and more sites fall off AD) and finally, transfer the FSMO roles from the VM to the physical box at the site.  Demote the VM and not you have your one, lonely DC with no connection to the remote systems and an otherwise clean AD.

MS has never advocated using seizure as a preferred method of doing anything and as such, I would question any recommendation that suggests it over less "potentially dangerous" methods.

(Sorry for the rambling - more and more points keep coming to mind).
0
 
reesejlAuthor Commented:
I think I see where you're coming from on the cost... Loading the VMWare server software on one of the servers/PCs already there and using it to host the VM DC.  I am so used to our environment where we use VMWare ESX servers that I didn't think to use the VMWare version we could install free.  So yes, I agree there would be little cost, if any, to implement the VMWare solution.
I will run your solution by our team here and see if they want to try it.  
Thanks again...
0
 
MSE-dwellsCommented:
>> leew: I'm not trying to suggest the solution MSE-dwells posted was "wrong"
Hehe - good ;0) ... pleased to hear it ...

I too like leew's solution and would suggest you investigate if you have sufficient experience with virtualization products and AD.  Be certain to destroy the VMs after the fact since they have a tendency to cause problems if re-introduced at a later point in time (query on USN rollback & differencing disk/undo disks if interested -- they do work extremely well if used properly).  

There was something of an implication that an AD containing seized FSMOs equates to a "dirty" AD that I don't agree with.  Role-transfer is always going to be preferred over role-seizure since we're involving both the old DC and the new DC and merely exchanging state without even stopping for breath so to speak.  In fact, the code-path for role seizure is such that it requires that a transfer attempt fail before the directory will accept the forced modification ... this is not an artifact of the UI.

Regardless of scenario, gaining a thorough understanding of each FSMO's responsibilties and the possible hazards caused by inadvertent (or deliberate) role duplication is time well-spent.  Having done so myself, I'm comfortable to volunteer role seizure as an option in situations such as this.  Keeping in mind mind that the goal here was to isolate and clone a directory, the potential for FSMO collision goes well beyond "unlikely" because the original DCs will never be seen again through 1) an obvious requirement for adherence to technical best-practises and, more importantly, 2) because it is the exclusive goal of the project -- it represents exactly what we were trying to do from the get-go.

Anyway ... that's my technical perspective aired.  As for the h/w costs and licensing issues, I'm entirely in support of whatever you have to hand and will always advocate the virtual solution wherever suitable/possible.
0
 
reesejlAuthor Commented:
I just split up the points between MSE-dwells and leew.  Thanks for your help on this one...
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 8
  • 5
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now