PowerShell is the task automation and configuration management framework of Microsoft, which consists of command line shell and related scripting language. Initially only Windows components, known as Windows PowerShell , were created open-source and cross-platform on August 18, 2016 with the introduction of PowerShell Core . The first one is built on. NET Framework while the latter on.NET Core.
In PowerShell, administrative tasks are generally performed by cmdlet (pronounced command-let ), which is a special class of.NET that implements certain operations. It works by accessing data in various data storage, such as file system or registry, which is available for PowerShell through provider . Third-party developers can develop their own cmdlets and add them to PowerShell. A set of cmdlets can be combined into scripts .
PowerShell provides full access to COM and WMI, enabling administrators to perform administrative tasks on local and remote Windows systems as well as WS-Management and CIM enabling the management of remote Linux network systems and devices. PowerShell also provides a hosting API with which the PowerShell runtime can be embedded within other applications. The application can then use the PowerShell function to implement certain operations, including those exposed through the graphical interface. This capability has been used by Microsoft Exchange Server 2007 to expose its management functions as Cmdlets and PowerShell providers and implements a graphics management tool as a PowerShell host that calls the required cmdlets. Other Microsoft applications including Microsoft SQL Server 2008 also expose their management interface through PowerShell cmdlets.
PowerShell includes its own extensive console-based help (similar to the Manual page in the Unix shell) that can be accessed through the Get code Get-Help . Local help content can be retrieved from the Internet via the Update-Help cmdlet. Alternatively, help from the web can be obtained on a case-by-case basis via - online switch to Get-Help .
Video PowerShell
​​â € <â €
Each version of Microsoft Windows for personal computers includes a command line interpreter (CLI) to manage the operating system. Its predecessor, MS-DOS, rely solely on CLI. This is COMMAND.COM in MS-DOS and Windows 9x, and cmd.exe on the Windows NT family operating system. Both support some basic internal commands. For other purposes, console applications are separate. They also include a basic scripting language (batch file), which can be used to automate various tasks. However, they can not be used to automate all aspects of the graphical user interface function (GUI), in part because the equivalent command-line operation is limited, and the scripting language is basic. In Windows Server 2003, the situation is improved, but scripting support is still not satisfactory.
Microsoft attempted to address some of these flaws by introducing Windows Script Host in 1998 with Windows 98, and its command-line host: cscript.exe . It integrates with Active Script engine and allows scripts to be written in compatible languages, such as JScript and VBScript, utilizing APIs exposed by applications via COM. However, it has its own flaws: its documentation is not very accessible, and quickly gained a reputation as a system vulnerability vector after several high-profile computer viruses exploited flaws in its security provisions. Different Windows versions provide various special-purpose command line translators (such as netsh and WMIC) with their own command sets but are not interoperable.
In an interview published Sept. 13, Jeffrey Snover explains the motivation for the project:
I have driven many management changes, and then I initially took the UNIX tool and made it available on Windows, and then it did not work. Right? Because there is a difference between the core architecture of Windows and Linux. In Linux, everything is an ASCII text file, so all that can manipulate it is a management tool. AWK, grep, sed? Fun day!
I bring the tools available in Windows, and then they do not help manage Windows because in Windows, they are all APIs that return structured data. So, that does not help. [...] I came up with this PowerShell idea, and I said, "Hey, we can do this better."
In 2002 Microsoft has begun developing 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 entitled Monad Manifesto. Monad will be a new expandable CLI with new designs that will be able to automate core administration tasks. Microsoft first exhibited Monad at the Professional Development Conference in Los Angeles in October 2003. The private beta program began a few months later which eventually led to a public beta program.
Microsoft published the first public beta release of Monad on June 17, 2005, Beta 2 on September 11, 2005 and Beta 3 on January 10, 2006. Shortly thereafter, on April 25, 2006 Microsoft officially announced that Monad had been renamed i> Windows PowerShell , positioning it as an important part of their technology management offerings. Release Candidate 1 of PowerShell was released at the same time. A significant aspect of name change and RC is that it is now a Windows component, and not an additional product.
Release Candidate 2 from PowerShell version 1 was released on September 26, 2006 with Release to the web (RTW) on November 14, 2006 and announced at TechEd Barcelona. PowerShell for earlier versions of Windows was released on January 30, 2007.
Development of PowerShell v2.0 begins before PowerShell v1.0 is sent. During development, Microsoft sent three community technology previews (CTP). Microsoft makes this release publicly available. The last CTP release of Windows PowerShell v2.0 was 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. PowerShell versions for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 were released in October 2009 and available for download both for 32-bit and 64-bit platforms.
Windows 10 sends a testing framework for PowerShell.
On August 18, 2016, Microsoft announced that it has made PowerShell open-source and cross-platform with support for Windows, macOS, CentOS and Ubuntu. Source code published in GitHub. The switch to open source creates a second incarnation of PowerShell called "PowerShell Core", which runs on.NET Core. This differs from "Windows PowerShell", which runs on the.NET Framework full. Starting with version 5.1, PowerShell Core is bundled with Windows Server 2016 Nano Server.
Maps PowerShell
Design
PowerShell developers based on the core grammar of this tool on POSIX 1003.2.
Windows PowerShell can run four types of commands named:
- cmdlets (.NET Framework program designed to interact with PowerShell)
- PowerShell Script (file specifics by
.ps1) - PowerShell function
- self-executable programs
If the command is a self-executable program, PowerShell launches it in a separate process; if it is a cmdlet, it will be executed in the PowerShell process. PowerShell provides an interactive command line interface, where commands can be entered and the results are displayed. The user interface, based on the Win32 console, offers a customizable tab completion. PowerShell allows the creation of aliases for cmdlets, which literally translates PowerShell into the invocation of the original command. PowerShell supports named parameters and position parameters for commands. In executing cmdlets, the task of binding the argument values ​​to parameters is done by PowerShell itself, but for external executables, arguments are parsed by external executables separately from PowerShell interpretations.
PowerShell Extension Type System ( ETS ) is based on a.NET type system, but with extended semantics (e.g., Setup property and third-party extensibility). For example, it allows the creation of different views of objects by exposing only a subset of the data fields, properties, and methods, as well as defining custom formatting and sorting behavior. This view is mapped to the original object using an XML-based configuration file.
Cmdlets
Cmdlets are special commands in the PowerShell environment that implements certain functions. This is the original command in the PowerShell stack. Cmdlets follow Verbs - Noun naming patterns, such as Get-ChildItem , helping to make it self-descriptive. Cmdlets output their results as objects and can also accept objects as inputs, making them suitable for use as receivers in a pipeline. If a cmdlet produces many objects, each object in the collection is passed through the entire pipeline before the next object is processed.
Cmdlets are special classes. NET, which crumbles PowerShell collapse and calls at run-time. Cmdlets come either from Cmdlet or from PSCmdlet , the latter used when the cmdlet needs to interact with the PowerShell runtime. This base class specifies a particular method - BeginProcessing () , ProcessRecord () and EndProcessing () - which the implementation of this cmdlet overrides to provide functionality. Each time a cmdlet is running, PowerShell calls this method in sequence, with ProcessRecord () called when receiving channel input. If a collection of objects is distributed, this method is invoked for each object in the collection. A class that implements Cmdlets must have one.NET - CmdletAttribute attribute - that specifies the verb and nouns that make up the cmdlet name. Common verbs are provided as an enum.
If the cmdlet receives input either a channel input or a command line input, there must be a corresponding property in the class, with a mutator implementation. PowerShell invokes a solver with parameter values ​​or pipe input, which is stored by mutator implementations in a class variable. These values ​​are then called by methods that implements functionality. Properties that map to the command line parameters are marked by ParameterAttribute and set before the call to BeginProcessing () . Those who map to the pipeline input are also enclosed by ParameterAttribute , but with the set of ValueFromPipeline attributes.
The implementation of this cmdlet class can refer to the.NET API and possibly in any.NET language. In addition, PowerShell creates certain available APIs, such as WriteObject () , which is used to access special PowerShell functions, such as writing the generated object to the pipeline. Cmdlets can use the.NET data access API directly or use PowerShell infrastructure from PowerShell Providers , which makes data stores addressable using unique paths. The data store is exposed using a drive letter, and a hierarchy in it, called a directory. Windows PowerShell sends with providers for file systems, registry, certificate storage, as well as namespaces for command aliases, variables, and functions. Windows PowerShell also includes various cmdlets for managing various Windows systems, including file systems, or using Windows Management Instrumentation to control Windows components. Other apps can register cmdlets with PowerShell, making it possible to manage them, and, if they include datastore (such as databases), they can add certain providers as well.
PowerShell V2 adds a more portable version of Cmdlet called Module. PowerShell V2 release status notes:
"Modules allow scripts and administrators to partition and manage their Windows PowerShell code in reusable units The code of the module is run in standalone context and does not affect the state outside the module The module also allows you to specify a script-limited runspace environment. "
Pipeline
PowerShell implements the concept of pipeline , which allows piping the output of one cmdlet to another as an input cmdlet. For example, the output of the Get-Process cmdlet can be passed to Where-Object to filter any process that has less than 1 MB of paged memory, and then to the Sort-Object cmdlet (for example, to sort objects by handling counts), and finally to Select-Object cmdlet to select only the first 10 (ie, 10 processes based on the handle count).
As with Unix pipelines, PowerShell pipes can build complex commands, using the | operator to connect the stages. However, the PowerShell pipeline differs from the Unix pipes at the stage that runs in the PowerShell runtime rather than as a series of processes coordinated by the operating system, and the.NET structured object, rather than the byte stream, is passed from one stage to the next. Using objects and running stages in the PowerShell runtime eliminates the need to create a concatenated data structure, or to extract it by explicitly decomposing text output. An object can also encapsulate certain functions that work on the contained data, which becomes available to the receiving command for use. For the last cmdlet in a pipe, PowerShell automatically distributes its output object to the Out-Default cmdlet, which converts the object into a stream of object formatting and then renders it to the screen.
Since all PowerShell objects are.NET objects, they share the .ToString () method, which takes a text representation of the data in an object. In addition, PowerShell allows formatting definitions to be specified, so the representation of object text can be adjusted by selecting the data elements to be displayed, and in what way. However, to keep backwards compatibility, if an external executable is used in a pipeline, it accepts a text stream representing an object, rather than directly integrating it with a PowerShell type system.
Scripting
Windows PowerShell includes a dynamically typed scripting language that can implement complex operations using imperative cmdlets. The scripting language supports variables, functions, branches ( if-then-else ), loops ( while , do , for , and foreach ), structured error/exception handling and lambda closure/expression, and integration with.NET. The variables in the PowerShell script begin with $ . Variables can be assigned any value, including cmdlet output. Strings can be attached either in single quotes or in double quotes: when using double quotes, variables will be expanded even if they are inside quotation marks. Attaching a path to a braces file beginning with a dollar sign (as in $ {C: \ foo.txt} ) makes reference to the file contents. If used as L-value, anything assigned to it will be written to the file. When used as a R-value, the contents of the file will be read. If an object is assigned, it is serialized before it is stored.
Members of the object can be accessed using the notation. , as in C # syntax. PowerShell provides custom variables, such as $ args , which is an array of all command-line arguments passed to a function from the command line, and $ _ , which refers to the current object in in a pipe. PowerShell also provides associative arrays and arrays. The PowerShell scripting language also evaluates arithmetic expressions entered on the command line immediately, and parses common abbreviations, such as GB, MB, and KB.
Using the function keyword, PowerShell provides for the creation of a function, the following general form:
The specified function is called in one of the following forms:
PowerShell supports named parameters, position parameters, switch parameters and dynamic parameters.
PowerShell allows each.NET method to be invoked by providing their namespaces which are enclosed in brackets ( [] ), and then using a colon ( :: ) to indicate static method. For example, [System.Console] :: WriteLine ("PowerShell") . The object is created using the New-Object cmdlet. The.NET object call method is performed using the regular notation. .
PowerShell accepts strings, both raw and loose. A closed string between single quotes is a raw string while a closed string between double quotes is a string that passes. PowerShell treats straight and curly quotes as equivalent.
For error handling, PowerShell provides a NET-based exception handling mechanism. In the case of errors, objects containing information about the error ( Exception object) are thrown, caught using try... catch construct (albeit a trap constructs supported too). PowerShell can be configured to secretly resume execution, without actually throwing an exception; this can be done either on one command, one session or continuously.
Scripts written using PowerShell can be created to persist across sessions in either the .ps1 file or the .psm1 file (the last one used to implement the module). Later, either the overall script or individual function in the script can be used. Scripts and functions operate analogously with cmdlets, where they can be used as commands in pipelines, and parameters can be bound to them. The pipeline object can be passed between functions, scripts, and cmdlets seamlessly. To prevent unintentional scripts, script execution is disabled by default and must be explicitly enabled. Enabling scripts can be done either at the system, user, or session level. PowerShell scripts can be signed to verify their integrity, and are subject to Access Code Security.
The PowerShell scripting language supports binary prefix notation similar to scientific notation supported by many programming languages ​​in C-family.
Hosting
One can also use PowerShell embedded in a management application, which uses the PowerShell runtime to implement management functions. For this, PowerShell provides a managed hosting API. Through the API, the app can instantiate runspace (one Instantiation of PowerShell runtime), which runs in the application process and is exposed as a Runspace object. The runspace status is enclosed in the SessionState object. When the runspace is created, the Windows PowerShell runtime initializes instantiation, including initializing the provider and the cmdlet enumeration, and updating the corresponding SessionState object. The Runspace should then be opened for synchronous processing or asynchronous processing. After that it can be used to execute commands.
To run the command, the pipeline (represented by the Pipeline ) object must be created and associated with the runspace. The pipeline object is then filled with the cmdlets that make up the pipeline. For sequential operations (as in PowerShell scripts), Pipeline objects are created for each statement and nested within other Pipeline objects. When a pipe is created, Windows PowerShell will call the channel processor, which completes the cmdlet into its own assembly ( command processor ) and adds a reference to the pipeline, and connects it to InputPipe , < code> Outputpipe and the ErrorOutputPipe object, to represent the connection with the pipeline. The type is verified and the parameters are bound using reflection. Once the pipeline is set, the host invokes the Invoke () method to run the command, or the asynchronous equivalent - InvokeAsync () . If the pipeline has a Write-Host cmdlet at the end of the pipeline, it will write the result to the console screen. Otherwise, the results are left to the host, who may apply the process further or display the output itself.
Microsoft Exchange Server 2007 uses the hosting API to provide its management GUI. Each operation exposed in the GUI is mapped to a command sequence of PowerShell (or pipeline). The host creates a pipeline and executes it. In fact, the interactive PowerShell console itself is a PowerShell host, which interprets scripts entered on the command line and creates the required Pipeline objects and calls them.
Desired State Configuration
DSC allows to declare declaratively how the software environment should be configured.
After running configuration , the DSC will ensure that the system gets the status described in the configuration. DSC configuration is idempotent. The Local Configuration Manager (LCM) periodically polls the system using the control flows described by the resources (DSC imperative pieces) to ensure that configuration states are maintained.
Version
Initially using the code name "Monad", PowerShell was first publicly displayed at the Professional Developer Conference in September 2003. All major releases are still supported, and every major release has featured backward compatibility with previous versions.
PowerShell 1.0
PowerShell 1.0 was released in November 2006 for Windows XP SP2, Windows Server 2003 SP1 and Windows Vista. This is an optional component of Windows Server 2008.
PowerShell 2.0
PowerShell 2.0 integrates with Windows 7 and Windows Server 2008 R2 and 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 scripting languages ​​and hosting APIs, besides including more than 240 cmdlets.
New features of PowerShell 2.0 include:
- PowerShell remoting : Using WS-Management, PowerShell 2.0 allows scripts and cmdlets to be called on remote machines or large numbers of remote machines.
- Work background : Also called PSJob , this allows the order of commands (scripts) or pipes to be called asynchronously. Jobs can be run on a local computer or on multiple remote computers. An interactive cmdlet within PSJob blocks job execution until user input is provided.
- Transactions : Enable cmdlets and developers can perform transactional operations. PowerShell 2.0 includes transaction cmdlets to start, perform, and play back PSTransaction and features to manage and redirect transactions to participating participating cmdlets and operators. The PowerShell Registry provider supports transactions.
- Advanced functions : These are cmdlets written using the PowerShell scripting language. Originally called "script cmdlets", this feature was later renamed "advanced function".
- SteppablePipelines : This allows users to control when
BeginProcessing (),ProcessRecord ()andEndProcessing ()called cmdlet function. - Modules : This allows script and administrator developers to organize and repartition PowerShell scripts in reusable units. The code of the module executes in its own context and does not affect the state outside the module. The module can define a restricted runspace environment using a script. They have a persistent state as well as public and private members.
- Data languages ​​: A domain-specific subset of the PowerShell scripting language that allows data definitions to be separated from scripts and enables localized string resources to import into scripts at runtime ( Internationalization of the manuscript ).
- Debugging script : This allows breakpoints to be set in a script or PowerShell function. Breakpoint can be set on line, line & amp; column, command and read access or write variables. This includes a set of cmdlets to control the breakpoints through the script.
- Eventing : This feature allows listening, forwarding, and acting on management and system events. Eventing allows PowerShell hosts to be notified of status changes to managed entities. It also allows PowerShell scripts to subscribe to ObjectEvents , PSEvents , and WmiEvents and process them simultaneously and asynchronously.
- Windows PowerShell Integrated Scripting Environment (ISE) : PowerShell 2.0 includes a GUI-based PowerShell host that provides integrated debugger, syntax highlighting, tab completion, and up to 8 PowerShell Unicode (Runspaces) powered consoles on the UI tab , as well as the ability to run only selected sections in the script.
- Network file transfers : Original support for prioritized, strangled, and asynchronous file transfers between machines using Background Intelligent Transfer Service (BITS).
- New Cmdlet : Include
Out-GridView, which displays table data in WPF GridView objects, on possible systems, and if ISE is installed and enabled. - New operator operators:
-Split,-Join, and Splatting (@). - Handling exceptions with Try-Catch-Finally : Unlike other.NET languages, this allows multiple exception types to one capture block.
- Nest Here-Strings : PowerShell Here-Strings has been upgraded and now can be nested.
- Block comments : PowerShell 2.0 supports blocking comments using
& lt; #and# & gt;as a delimiter. - New APIs : The new API range from assigning more control over the PowerShell parser and processing time to the host, to create and manage Runspace collections ( RunspacePools ) as well as the ability to create Restricted Runspace that only allows a subset of PowerShell that is configured to be called. The new API also supports participation in managed transactions of Windows PowerShell.
PowerShell 3.0
PowerShell 3.0 integrates with Windows 8 and with Windows Server 2012. Microsoft has also created 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 WinRM services to support remoting. Microsoft made several launches of Community Technology Preview from WMF3. The initial community technology version 2 (CTP 2) from Windows Management Framework 3.0 was released on December 2, 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:
- Scheduled jobs : Jobs can be scheduled to run at a predetermined time and date.
- Session connectivity : Sessions can be disconnected and reconnected. Long-distance sessions become more tolerant of temporary network failures.
- Enhanced code writing : Code completion (IntelliSense) and snippet added. PowerShell ISE allows users to use a dialog box to populate parameters for PowerShell cmdlets.
- Delegate support : Administrative tasks can be delegated to users who do not have permissions for these types of tasks, without giving them additional, lasting permissions.
- Help update : Help documentation can be updated via the Update-Help command.
- Automatic module detection : The module is loaded implicitly each time a command from that module is called. Code completion works for modules that are not loading as well.
- New commands : Dozens of new modules added, including the functionality to manage the disk
get-WmiObject win32_logicaldisk, volume, firewall, network connection and printer management, previously done via WMI.
PowerShell 4.0
PowerShell 4.0 integrates 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:
- Preferred Country Configuration : Declarative language extensions and tools that allow the deployment and management of configuration data for systems that use DMTF and WS-Management Protocol management standards
- New default execution policy : On Windows Server, the default execution policy is now Abandoned by RemoteSigned.
- Save-Help : Help can now be saved for modules installed on the remote computer.
- Debug enhancement : The debugger now supports debugging workflows, remote script execution, and maintains debugging sessions throughout PowerShell session reconnection.
- -PipelineVariable switches : New parameters everywhere to expose current pipeline objects as variables for programming purposes
- Network Diagnostics to manage virtual network switches and physical Hyper-V
- Where and forEach syntax methods provide an alternative method for filtering and repeating objects.
PowerShell 5.0
The Windows Management Framework (WMF) 5.0 RTM that includes PowerShell 5.0 was re-released to the web on February 24, 2016, after an initial release with a severe bug. Key features include OneGet PowerShell cmdlets to support Chocolate repository-based package management and expand support for switch management to layer 2 network switches.
New features in PowerShell 5.0 include:
- PowerShell class definition (property, method)
- PowerShell. NET Enumeration
- Debugging for PowerShell Runspaces in the remote process
- Debugging for a PowerShell Background Job
- Configuration of Desired Status (DSC) Local Configuration Manager (LCM) version 2.0
- DSC partial configuration
- DSC Configuration of Local Manager meta-configuration
- Generate DSC resources using the PowerShell class
PowerShell 5.1
It was released in conjunction with Windows 10 Anniversary Update on 2 August 2016, and on Windows Server 2016. PackageManagement now supports proxies, PSReadLine now has ViMode support, and two new cmdlets added: Get-TimeZone and Set-TimeZone. The LocalAccounts module allows to add/delete local user accounts. Preview PowerShell 5.1 was released for Windows Vista, 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 that comes in two editions of "Desktop" and "Core". The "Desktop" edition is a continuation of the traditional Windows PowerShell running full. NET Framework stack. The "Core" edition runs on. NET Core and bundled with Windows Server 2016 Nano Server. Instead of smaller footprints, the latter does not have some features like cmdlets for managing clipboards or joining a computer to a domain, WMI version 1 cmdlet, cmdlet and Event Log profiles.
PowerShell Core 6.0
PowerShell Core 6.0 was first announced on August 18, 2016, when Microsoft launched PowerShell Core and its decision to create a cross-platform product, independent of Windows, free and open source. It reached general availability on January 10, 2018 for Windows, macOS and Linux. It has its own support life cycle and adheres to the Microsoft life cycle policy introduced with Windows 10: Only the latest versions of PowerShell Core are 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 expansion to other platforms. For Windows administrators, this version of PowerShell does not have great new features. In an interview with the community on January 11, 2018, the PowerShell team was asked to list the 10 most interesting things that would happen to a Windows IT professional who would migrate from Windows PowerShell 5.1 to PowerShell Core 6.0; in response, Angel Calvo from Microsoft can only mention two: cross-platform and open-source.
Comparison of cmdlets with similar commands
The following table contains a selection of cmdlets that are shipped with PowerShell, which records similar commands in other well-known command line interpreters. Many of these similar commands come out of the box defined as aliases in PowerShell, making it easy for people familiar with other common shell to start working.
Note
File extension
- PS1Ã, - Windows PowerShell shell scripts
- PSD1Ã, - Windows PowerShell data files (for Version 2)
- PSM1Ã, - Windows PowerShell module files (for Version 2)
- PS1XMLÃ, - Windows PowerShell format and type definitions
- CLIXMLÃ, - Windows PowerShell serialization data
- PSC1Ã, - Windows PowerShell console files
- PSSCÃ, - Windows PowerShell Session Configuration file
App support
Snap-in and host
Alternative implementations
Source of the article : Wikipedia
0 Comments