Illustrating the Problem

Take the relatively simple-seeming problem of adding a new user to a Microsoft Active Directory domain, a task that most large companies must accomplish several times each day.

Microsoft’s “first-class citizen” approach was to use the Active Directory Users & Computers graphical user interface, or GUI. ADUC, as it’s often called, was created as a snap-in, or extension, to a generic GUI administration tool called the Microsoft Management Console, or MMC. The idea with the MMC was to provide administrators with a single window—a “single pane of glass,” in industry parlance—where they could do anything their jobs needed. Need to administer your company’s Domain Name System? Add the DNS snap-in to the MMC. Need to do something with Microsoft SQL Server? Add the right snap-in to the MMC. The MMC was part of Microsoft’s Common Engineering Criteria, or CEC, of the day, and it was an attempt to make all of the company’s various GUI administration consoles more accessible and more consistent.

But you still had to click icons. A large company that brought on a dozen new employees a day—or more—could easily wind up with one or more human beings who literally did nothing but click buttons and checkboxes in the ADUC GUI. Many organizations rightfully saw that as a waste of human labor, and looked for automation solutions.

But as we’ve learned, Microsoft was leagues away from having a cohesive automation story. In this instance, an administrator looking to automate Active Directory user creation might have to explore no less than eleven potential tools to see if any of them could get the job done:

• The Active Directory Services Interface (ADSI) “WinNT” provider.
• The ADSI “LDAP” provider—similar to its “WinNT” sibling, but with distinct capabilities.
• Using a Csvde.exe command-line tool to import a comma-separated values file containing the new user data.
• Running the Dsadd.exe command-line tool.
• Using the LDAP Data Interchange Format (Ldifde.exe) tool.
• Using a .NET Framework class—there were several potential ones to choose from—in a program.
• Using Windows Management Instrumentation, or WMI.

None of these tools accomplished exactly the same thing, although they all had overlap with each other. If you were creating a simple user account—a name and a password, perhaps—any of them might have done the trick. But companies also tend to log data like an employee’s department, manager name, address, phone extension, and so on, and only some of those tools could do all of those. Still other attributes in Active Directory were accessible only from the GUI, so many administrators would spend days or weeks experimenting with various tools, only to glumly return to the GUI after failing to find an automation tool that could do everything they needed.

The underlying reasons for all this were largely political, and they were legion.

Microsoft product teams are largely autonomous, and often smaller than outsiders imagine. Although shipped as part of the Microsoft Windows Server operating system, Active Directory is its own product team, distinct from the base operating system. Teams—at least, back then—tended to operate as self-contained fiefdoms, cooperating with other teams only at need, and typically only when sufficient political capital existed to compel cooperation.

Within the Windows operating system universe, including its many sub-components like Active Directory, the Common Engineering Criteria was one of the few documents that provided cross-team requirements. If the CEC said you had to provide administrative capabilities by means of an MMC snap-in, then you had to do it, even if taking the time to do so meant sidelining some other features you’d hoped to work into your next release. The CEC in 2003, notably, didn’t touch on administrative automation at all, so it’s no wonder so few Microsoft products of the time got automation right.

A team was welcome to provide capabilities above and beyond the CEC, if they had the resources to do so. The automation tools produced by the Active Directory team tended to focus on bulk-import of users, because those bulk imports were a key scenario in migrating large enterprise customers from a competing solution. Enabling migration meant winning deals, which meant incoming revenue, so it’s hardly surprising that those scenarios were the ones prioritized over automated day-to-day administration. Few technology executives of the time were sophisticated enough to consider “how will we manage this thing day-to-day” in their purchasing decisions, and—again, at the time—the ones who were tended to avoid Windows when they could.

It’s worth noting that writing automation tooling isn’t easy, which is another reason why few Microsoft teams committed to it. Developing an MMC snap-in was relatively easy: the MMC itself provided a lot of the code that was boring, such as presenting different views for data, intercepting user clicks and interpreting them as actions, and so on. The MMC was kind of a framework of functionality that was common to GUI-based administration, and so knocking out an MMC snap-in, while not trivial, wasn’t a huge investment.

Nothing like the MMC existed for automation-enabled tools, though. Teams looking to create command-line tools, which could be more easily integrated into scripts, were entirely on their own. They had to develop their own command structure, write code to accept and interpret commands, develop output displays, and more. It’s actually a lot of work, and given the competing priorities of the day—and the fact that the MMC was a CEC requirement—many teams simply couldn’t afford the investment.

The go-it-on-your-own approach to Microsoft product teams didn’t help, either. With no framework for command-line tools in place at the operating system level, and with each team basically choosing their own destiny when it came to what they produced, the tools that did get produced were all but incompatible with each other. One team might produce a great command-line tool that could grab user information from a Human Resources database, but there might not be any way to “link” that data to a tool that could create new Active Directory user accounts. The “walls” between the tools reflected the political boundaries between teams.

As we’ve seen, it was a mess. But Unix wasn’t a mess, right? So let’s just copy that!