Another AD Must-Have: Reflection

Last month, I suggested that with Longhorn's release far off in the distance, it might be a good time to lay out some things that could make the release a “must-have” upgrade, and suggested that Microsoft could greatly improve Active Directory (AD) by letting AD objects have aliases that allow them to exist in several containers at one time--the way file and folder shortcuts do. This month, let me suggest another AD enhancement: reflectivity.

Reflectivity is the ability of a software system to create a set of archivable commands that can reconstruct that system. Suppose you create an AD by using GUI tools such as DCPROMO, the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, and other AD-relevant MMC snap-ins. GUI tools work well when you’re performing a task that you don’t do often, but they’re slow and involve a fair amount of babysitting. It would be great to be able to enter commands at the command line that would perform the same tasks. Then you could stuff those commands into a batch file or series of batch files. The attractive part about that approach--no babysitting required.

But command-line commands aren’t trouble-free, either. They often involve obscure syntax that can have a steep learning curve, and we tend to forget that syntax if we don’t use the commands enough. So GUIs are simple to use but inefficient and not automated, and command-line interfaces are powerful and easy to automate but not easy to learn. With a reflective system, you could set up an AD (or anything else) via the GUI, push a button, and AD would generate a batch file. You could then run that batch file on a freshly installed copy of Windows Server to create an AD that works just like the first AD that you built.

Why would you want this functionality? I can think of three reasons: disaster recoverability, auditability, and training and testing. First, disaster recovery: You'd have a set of automatically created batch files that could rebuild your AD, Group Policy, organizational unites (OUs), accounts, trust relationships, and sites. Second, auditability: These batch files would be like a complete set of AD documentation--almost like having a program’s source code. Third, training and testing: You could walk into any lab and quickly build an independent teaching network that worked like your production network. You could then either train network engineers on that network or use the network to test AD changes and processes. There have been a few reflective tools in Windows since Windows 2000: Go to any computer with an Ethernet connection, open a command line, and type

netsh int ip dump

You’ll get a bunch of commands that you can save to a file. Name the file (e.g., nicsetup.txt). Take nicsetup.txt to another computer, and type

netsh exec nicsetup.txt

at a command line; this will configure the second computer’s IP stack identically to the first machine. You can use similar netsh commands to configure and reflectively back up a DHCP server.

Sounds neat, doesn’t it? A system that is both self-documenting and capable of spitting out a series of batch files that would let you automatically recreate the system Let me pass on a bit of good news: If the folks working on Microsoft Scripting Host (MSH--code-named Monad) get their way, this functionality will happen. But installing reflection into AD and Windows would be a huge undertaking--one that would require developers to make their code accessible through command-line commands and to include a reflectivity capability in that code. That would require a discipline possessed by few software companies. I think that if Microsoft implemented reflectivity Windowswide, then Longhorn would mark a major OS advance--one written with administrators, security, and auditability in mind.