.svg)
On November 14, 2006, at a conference keynote in Barcelona, Microsoft announced Windows PowerShell 1.0. Administrators now use this object-based shell and scripting language to automate practically any Microsoft IT ops task. Twenty years later, it's running daily operations in Active Directory, Exchange, Microsoft 365, and Azure. Five design choices explain why.
Who was PowerShell built for?
PowerShell was built for administrators rather than programmers. In 2002, Jeffrey Snover wrote the Monad Manifesto, the design paper that set out what was to become PowerShell. At the time, Windows offered graphical tools for basic tasks and APIs for programmers. What was missing, Snover argued, was "the vital middle": tools that administrators could type, compose, and automate. He called most administrators "para-programmers," people who script as part of the job and have little time for sophisticated programming.
The Manifesto also traced a path that every admin has walked since. You type the same commands again and again, so you write a script, and over time those ad hoc scripts grow into automated operations. That path still holds today. PowerShell gives admins a way to follow it without switching tools at every step.
What did PowerShell get right?
PowerShell got five design choices right, and each one still pays off for admins and for the IT organization around them.
1. Objects instead of text
The Manifesto put the first choice in one sentence: "Instead of piping unstructured text, we pipe .Net objects." The object pipeline made PowerShell scripts composable and reusable beyond their author. Admins skip the text parsing and can optimize PowerShell pipeline with script blocks, because every property travels straight through the pipeline. You gets scripts that the next person can read, combine, and reuse.
2. Verb-Noun names
Every cmdlet carries a Verb-Noun name, such as Get-Mailbox or Restart-Service. Microsoft's PowerShell documentation explains the pair: the verb identifies the action, and the noun identifies the resource. Admins can guess a command they've never used, so they discover commands instead of memorizing them. In IT ops, a script that someone other than its author can read means less dependence on one expert.
3. The shell can do everything the console can
Exchange Server 2007 shipped the Exchange Management Shell, the first Microsoft PowerShell snap-in. According to Microsoft's Exchange Server 2007 documentation, the shell performs every task available in the management console, plus tasks the console can't. Admins learned that anything they could click, they could also script. IT got one automation language across the Microsoft stack.
4. One script, many machines
The Manifesto planned for scale from the start, with scripts that are "remotely executed on many machines." Today, an admin can change a whole fleet of servers from one console. For IT, the same script can apply the same change to every machine it targets.
5. Open source and cross-platform
In 2016, Microsoft made PowerShell open source and available on Linux and macOS. Admins can now use PowerShell 7.6, the current long-term support (LTS) release, on every platform they manage. IT gets skills that move between platforms and a support lifecycle it can plan around.
What does 20 years of PowerShell mean for IT Operations?
PowerShell's success has a price. Scripts now run production work across entire infrastructures. ScriptRunner's State of Microsoft Automation 2026 benchmark surveyed 180 IT managers and senior system engineers at enterprises with 1,000 or more employees. The survey ran from October to December 2025. In it, 63% of respondents said they allow non-developers to contribute to automation with IT support.
Meanwhile, Microsoft keeps moving, and old foundations retire. Microsoft deprecated PowerShell 2.0 in 2017 and, eight years later, published its notice on PowerShell 2.0 removal from Windows. The removal began in August 2025 for Windows 11, version 24H2, and in September 2025 for Windows Server 2025. Microsoft's Entra team announced that the MSOnline module would stop working for all tenants by late May 2025. Support for PowerShell 7.4 just ended on November 10, 2026, four days before PowerShell's twentieth birthday.
Each retirement raises the same question: which scripts depend on this version or module? Answering it takes an inventory of production scripts and their dependencies, along with their owners, permissions, and targets.
Where ScriptRunner fits
ScriptRunner builds on PowerShell instead of replacing it. You import your existing scripts. What changes is the way credentials, targets, and access are managed. Hard-coded credentials need to be removed from the code and replaced with managed credentials.
Scripts sit in a central repository. An Action connects a script with its parameters and targets; the target configuration determines the credentials used to run it. The script's param block becomes an input form, a PowerShell parameter GUI for delegated self-service, with input checks based on supported parameter types and validation attributes.
Your help desk can then run approved Actions without receiving admin rights on the target systems. The execution account still needs the permissions required for the task. Each run produces a log that includes who started it, the target, the parameters, and the result.
Admins keep the power of PowerShell, while IT Operations gains control over how scripts run and who can use them.
Here's to the next twenty
In twenty years, PowerShell grew from an admin tool into the operating layer of Microsoft IT operations. PowerShell is still relevant for enterprise IT in 2026 because the design choices behind it have aged well. Let's celebrate the design and start running scripts like the infrastructure they've become.
To help you celebrate, we've put together a bundle of 5 Powershell Cheat Sheets for all your Microsoft IT automation needs.