Has Microsoft given up on making Active Directory (AD) forests flexible? Iâ€™m beginning to wonder. Last month, I described Microsoft Identity Integration Server (MIIS), the companyâ€™s â€śmetadirectoryâ€ť offering. I explained that it's a tool intended to make life easier for administrators working in multivendor, multidirectory environments by making it easier to manage those environments. I also explained that there are two versions: the full-blown MIIS, which costs $25,000 per processor, and Microsoftâ€™s Identity Integration Feature Pack (IIFP), which is a free download but requires Windows Server 2003 Enterprise Edition to run--sorry, Standard Edition folks.
Basically, IIFP automates the task of maintaining identical user accounts on two or more AD forests. But why would you want to do that?
The first reason you might need to maintain identical user accounts on two or more AD forests is legal. If youâ€™re an investment house, you probably employ three types of positions: brokers, who sell products to clients; analysts, who create high-quality research to help those clients make good buying decisions; and everybody else. Letâ€™s say, for safetyâ€™s sake or because of your countryâ€™s legal requirements, you need two forests: one for the research side of the firm and another for the sales side. But some people need to live on both sides--for example the IT staff and the big cheeses. So Jane Administrator needs an account in the research forest and another in the sales forest, with all the associated irritants. For instance, when she changes her password in one forest, she needs to do it in the other one, or if she gets married, she has to monkey with ADâ€™s bizarre your-name-appears-in-15-places quirks. With IIFP, Jane changes her information in just one place, and IIFP does the rest. Synchronizing user accounts in two--or three or fifty--forests might sound like a small thing, but believe me, itâ€™s a major pain. Having a free tool like IIFP is delightful.
Whatâ€™s that you say? You donâ€™t work in a brokerage house or have legal constraints forcing you to have multiple forests? Well, if youâ€™re running an AD, Iâ€™ll bet that youâ€™re running at least two forests: the one that your company depends on and a separate AD forest in a test lab. So at least some of your employees will need accounts in both forests and therefore could use an account synchronizer like IIFP.
Now, letâ€™s consider a second use. Imagine United Airlines decides that flying people around is a losing proposition and wants to diversify into other means of transportation, so the company buys Amtrak. (I didnâ€™t say it was a good decision, I just said â€śimagine.â€ť) Both firms have a functioning AD forest. Now that theyâ€™re one organization, how does that organization merge the two forests?
The quickest way is probably to use IIFP. With IIFP, thereâ€™s nothing stopping you from running two forests, each with their own Exchange organization. But many of the Amtrak folks would probably soon need an account in the United forest without abandoning their old Amtrak account, and youâ€™d probably eventually centralize the IT staff. By now, you see how IIFP could help. But what should United and Amtrak plan for the long run? Most likely, they'll be looking at migrating the objects in the Amtrak forest to the United forest with an eye to eventually shutting down the Amtrak forest. Now, if that sounds easy, then thatâ€™s just because the term â€śmigrateâ€ť is a bit misleading when referring to AD forests. Migrate really means â€śto loosen up the security in both domains, hook them up with a trust, then use a migration tool to copy objects from one forest to another.â€ť It also means â€śget ready to fiddle with those copied objects a bunch, prepare to deal with incompatibilities (e.g., SID histories), and more.â€ť In short, it means a mess. Now, donâ€™t get me wrong, Iâ€™m not beating up on the folks who make migration tools; the fact that anyone could write such a program is impressive as heck. Iâ€™m saying--and have said in print for 6 years now--that Windows desperately needs a way to painlessly merge two forests, a sort of â€śforest smoosh wizard.â€ť This isnâ€™t some personal fantasy of mine. I first heard of it from the Microsoft folks back in the late 90s. I must have heard a dozen times that â€śYes, we know, you canâ€™t remove domains from existing forests and make them stand-alone forests, you canâ€™t take a domain from one forest and glue it onto another forest, and you canâ€™t merge two domains, but this is just the first release. Weâ€™ll certainly have that worked out by the Blackcomb time frame.â€ť
I had no problem with that. All the Microsoft folks pitching AD at the time said that 2005-2006 was the Blackcomb time frame. Iâ€™m a patient guy. I figured I could wait 5 years. And Iâ€™m not even complaining that Blackcomb isn't out yet or that itâ€™s currently on Microsoftâ€™s long-term schedule for about 2011 because Iâ€™d much rather wait for working code than have bug-infested code now. Instead, Iâ€™m worried about what Iâ€™m currently hearing from Microsoft about the future of the promised forest merger functionality--nothing. The AD folks seem to think that the answer is for organizations with lots of forests to simply continue working with their different forests and use some form of MIIS (e.g., IIFP), to synchronize those forests, rather than work toward forest unification through some Longhorn or Blackcomb-based AD technology.
Where once Microsoft said that the largest unit in Windows was the forest, it now says the largest thing in Windows is the â€śfederation,â€ť a group of forests connected in some way, probably via an IIFP-like tool. The AD people at Microsoft now work for a group called the â€śIdentity and Access Group.â€ť Itâ€™s certainly a better name given all of the things that they handle, but itâ€™s still troubling to think that major AD reworking has taken a back seat. When asked about the progress of forest or domain merging functionality, one highly placed individual replied that he had no knowledge of anyone working on such a project in Windows.
Using a metadirectory tool like IIFP to keep multiple forests working together is a nice solution, and offering IIFP for nothing is a kind gesture on Microsoftâ€™s part. But how well will the tool work on a large scale? How reliable would a federation joined by hundreds or thousands of trusts be? I donâ€™t think anyone knows. We all remember Windows NT 4.0-based organizations whose trusts were unreliable because there were so many of them; is it inconceivable that this would happen to large federations of AD forests as well?
Metadirectories seem to be a wonderful short-term interim solution to the multiforest problem, but with no workable forest or domain merge tools on the horizon, it seems that we're still left with a long-term interim problem.