PowerShell
PowerShell is a task automation and configuration management program from Microsoft, consisting of a command-line shell and the associated scripting language. Initially a Windows component only, known as Windows PowerShell, it was made open-source and cross-platform on 18 August 2016 with the introduction of PowerShell Core. The former is built on the .NET Framework, the latter on .NET Core. In PowerShell, administrative tasks are generally performed via "cmdlets" (pronounced "command-lets"), which are specialized .NET classes implementing a particular operation. These work by accessing data in different data stores, like the file system or Windows Registry , which are made available to PowerShell via "providers". Third-party developers can add cmdlets and providers to PowerShell. Cmdlets may be used by scripts, which may in turn be packaged into modules. Cmdlets work in tandem with the .NET API. PowerShell's support for .NET Remoting, WS-Management, CIM, and SSH enables administrators to perform administrative tasks on both local and remote Windows systems. PowerShell also provides a hosting API with which the PowerShell runtime can be embedded inside other applications. These applications can then use PowerShell functionality to implement certain operations, including those exposed via the graphical interface. This  capability has been used by Microsoft Exchange Server 2007 to expose its management functionality as PowerShell cmdlets and providers and implement the graphical management tools as PowerShell hosts which invoke the necessary cmdlets. Other Microsoft applications including Microsoft SQL Server 2008 also expose their management interface via PowerShell cmdlets. PowerShell includes its own extensive, console-based help (similar to man pages in Unix shells) accessible via the codice_1 cmdlet. Updated local help contents can be retrieved from the Internet via the codice_2 cmdlet. Alternatively, help from the web can be acquired on a case-by-case basis via the codice_3  switch to codice_1. Background. Background. The command-line interpreter (CLI) has been an inseparable part of most Microsoft operating systems. MS-DOS and Xenix relied almost exclusively on CLI. (MS-DOS 5 came with a complementary DOS Shell.) The Windows 9x family came bundled with codice_5, the command-line environment of MS-DOS. The Windows NT and Windows CE families, however, came with a new codice_6 that bore strong similarities to COMMAND.COM. Both environments support a few basic internal commands and a primitive scripting language (batch files), which can be used to automate various tasks. However, they cannot automate  all facets of Windows graphical user interface (GUI) because command-line equivalents of operations are limited and the scripting language is elementary. Microsoft attempted to address some of these shortcomings by introducing the Windows Script Host in 1998 with Windows 98, and its command-line based host, codice_7. It integrates with the Active Script engine and allows scripts to be written in compatible languages, such as JScript and VBScript, leveraging the APIs exposed by applications via the component object model (COM). However, it has its own deficiencies: its documentation is not very accessible, and it quickly gained a reputation as  a system vulnerability vector after several high-profile computer viruses exploited weaknesses in its security provisions. Different versions of Windows provided various special-purpose command-line interpreters (such as netsh and WMIC) with their own command sets but they were not interoperable. Windows Server 2003 further attempted to improve the command line experience but scripting support was still unsatisfactory. Kermit. By the late 1990s, Intel had come to Microsoft asking for help in making Windows, which ran on Intel CPUs, a more appropriate platform to support the development of future Intel CPUs. At the time, Intel CPU development was accomplished  on Sun Microsystems computers which ran Solaris (a Unix variant) on RISC-architecture CPUs. The ability to run Intel's many KornShell automation scripts on Windows was identified as a key capability. Internally, Microsoft began an effort to create a Windows port of Korn Shell, which was code-named Kermit. Intel ultimately pivoted to a Linux-based development platform that could run on Intel CPUs, rendering the Kermit project redundant. However, with a fully funded team, Microsoft program manager Jeffrey Snover realized there was an opportunity to create a more general-purpose solution to Microsoft's problem of administrative automation . Monad. By 2002, Microsoft had started to develop a new approach to command-line management, including a CLI called Monad (also known as Microsoft Shell or MSH). The ideas behind it were published in August 2002 in a white paper called the "Monad Manifesto" by its chief architect, Jeffrey Snover. In a 2017 interview, Snover explains the genesis of PowerShell, saying that he had been trying to make Unix tools available on Windows, which didn't work due to "core architectural difference[s] between Windows and Linux". Specifically, he noted that Linux considers everything an ASCII text file, whereas Windows considers  everything an "API that returns structured data". They were fundamentally incompatible, which led him to take a different approach. Monad was to be a new extensible CLI with a fresh design capable of automating a range of core administrative tasks. Microsoft first demonstrated Monad publicly at the Professional Development Conference in Los Angeles in October 2003. A few months later, they opened up private beta, which eventually led to a public beta. Microsoft published the first Monad public beta release on 17 June 2005 and the Beta 2 on 11 September 2005, and Beta 3 on 10 January 2006. PowerShell . On 25 April 2006, not long after the initial Monad announcement, Microsoft announced that Monad had been renamed Windows PowerShell, positioning it as a significant part of its management technology offerings. Release Candidate (RC) 1 of PowerShell was released at the same time. A significant aspect of both the name change and the RC was that this was now a component of Windows, rather than a mere add-on. Release Candidate 2 of PowerShell version 1 was released on 26 September 2006, with final release to the web on 14 November 2006. PowerShell for earlier versions of Windows was released  on 30 January 2007. PowerShell v2.0 development began before PowerShell v1.0 shipped. During the development, Microsoft shipped three community technology previews (CTP). Microsoft made these releases available to the public. The last CTP release of Windows PowerShell v2.0 was made available in December 2008. PowerShell v2.0 was completed and released to manufacturing in August 2009, as an integral part of Windows 7 and Windows Server 2008 R2. Versions of PowerShell for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 were released in October 2009 and are available for download for both 32-bit and 64-bit platforms . In an October 2009 issue of "TechNet Magazine", Microsoft called proficiency with PowerShell "the single most important skill a Windows administrator will need in the coming years". Windows 10 shipped a testing framework for PowerShell. On 18 August 2016, Microsoft announced that they had made PowerShell open-source and cross-platform with support for Windows, macOS, CentOS and Ubuntu. The source code was published on GitHub. The move to open source created a second incarnation of PowerShell called "PowerShell Core", which runs on .NET Core. It is distinct from "Windows PowerShell", which runs on the full .NET Framework. Starting with  version 5.1, PowerShell Core is bundled with Windows Server 2016 Nano Server. Design. A key design tactic for PowerShell was to leverage the large number of APIs that already existed in Windows, Windows Management Instrumentation, .NET Framework, and other software. PowerShell cmdlets “wrap around” existing functionality. The intent with this tactic is to provide an administrator-friendly, more-consistent interface between administrators and a wide range of underlying functionality. With PowerShell, an administrator doesn't need to know .NET, WMI, or low-level API coding, and can instead focus on using the cmdlets exposed by PowerShell. In this regard, PowerShell  creates little new functionality, instead focusing on making existing functionality more accessible to a particular audience. Grammar. PowerShell's developers based the core grammar of the tool on that of the POSIX 1003.2 KornShell. However, PowerShell's language was also influenced by PHP, Perl, and many other existing languages. Named Commands. Windows PowerShell can execute four kinds of named commands: If a command is a standalone executable program, PowerShell launches it in a separate process; if it is a cmdlet, it executes in the PowerShell process. PowerShell provides an interactive command-line interface, where the commands can be entered and  their output displayed. The user interface offers customizable tab completion. PowerShell enables the creation of "aliases" for cmdlets, which PowerShell textually translates into invocations of the original commands. PowerShell supports both named and positional parameters for commands. In executing a cmdlet, the job of binding the argument value to the parameter is done by PowerShell itself, but for external executables, arguments are parsed by the external executable independently of PowerShell interpretation. Extended Type System. The PowerShell "Extended Type System" ("ETS") is based on the .NET type system, but with extended semantics (for example, propertySets and third-party extensibility). For example , it enables the creation of different views of objects by exposing only a subset of the data fields, properties, and methods, as well as specifying custom formatting and sorting behavior. These views are mapped to the original object using XML-based configuration files. Cmdlets. Cmdlets are specialized commands in the PowerShell environment that implement specific functions. These are the native commands in the PowerShell stack. Cmdlets follow a "Verb"-"Noun" naming pattern, such as "Get-ChildItem", which makes it self-documenting code. Cmdlets output their results as objects and can also receive objects as input, making them suitable for use as  recipients in a pipeline. If a cmdlet outputs multiple objects, each object in the collection is passed down through the entire pipeline before the next object is processed. Cmdlets are specialized .NET classes, which the PowerShell runtime instantiates and invokes at execution time. Cmdlets derive either from codice_9 or from codice_10, the latter being used when the cmdlet needs to interact with the PowerShell runtime. These base classes specify certain methods – codice_11, codice_12 and codice_13 – which the cmdlet's implementation overrides to provide the functionality. Whenever a cmdlet runs, PowerShell invokes these methods in sequence, with codice_12 being called if  it receives pipeline input. If a collection of objects is piped, the method is invoked for each object in the collection. The class implementing the cmdlet must have one .NET attribute – codice_15 – which specifies the verb and the noun that make up the name of the cmdlet. Common verbs are provided as an enum. If a cmdlet receives either pipeline input or command-line parameter input, there must be a corresponding property in the class, with a mutator implementation. PowerShell invokes the mutator with the parameter value or pipeline input, which is saved by the mutator implementation in class variables . These values are then referred to by the methods which implement the functionality. Properties that map to command-line parameters are marked by codice_16 and are set before the call to codice_11. Those which map to pipeline input are also flanked by codice_16, but with the codice_19 attribute parameter set. The implementation of these cmdlet classes can refer to any .NET API and may be in any .NET language. In addition, PowerShell makes certain APIs available, such as codice_20, which is used to access PowerShell-specific functionality, such as writing resultant objects to the pipeline. Cmdlets can use .NET data  access APIs directly or use the PowerShell infrastructure of PowerShell "Providers", which make data stores addressable using unique paths. Data stores are exposed using drive letters, and hierarchies within them, addressed as directories. Windows PowerShell ships with providers for the file system, registry, the certificate store, as well as the namespaces for command aliases, variables, and functions. Windows PowerShell also includes various cmdlets for managing various Windows systems, including the file system, or using Windows Management Instrumentation to control Windows components. Other applications can register cmdlets with PowerShell, thus allowing it to manage them, and, if they enclose any datastore  (such as a database), they can add specific providers as well. The number of cmdlets included in the base PowerShell install has generally increased with each version: Cmdlets can be added into the shell through snap-ins (deprecated in v2) and modules; users are not limited to the cmdlets included in the base PowerShell installation. Pipeline. PowerShell implements the concept of a "pipeline", which enables piping the output of one cmdlet to another cmdlet as input. For example, the output of the codice_21 cmdlet could be piped to the codice_22 to filter any process that has less than 1 MB  of paged memory, and then to the codice_23 cmdlet (e.g., to sort the objects by handle count), and then finally to the codice_24 cmdlet to select just the first ten processes based on handle count. As with Unix pipelines, PowerShell pipelines can construct complex commands, using the codice_25 operator to connect stages. However, the PowerShell pipeline differs from Unix pipelines in that stages execute "within" the PowerShell runtime rather than as a set of processes coordinated by the operating system. Additionally, structured .NET objects, rather than byte streams, are passed from one stage to the next. Using objects and executing  stages within the PowerShell runtime eliminates the need to serialize data structures, or to extract them by explicitly parsing text output. An object can also encapsulate certain functions that work on the contained data, which become available to the recipient command for use. For the last cmdlet in a pipeline, PowerShell automatically pipes its output object to the codice_26 cmdlet, which transforms the objects into a stream of format objects and then renders those to the screen. Because all PowerShell objects are .NET objects, they share a codice_27 method, which retrieves the text representation of the data in an object . In addition, PowerShell allows formatting definitions to be specified, so the text representation of objects can be customized by choosing which data elements to display, and in what manner. However, in order to maintain backward compatibility, if an external executable is used in a pipeline, it receives a text stream representing the object, instead of directly integrating with the PowerShell type system. Scripting. Windows PowerShell includes a dynamically typed scripting language which can implement complex operations using cmdlets imperatively. The scripting language supports variables, functions, branching (codice_28), loops (codice_29, codice_30, codice_31, and codice_32), structured error/exception handling and closures/lambda  expressions, as well as integration with .NET. Variables in PowerShell scripts are prefixed with codice_33. Variables can be assigned any value, including the output of cmdlets. Strings can be enclosed either in single quotes or in double quotes: when using double quotes, variables will be expanded even if they are inside the quotation marks. Enclosing the path to a file in braces preceded by a dollar sign (as in codice_34) creates a reference to the contents of the file. If it is used as an L-value, anything assigned to it will be written to the file. When used as  an R-value, the contents of the file will be read. If an object is assigned, it is serialized before being stored. Object members can be accessed using codice_35 notation, as in C# syntax. PowerShell provides special variables, such as codice_36, which is an array of all the command line arguments passed to a function from the command line, and codice_37, which refers to the current object in the pipeline. PowerShell also provides arrays and associative arrays. The PowerShell scripting language also evaluates arithmetic expressions entered on the command line immediately, and it parses common abbreviations, such as GB, MB , and KB. Using the codice_38 keyword, PowerShell provides for the creation of functions. A simple function has the following general look: function name ([Type]$Param1, [Type]$Param2) However, PowerShell allows for advanced functions that support named parameters, positional parameters, switch parameters and dynamic parameters. function Verb-Noun The defined function is invoked in either of the following forms: name value1 value2 Verb-Noun -Param1 value1 -Param2 value2 PowerShell allows any static .NET methods to be called by providing their namespaces enclosed in brackets (codice_39), and then using a pair of colons (codice_40) to indicate the static method. For example: [Console]::WriteLine("PowerShell") There are  dozens of ways to create objects in PowerShell. Once created, one can access the properties and instance methods of an object using the codice_35 notation. PowerShell accepts strings, both raw and escaped. A string enclosed between single quotation marks is a raw string while a string enclosed between double quotation marks is an escaped string. PowerShell treats straight and curly quotes as equivalent. The following list of special characters is supported by PowerShell: For error handling, PowerShell provides a .NET-based exception-handling mechanism. In case of errors, objects containing information about the error (codice_42 object) are thrown, which are  caught using the codice_43 construct (although a codice_44 construct is supported as well). PowerShell can be configured to silently resume execution, without actually throwing the exception; this can be done either on a single command, a single session or perpetually. Scripts written using PowerShell can be made to persist across sessions in either a codice_8 file or a codice_46 file (the latter is used to implement a module). Later, either the entire script or individual functions in the script can be used. Scripts and functions operate analogously with cmdlets, in that they can be used as commands in pipelines, and  parameters can be bound to them. Pipeline objects can be passed between functions, scripts, and cmdlets seamlessly. To prevent unintentional running of scripts, script execution is disabled by default and must be enabled explicitly. Enabling of scripts can be performed either at system, user or session level. PowerShell scripts can be signed to verify their integrity, and are subject to Code Access Security. The PowerShell scripting language supports binary prefix notation similar to the scientific notation supported by many programming languages in the C-family. Hosting. One can also use PowerShell embedded in a management application, which uses the PowerShell  runtime to implement the management functionality. For this, PowerShell provides a managed hosting API. Via the APIs, the application can instantiate a "runspace" (one instantiation of the PowerShell runtime), which runs in the application's process and is exposed as a codice_47 object. The state of the runspace is encased in a codice_48 object. When the runspace is created, the Windows PowerShell runtime initializes the instantiation, including initializing the providers and enumerating the cmdlets, and updates the codice_48 object accordingly. The Runspace then must be opened for either synchronous processing or asynchronous processing. After that it can be used to  execute commands. To execute a command, a pipeline (represented by a codice_50 object) must be created and associated with the runspace. The pipeline object is then populated with the cmdlets that make up the pipeline. For sequential operations (as in a PowerShell script), a Pipeline object is created for each statement and nested inside another Pipeline object. When a pipeline is created, Windows PowerShell invokes the pipeline processor, which resolves the cmdlets into their respective assemblies (the "command processor") and adds a reference to them to the pipeline, and associates them with codice_51, codice_52 and codice_53 objects, to represent the  connection with the pipeline. The types are verified and parameters bound using reflection. Once the pipeline is set up, the host calls the codice_54 method to run the commands, or its asynchronous equivalent, codice_55. If the pipeline has the codice_56 cmdlet at the end of the pipeline, it writes the result onto the console screen. If not, the results are handed over to the host, which might either apply further processing or display the output itself. Microsoft Exchange Server 2007 uses the hosting APIs to provide its management GUI. Each operation exposed in the GUI is mapped to a sequence  of PowerShell commands (or pipelines). The host creates the pipeline and executes them. In fact, the interactive PowerShell console itself is a PowerShell host, which interprets the scripts entered at command line and creates the necessary codice_50 objects and invokes them. Desired State Configuration. DSC allows for declaratively specifying how a software environment should be configured. Upon running a "configuration", DSC will ensure that the system gets the state described in the configuration. DSC configurations are idempotent. The "Local Configuration Manager" (LCM) periodically polls the system using the control flow described by "resources" (imperative pieces of DSC) to make sure  that the state of a configuration is maintained. Versions. Initially using the code name "Monad", PowerShell was first shown publicly at the Professional Developers Conference in October 2003 in Los Angeles. All major releases are still supported, and each major release has featured backwards compatibility with preceding versions. Windows PowerShell 1.0. PowerShell 1.0 was released in November 2006 for Windows XP SP2, Windows Server 2003 SP1 and Windows Vista. It is an optional component of Windows Server 2008. Windows PowerShell 2.0. PowerShell 2.0 is integrated with Windows 7 and Windows Server 2008 R2 and is released for Windows XP with  Service Pack 3, Windows Server 2003 with Service Pack 2, and Windows Vista with Service Pack 1. PowerShell v2 includes changes to the scripting language and hosting API, in addition to including more than 240 new cmdlets. New features of PowerShell 2.0 include: Windows PowerShell 3.0. PowerShell 3.0 is integrated with Windows 8 and with Windows Server 2012. Microsoft has also made PowerShell 3.0 available for Windows 7 with Service Pack 1, for Windows Server 2008 with Service Pack 1, and for Windows Server 2008 R2 with Service Pack 1. PowerShell 3.0 is part of a larger package, Windows Management  Framework 3.0 (WMF3), which also contains the WinRM service to support remoting. Microsoft made several Community Technology Preview releases of WMF3. An early community technology preview 2 (CTP 2) version of Windows Management Framework 3.0 was released on 2 December 2011. Windows Management Framework 3.0 was released for general availability in December 2012 and is included with Windows 8 and Windows Server 2012 by default. New features in PowerShell 3.0 include: Windows PowerShell 4.0. PowerShell 4.0 is integrated with Windows 8.1 and with Windows Server 2012 R2. Microsoft has also made PowerShell 4.0 available for Windows 7 SP1, Windows Server  2008 R2 SP1 and Windows Server 2012. New features in PowerShell 4.0 include: Windows PowerShell 5.0. Windows Management Framework (WMF) 5.0 RTM which includes PowerShell 5.0 was re-released to web on 24 February 2016, following an initial release with a severe bug. Key features included: Windows PowerShell 5.1. It was released along with the Windows 10 Anniversary Update on August 2, 2016, and in Windows Server 2016. PackageManagement now supports proxies, PSReadLine now has ViMode support, and two new cmdlets were added: Get-TimeZone and Set-TimeZone. The LocalAccounts module allows for adding/removing local user accounts. A preview  for PowerShell 5.1 was released for Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 on July 16, 2016, and was released on January 19, 2017. PowerShell 5.1 is the first version to come in two editions of "Desktop" and "Core". The "Desktop" edition is the continuation of the traditional Windows PowerShell that runs on the .NET Framework stack. The "Core" edition runs on .NET Core and is bundled with Windows Server 2016 Nano Server. In exchange for smaller footprint, the latter lacks some features such as the cmdlets to manage clipboard  or join a computer to a domain, WMI version 1 cmdlets, Event Log cmdlets and profiles. This was the final version of PowerShell made exclusively for Windows. PowerShell Core 6. PowerShell Core 6.0 was first announced on 18 August 2016, when Microsoft unveiled PowerShell Core and its decision to make the product cross-platform, independent of Windows, free and open source. It achieved general availability on 10 January 2018 for Windows, macOS and Linux. It has its own support lifecycle and adheres to the Microsoft lifecycle policy that is introduced with Windows 10: Only the latest version of PowerShell Core  is supported. Microsoft expects to release one minor version for PowerShell Core 6.0 every six months. The most significant change in this version of PowerShell is the expansion to the other platforms. For Windows administrators, this version of PowerShell did not include any major new features. In an interview with the community on 11 January 2018, the PowerShell team was asked to list the top 10 most exciting things that would happen for a Windows IT professional who would migrate from Windows PowerShell 5.1 to PowerShell Core 6.0; in response, Angel Calvo of Microsoft could only name two: cross-platform  and open-source. According to Microsoft, one of the new features of PowerShell 6.1 is "Compatibility with 1900+ existing cmdlets in Windows 10 and Windows Server 2019." Still, no details of these cmdlets can be found in the full version of the change log. Microsoft later professes that this number was insufficient as PowerShell Core failed to replace Windows PowerShell 5.1 and gain traction on Windows. It was, however, popular on Linux. PowerShell Core 6.2 is focused primarily on performance improvements, bug fixes, and smaller cmdlet and language enhancements that improved developer productivity. PowerShell 7. PowerShell 7 is the  replacement for PowerShell Core 6.x products as well as Windows PowerShell 5.1, which is the last supported Windows PowerShell version. The focus in development was to make PowerShell 7 a viable replacement for Windows PowerShell 5.1, i.e. to have near parity with Windows PowerShell in terms of compatibility with modules that ship with Windows. New features in PowerShell 7 include: PowerShell 7.2. PowerShell 7.2 is the next long-term support version of PowerShell, after version 7.0. It uses .NET 6.0 and features universal installer packages for Linux. On Windows, updates to PowerShell 7.2 and later come via the Microsoft Update  service; this feature has been missing from PowerShell 6.0 through 7.1. Comparison of cmdlets with similar commands. The following table contains a selection of the cmdlets that ship with PowerShell, noting similar commands in other well-known command-line interpreters. Many of these similar commands come out-of-the-box defined as aliases within PowerShell, making it easy for people familiar with other common shells to start working. Notes Alternative implementation. A project named "Pash", a pun on the widely known "bash" Unix shell, has been an open-source and cross-platform reimplementation of PowerShell via the Mono framework. Pash  was created by Igor Moochnick, written in C# and was released under the GNU General Public License. Pash development stalled in 2008, was restarted on GitHub in 2012, and finally ceased in 2016 when PowerShell was officially made open-source and cross-platform.