Windows Tip: A classic Active Directory mistake

By Mitch Tulloch, ITworld |  Operating Systems, active directory Add a new comment

Once again I've just heard about a company that wants to spin off one of their departments into a separate business, and plans to use the easy way of divvying up their single-domain Active Directory assets.


Here's the plan:


  • Deploy a couple of extra domain controllers on the departing department's subnet; ensuring full replication takes place everywhere;
  • Make sure all FSMO roles are on domain controllers on the parent company's side of the network;
  • Disconnect the department's subnet and make it a separate, isolated network;
  • Delete all of the OUs and computer/user accounts belonging to the department from the parent company's domain;
  • Delete all the OUs and computer/user accounts belonging to the parent company from the departing department's domain;
  • Seize all FSMO roles onto domain controllers on the department's new network.

The result? Two completely separate and fully-functional forests, right?



Before I answer that, let me point out their rationale for their wanting to do it this way. They argued their case using two reasons:

  • They didn't care if both forests and domains had identical DNS names since they were local names anyway.
  • They wanted to hedge their bet so that in case the new business venture failed, the spun-off department could return to the fold of the parent company and its Active Directory could simply be merged back into the parent's.

This approach is not a good idea.


It's an Active Directory disaster waiting to happen. Why? Because if later on they try merging the two forests together, what's likely to happen is that the domain controllers on each side will end up deleting objects from the other side's directory and vice-versa and they'll end up totally trashing their directory. Or they may not even be able to get the two directories to talk to each other because of identical SIDs and service accounts on both sides. Ouch!


I've heard this idea many times from companies wanting to split off one of their business units, and I try to shoot it down immediately whenever I hear it because the official word from Microsoft is that taking such an approach would place your Active Directory deployment into an unsupportable state. So don't do it. Migrate. Don't split. Learning how to perform an AD migration takes time and is somewhat complicated, but it's clearly documented in many places and what's more important, it's supported by Microsoft.


Heard any classic network management mistakes that make you cringe when you think about them? Email me and I'll share them in an upcoming column.

 

ITworld LIVE

Operating SystemsWhite Papers & Webcasts

White Paper

A Comparison of PowerVM and VMware vSphere (4.1 & 5.0) Virtualization Performance

This technical white paper presents benchmark results showing greater VM consolidation ratios than demonstrated in previous benchmarks and demonstrating the extent of the performance lead that PowerVM virtualization technologies deliver over x86-based add-on virtualization products.

White Paper

Consolidating Lotus Domino x86 Workloads on IBM Power Systems

Read the white paper to learn how moving up to Lotus Domino 8.5 and consolidating with IBM Power Servers can help you boost performance results and ROI.

White Paper

Task, workflow & issue management for teams. Try free!

Need a flexible system for managing team tasks, issue tracking, and automating and managing workflow processes? Comindware® Tracker helps you do it all.

Webcast On Demand

Best Practices in Monitoring VMware

The benefits of virtualization are unassailable: increased agility, scale, and cost savings to name a few. However, so too are the monitoring challenges posed by these environments-including complexities, lack of visibility and control, and inefficiency.

Sponsor: Nimsoft

White Paper

How Nimsoft Service Desk Speeds Deployment and Time to Value

For years, many support teams have been hamstrung by their traditional service desk platforms, which require complex, time-consuming coding for virtually every aspect of customization. This complexity makes it costly and difficult for support organizations to adapt-and places an increasingly substantial burden on the agility and efficiency of the business as a whole.

See more White Papers | Webcasts

Ask a question

Ask a Question