Instant Windows PowerShell Guide: Enhance your knowledge of Windows PowerShell and get to grips with its latest features

Let us see what Windows Management Framework 3.0 requires.

By default, Windows PowerShell 3.0 comes with Windows Server 2012 and Windows 8. There are a number of default modules present in this version. If you are running an operating system lower than the one specified, you need to manually install Windows Management Framework 3.0 (WMF 3.0). If you have installed any previous releases of Windows Management Framework, you must uninstall them before installing Windows Management Framework 3.0.

Windows Management Framework 3.0 can be installed only on the following operating system versions:

Windows Management Framework 3.0 requires the following software to be installed prior to installing WMF 3.0:

Now, let us see what Windows Management Framework 4.0 requires.

By default, Windows PowerShell 4.0 comes up with Windows Server 2012 R2 and Windows 8.1. If you are running an operating system lower than the one specified earlier, you need to manually install Windows Management Framework 4.0 (WMF 4.0). If you have installed any previous releases of Windows Management Framework, you must uninstall them before installing Windows Management Framework 4.0.

Windows Management Framework 4.0 can be installed only on the following operating system versions:

Windows Management Framework 4.0 requires the following software to be installed prior to installing WMF 4.0:

The following is information about the contents of WMF 3.0 and WMF 4.0.

Additionally, the following requirements should also be met:

In the previous versions, if we install WMF in our machine, it will install the help system available with that WMF package at the time of installation. We do not have any way to update our help system later; the only way is to reinstall the WMF package with the latest updates.

To overcome this issue, the Windows PowerShell team has introduced two new CMDLETs in Version 3.0 to update the help system: Update-Help and Save-Help.

If you are installing WMF 3.0 on your operating system for the first time or running fresh operating system as Windows Server 2012 or Windows 8, by default, Windows PowerShell v3.0 will not have any help system embedded into it. You need to manually update the help system to utilize the discoverability feature in the Windows PowerShell v3.0 console.

If your computer is not directly connected to the Internet and you want to update the help system, there is one CMDLET introduced in Version 3.0 called Save-Help.

The Save-Help CMDLET downloads and saves the latest help files to the specified filesystem directory. You can carry these help files into removable devices or copy them into the network file share location. This CMDLET will be useful in installing updated help files on multiple computers by downloading help files once on a single computer and storing them in a shared location.

Also, to run the Save-Help CMDLET, you must be a member of the administrative group and start the PowerShell console using the Run as administrator option. Save-Help saves the downloaded help files in cabinet (.cab) files in the destination directory. The saved help files consist of a help information (HelpInfo XML) file and a cabinet (.cab) file for each module installed in a PSModulePath location.

PS C :\> Save-Help -DestinationPath C:\UpdatedHelp

The preceding command statement downloads and saves updated help files for all the modules in the UpdatedHelp directory in a local computer's C:.

The DestinationPath parameter name needs to specify the destination directory in which we wish to place all the downloaded help files.

PS C :\> Save-Help -Module Microsoft.PowerShell* -DestinationPath \\FileSrv001\UpdatedHelp

The preceding command statement downloads updated help files for module names that start with Microsoft.PowerShell and stores them in the \\FileSrv001\UpdatedHelp directory.

PS C :\> Update-Help -SourcePath \\FileSrv001\UpdatedHelp -Credential PSDomain\PSAdmin

The preceding command statement updates the help system from the specified shared location and domain administrator credential. It prompts for the administrator password and updates the help system offline.

If you want to update the help system for multiple computers in a single click, use the following command:

PS C :\> Invoke-Command -ComputerName (Get-Content Servers.txt) -ScriptBlock {Update-Help -SourcePath \\FileSrv001\UpdatedHelp -Credential PSDomain\PSAdmin}

Using the preceding command statement, Invoke-Command runs the given ScriptBlock parameter on all the remote computers specified in Servers.txt. The remote computers must be able to access the file share instead of using the Internet.

With the beginning of Windows PowerShell 4.0, Save-Help can also save help files for the modules that are installed on remote computers. It works as described:

PS C :\> $session = New-PSSession -ComputerName PSTest

The preceding command statement creates a remote PowerShell session on the PSTest remote computer.

PS C :\> $modlist = Get-Module -PSSession $session –ListAvailable

Then, using the session object created by running the previous command statement, it retrieves the list of modules that are installed on the PSTest remote computer.

PS C :\> Save-Help -Module $modlist -DestinationPath \\FileSrv001\UpdatedHelp

Finally, it downloads and saves the help files for the modules that are fetched in the previous command statement. We can use the Update-Help CMDLET again to install help files on multiple computers from a centralized file share.

There are a few tricks using which we can effectively leverage the discoverability feature within the Windows PowerShell console. This section discusses a few among those.

How you discover the commands

Once your help system is updated, you can choose any dumb keyword and start demanding to the Windows PowerShell console. Let's say I want to know all the information about the log keyword.

PS C :\> Get-Help *log*

The following screenshot describes search results for the log keyword:

It will list out all the CMDLETs, functions, and help files that contain the log keyword. You can pick any one of them and start discovering further help. For example, I want to check the help of Get-EventLog.

PS C :\> Get-Help Get-EventLog

It throws an output listing information specific to the Get-EventLog CMDLET, such as Name, Synopsis, Syntax, Description, and Related links.

PS C :\> Get-Help about*

PS C :\> Get-Help about_Windows_PowerShell_3.0

The ShowWindow parameter

Sometimes, it could be boring to refer help files into the blue Windows PowerShell console for a long time. To overcome this, we have the –ShowWindow parameter that comes with the Get-Help CMDLET supported in Version 3.

PS C :\> Get-Help Get-Command –ShowWindow

It provides a graphical view of the help files and opens in another window with search capabilities.

Most of the functionalities are inherited from Version 2, but there are some enhancements in terms of methods and properties.

Let's go one step forward:

PS C :\> "Windows PowerShell" | Get-Member

The previous command displays all the methods and properties available with the string object we have piped earlier.

If you compare the execution of the same command statement between both the Windows PowerShell Versions (2.0 and 3.0), you will get additional methods and properties listed as follows:

TypeName: System.String
Name          MemberType     Definition
ToBoolean     Method         bool IConvertible.ToBoolean(System.IFormatProvider provider)
ToByte        Method         byte IConvertible.ToByte(System.IFormatProvider provider)
ToChar        Method         char IConvertible.ToChar(System.IFormatProvider provider)
ToDateTime    Method         datetime IConvertible.ToDateTime(System.IFormatProvider provider)
ToDecimal     Method         decimal IConvertible.ToDecimal(System.IFormatProvider provider)
ToDouble      Method         double IConvertible.ToDouble(System.IFormatProvider provider)
ToInt16       Method         int16 IConvertible.ToInt16(System.IFormatProvider provider)
ToInt32       Method         int IConvertible.ToInt32(System.IFormatProvider provider)
ToInt64       Method         long IConvertible.ToInt64(System.IFormatProvider provider)
ToSByte       Method         sbyte IConvertible.ToSByte(System.IFormatProvider provider)
ToSingle      Method         float IConvertible.ToSingle(System.IFormatProvider provider)
ToType        Method         System.Object IConvertible.ToType(type conversionType, System.IFormatProvider provider)
ToUInt16      Method         uint16 IConvertible.ToUInt16(System.IFormatProvider provider)
ToUInt32      Method         uint32 IConvertible.ToUInt32(System.IFormatProvider provider)
ToUInt64      Method         uint64 IConvertible.ToUInt64(System.IFormatProvider provider)

Now, retrieve methods and properties for Integer objects:

PS C :\> 2+3 | Get-Member

It displays all the methods and properties available with the integer object we have piped earlier.

If you compare the execution of the same command statement between both the Windows PowerShell Versions (2.0 and 3.0), you will get additional methods and properties listed as follows:

TypeName: System.Int32
Name          MemberType     Definition
ToBoolean     Method         bool IConvertible.ToBoolean(System.IFormatProvider provider)
ToByte        Method         byte IConvertible.ToByte(System.IFormatProvider provider)
ToChar        Method         char IConvertible.ToChar(System.IFormatProvider provider)
ToDateTime    Method         datetime IConvertible.ToDateTime(System.IFormatProvider provider)
ToDecimal     Method         decimal IConvertible.ToDecimal(System.IFormatProvider provider)
ToDouble      Method         double IConvertible.ToDouble(System.IFormatProvider provider)
ToInt16       Method         int16 IConvertible.ToInt16(System.IFormatProvider provider)
ToInt32       Method         int IConvertible.ToInt32(System.IFormatProvider provider)
ToInt64       Method         long IConvertible.ToInt64(System.IFormatProvider provider)
ToSByte       Method         sbyte IConvertible.ToSByte(System.IFormatProvider provider)
ToSingle      Method         float IConvertible.ToSingle(System.IFormatProvider provider)
ToType        Method         System.Object IConvertible.ToType(type conversionType, System.IFormatProvider provider)
ToUInt16      Method         uint16 IConvertible.ToUInt16(System.IFormatProvider provider)
ToUInt32      Method         uint32 IConvertible.ToUInt32(System.IFormatProvider provider)
ToUInt64      Method         uint64 IConvertible.ToUInt64(System.IFormatProvider provider)

The same mechanism is applicable to all the other objects, such as double and so on. For example, take a real-time scenario:

As an administrator, you are dealing with server memory configurations in units such as MB, GB, TB, and so on.

Let's utilize the Windows PowerShell console for such calculations:

PS C :\> 1024MB/1GB
1
PS C :\> 1000MB/1GB
0.9765625

Say you have 2 TB of external storage and you need to create a data drive of 4 GB for each user. How many users can you accommodate in this requirement?

PS C :\> 2TB/4GB
512

Isn't it tricky?

In such scenarios, we can easily utilize the built-in calculation functionality of the Windows PowerShell console.

There are some functionality changes when we create a new custom PSDrive using PowerShell Version 3.0. Let's walk through them.

New-PSDrive

This CMDLET creates a new temporary or persistent drive with various Windows PowerShell provider types.

Let's get the full information of the PowerShell drive named T earlier:

PS C :\> Get-PSDrive -Name T
Name         Provider        Root
----         --------        ----
T            FileSystem      T:\

In Version 3.0, the following are a few functionality changes with respect to the New-PSDrive CMDLET.

There are couple of more parameters that are introduced with various CMDLETs in Version 3. The information is as described in this section.

Get-Credential

In Version 3.0, the Get-Credential CMDLET has one additional parameter name called the Message parameter. Using the Message parameter, you can specify customized messages to the users on prompted credential windows.

For example:

PS C :\> Get-Credential -Message "Enter your valid Username and Password" -UserName PSDomain\PSAdmin

PS C :\> Get-Process | Select-Object Name -First 5 –Wait

PS C :\> $header = "Current State", "Service Name", "Description"

PS C :\> Import-Csv –Path .\Services.csv -Header $header 

PS C :\> Get-Process | ConvertTo-Json

PS C :\> Get-Process | ConvertTo-Json | ConvertFrom-Json

PS C :\> $Objv2 = New-Object –TypeName PSObject -Property @{x=1; y=2; z=3}

PS C :\> $Objv2 | Format-List
y: 2
z: 3
x: 1

PS C :\> $Objv3 = [PSCustomObject]@{x=1; y=2; z=3}

PS C :\> $Objv3 | Format-List
x: 1
y: 2
z: 3

PS C :\> $Objv3 | Get-Member

TypeName: System.Management.Automation.PSCustomObject
Name            MemberType     Definition
----            ----------     ----------
Equals          Method         bool Equals(System.Object obj)
GetHashCode     Method         int GetHashCode()
GetType         Method         type GetType()
ToString        Method         string ToString()
x               NoteProperty   System.Int32 x=1
y               NoteProperty   System.Int32 y=2
z               NoteProperty   System.Int32 z=3

The Add-Computer CMDLET is used for adding a local computer to a domain or workgroup.

Try executing the following code sequence:

Given below are the additional parameter names introduced with Add-Computer in Version 3.0:

The Remove-Computer CMDLET has the same set of enhancements as Add-Computer. The changes are identical with respect to both the CMDLETs.

PS C:\>Rename-Computer -NewName NewMember01 -DomainCredential PSDomain\PSAdmin –Restart

PS C :\> Get-ControlPanelItem -Name *Device* | Format-List

Name          : Device Manager
CanonicalName : Microsoft.DeviceManager
Category      : {All Control Panel Items}
Description   : View and update your hardware's settings and driver software.
Name          : Devices and Printers
CanonicalName : Microsoft.DevicesAndPrinters
Category      : {Hardware and Sound}
Description   : View and manage devices, printers, and print jobs
PS C :\> Get-ControlPanelItem -Name *Printers* | Show-ControlPanelItem

PS C:\>Test-Connection –Source Member01, Member02 -ComputerName DC01 -Credential PSDomain\PSAdmin

PS C :\> Test-NetConnection –ComputerName PSTest.PSLab.com -Port 8080 -InformationLevel Detailed

In previous versions, we used to run the Import-Module CMDLET to load specific modules onto a console, but now, in Version 3, there is no need to explicitly import modules that are specified in $env:PSModulePath. There are a few more modules that come along with the Version 3 consoles.

Let's try to put it in an example:

For better understanding, let's get the list of the newly introduced modules in version 3.0. Have a look at the following command:

PS C :\> Get-Module -ListAvailable | where PowerShellVersion -eq '3.0'
Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules

Check the following list of available modules with PowerShell v3.0:

Sometimes, you have many modules placed in your PSModulePath location and they will be loaded onto your current session eventually, one-by-one, based on your CMDLET interaction. It will overhead for the current session to load all available modules. There is a way to restrict such behavior. In Version 3, a new preference variable has been introduced, named $PSModuleAutoloadingPreference.

It enables or disables autoloading behavior in modules. The default value is All. So, by default, it loads all the modules onto the console from the PSModulePath location, when and where required. Irrespective of the value of $PSModuleAutoloadingPreference, you can leverage the Import-Module CMDLET to load the required modules at any time.

$PSModuleAutoloadingPreference has three values listed as follows:

With Windows PowerShell v3.0, you can log execution events for Windows PowerShell modules.

PS C :\> Import-Module -Name PSScheduledJob
PS C :\> $Temp = Get-Module -Name PSScheduledJob
PS C :\> $Temp.LogPipelineExecutionDetails = $True

PS C:\> Get-EventLog -LogName "Windows PowerShell" | Format-Table -AutoSize –Wrap

@{ModuleName = "modulename"; ModuleVersion = "version_number"}

We have some simplified syntax introduced in the latest version of Windows PowerShell with respect to the Where-Object and ForEach-Object CMDLETs.

If we compare the preceding two different version's outputs, it is evident that PowerShell v3.0 has simplified syntax. Moreover, we do not need to use curly braces anymore to run a command statement.

Also, it automatically gets the previous command pipeline output as input for the Where clause. We don't need to explicitly provide the parameter value with the $_ syntax.

Novice users would find the $_ syntax a bit strange; now, in PowerShell v3.0, we can use $PSItem instead of $_.

The same is the case with Where-Object; we don't need to use curly braces and the $_ syntax if we are dealing with ForEach-Object in PowerShell v3.0.

In PowerShell v2.0, Get-Command only retrieves the CMDLETs available in the present session whereas, in v3.0, it retrieves all the CMDLETs that are installed on the local computer, including modules, functions, workflows, scripts, and so on. It also includes the application in the output available at the $env:Path location.

Execute the following commands:

The following are the newly introduced parameters in PowerShell v3.0 with Get-Command:

PS C :\> Get-Process
PS C :\> #Get <Tab>

As stated in earlier recipes, Windows PowerShell 4.0 has a new feature called Desired State Configuration (DSC).

PS C :\> Get-Command -CommandType Configuration

$PSDefaultParameterValues is a default preference variable introduced in PowerShell v3.0. This variable sets the custom parameter values to specified CMDLETs and functions. It maintains a hash table to store all of the defined values.

Try the following test code to set the default parameter values:

The following are the syntaxes to define the $PSDefaultParameterValues preference variable:

The following are a couple of functionality changes with respect to Windows PowerShell v4.0.

PS C :\> (Get-Command).where("Name -like *log")

PS C :\> Import-Module PSDesiredStateConfiguration
PS C :\> (Get-Command).where
Script              : $prop, $psop, $val = [string] $args[0] -split
                      '(-eq|-ne|-gt|-ge|-lt|-le|-like|-notlike|-match|-notmatch)'
                      $operation = @{ Prop = $prop.Trim(); Value = $val.Trim(); $psop = $true }
                      $this | where @operation
OverloadDefinitions : {System.Object where();}
MemberType          : ScriptMethod
TypeNameOfValue     : System.Object
Value               : System.Object where();
Name                : where
IsInstance          : False

PS C :\> Update-TypeData -Force -MemberType ScriptMethod -MemberName where -TypeName System.Array -Value { $prop, $psop, $val = [string] $args[0] -split '(-eq|-ne|-gt|-ge|-lt|-le|-like|-notlike|-match|-notmatch)' $operation = @{ Prop = $prop.Trim(); Value = $val.Trim(); $psop = $true } $this | where @operation}

PS C :\> (Get-Command).where("Name -like *log")

In PowerShell Version 3.0, many parameters have been introduced for Get-ChildItem that are very efficient with filesystem drives.

The following are the parameters newly introduced with the Get-ChildItem CMDLET.

There are few aliases available with respect to the Get-ChildItem CMDLET, specified as follows:

There are a few minor enhancements in Version 3.0 for alias mechanisms with respect to the following CMDLETs.

PS C:\> Get-Alias ps, cls
CommandType         Name
-----------         ----
Alias               ps -> Get-Process
Alias               cls -> Clear-Host
PS C:\> Get-Alias | Select-Object Name,DisplayName,Options

There are a few new operators introduced in PowerShell Version 3.0. For example, the In and NotIn operators.

Try executing the following code:

The following table mentions the syntaxes for these operators:

There are a few new parameters introduced with the following CMDLETs:

The Out-GridView CMDLET gets the output in a graphical form. It leverages the .NET Framework to construct an output window, so the .NET Framework is mandatorily required to deal with the Out-GridView CMDLET.

Try executing the following lines of code.

A few more parameters are introduced with the popular Out-GridView CMDLET.

There are a few more CMDLETs that can be useful to operate the data in an efficient way. Some are listed as follows:

PS C :\> Get-FileHash -FilePath D:\SpaceAnalyser.ps1 -Algorithm MD5 | Format-List
Path : D:\SpaceAnalyser.ps1
Type : System.Security.Cryptography.MD5CryptoServiceProvider
Hash : h9uUHj8CGtGnV35reUkehw==

There are a few recently introduced parameters for Get-PSSession and New-PSSession CMDLETs. Also, there are some newly introduced CMDLETs such as Connect-PSSession, Disconnect-PSSession, and New-PSTransportOption.

Try executing the following lines of code by performing the following steps:

As discussed earlier in this chapter, with PowerShell Version 3.0, we have the facility to reconnect to the remote session that is disconnected due to certain reasons such as network interruption, remote server unavailability, and so on. In such cases, we can use a couple of commands to handle the sessions; they are Connect-PSSession and Disconnect-PSSession.

The Connect-PSSession CMDLET connects to the disconnected session again and enables us to resume our work in the same session. It has certain parameters such as Authentication, CertificateThumbPrint, ComputerName, Credential, Id, Name, Port, ThrottleLimit, UseSSL, AllowRedirection, ConnectionUri, and so on, which have been discussed earlier in this book. The following are two parameters specific to sessions:

The Disconnect-PSSession CMDLET disconnects the specified session from the current session. You can provide a reference to the session by having parameters such as Name, Session, Id, and so on. There are a few other parameters that are specified as follows:

A few parameters are also introduced with respect to PowerShell sessions in Version 3.0. The following are some of these parameters.

PS C :\> help about_Session_Configurations
PS C :\> help about_Session_Configuration_Files

Execute the following command statement, by performing the step:

The following command statement executes DiskInventory.ps1 scripts on computers specified in servers.txt, and it maintains the disconnected session named DiskInventory within the scope of the current console:

PS C:\>Invoke-Command -ComputerName (Get-Content C:\servers.txt) –SessionName DiskInventory –InDisconnectedSession -FilePath \\Scripts\DiskInventory.ps1 -NoNewScope

There are a few new parameters introduced with the Invoke-Command CMDLET.

You can learn to use a local variable in the remote PowerShell session by going through the following explanation.

PS C:\> $PSCred = Get-Credential PSDomain\PSAdmin
PS C:\> Invoke-Command -ComputerName DC01,Member01,Member02 -ScriptBlock {Restart-Computer -Credential $Using:PSCred}

WorkFlow is an enhanced version of a function where you can create an execution sequence by using various command statements. It maintains a reliable session throughout the execution, which serves the reboot and disconnection of network problems in between the execution.

The following are the CMDLETs that are responsible for executing the PowerShell Workflow.

The following are a few more workflow enhancements.

We have the default ISE module introduced in PowerShell Version 3.0.

The New-IseSnippet CMDLET creates a code snippet that can be re-used in the Windows PowerShell ISE environment. The snippet can be a frequently used command, a small portion of text that you can define as a string. This CMDLET indeed creates a PS1XML file that contains the snippet data. Snippet files will be created in the form of <SnippetTitle>.Snippets.ps1xml.

The following are a few more CMDLETs that can be helpful for writing a script quickly.

PS C:\> Get-IseSnippet
    Directory: C:\Users\Harshul\Documents\WindowsPowerShell\Snippets
Mode      LastWriteTime     Length Name
----        -------------   ------ ----
-a---       8/29/2013 6:34 PM 1071 TestSnippet.snippets.ps1xml

Show-Command

The Show-Command CMDLET is very useful to newbies who need some assistance to construct a command statement. Show-Command provides a graphical input window where you can put all your input in Graphical User Interface, and PowerShell will construct a command statement for you based on your inputs. There are options to Run or Copy your code into the script from the graphical window itself. Try to execute the following command:

PS C :\> Show-Command Invoke-Command

If you use the Copy button to copy the code to the clipboard, it appears as follows:

PS C :\> Invoke-Command -ScriptBlock {Get-EventLog -LogName System} -AsJob -Authentication Default -ComputerName PSTest

PS C :\> Get-ChildItem -Path C:\PSScripts | Unblock-File

PS C :\> Restart-Computer -ComputerName PSTest –Credential PSDomain\PSAdmin -WSManAuthentication Basic -Protocol WSMan 

PS C :\> Restart-Computer -ComputerName PSTest -Wait -For WinRM -Timeout 500 -Delay 3

Moreover, CIM CMDLETs work with WSMan to manage Windows as well as other operating systems. To ensure all the CMDLETs are available with CimCmdlets, use the following code:

PS C :\> Get-Comman d -Module CimCmdlets
CommandType     Name                          ModuleName
-----------     ----                          ----------
Cmdlet          Get-CimAssociatedInstance     CimCmdlets
Cmdlet          Get-CimClass                  CimCmdlets
Cmdlet          Get-CimInstance               CimCmdlets
Cmdlet          Get-CimSession                CimCmdlets
Cmdlet          Invoke-CimMethod              CimCmdlets
Cmdlet          New-CimInstance               CimCmdlets
Cmdlet          New-CimSession                CimCmdlets
Cmdlet          New-CimSessionOption          CimCmdlets
Cmdlet          Register-CimIndicationEvent   CimCmdlets
Cmdlet          Remove-CimInstance            CimCmdlets
Cmdlet          Remove-CimSession             CimCmdlets
Cmdlet          Set-CimInstance               CimCmdlets

Execute the following lines of code, by performing the following steps:

The Get-CimInstance CMDLET retrieves CIM instances from the specified computer and the CIM class name. This CMDLET omits one or more output instance object, providing information from the specified class. The following are the parameters available with this CMDLET:

There is also the Invoke-CimMethod CMDLET available with the CimCmdlets module. Instead of using Invoke-WmiMethod, consider using Invoke-CimMethod.

With the concept of scheduled jobs, we have the freedom to operate the data and operations as and when required. We don't need manual interaction too. PSScheduledJob refers to an instance of a scheduled job that is started by a job trigger. There are a bunch of CMDLETs available with this module as shown:

PS C :\> Get-Command -Module PSScheduledJob
CommandType   Name                       ModuleName
-----------   ----                       ----------
Cmdlet        Add-JobTrigger             PSScheduledJob
Cmdlet        Disable-JobTrigger         PSScheduledJob
Cmdlet        Disable-ScheduledJob       PSScheduledJob
Cmdlet        Enable-JobTrigger          PSScheduledJob
Cmdlet        Enable-ScheduledJob        PSScheduledJob
Cmdlet        Get-JobTrigger             PSScheduledJob
Cmdlet        Get-ScheduledJob           PSScheduledJob
Cmdlet        Get-ScheduledJobOption     PSScheduledJob
Cmdlet        New-JobTrigger             PSScheduledJob
Cmdlet        New-ScheduledJobOption     PSScheduledJob
Cmdlet        Register-ScheduledJob      PSScheduledJob
Cmdlet        Remove-JobTrigger          PSScheduledJob
Cmdlet        Set-JobTrigger             PSScheduledJob
Cmdlet        Set-ScheduledJob           PSScheduledJob
Cmdlet        Set-ScheduledJobOption     PSScheduledJob
Cmdlet        Unregister-ScheduledJob    PSScheduledJob

Execute the following lines of code.

A PowerShell scheduled job is a background job that triggers at a specific time or during a recurring schedule. The Register-ScheduledJob CMDLET creates a new scheduled job, while the Set-ScheduledJob CMDLET changes the properties of jobs that were scheduled earlier. The following are the various parameters available with these CMDLET:

There is another module that is available and that can be leveraged for managing the Web, that is, the WebAdministration module. Invoke-RestMethod and Invoke-WebRequest are CMDLETs that are used here.

For example, have a look at the following command:

PS C:\ > $url=http://blogs.msdn.com/b/powershell/rss.aspx

The preceding command statement stores the PowerShell rss link in a variable named $url.

PS C:\ > Invoke-RestMethod -Uri $url | Select-Object Title

By using Invoke-RestMethod, we can retrieve information from the $url variable and further filter the output as the title list.

We are living in a world where device adoption is quicker than ever. Hence, we must ensure that all the devices are in a desired state. DSC allows us to manage all the devices using Windows PowerShell.

The DSC flow can be categorized into two different models: Push and Pull. The DSC process could be divided in to three phases as follows:

configuration MyWebConf
{  # Parameters are optional
   param ($MachineName, $WebsitePath)
   # A Configuration block can have one or more Node blocks
   node $MachineName
   {  # Next, specify one or more resource provider blocks
      # WindowsFeature is one of the providers you can use in a Node block
      # This example ensures the Web Server (IIS) role is installed
      WindowsFeature IIS
      {   Name  = "Web-Server" # Use the Name property from Get-WindowsFeature
          Ensure= "Present" # To uninstall the role, set Ensure to "Absent" }
      # You can use the File provider to create files and folders
      # "File" is the name of the resource provider to use
      # "WebDirectory" is the name you want to use to refer to this instance
      File WebDirectory
      {  SourcePath      = $WebsiteFilePath
         DestinationPath = "C:\inetpub\wwwroot"
         Requires     = "[WindowsFeature] IIS" # Use Requires for dependencies
         Ensure       = "Present" # You can also set Ensure to "Absent" }
   }
}

The DSC feature consists of multiple subcomponents. The information is as follows:

To use DSC, first define a desired configuration. Like functions, configurations in DSC can be defined in the Windows PowerShell language by using the Configuration keyword and stored in script (.ps1) or module (.psm1) files. Also, similar to functions, configurations need to be defined and then run.

Each Configuration block must have at least one Node block. Each Node block can have one or more resource provider blocks. You can use the same role provider more than once in the same Node block.

In addition to new language keywords, DSC includes the following set of CMDLETs for managing configurations:

There is one more CMDLET that helps to detect the configuration drift:

Each resource is technically represented by a DSC provider. The default location for these DSC providers is at C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\PSProviders.

There are various DSC providers available. The following is the syntax for a few of them:

You can get the list of DSC providers by using following command:

PS C:\> Get-DscResource

As stated earlier, there are multiple resources available. I've provided information on some of these resources here.

Archive MyArchive
{  Ensure      ="Present" # You can also set Ensure to "Absent"
   Path        ="C:\PS\MyScripts.zip"
   Destination ="C:\PS\MyScripts" }

Group MyGroup
{     Ensure   ="Absent" # This will remove MyGroup, if present
      GroupName="MyGroup" }

Package MyPackage
{  Ensure ="Present"# You can also set Ensure to "Absent"
   Path   ="$FilePath\MySoftware.msi"
   Name   ="MyPackage" }

Registry MyRegistry
{  Ensure    ="Present" # You can also set Ensure to "Absent"
   Key       ="HKEY_LOCAL_MACHINE\SYSTEM\MyHiveKey"
   ValueName ="RegName"
   ValueData ="RegData" }

Script MyScript
{
   SetScript  = { # This block will run if TestScript returns False }
   TestScript = { # This block runs first }
   GetScript  = { # This must return a hash table }
}

Service MyService
{  Name       ="MyService"
   StartupType="Automatic" }

User MyUser
{  Ensure   ="Present" # To delete a user account, set Ensure to "Absent"
   UserName ="MyName"
   Password =$MyPassword # This needs to be a credential object
   Requires ="[Group]MyGroup"# Configures MyGroupfirst }

We can integrate any solution with DSC, and the minimal requirement is that you should be able to run the PowerShell script in such environments. You can create your own custom resources; we'll discuss this now.