Getting Started with Windows PowerShell

Windows PowerShell is a new command-line shell designed especially for system administrators. Windows PowerShell includes an interactive prompt and a scripting environment that can be used independently or in combination.

Unlike most command-line shells, which accept and return text, Windows PowerShell is built on top of the .NET Framework common language runtime (CLR) and the .NET Framework, and accepts and returns .NET Framework objects. This fundamental change in the environment brings entirely new tools and methods to the management and configuration of Windows.

Like many shells, Windows PowerShell gives you access to the file system on the computer. In addition, Windows PowerShell Providers enable you to access other data stores, such as the registry and the digital signature certificate stores, as easily as you access the file system.

Windows PowerShell Cmdlets

A cmdlet (pronounced as “command-let”) is a single-feature command that manipulates objects in Windows PowerShell. You can recognize cmdlets by their name format which is verb and noun separated by a dash (-), such as Get-HelpGet-Process, and Start-Service.

In traditional shells, the commands are executable programs that range from the very simple (such as ren.exe) to the very complex (such as netsh.exe).

In Windows PowerShell, most cmdlets are very simple, and they are designed to be used in combination with other cmdlets. For example, the “get” cmdlets only retrieve data, the “set” cmdlets only change data, the “format” cmdlets only format data, and the “out” cmdlets only direct the output to a specified destination.

Each cmdlet has a help file that you can access by typing:

get-help <cmdlet-name> -detailed

The detailed view of the cmdlet help file includes a description of the cmdlet, the command syntax, descriptions of the parameters, and an example that demonstrate use of the cmdlet.

Windows Commands and Utilities

You can run Windows command-line programs in Windows PowerShell, and you can start Windows programs that have a graphical user interface, such as Notepad and Calculator, at the Windows Powershell prompt. You can also capture the text that Windows programs generate and use that text in Windows PowerShell.

For example, the following commands use ipconfig and net commands.

PS C:\Windows\system32> ipconfig

Windows IP Configuration

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::6594:644d:560c:dbfb%15
   IPv4 Address. . . . . . . . . . . : 192.168.4.254
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::ed2:b5ff:fe1f:5174%15
                                       192.168.4.10

Tunnel adapter isatap.{962CC11B-3F41-40C1-8E02-F5CF5976F2D7}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

PS C:\Windows\system32> net localgroup administrators
Alias name     administrators
Comment        Administrators have complete and unrestricted access to the computer/domain

Members

-------------------------------------------------------------------------------
techtutsonline\surender
localadmin
The command completed successfully.

You can even use Windows PowerShell cmdlets, like Select-String, to manipulate the text that Windows programs return.

For example, the following command uses a pipeline operator to send the results of an ipconfig command to the Windows PowerShell Select-String cmdlet, which searches for text in strings. In this case, you use Select-String to find the pattern “IPv4” in the ipconfig output.

PS C:\Windows\system32> ipconfig | select-string -pattern IPv4

   IPv4 Address. . . . . . . . . . . : 192.168.4.254

When a Windows command or tool has parameters, such as the “-r” (restart) parameter of shutdown command (shutdown -r), Windows PowerShell passes the parameters to the tool without interpreting them.

However, if the tool uses a Windows PowerShell reserved word, or uses a command format that is unknown to Windows PowerShell, such as “-D:debug=false” parameter (Windows PowerShell interprets this as two parameters, “-D” and “debug=false”), enclose the parameters in quotations marks to indicate to Windows PowerShell that it should send the parameters to the tool without interpretation.

Processing Objects

Although you might not realize it at first, when you work in Windows PowerShell, you are working with .NET Framework objects. As you gain experience, the power of object processing becomes more evident, and you’ll find yourself using the objects and even thinking in objects.

Technically, a .NET Framework object is an instance of a .NET Framework class that consists of data and the operations associated with that data. But you can think of an object as a data entity that has properties, which are like characteristics, and methods, which are actions that you can perform on the object.

For example, when you get a service in Windows PowerShell, you are really getting an object that represents the service. When you view information about a service, you are viewing the properties of its service object. And, when you start a service, that is, when you change the Status property of the service to “Started,” you are using a method of the service object.

All objects of the same type have the same properties and methods, but each instance of an object can have different values for the properties. For example, every service object has a Name and Status property. However, each service can have a different name and a different status.

When you’re ready, it’s easy to learn about the objects. To find out what type of object a cmdlet is getting, use a pipeline operator (|) to send the results of a “get” command to the Get-Member cmdlet. For example, the following command sends the objects retrieved by a Get-Service command to Get-Member.

PS C:\Windows\system32> Get-Service | Get-Member

   TypeName: System.ServiceProcess.ServiceController

Name                      MemberType    Definition
----                      ----------    ----------
Name                      AliasProperty Name = ServiceName
RequiredServices          AliasProperty RequiredServices = ServicesDependedOn
Disposed                  Event         System.EventHandler Disposed(System.Object, System.EventArgs)
Close                     Method        void Close()
Continue                  Method        void Continue()
CreateObjRef              Method        System.Runtime.Remoting.ObjRef CreateObjRef(type requestedType)
Dispose                   Method        void Dispose(), void IDisposable.Dispose()
Equals                    Method        bool Equals(System.Object obj)
ExecuteCommand            Method        void ExecuteCommand(int command)
GetHashCode               Method        int GetHashCode()
GetLifetimeService        Method        System.Object GetLifetimeService()
GetType                   Method        type GetType()
InitializeLifetimeService Method        System.Object InitializeLifetimeService()
Pause                     Method        void Pause()
Refresh                   Method        void Refresh()
Start                     Method        void Start(), void Start(string[] args)
Stop                      Method        void Stop()

[output cut]

To find the values of all of the properties of a particular object, use a pipeline operator (|) to send the results of a “get” command to a Format-List or Format-Table cmdlet. Use the Property parameter of the format cmdlets with a value of all (*). For example, to find all of the properties of the Windows Update service on the system, type:

PS C:\Windows\system32> Get-Service wuauserv | Format-List -Property *

Name                : wuauserv
RequiredServices    : {rpcss}
CanPauseAndContinue : False
CanShutdown         : False
CanStop             : False
DisplayName         : Windows Update
DependentServices   : {}
MachineName         : .
ServiceName         : wuauserv
ServicesDependedOn  : {rpcss}
ServiceHandle       : SafeServiceHandle
Status              : Stopped
ServiceType         : Win32ShareProcess
Site                :
Container           :

Remember that Windows PowerShell is not case sensitive. It means cmdlet “Get-Service” and “get-service” will return same result. But you will see in many blogs that cmdlets are accented such has first letter is always uppercase. This is because Windows PowerShell uses TAB key for auto-completion and TAB key automatically changes the first letter to uppercase. If you type “get-ser” and press TAB key, you will see that the cmdlet name changes to “Get-Service”.

Object Pipelines

One major advantage of using objects is that it makes much easier to pipeline commands. Pipeline means to pass the output of one cmdlet to another cmdlet as input. In a traditional command-line environment, you would have to manipulate text to convert output from one format to another and to remove titles and column headings.

Windows PowerShell provides a new architecture that is based on objects, rather than text. The cmdlet that receives an object can act directly on its properties and methods without any conversion or manipulation. Users can refer to properties and methods of the object by name, rather than calculating the position of the data in the output.

In the following example, the result of an ipconfig command is passed to a findstr command. The pipeline operator (|) sends the result of the command on its left to the command on its right. In Windows PowerShell, you do not need to manipulate strings or calculate data offsets.

PS C:\Windows\system32> ipconfig | findstr "Address"
   Link-local IPv6 Address . . . . . : fe80::6594:644d:560c:dbfb%15
   IPv4 Address. . . . . . . . . . . : 192.168.4.254

Windows PowerShell System Requirements

When Windows PowerShell was initially started (with version 1.0), it was mainly designed to work with only local computer. The latter version (version 2.0 and above) included the PowerShell Remoting feature  which allow the system administrators to run the commands on remote computers and servers.

In this section, I will look into the system requirements for Windows PowerShell 3.0 and Windows PowerShell 4.0, and for special features, such as Windows PowerShell Integrated Scripting Environment (ISE), CIM commands, and workflows.

Windows 8.1 and Windows Server 2012 R2 comes with Windows PowerShell installed by default.

Operating System Requirements

Windows PowerShell 4.0 runs on the following versions of Windows:

  • Windows 8.1, installed by default
  • Windows Server 2012 R2, installed by default
  • Windows 7 with Service Pack 1, install Windows Management Framework 4.0 to run Windows PowerShell 4.0
  • Windows Server 2008 R2 with Service Pack 1, install Windows Management Framework 4.0 to run Windows PowerShell 4.0.

Windows PowerShell 3.0 runs on the following versions of Windows:

  • Windows 8, installed by default
  • Windows Server 2012, installed by default
  • Windows 7 with Service Pack 1, install Windows Management Framework 3.0 to run Windows PowerShell 3.0
  • Windows Server 2008 R2 with Service Pack 1, install Windows Management Framework 3.0 to run Windows PowerShell 3.0
  • Windows Server 2008 with Service Pack 2, install Windows Management Framework 3.0 to run Windows PowerShell 3.0.

Microsoft .NET Framework Requirements

Windows PowerShell 4.0 requires the full installation of Microsoft .NET Framework 4.5. Windows 8.1 and Windows Server 2012 R2 include Microsoft .NET Framework 4.5 by default.

Windows PowerShell 3.0 requires the full installation of Microsoft .NET Framework 4. Windows 8 and Windows Server 2012 include Microsoft .NET Framework 4.5 by default, which fulfills this requirement.

To install Microsoft .NET Framework 4.5  download the file dotNetFx45_Full_setup.exe from Microsoft Download Center.

WS-Management 3.0

Windows PowerShell 3.0 and Windows PowerShell 4.0 require WS-Management 3.0, which supports the WinRM service and WSMan protocol. This program is included in Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows Management Framework 4.0, and Windows Management Framework 3.0.

Windows Management Instrumentation 3.0

Windows PowerShell 3.0 and Windows PowerShell 4.0 require Windows Management Instrumentation 3.0 (WMI). This program is included in Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows Management Framework 4.0, and Windows Management Framework 3.0. If this program is not installed on the computer, features that require WMI, such as CIM commands, do not run.

Windows PowerShell Engine Requirements

Windows PowerShell 4.0 is designed to be backwards compatible with Windows PowerShell 3.0 and Windows PowerShell 2.0. Cmdlets, providers, snap-ins, modules, and scripts written for Windows PowerShell 2.0 and Windows PowerShell 3.0 run unchanged in Windows PowerShell 4.0.

However, due to a change in the runtime activation policy in Microsoft .NET Framework 4.0, Windows PowerShell host programs that were written for Windows PowerShell 2.0 and compiled with Common Language Runtime (CLR) 2.0 cannot run without modification in Windows PowerShell 3.0, which is compiled with CLR 4.0.

The Windows PowerShell 2.0 engine requires Microsoft .NET Framework 2.0.50727 at a minimum. This requirement is fulfilled by Microsoft .NET Framework 3.5 Service Pack 1. This requirement is not fulfilled by Microsoft .NET Framework 4.0 and later releases of Microsoft .NET Framework.

Installing Windows PowerShell on Windows 8 and Windows Server 2012

Windows PowerShell 3.0 arrives installed, configured, and ready to use. Windows PowerShell Integrated Scripting Environment (ISE) is installed and enabled.

Installing Windows PowerShell on Windows 7 and Windows Server 2008 R2

To install Windows PowerShell 3.0

  • Install the full installation of Microsoft .NET Framework 4 (dotNetFx40_Full_setup.exe) from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkID=212547. OR, install Microsoft .NET Framework 4.5 (dotNetFx45_Full_setup.exe) from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkID=242919.
  • Install Windows Management Framework 3.0 from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkID=240290.

    Installing Windows PowerShell on Server Core

    To install Windows PowerShell 3.0

    1. Start Cmd.exe
    2. Run the following DISM commands. These commands install .NET Framework 2.0 and Windows PowerShell 2.0.
      dism /online /enable-feature:NetFx2-ServerCore
      dism /online /enable-feature:MicrosoftWindowsPowerShell
      dism /online /enable-feature:NetFx2-ServerCore-WOW64
    3. Install Microsoft .NET Framework 4.0 full installation for Server Core from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkID=248450.
    4. Install Windows Management Framework 3.0 from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkID=240290.

    Getting Ready to Use Windows PowerShell

    When Windows PowerShell is installed and started, consider the following setup options. You can perform these tasks at any time.

  • Install help files. The cmdlets that are included in Windows PowerShell 3.0 do not come with help files. However, you can use the Update-Help cmdlet to download and install the newest help files on your computer. When the files are installed, you can use the Get-Help cmdlet to display them right at the command line.
  • Run scripts. To keep Windows PowerShell secure, the default execution policy on Windows PowerShell is Restricted. This policy allows you to run cmdlets, but not scripts. To run scripts, use the Set-ExecutionPolicy cmdlet to change the execution policy to AllSigned, RemoteSigned or Unrestricted. To see the current ExecutionPolicy of system, use Get-ExecutionPolicy cmdlet. Only members of the Administrators group on the computer can run this cmdlet.
  • Enable Remoting. The system is already configured for you to run remote commands on other computers. On Windows Server 2012 R2 and Windows Server 2012, the system is also configured to receive remote commands, that is, to allow other computers to run remote commands on the local computer. To enable computers running other versions of Windows to receive remote commands, run the Enable-PSRemoting -Force cmdlet on the computer that you want to manage remotely. Only members of the Administrators group on the computer can run this cmdlet.

NOTE: If remoting is enabled on a computer that is running Windows PowerShell 2.0, remoting is still enabled after you install Windows Management Framework 3.0. However, on Windows Server 2008 (not Windows Server 2008 R2), you must re-enable remoting after installing Windows Management Framework 3.0.

Back



Microsoft Certified Professional | Cisco Certified Network Associate

Leave a Reply