In the past two Windows IT Pro UPDATE--Special Edition commentaries, I've suggested a few improvements that Microsoft should consider when designing Longhorn's Active Directory (AD). And because the company has announced that it will further delay Longhorn, I can note with tongue in cheek that it now has more time to implement those ideas. This month, I continue with a third suggestion, and although it's number three in this sequence, it's number one on many people's lists: flexible forests.
Not many people will dispute the statement that AD is a bit unforgiving with its forest structure; you might say that if AD were a pencil, it would lack an eraser. Let's say you've purchased another company and need to merge your forests. Sorry, AD has no "forest-smoooosh wizard." Or, you've sold part of your company and want to remove that part's domain, leaving a standalone forest. You can't do that either. Maybe you've installed an AD-aware application that modified the AD schema, but you've uninstalled that application and now you want to remove its changes to the schema? No can do. (One reader tells me that he tried to run Microsoft's Adprep utility--you need to run Adprep to upgrade a Windows 2000-based AD to a Windows Server 2003-based AD--only to have the Adprep process fail. It turned out that he'd previously installed an AD-aware application on his Win2K-based AD, and that application made schema changes that conflict with the changes that Adprep must make to the schema ... ouch.) Although I'd like to have all the above capabilities, if I had to just choose one, I'd choose forest merges.
Here's what I'd like to see Longhorn AD be able to do in terms of forest merges. I'd like it to analyze differences in the schemas of the two forests to be merged, detecting which items each schema contains. Then, it would create a new schema structure comprising the union of the two schemas, resulting in the combination of all items in both schemas without duplicating any items. Next, AD would modify the schemas of both forests to reflect this new, expanded schema structure. The Longhorn AD forest-merging system would then duplicate this process for the Global Catalogs (GCs) of each forest, ensuring that they contain the sum of the information in each GC but omitting duplication. Finally, Longhorn AD would create the transitive trusts from the first forest to the second forest. The forest-merger feature would then ask the administrator which domain to make the new forest's root domain.
Clearly, stitching a forest together entails more than what I've outlined. Based on my experience, Microsoft's current forest-reshaping tool, the domain-rename function in Windows 2003-based ADs, is nothing short of awful. This functionality requires that you have simultaneous online access to every domain controller (DC) in a domain, then requires you to reboot all member servers and workstations twice and change the domain suffix on the DCs by hand. Yuck. I wouldn't recommend you use this method for any but the smallest domains.
Microsoft is aware that AD's inflexibility is a major source of irritation. So why doesn't the company change that? It might well be that I'm simply ignorant of some deeper matters. Perhaps then, the truth is, with apologies to poet Joyce Kilmer, "Columns are written by fools like me, but only Dcpromo can make a tree."
Perhaps I'd understand why AD has to be so inflexible if Redmond released a bit more information about AD internals. Some day, perhaps.
