Design
PowerShell was designed specifically for systems administration and was designed based on years of experience with both the old command prompt and with the Unix shell. As with most things in Windows, PowerShell was based on the .NET common language runtime (CLR) and framework and can thus manipulate .NET objects rather than just text and text files.
In Unix
An early design criterion was that every command should have one and only one function. Simplicity leads to ease of use and training, less bugs, less security issues, easier maintainability, etc. PowerShell brings a new concept, the cmdlet, which follows the same sort of logic.
We can pipe the output of one command into another and we can do the same in PowerShell using the pipe | symbol.
We can assemble complex lists of commands into scripts, with all the advantages we have previously discussed. A task becomes self-documenting, repeatable and institutionalised by scripting. These scripts then become your own cmdlets.
PowerShell still isn’t the most readable or understandable language in the world. Part of the reason is that objects vary from language to language and part of the task of getting used to any language is learning the common objects which is exposes.
PowerShell is now deeply embedded in Microsoft products and realistically, all Microsoft administrators need to know how to use it now. Whenever you configure modern versions of Windows server, you can extract the PowerShell commands behind the GUI.
All cmdlets have a structure of verb-noun, not case sensitive. A verb means do something like get, read information from the system somewhere. NetIPAddress is a noun, a thing. I can type
get-netipaddress and that is a valid command.
Every cmdlet in PowerShell is organised in modules of related materials. For example, if I’m working on DNS, I will load the DNS module. Not all modules are loaded by default. There are four module types.
Script Modules (.psm1) hold functions
Manifest Modules (.psd1) hold metadata and instructions
Binary Modules are written in C# and compiled into a .dll file
Dynamic Modules are created on demand, in memory
Variables
In PowerShell, variables are represented by text strings prefixed with a dollar sign ($). In coding, we create user defined variables. There are some automatic state variables which PowerShell itself keeps for housekeeping. There are also user preference variables, populated with default values but changeable.
Last updated