Ying Li at myITforum.com

The assignment operators of PowerShell

Here are some examples about PowerShell assignment operators:

“=”

$a = 3

sets the variable to the specified value

“+=”

$a += 2, same as $a = $a + 2

performs the addition operation in the existing value, then assigns the result back to the variable.

“-=”

$a -= 15, same as $a = $a – 15

performs the subtracdtion operation in the existing value, then assigns the result back to the variable.

“*=”

$a = $a * 3, same as $a = $a * 3

multiplies the value of a variable by the specified value or appends to the existing value.

“/=”

$a /= 3, same as $a = $a / 3

divides the value of a variable by the specified value.

“%=”

$a %= 3, same as $a = $a % 3

divides the value of a variable by the specified value and assigns the remainder(modulus) to the variable.

The comparison operators in PowerShell

Here are PowerShell comparison operators:

-eq –ceq –ieq       Equals                                              5 –eq 5                      $true

-ne –cne –ine        Not Equals                                       5 –ne 5                      $false

-gt –cgt –igt          Greater than                                      5 –gt 3                       $true

-ge –cge –ige        Greater than or equal                         5 –ge 3                      $true

 -lt –clt –ilt             Less than                                           5 –lt 3                       $false

 -le –cle –ile           Less than or equal                              5 –le 3                       $false

 -contains

 -ccontains             The collection on the left side              1,2,3 –contains 2        $true

 -icontains              contains the value on the right side

 -notcontains

 -cnotcontains         The collection on the left side does      1,2,3 –notcontains 2   $false

 -inotcontains           not contains the value on the right side

For each operator there is a base operator form, like –eq and its two variants –ceq and –ieq. The “c” variant is case-senstive and the “I” variant is case-insenstive. The base operators are case-insensitive.

The basic arithmetic operators in PowerShell and the all important "Left Hand" rule!

Here are basic arithmetic operators in PowerShell:

The addition operator – Add two values together

Example:    2 + 4 = 6

                “Hello” + “World” = “Hello World”

                1,2,3 + 4,5,6 = 1,2,3,4,5,6

The multiplication operator – Multiply 2 values

Example:    2 * 4 = 8

                “x” * 3 = “xxx”

                1,2 * 2 = 1,2,1,2

The subtraction operator – Subtract one value from another

Example:     8 – 4 =  4

The division operator – Divide two values

Example:     8 / 4 = 2

                 9 / 6 = 1.5

The modulus operator – Return the remainder from a division operation

Example:     7 % 4 = 3

As you can see, when we adding or multiplying two numbers produces a numeric result. Adding two stings performs a string concatenation, resulting a new string, and adding two arrays joins the two arrays (array catenation), producing a new array. It’s get interesting when you mix operand types. In this situation, the type of left operand determines how the operation will proceed ( “Left-Hand” rule!). Let’s see the below example:

PS P:\>  5 + "125"
130

Left operand is number, PowerShell convert the right operand to a number

PS P:\> "5" + 125
5125

Left operand is string, the operand on the right (the number 125) is converted to a string and appended to “5” to produce a new sting “5125”

If the right operand can’t be converted into the type of the left operand then a type conversion error will be raised:

PS P:\> 5 + "xyz"
Cannot convert value "xyz" to type "System.Int32". Error: "Input string was not in a correct format."
At line:1 char:4
+ 5 +  <<<< "xyz"

You got the idea…

TechNet Webcast: Windows PowerShell in Windows Server 2008 (Level 200)

TechNet Webcast: Windows PowerShell in Windows Server 2008 (Level 200).

The basic set of object adapters avaliable in PowerShell

As we all know PowerShell is object oriented. It has objects and object types, programming is all about working with different types of objects. For each kind (type) data (object) that PowerShell works with, there is a corresponding adapter.

Here is the basic set of object adapters available in PowerShell

.NET Adapter – This is the basic adapter for all .NET types. This adapter directly maps the properties on the .NET object and adds several new ones that start with a PS prefix.

COM Object Adapter – This adapter provides access to COM objects. Supported objects include the Windows Script Host classes and scriptable applications such as Microsoft Excel or Internet Explorer.

WMI Adapter – This adapts objects returned from a WMI provider.

ADO Adapter – This adapter allows you to treat the columns in ADO data tables as though they were properties

Custom Object Adapter – This adapter manage objects for which there is no actual underlying object, only synthetic properties.

ADSI Object Adapter – This adapts objects returned from the ADSI.

Convert WMI time to system datetime

Please take a look at the below code:

PS C:\MyWorkPlace\PS> $pc = get-wmiobject win32_operatingsystem
PS C:\MyWorkPlace\PS> $pc.installdate
20060125222312.000000-300

The date is kind hard to read and that is because WMI uses the date and time formats defined by the Distributed Management Task Force DMTF.org Common Informaton Model (CIM) specification.

There is a .Net class ManagementDateTimeconverter can convert WMI time to system datetime:

PS C:\MyWorkPlace\PS> [System.Management.ManagementDateTimeconverter]::ToDateTime("20060125222312.000000-300")

Wednesday, January 25, 2006 10:23:12 PM

Also the below script can do the same:

http://www.jdhitsolutions.com/resources/scripts/ConvertWMITime.txt

PowerShell script execution policy

When PowerShell is installed, script execution is disabled by default. This is controlled by the PowerShell execution policy.

PowerShell has the following execution policies defined:

Restricted – This is the default execution policy on installation. When this policy is in effect, script execution is disabled. PowerShell itself is not disabled. It may still be used as an interactive command interpreter. While this is the most secure policy, it severely impacts our ability to use PowerShell for automation.

AllSigned – When the execution policy is AllSigned, scripts can be executed, but they must be Authenticode-signed before they will run. When running a signed script, you will be asked if you want to trust the signer of the script.

RemoteSigned – RemoteSigned requires that all scripts that are downloaded from a remote location must be Authenticode-signed before they can be executed.

Unrestricted – When the execution policy is unrestricted, PowerShell will run any script. It will still prompt the user when it encounters a script that has been downloaded however, this is the least secure setting.

The execution policy is controlled by a registry. Two comdlets, Get-ExecutionPolicy and Set-ExecutionPolicy, can be used to view and change this key.

You can also use the registry provider to find out the current execution policy setting:

PS P:\> (Get-ItemProperty "HKLM:\Software\Microsoft\Powershell\1\ShellIds\Microsoft.Powershell").ExecutionPolicy
RemoteSigned

Of course, it’s much easier to check it with Get-ExecutionPolicy:

PS P:\> Get-ExecutionPolicy
RemoteSigned

PowerShell script to check when the computer was last patched (Using Windows Update Agent API)

Here is a small PS script to check when the target computer was last patched and what patch was installed.

$objSession = New-Object -com "Microsoft.Update.Session"

$objSearcher= $objSession.CreateUpdateSearcher()

$colHistory = $objSearcher.QueryHistory(1, 1)

Foreach($objEntry in $colHistory)
{
Write-host $objEntry.Title
Write-host $objEntry.Date
}

Unfortunately this doesn’t work on remote computer. (It can work on remote computer if using VBS). I am trying to figure out a way to use .NET or remote registry to do the same for remote computer without success so far.