Advanced Windows PowerShell Scripting Video Training

Advanced Windows PowerShell Scripting Video Training
Advanced Windows PowerShell Scripting Video Training

Tuesday, August 30, 2016

Another Advantage of Write-Information

Yesterday, at the end of my post, I mentioned that displaying information on the screen can slow down processing time.  It is true.  Here is a simple test.

First of all, execute this code in the ISE

Function Test-Information

For ($X = 0 ; $X -lt 1000; $X++)
    Write-Information -MessageData "The value of X is $X"

    Write-Information -MessageData "Script Complete" -InformationAction Continue

Next execute this line of code.
PS C:\> Measure-Command -Expression {Test-Information}
Script Complete

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 186
Ticks             : 1860662
TotalDays         : 2.15354398148148E-06
TotalHours        : 5.16850555555556E-05
TotalMinutes      : 0.00310110333333333
TotalSeconds      : 0.1860662
TotalMilliseconds : 186.0662

Take note of the milliseconds.  Now execute this line of code.
PS C:\> Measure-Command -Expression {Test-Information -InformationAction Continue}

Notice that we are using the –InformationAction parameter to tell PowerShell to display the information messages.  Now look at the milliseconds in the measurement data.
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 443
Ticks             : 4439468
TotalDays         : 5.13827314814815E-06
TotalHours        : 0.000123318555555556
TotalMinutes      : 0.00739911333333333
TotalSeconds      : 0.4439468
TotalMilliseconds : 443.9468

It took more than twice as long to run.  Moral of the story is this.  Let your user decide if they want to see the “extra” information or just let PowerShell run and do its thing.  

How to use Write-Information

It is always fun to write on a topic that people are passionate about.  Yes, we will be talking about Write-Host in this post.  I know, you either love it or you hate it.

PowerShell uses different “streams” of information.  Here is a quick visual.

Stream |  Definition             | Cmdlet
1      |  Success output         | Write-Output      
2      |  Errors                 | Write-Error       
3      |  Warning messages       | Write-Warning     
4      |  Verbose output         | Write-Verbose     
5      |  Debug messages         | Write-Debug       
6      |  Informational messages | Write-Information 
NA     |  User Experience        | Write-Host         

The above is a little display that I use in class.  Yes, it is created with Write-HostWrite-Host is OK to use if you need to create a user interface of some type.  PowerShell was designed to use the pipeline.  This is stream 1.  Notice that there is no stream for Write-HostWrite-Host sends information directly to the monitor.  There is a stream for Write-Information.

Write-Information became available with PowerShell 5.  Why do we have another cmdlet to put information on the screen? Well, first of all, the end user cannot stop Write-Host from working.  Take a look at this.

PS C:\>     $InformationPreference

The information stream is controlled by a global variable called $InformationPreferenceWrite-Host has no such global variable controlling it.  By default, your information messages are not displayed.

PS C:\> Write-Information -MessageData "Nothing will display"

PS C:\> 

However, you can override this in code.
PS C:\> Write-Information -MessageData "Something will display" -InformationAction Continue
Something will display

The –InformationAction parameter is one of the common parameters.  That means the user running the code can ask for your information messages if they want to see them.  You can also redirect the output of your information stream to another stream if it is appropriate.  You cannot do that with Write-Host because it sends information directory to the screen.  Below is a comparison of the two commands.

Writes directly to the screen
Can display colors
Can be suppressed by the user
Can be redirected to another stream
Can have TAGs in the metadata
Can be saved in a variable

I understand the draw that Write-Host has with its ability to display colors.  If you are creating a script that requires user interaction, go for it.  If you want code that works well with the pipeline and does not display information on the screen (Which can slow processing times) then consider making the switch to Write-Information.

Monday, August 29, 2016

What Version of Windows are on my Clients?

It has been a very busy few months for me.  As you can see below, I’ve been spending a little time on board some Ships of the United States Navy.  Time to get back to work!!!

So, how do you know what version of PowerShell your clients are running.  There are a variety of ways of doing this.  We are going to use a CIM sessions to remotely pull this information from your client machines.  A few things need to be in place first.

  1. PowerShell Remoting needs to be turning on. (
  2. Give your clients time to update their group policy.  This may take more than a day depending on how your network is laid out.
  3. Query the clients from Active Directory that you want to query.  Here is the link to the Remote Server Administrator Tools for Windows 10.  There are similar versions all the way back to Windows 7.  Install this on your client. (
  4. Execute Get-CIMInstance.

We are focused on the fourth item.  In the past, I’ve advocated using Invoke-Command.  That still works but a CIMSession is a bit lighter weight.  Below is our code.

Get-ADComputer -Filter * |
    Select-Object -ExpandProperty Name |
    Get-CimInstance -ClassName Win32_OperatingSystem |
    ForEach-Object -Process {
        $Obj = New-Object -TypeName PSObject -Property @{
            Name = $_.PSComputerName
            OS = $Null
            Product = $Null
        If ($_.ProductType -eq 1) {$Obj.Product = "Client"}
        ElseIf ($_.ProductType -eq 2) {$Obj.Product = "Domain Controller"}
        Else {$Obj.Product = "Server"}

        Switch -Wildcard ($_.Version)
            "10.0*" {$Obj.OS = "Windows 10/2016"}
            "6.3*" {$Obj.OS = "Windows 8.1/2012 R2"}
            "6.2*" {$Obj.OS = "Windows 8/2012"}
            "6.1*" {$Obj.OS = "Windows 7/2008 R2"}
            "6.0*" {$Obj.OS = "Windows Vista/2008"}
        Write-Output $Obj

The first line uses Get-ADComputer to gather all computer objects in your domain.  Make sure you collect only the objects that you are interested in.

The Select-Object line provides us with just the name of the node.  This is important because of the next line which utilizes Get-CIMInstance.  If you look at the –CIMSession parameter for Get-CIMInstance, you will see that it accepts STRING ByValue.

PS C:\> Get-Help Get-CimInstance -Parameter CIMSession

    Specifies the CIM session to use for this cmdlet. Enter a variable that contains the CIM session or a command that creates or gets the CIM session, such as the New-CimSession or
    Get-CimSession cmdlets. For more information, see about_CimSessions.
    Required?                    true
    Position?                    named
    Default value               
    Accept pipeline input?       True (ByValue)
    Accept wildcard characters?  false

We are using the Win32_OperatingSystem class to gather our information.  Two properties from this class that we are interested in are Version and ProductType.  You can see the documentation for the Win32_OperatingSystem class here (  We take the numeric values for these properties and translate them into something human readable.  This is done in a custom object which is then sent to the pipeline.
Name    OS              Product         
----    --              -------         
LON-DC1 Windows 10/2016 Domain Controller
LON-CL1 Windows 10/2016 Client    

One thing to note, this is not handling errors.  I have to leave some of the fun up to you.