What is the point of PowerShell?
It handles any task that requires scripting and gives power back to the user, developer, or administrator. Power Shell is a tool that is at a very high level of abstraction, and thus can quickly provide a means of getting a task done by creating a chain of software tools without resorting to writing a compiled application.
PowerShell is an: extensible, open-source, cross-platform object-oriented scripting language that uses .NET.
It can use: COM, WMI, WS-Management and CIM to communicate with, and interact with, any Windows-based process.
It can execute scripts on either a local workstation or remotely.
It is ideal for automating all sorts of processes, and is simple enough to manage your workstation, and yet robust enough to manage SQL Azure.
It will evolve to become the built-in batch processing system in future versions of Windows.
It is important as a configuration management tool and task automation tool, and is versatile enough to be used as a general-purpose programming language.
How did PowerShell come about?
Unix inherited from its mainframe ancestors the use of the batch and its script.
The use of the script allowed UNIX to develop a group of specialized applications that did one job and did it well.
Data could be passed into an application through its standard input, and the results passed to the standard output which meant that data could be streamed like items on a conveyor belt.
It was like building repeatable processes out of Lego like blocks of code.
Scripting did more than encourage piped streams of data. It also encouraged batches and command-line configuration of machines and services. This made it easy to use Unix for servers, because all administration tasks could be scripted.
Scaling up to large groups of servers was smooth since everything was in place to allow it to happen.
Scripting also made the management of servers more precise and error-free. After the script was developed, no further work was needed. The script would do the same thing in the same order with the same result. It made operations work a lot easier.
Think tKorn Shell, with ideas from Bash shell.
Why didn’t Windows have a powerful scripting language like Korn?
Unlike the contemporary UNIX workstations, The first PCs had no pretensions to host server processes. Those were low-specification affordable personal computers and initially conquered the market previously occupied by dedicated word processors, before becoming ubiquitous with the invention of the spreadsheet.
They had the ability to run batches, but this was intended merely to ease the task of installing software. Scripting just seemed old-fashioned or best left to dos.
Microsoft DOS could and did run batches from the command processor, and autoexec.bat is still there in Windows (called AUTOEXEC.NT and located in the %SystemRoot%\system32 directory).
After MSDOS borrowed from the UNIX clone Xenix, this command processor took on some of the features of UNIX shells such as the pipe, but with limited functionality when compared to the UNIX shells.
Microsoft Windows was originally booted from the command processor, and , in later editions, it took over the tasks of the operating system and incorporated the old MSDOS command-line interface tool (shell).
The features of the batch were sufficient to allow it to do a lot of configuration, installation and software maintenance tasks. The system wasn’t encouraged or enhanced after Xenix was abandoned, but remained a powerful tool. Xenix’s replacement, Windows NT or WNT (add a letter to DEC’s VMS to guess its parent.) did not have anything new for the command processor, and inherited MSDOS’s enhanced version from MSDOS 3.3.
This Batch language still exists in the latest versions of Windows, though it is due to be deprecated. It has had quite a few enhancements over the years but essentially what came into MSDOS is still the basis of what is currently shipped. It has a major failing within a Windows environment that it cannot be used to automate all facets of GUI functionality, since this demanded at least COM automation, and some way of representing data other than text.
There have been attempts to replace the DOS batch file technology, including VBS and Windows Script Host (1998), but PowerShell is by far the most effective replacement.
Why did it take so long to get PowerShell?
Maybe because Microsoft under Bill Gates retained the vision that BASIC should remain the core language for Windows scripting and administration …
Basic scripting driving COM automation
Today the office applications still have, underlying BASIC scripting that can be controlled via COM automation. To keep batches consistent with this, the tasks done by batch scripting were to be done by Visual Basic for Applications: VBA. This was supplied with the operating system to drive all automation tasks. Wang’s Office system, similarly, was automated and scripted via Cobol!
Language -driven development and divergence
Over time each office application developed a slightly different incompatible dialect and could not be kept in sync. Visual Basic was inadequate for the task and evolved into vb.net, a somewhat comical dialect of Java. It proved to be unpopular.. VBA was never quite consistent with the Visual Basic used for building applications.
Windows Script Host
Windows Script Host was introduced as an automation and administration tool to provide automation technology, primarily for Visual Basic and JavaScript. it supported several interpretive languages such BASIC, Perl, Ruby, Tcl, JavaScript, Delphi and Python. Initially, it had security loopholes finally solved with digital signing in Windows XP. It is still installed with MS Windows and still provides a number of useful COM interfaces that can be accessed in PowerShell and any other application that can interact with COM.
Windows Script Host was, designed before .NET so it is not able to directly use the .NET library. It also does use WMI, WS-Management and CIM for administration and monitoring. It focused on manage the platform by using very low level abstractions such as complex object models, schema, and APIs. Although it was useful for systems programming it was almost unusable for the typical small, simple and incremental task that is at the heart of administration, which needs very high levels of abstraction.
Microsoft competes in the server market
Microsoft was focused on the desktop market for a long time, so maybe did not realize the scale of the problem to compete in the server market. The GUI-centric Microsoft culture and ecosystem, idea was that all configuration was a point-and-click affair. OK for one or two servers, but not so easy or error free for a server-room.
PowerShell
Due to the determination and persuasive powers of Jeffrey Snover, Microsoft belatedly woke up to the fact that it hadn’t a viable solution for the administration of a number of servers in a medium sized company.
The GUI didn’t scale, and the batch system of the command line, though useful, was stuck in mid-eighties time-warp.
Microsoft had to replace the command line; so it needed all the things it and other interactive shells had, such as aliases, wildcard matching, running groups of commands, conditional running of groups of commands and editing previous commands.
It also had to replace VBA, and to integrate easily with Windows Management Objects.
It had to take over the role of VBA embedded in applications to make automation easier.
Microsoft needed something that looked both backwards and forwards, i.e an industry standard shell backward compatible with the command Line.
PowerShell started with the POSIX standard shell of IEEE Specification 1003.2, the Korn Shell, which is also available in Windows. However, this dealt only with strings, so it had to be altered to also deal with objects so that it could access WMI, WS-Management, CIM and COM. Because it needed so much connectivity and data interchange, it had to be able to use the .NET library to process NET objects and datatypes.
So a new system also needed to understand .NET to utilize the man-years of work of providing a common object model able to describe itself, and that can be manipulated without converting either to or from text. The new scripting system had to be resolutely object-oriented.
So the new PowerShell needed the ability to use any .NET object or value.
PowerShell, was given an intuitive naming convention based on the verb-noun pair, with simple conventions such as ‘Get’ to get an object and a noun describing the object.
To replace the command line Powershell had to be better. The whole point of a command shell is that it must be convenient to type short commands into it e.g. like ‘REPL’ in Python. Powershell also needs to work with existing terse DOS command-line commands so that an expert can type in very truncated commands.
PowerShell was also to be used in scripts stored on disk and repeatedly invoked, with just a change in parameters. This also meant that it had to be easy to read, with intuitive commands and obvious program flow.
It wasn’t an easy compromise, but it was done by means of aliases. Aliases also helped to ‘transition’ users from the other shells they were using to PowerShell (For CMD.EXE it is dir, type, copy etc, for UNIX ls, cat, cp etc.) You can even define your own in Power Shall!
Powershell took an idea from.NET everything should be learnable by discovery, without needing documentation. All the objects and Cmdlets in Powershell are self-documenting in that you can use PowerShell to find out what they do, what functions can be called, and parameters.
Why is the PowerShell Pipeline Important?
The pipeline in PowerShell inherited the concept of a pipe from UNIX. The PowerShell team had to solve the problem of dealing with Windows Management Objects and Instrumentation by passing objects rather than text down the pipe.
Having done so, it found itself in possession of a radical and extraordinarily useful system. It had the means of processing objects as though they were on a conveyor belt, with the means of selecting and manipulating each one as it passed down the pipeline.
This made the code easier to understand and also helped with memory management. A long file could be passed down a pipeline, line-by line, for example, searching for text, instead of having to read the entire file into memory (you can do that too if you want, and if you have no fear of the large object stack; you have to do it if you want, for example, to order the lines). . It also meant you needed only one cmdlets for selecting things, one for sorting, one for grouping , and only one for listing things out in a table. PowerShell could do a lot in a line of code, far, far, more than C# could.
Suddenly, the task of tackling the huge range of data on the average server that one might need to know about was less frightening. It was already there, and was now easy to get at and filter.
Why is PowerShell useful?
Scripts don’t require special components.
PowerShell now has all the power of a compiled .NET language. Automating processes using the windows command line needed many existing command files to determine settings and to configure. This meant that, the developer often had to write components in a compiled language. In developing scripts, part of the time was spent making small commands. This isn’t necessary in PowerShell thanks to .NET.
PowerShell simplifies the management of hierarchical data stores. Through its provider model, PowerShell lets you manage data stores such as the registry, or a group of SQL Servers using the same techniques of specifying and navigating paths that you already use to manage files and folders.
This doesn’t turn PowerShell into a rival to C#, VB-Net, ActionScript or F#.
It is not for developing applications but for automating administrative tasks.
It is theoretically possible to write a webserver in PowerShell, or an interactive GUI using Windows Presentation Foundation but that is not its purpose.
What is PowerShell’s main use?
Traditionally, the command line was used for complex deployments. BPowerShell can work remotely on any computer in the domain, and give far more information about the computer. It quickly became the default means of deployment for Windows.
This is great for the developer. He develops his package in NuGet and can use Chocolatey to deploy it. Linux allows you to install a package with just one simple command. Chocolatey does the same, but also allows you to update and uninstall the package just as easily. A simple script can grab the latest source from Git, compile it, install it and any dependencies, and do any special configuration tasks. There are 4,511 packages you can install from the Chocolatey site. PowerShell now has its own package manager but the current incarnation isn’t as versatile as Chocolatey.
Server Administration.
The release of PowerShell was most welcomed by the server teams.
The Microsoft Exchange Server team were early adopters and used PowerShell to allow the administration of Exchange.
The Microsoft SQL Server team, and Active Directory team also followed suit.
These teams provided specialized Applets that covered all aspects of the administration of the server.
Windows Server now has the capabilities of using Hyper-V to provide a ‘private cloud’ which allows companies to allow a degree of ‘self-service’ for server resources – all driven and maintained by PowerShell
Provisioning.
Provisioning is one of the areas where PowerShell excels.
PowerShell’s DSC package allows a PowerShell script to specify the configuration of the machine being provisioned, using a declarative model in a simple standard way that is easy to maintain and to understand.
It can either ‘push’ the configuration to the machine being provisioned, or get the machine to ‘pull’ the configuration.
Chocolatey, a PowerShell script, can not only install a large range of software, but also update it or remove it.
PowerShell has a built-in system called ‘PackageManagement’ that isn’t so versatile, but which allows you to install packages from a wider variety of sources.
Use PowerShell within an application or website
As well as providing a scripting environment, PowerShell can be embedded into an application by using System.Management,Automation , so that the user of the application can extend it via scripts. You can even do this in ASP.NET
Parallelism and workflow
Although PowerShell is an interpreted dynamic language (using .NET’s DLR) , its performance is enhanced by its ability to run parallel processes and to be able to run asynchronously. It is also designed to be able to run securely on other machines, remotely, and pass data between them. All this is possible without Workflow.
Scripted processes that have complex interdependencies, need to be interruptable and robust, and that is supported by PowerShell workflow.
Workflow can be complicated, and will always be a niche technique for scripting. . it is now able to run complex workflows within a domain thereby making it possible to script even the most difficult of business processes that contain long-running tasks that require persistence and need to survive restarts and interruptions.
PowerShell uses the Windows Workflow Foundation (WF) engine. A PowerShell workflow involves the PowerShell runtime compiling the script into Extensible Application Markup Language (XAML) and submitting this XAML document to the local computer’s Workflow Foundation engine for processing.
PowerShell Workflow scripting is particularly useful in high availability environments for processes such as ETL (data Extraction, Transform and Load), that potentially requiring throttling and connection pooling, and it is ideal where data must come from a number of sources and be load in a certain order.
