[{"_1":2,"_153":-5,"_154":-5},"loaderData",{"_3":4,"_38":-5,"_39":40,"_129":130,"_151":-5,"_152":-5},"root",{"_5":-5,"_6":-5,"_7":8,"_22":23,"_24":25,"_26":27,"_30":31,"_36":37},"user","shoppingCartId","shoppingCart",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":14},"id","no-cart","count",0,"free",true,"updatedAt","2026-02-07T10:22:26.529Z","paymentGateway","STRIPE","cartItems",[],"loading","locale","en","readerTheme","system","constants",{"_28":29},"paypalClientId","AX53Cwz8jR6rVVzzZiZNWWXl0dGagi-GZrjG-S3Ua14E5nrKMn7DxDQ730O4R8LusLPp49ALn6aRVaEy","publishers",{"_32":33,"_34":35},"companies",[],"universities",[],"needsLocaleCookieSync",false,"routes/_store+/_readers+/read_/route","routes/_store+/_readers+/read_.$slug/route",{"_41":42,"_67":68,"_118":119,"_127":37,"_128":-7},"book",{"_43":44,"_45":46,"_47":48,"_49":50,"_53":54,"_56":57,"_65":66},"title","Shell of an Idea","slug","shell-of-an-idea","metaText","Shell of an Idea: The untold history of PowerShell","coverFeatured",{"_51":52},"url","https://d2sofvawe08yqg.cloudfront.net/shell-of-an-idea/s_featured?1620622704&1620622704","coverFeatured2x",{"_51":55},"https://d2sofvawe08yqg.cloudfront.net/shell-of-an-idea/s_featured2x?1620622704&1620622704","authors",[58],{"_9":59,"_60":61,"_5":62},"Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6UHJvZHVjdEF1dGhvci8zODQ3Mw","name","Don Jones",{"_63":64},"username","donjones","showReadLinkString","sample","parts",[69],{"_43":44,"_70":71,"_72":12,"_73":74},"description","","fileCount","chapters",[75,94,98,102,106,110,114],{"_76":77,"_43":78,"_79":80,"_72":81,"_82":83,"_90":-5},"level",2,"A Special Note","path","#leanpub-auto-a-special-note",1,"subsections",[84,91],{"_76":85,"_43":86,"_70":-5,"_79":87,"_72":81,"_88":-5,"_89":-5,"_90":-5},3,"Respect the Author’s Rights","#leanpub-auto-respect-the-authors-rights","quizType","sectionNum","youtubeId",{"_76":85,"_43":92,"_70":-5,"_79":93,"_72":81,"_88":-5,"_89":-5,"_90":-5},"Updates","#leanpub-auto-updates",{"_76":77,"_43":95,"_79":96,"_72":81,"_82":97,"_90":-5},"Foreword","#leanpub-auto-foreword",[],{"_76":77,"_43":99,"_79":100,"_72":81,"_82":101,"_90":-5},"Introduction","#leanpub-auto-introduction",[],{"_76":77,"_43":103,"_79":104,"_72":81,"_82":105,"_90":-5},"A Shell of a Problem","#leanpub-auto-a-shell-of-a-problem",[],{"_76":77,"_43":107,"_79":108,"_72":81,"_82":109,"_90":-5},"Illustrating the Problem","#leanpub-auto-illustrating-the-problem",[],{"_76":77,"_43":111,"_79":112,"_72":81,"_82":113,"_90":-5},"Let’s Just Copy Unix","#leanpub-auto-lets-just-copy-unix",[],{"_76":77,"_43":115,"_79":116,"_72":81,"_82":117,"_90":-5},"Kermit","#leanpub-auto-kermit",[],"toc",[120,84,91,121,122,123,124,125,126],{"_76":77,"_43":78,"_70":-5,"_79":80,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":95,"_70":-5,"_79":96,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":99,"_70":-5,"_79":100,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":103,"_70":-5,"_79":104,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":107,"_70":-5,"_79":108,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":111,"_70":-5,"_79":112,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":115,"_70":-5,"_79":116,"_72":81,"_88":-5,"_89":-5,"_90":-5},"isUnavailableOnline","unavailableMessage","routes/_store+/_readers+/read_.$slug.$chapterId/route",{"_43":44,"_131":132,"_41":133,"_148":142,"_149":150},"content","

\nForeword

",{"_134":135,"_43":44,"_47":48,"_45":46,"_65":66,"_136":137,"_147":132},"previewContent","

\n A Special Note\n
- \n Respect the Author’s Rights\n
- \n Updates\n
\n
\n Foreword\n
\n Introduction\n
\n A Shell of a Problem\n
\n Illustrating the Problem\n
\n Let’s Just Copy Unix\n
\n Kermit\n

\nA Special Note

Thank you for pre-purcahsing Shell of an Idea. You should know that this book is being Agile-published, which means chapters are under development and revision. You may run across some incorrect facts, or some out-of-sequence statements; that’s to be expected, as part of the revision process is checking all those things. If you note anything in particular, you’re welcome to drop me a line by using the “HMU” (Hit Me Up) page at DonJones.com. Please note that page numbers are not a valuable reference; a chapter title and a brief snippet of text will help me find any passages you’re referring to.

\n\n

\nRespect the Author’s Rights

I appreciate you not sharing copies of this book online or in other ways. I’ve chosen a DRM-free format so that you can read your copy wherever and whenever you like; please don’t ruin that by handing out illegal copies. Forward folks to Leanpub.com/shell-of-an-idea to buy their own, and support this and other independent writing!

\n\n

\nUpdates

I strongly recommend that you allow Leanpub to send you update emails when I update the manuscript. This is not turned on by default; you will need to:

\n\n

Log into your Leanpub account
Select “Library” from your account menu (upper-right)
Click on this book’s cover image
Select “New Version Available” under “Email Settings”

\n\n

If you’re reading on a Kindle, you can add your Kindle email address so that Leanpub can send new versions right to it.

\n\n\n

\nForeword

\n\n\n

\nIntroduction

My history with Windows administrative automation goes back a long ways, at least to my 2003 book, Managing Windows with VBScript and WMI. A bestseller of the time, it put me “on the map” as someone who spoke about, taught, and wrote about Windows automation. It helped drive my first Microsoft MVP Award recognition in 2004, and made it natural for me to jump into Windows PowerShell—“Monad”—when it hit the scene in 2005.

\n\n

I was honored to co-present with Jeffrey Snover at TechEd Europe 2006 in Barcelona, where Microsoft formally launched PowerShell and introduced it to the world. I wrote the first published book on PowerShell, Windows PowerShell: TFM (SAPIEN Press), and have in total written or co-authored close to a dozen books on PowerShell. Learn Windows PowerShell in a Month of Lunches remains a go-to bestseller for newcomers, and PowerShell In Depth is still a top reference for PowerShell admins. I co-founded PowerShell.org, launched PowerShell + DevOps Global Summit with my partner, and was named “PowerShell First Follower” by Jeffrey Snover at the first Microsoft Ignite events in Chicago. I coined the terms “Toolmaker” and “Toolmaking” within the PowerShell world, and have been an advocate for strong practices and patterns. I even substituted for Jeffrey Snover as a speaker at the TechEd North American 2017 conference. Suffice to say that PowerShell has been an enormous part of my life and career.

\n\n

Over the years, I’ve made a ton of good friends in the PowerShell community, which is easily one of the friendliest and most down-to-earth group of technologists I’ve ever met. My office has a small collection of the thoughtful, tongue-in-cheek mementos they’ve picked up for me: a CIA challenge coin, a Lego minifig of myself, a beer stein with PowerShell and Disney’s Figment character etched into it, and more. My career has taken me away from the day-to-day engagements with both the technology and that audience, but they’ve both been such a huge part of my life and career that I can never step fully away.

\n\n

In fact, that was the genesis for this book. I just can’t let PowerShell go: it’s not only been important to me, it’s been hugely important and impactful to so many people in the industry. And yet PowerShell almost never happened. In fact, it “almost never happened” more than once; were it not for a team of passionate visionaries willing to make the occasional possibly-career-limiting moves, PowerShell—and all the positive impact it’s created—wouldn’t have existed. PowerShell might have just been a port of Unix’ KornShell, or it might have just been a WMI querying tool. Or it might not have been a thing at all.

\n\n

There’s a lot of untold story under the shell, and it’s a story I wanted to tell. Much of PowerShell’s core team have moved on to other teams, or even to other companies. Nobody’s getting any younger. I felt it was time to capture their stories, and the shell’s story, while I could still track everyone down. Some bits of the story have been told at conferences or in other venues, but it’s never been pulled together into one place—and it’s never been told in its entirety.

\n\n

If you’ve worked with PowerShell, then Shell of an Idea should provide some fascinating backstory to that tool. If you haven’t, but you’re at least conversant with computers and systems administration, then you’re in for a real treat. As much as possible, I’ve tried to wrap context around the stories so that you can see where they fit into the world, and what PowerShell struggled against and sought to solve.

\n\n

I’ve also included a number of quotes, solicited through my blog at DonJones.com. These may seem out-of-context as I present them, but they’re intended to provide some of the background and context for the people that PowerShell has impacted the most. I’ve edited these as lightly as possible for length and clarity, because I feel that the effect of the shell’s story is just as important as the story itself. Here’s one example:

\n\n

\n\n
PowerShell changed my life…. I realize that such a statement may seem exaggerated, but every Powershell enthusiast can relate in some way to the overwhelming benefits, and career opportunities that learning PowerShell has given them.
\n\n
I had worked in an operations management position for 5 years, and dreaded going into work everyday. The stress was awful, but the monotony was worse. I was 30 years old, had a wife, two boys under 2 years old, and living on my single income. I was afraid it was too late to change careers and find work I actually enjoyed. However, my older brother who worked as a system administrator for a large tech company told me about how he used Powershell in his job and loved it. He was a PowerShell enthusiast and thought I could learn it and open up an opportunity to change into the IT field. So he actually gave me the book he used that helped him learn, “Learn PowerShell In a Month of Lunches”.
\n\n
That was about 6 months ago, and I was fortunate that an opportunity opened up at my current company in our IT department soon after I started learning. The little I knew at the time allowed me to get my foot in the door, but also gave me the opportunity to make an immediate impact and learn in a practical way.
\n\n
PowerShell is easy to learn and is incredibly practical and useful in most every environment. Since I started, i’ve scripted automated tasks that run daily, created GUI tools for our Operations department, and many more things like interacting with web APIs and more.
\n\n
I now love what I do, and I’m excited about the career and financial opportunities this new path will help provide for me and my family. I will forever be a Powershell evangelist and look forward to continuing to gain a more in-depth knowledge, and hopefully have the opportunity to teach and train others how Powershell can potentially change their lives as well.
\n\n
—Aaron
\n

\n\n

How can you not want to read more of the story of a technology that can generate that kind of feeling? “Easy to learn,” “incredibly practical,” and “I now love what I do.” Those aren’t statements we often see all attached to a single technology, right? The journey to create a product that engenders those remarks… must be amazing.

\n\n

It’s easy, as we sit in front of our monitors and tap away on our phones, to forget that the story of technology is a story of people. It’s about visionaries who see problems and try to solve them, who take on some small piece of the world and try to make it at least a little better. It can be difficult for us everyday folks to look at the end result and be impressed by it. What I hope you take away from this book, though, is that those amazing end results come in tiny, often-difficult steps. If you’re willing to take those little steps and push through the hurdles, you can make just as big of a difference. The people who brought PowerShell to life are just ordinary people, who shared a vision and worked hard to make it a reality.

\n\n

This is, hopefully, their story, and I hope you enjoy it.
Don Jones

\n\n\n

\nA Shell of a Problem

To understand the history of PowerShell, and its subsequent impact, you need to understand a bit of Microsoft history. At least, a simplified version of a tiny piece of it.

\n\n

Until 1993, Microsoft Windows was a desktop operating system, meaning it ran on individual computers used by individual people. Most of those computers were fairly large, beige boxes that sat on, or under, a desk; laptop computers at the time were pretty primitive and bulky compared to what you might see today. The Windows of the day was version 3.1, and it couldn’t even participate fully in the more-primitive computer networks of the day, and home users tended to rely on dial-up services like America Online rather than the always-on Internet we take for granted these days. That Windows was shortly succeeded by Windows for Workgroups, the first fully network-capable Windows operating environment, and the first Windows arguably created with business scenarios specifically in mind. But even then, Windows for Workgroups could really only join a network; there was no version of Windows capable of hosting a network. Networks of the time were hosted by a server, with the most common servers running either a product called NetWare 3.1, produced by a company called Novell, or a variant of the UNIX operating system.

\n\n

Unix (as it is more commonly styled nowadays) had been around for a while by then, primarily at military research facilities and large universities, but also running on the enormously expensive mainframe and midrange computers used by the largest enterprise companies. It featured robust networking, and in fact provided the underpinnings of what would become today’s Internet. Unix at the time was both incredibly complex to use (compared to Windows) and incredibly expensive; a single Unix computer could easily represent an investment in the tens of thousands of dollars.

\n\n

NetWare was common in smaller- and medium-sized businesses; it was a fairly complex product to install and manage, and included its own protocols for network communications. NetWare could run on smaller, cheaper computers, and it was somewhat simpler for network administrators to learn to use.

\n\n

Perhaps most importantly, many decent-sized companies didn’t have a “network” at all: they has a midrange computer like an IBM AS/400 that handled all of the business’ computing. Users connected to these midrange computers through “terminal emulation” cards that plugged into their bulky desktop computers, and by using applications that ran on Windows. Essentially, these terminal emulators turned each desktop into a “dumb monitor”—literally not much more than a television that was hardwired to the midrange machine—capable of sending keystrokes and displaying whatever the midrange sent back. Truly huge companies often had a mainframes, which was basically just a giant equivalent to a midrange, such as the Digital Equipment VAX line of computers.

\n\n

The point is that, in the early 1990s, computer networking wasn’t a big thing for most businesses, and you needed specialized personnel to build and run a network if you did have one. It wasn’t like today, where your smartphone can join a wireless network with a couple of taps, and you can set up your own home WiFi network just by plugging in a box and running a setup app on your phone.

\n\n

So, the landscape of the time: big companies had a single enormous computer, and perhaps a bunch of pricey Unix machines to supplement it. Smaller companies maybe had a few desktop computers connected to a NetWare server. Without networking, it was a pretty big pain to own more than a handful of computers. Even a giant tech university like MIT could probably have counted up all the computers they owned without much effort—a marked contrast to today’s world, where most of us have a pocket computer (called a smartphone), maybe a laptop or tablet, maybe a wrist computer (smart watch), a gaming machine, and more. In the early 1990s, a single human being didn’t run around owning a half-dozen computers!

\n\n

In 1993, Microsoft launched Windows NT, its first truly “business grade” edition of Windows. Most critically, it launched Windows NT Server, which was their first operating system capable of hosting a robust network. Windows NT wasn’t yet anywhere near the class of a midrange or mainframe operating system, but it could certainly compete with Novell NetWare as the centerpiece of a small- or medium-sized business network. Even large companies started buying Windows NT: not to replace their AS/400 or VAX machine, mind you: in most cases, Windows NT “snuck into” the environment, purchased by a single department that was tired of not getting the computing resources they wanted from their company’s midrange or mainframe. Compared to NetWare, Windows NT was easy to set up and straightforward to operate: it adopted the same graphical user interface that had made Windows so popular on the desktop. It was an easy sell: “add a file or print network as easily as opening up your word processor!”

\n\n

This was a truly critical point in computing history: suddenly, everyone could have a server capable of hosting shared files, providing shared printing services, and other basic tasks. Servers were cheaper, and Windows NT made it easy for almost anyone to set up a network. Network computing had been democratized and commoditized, and almost every business wanted in on it. So the number of servers installed in the world’s companies began to proliferate markedly. Microsoft followed Windows NT, initially versioned 3.1, with Windows NT 3.51, and then Windows NT 4. Dropping the “NT,” they then followed with Windows 2000 Server, and then Windows Server 2003.

\n\n

By 2003, Windows—and the many applications that ran on it—had grown up a lot. It was fully capable of taking on numerous enterprise-class workloads, such as messaging, collaboration, databases, and more. Microsoft—themselves an AS/400 company for much of the company’s history—committed to running their own company on Windows Server, and by the 2003-2005 timeframe had made the jump.

\n\n

Here’s the advantage of moving your computing from giant, multimillion-dollar AS/400 and VAX systems to smaller, “commodity” servers running Windows Server: it’s cheaper. Sure, a single Windows Server might not be able to do messaging and file and print and databases and whatever else, but you could buy three dozen Windows Server machines for far less than the price of a single AS/400. In the late Nineties, as the public Internet and World Wide Web came online and proliferated, people quickly realized that having more, cheaper servers was often better than having one, expensive one. Want to stand up a website that can survive getting mentioned on Oprah? Have that website served up by an entire building full of cheap web servers, each taking a small part of the overall workload. Today’s modern cloud, in the form of Amazon Web Services, Microsoft Azure, Google Cloud, and others, exists entirely around the concept of “lots of cheap computers.”

\n\n

But here’s the downside of all those servers: someone has to manage them all. They need to be configured to work properly, and they need to stay configured. They need periodic security updates and bug patches. Patching one server back in 1994 was no big deal; patching a building containing thousands of servers in 2003 became an entirely different thing.

\n\n

And that’s where Windows Server ran into trouble.

\n\n

Sure, Windows Server was “as easy to run as the desktop you already know and love,” but the ability to click through a “Wizard” to install a patch didn’t scale well. Having to run through the same “Wizard” on ten computers—clicking Next, Next, Next, Next, Finish on each one—might be acceptable, but doing it for a thousand computers? Not so much.

\n\n

Windows started to bog down in the terms of the labor it required, and so computers running Linux started giving Microsoft trouble in enterprise environments.

\n\n

Linux, an open-source operating system that’s largely compatible with Unix, was created mainly in response to the high cost of Unix operating systems. Linux is free to use in most cases, and it runs on the same cheaper, commodity hardware that Windows Server can run on. Linux is a lot harder to administer, though: it favors cryptic commands typed into the computer, versus Windows’ pretty icons and Next-Next-Finish “Wizards.” The upside of Linux, though, is that once you do learn to manage it, it’s almost as easy to manage a hundred computers as it is just one. Instead of typing the commands into each computer yourself, you simply type them into a text file—not unlike a word-processing document—and tell all of your computers to “run” that text file. The text file becomes a script, like you might hand out to actors in Hollywood, with each computer “reading their lines” so that you don’t have to.

\n\n

Microsoft started struggling to close deals in large companies, due in part to the perception that managing large batches of Windows Server machines took more labor than doing the same thing with cheap Linux machines.

\n\n

Microsoft first countered with Visual Basic Script, or VBScript. This “scripting language” was intended to let you manage Windows Server by typing commands into text files, just as Linux could do.

\n\n

But the fundamental architecture of Windows Server wasn’t the same as that of Linux, and it impacted Windows’ ability to have an effective scripting language.

\n\n

Linux, as with Unix before it, is a “text-based operating system.” Everything that tells the server how to behave—its configuration—is basically lines in text files. The operating systems’ means of communicating with other devices is similarly simplistic. Changing a text file is easy: most Linux administrators quickly figured out the small number of tools that enabled them to change text files on hundreds of computers at once, effectively reconfiguring those computers with a single keystroke, if needed. Sure, those tools were cryptic, with incomprehensible names like grep, sed, awk, cat, and more, but you only needed to learn them once. Once you did, the world of Linux administration was open to you. Learn a little, and you could do a lot.

\n\n

Windows, on the other hand, is an “API-based operating system.” Each component inside Windows defines a set of interfaces that you use to tell it what to do. When you click an icon in Windows, one bit of software uses those interfaces to tell another bit of software to do something: open a file, send a message, or whatever. Automating Windows administration, then, is less about changing text files and more about some pretty serious computer programming. These interfaces are (for the most part) documented, but that documentation presumes you’re an experienced software engineer. Sadly, the people hired to manage computer networks tend not to be experienced software engineers. In the Windows world, they were used to clicking icons, not coding programs of a hundred lines or more. VBScript helped a bit, but VBScript couldn’t access all of the APIs needed to make Windows do everything it did. Eventually, someone using VBScript would run into a situation they simply couldn’t handle, leaving them to go back to clicking icons to make stuff happen.

\n\n

Worse, Windows’ various APIs had all been created by developers who never expected anyone but themselves to use those APIs. Some APIs required you to use low-level programming languages like C or C++, while others could use more-accessible, higher-level languages like VBScript. Still others were best used from Microsoft’s .NET Framework, a set of APIs released in the late 1990s to make software development faster and more consistent. But .NET Framework didn’t cover everything a server administrator might need.

\n\n

Lest you think Microsoft had been remiss in their architecture, rest assured that’s not the case. Using APIs to “wall off” different components from each other is not only a standard practice, it’s a recommended practice. APIs let multiple teams of people work on different subsystems, without interference or dependencies on other teams. Team A can do whatever they like with their piece of software, knowing that all they need to do is publish an interface through which other teams could access whatever was needed. It’s a bit like the radio in your car: you might not know how a radio works, but you can use the interface provided to change stations and adjust the volume. The back side of the radio sports another interface that lets the car supply power, antenna signals, and so on to the radio. If you buy a Ford truck, you’re welcome to swap out the Ford radio for a Pioneer one, provided the Pioneer can support the same interface that your truck expects of a radio.

\n\n

A problem with interfaces, though, is that they can only give you the things their developer anticipated you needing. If your truck radio has no interface for taking a satellite radio signal, then there’s nothing you can do about that. And that’s where Windows administrators often found themselves often: if the developers of some Windows subsystem hadn’t anticipated an administrator needing to do something, then the subsystem’s interfaces wouldn’t make it possible, and the administrator was out of luck.

\n\n

And here’s another problem Windows had: many of the teams who built Windows’ various components assumed nobody would ever do anything other than click the pretty icons they’d created. For those components, it was essentially impossible to automate their administration, because they simply had no interfaces through which to do so. It was, frankly, a bit of a mess, and it caused no end of frustration to Windows administrators who were managing a rapidly growing number of servers in their environments. This wasn’t necessarily a bad decision on the part of those teams, because the whole point of Windows was its graphical user interface. For many of them, suggesting that people might need to administer using something other than icons and “Wizards” approached heresy. Teams were required to deliver a comprehensive and easy-to-use graphical user interface; anything else was often optional in terms of Microsoft’s architecture standards, and optional things tend to fall by the wayside when resources get tight and timelines get short.

\n\n

Linux, to be clear, also technically relies on APIs. It’s just that nearly every piece of Linux adopted “put stuff in text files” as their interface. If you want to reconfigure a piece of Windows—say, you need to add a user account to the company directory—you have to hope the directory subsystem’s APIs offer a way to do that, and then you have to learn what data structure to pass them to make them do it. With Linux, you often just add a line to a text file. Notably, many recent Microsoft products have shifted to this text-based approach. With Microsoft Azure, for example, a specially formatted text file can be used to make Azure do almost anything.

\n\n

But in the early- to mid-2000s, complex APIs still ruled Windows Server. It seemed like all the bits were there to automate most Windows administration, but they were scattered over a half-dozen largely difficult and sometimes-incompatible languages and technologies. It’s like going into an auto shop and realizing you need a set of metric sockets for the frame of the vehicle, Imperial sockets for the body, a torch welder for the roof, and a magic wand for the engine. If you can master all of the different tools, maybe you’re fine, but it’s a lot to wrap your head around.

\n\n

Now, this problem would have been solvable: you just need your Windows server administrators to be really broad in the terms of the technologies they can support, and really fast at learning new things. Basically, if your admins are capable of being ersatz developers, you’re fine. Except that wasn’t the sales pitch Microsoft had been making for a decade: “Administer your network as easily as you use your own desktop!” had been the message, not “learn four programming languages and spend all your time writing code!” The bulk of Microsoft’s administrator audience wasn’t up to speed on software programming, and in a lot of cases they weren’t interested in learning languages like C#, C++. VBScript, or whatever else. Again, it’s as if Microsoft had attracted a large audience of competent, intelligent, hardworking automotive mechanics, and then carried a nuclear reactor into the shop and said, “you can do this too, right?” The audience was used to a certain level of consistency and abstraction that a graphical user interface affords, and they simply hadn’t been prepared to have Windows’ underlying inconsistencies and ugliness dumped in their laps.

\n\n

Understand, too, than in 2003, Windows administrators tended to be paid markedly less than a software developer with equivalent seniority, and in many cases less than a similarly situated Linux or Unix administrator. The assumption that “managing Windows is easy!” was baked in their their salaries, and the idea of suddenly being asked to take on a very different kind of role, without necessarily being paid more, didn’t sit well.

\n\n

This is the world that PowerShell (originally Windows PowerShell) was born into: Windows Server struggling to compete with Linux in large-scale companies, due in main part to the relative difficulty in automating Windows administration at scale. Under the hood, Windows was a hodgepodge of different interconnected systems, each one optimized for whatever its task was, and each one difficult to automate without knowing a half-dozen or more different technologies and approaches.

\n\n

Thing is, Microsoft had known this was a problem for quite a while, and their initial solution wasn’t even aimed at Windows administrators.

\n\n\n

\nIllustrating 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.

\n\n

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.

\n\n

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.

\n\n

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:

\n\n

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.

\n\n

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.

\n\n

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

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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

\n\n\n

\nLet’s Just Copy Unix

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/shell-of-an-idea.

\n\n\n

\nKermit

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/shell-of-an-idea.

\n\n\n\n

\n\n","tocStructure",[138,139,140,141,142,143,144,145,146],{"_76":77,"_43":78,"_70":-5,"_79":80,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":86,"_70":-5,"_79":87,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":92,"_70":-5,"_79":93,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":95,"_70":-5,"_79":96,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":99,"_70":-5,"_79":100,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":103,"_70":-5,"_79":104,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":107,"_70":-5,"_79":108,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":111,"_70":-5,"_79":112,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":115,"_70":-5,"_79":116,"_72":81,"_88":-5,"_89":-5,"_90":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\nForeword

Table of Contents

\nA Special Note

\nRespect the Author’s Rights

\nUpdates

\nForeword

\nIntroduction

\nA Shell of a Problem

\nIllustrating the Problem

\nLet’s Just Copy Unix

\nKermit