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-Host. Write-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-Host. Write-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

SilentlyContinue

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

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.

Feature

Write-Host

Write-Information

Writes directly to the screen

Yes

No

Can display colors

Yes

No

Can be suppressed by the user

No

Yes

Can be redirected to another stream

No

Yes

Can have TAGs in the metadata

No

Yes

Can be saved in a variable

No

Yes

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

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.

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-ExpandPropertyName|

Get-CimInstance-ClassNameWin32_OperatingSystem|

ForEach-Object-Process {

$Obj=New-Object-TypeNamePSObject-Property @{

Name =$_.PSComputerName

OS =$Null

Product =$Null

}

If
($_.ProductType
-eq1) {$Obj.Product
="Client"}

ElseIf
($_.ProductType
-eq2) {$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

-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 (https://msdn.microsoft.com/en-us/library/aa394239(v=vs.85).aspx). 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.