Search results for 'app:weblogs' matching tags 'Scripting Guy!' and 'Boe Prox'

Installing WSUS on Windows Server 2012

Anonymous — Mon, 15 Apr 2013 05:00:00 GMT

Summary: Honorary Scripting Guy, Boe Prox, talks about installing WSUS on Windows Server 2012 via Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson, is here. Welcome back today to Honorary Scripting Guy, Boe Prox. Without further ado, here is Boe…

In a previous Hey, Scripting Guy! Blog post, Introduction to WSUS and PowerShell, I demonstrated how you can download the Windows Server Update Services (WSUS) installation file and use various parameters to customize a WSUS installation on a local or remote system. With Windows Server 2012, we get a new version of WSUS that can be installed through Server Manager and also by…you guessed it…Windows PowerShell!

We can do the installation by using the Install-WindowsFeature cmdlet and specifying the proper feature names that you would like to have installed. In the case of WSUS, we are looking only at the update services feature. I will also take a look at some of the new cmdlets that are available in the UpdateServices module, which is available in Windows Server 2012 to help configure the WSUS server.

Let’s take a look at the possible subfeatures that are available by using the Get-WindowsFeature cmdlet and specifying UpdateServices* for the Name parameter.

Get-WindowsFeature –Name UpdateServices*

You could try to install everything, but that will end badly for you because there will be a conflict between using the Windows Internal Database (WID) and using another SQL Server database (local or remote) to store the SUSDB database on.

So which one should I choose? That depends on your environment and what your requirements are to support patching in your enterprise. Luckily for you, I will show examples of using the WID database or using another SQL Server database as part of the WSUS installation. After the installation, I will show one last thing you can do as a post installation that will allow you to specify a new location for the software update files and where the database is located.

Let’s start with the easiest, which is the WID database. I say easiest because it really comes down to just running a single line of code to get everything installed. Just to see what might be installed, I can use the WhatIf switch first.

Install-WindowsFeature -Name UpdateServices -IncludeManagementTools –WhatIf

From the looks of it, not only will WSUS be installed, but we also will be installing the WID database and some IIS components that are used for client check-ins and other things. I am confident that this is what I need, so let’s remove WhatIf and let it run again.

Wait for a bit…

And we are now finished with the installation. As you can see, we have a message stating some additional configuration may be required before our WSUS server can be up and running. In this case, we still need to configure a location for the update files to be stored.

This is where wsusutil.exe will come into play. This executable is located at C:\Program Files\Update Services\Tools. Besides the usual parameters that you can use with this utility, there is another set of parameters that become available when you use the PostInstall argument.

.\wsusutil.exe postinstall /?

We have parameters for specifying where to store the content and for where to build the database, if needed. Note that this can be used to specify a database that is local or remote (you will see this used on a remote system later).

Before I say where I want the content, I had better create a folder to store it. I don’t want all of this on my system drive, so I will create the folder on my D: drive.

New-Item -Path D: -Name WSUS -ItemType Directory

Now I can run the following command to configure my content directory to download and save all of the update files to D:\WSUS.

.\wsusutil.exe postinstall CONTENT_DIR=D:\WSUS

And with that, we have now configured the content directory on another drive to save the update files. Very simple…and a big recommendation to do it regardless!

Specify an alternate SQL Server

What if I want to specify a different SQL Server for saving the data instead of relying on a WID instance locally? Fortunately for us (and as you saw previously), this is an available option by using WSUSUtil.exe PostInstall. Going back to the beginning, I will perform a different installation of WSUS, this time specifying that I want a different SQL Server database.

Install-WindowsFeature -Name UpdateServices-Services,UpdateServices-DB -IncludeManagementTools

Now we need to use WSUSUtil again to not only specify the Content directory, but also to specify the SQL Server database that I want to use for my WSUS server. The WSUS server must be on a domain for the remote SQL Server database build to work. If it isn’t, you will get a message that states the host is unknown.

.\wsusutil.exe postinstall SQL_INSTANCE_NAME="DC1\SQL2008" CONTENT_DIR=D:\WSUS

And after a few minutes, the configuration has completed with the Content directory on D:\WSUS and the SUSDB database configured on my remote SQL Server.

Inspect the WSUS Installation State

By using my current installation of WSUS and the remote SQL Server database, we can now check the Best Practices Analyzer to see if anything else is required before we configure the WSUS server and kick off synchronization get all of the update metadata.

Invoke-BpaModel -ModelId Microsoft/Windows/UpdateServices

Now let’s see the results of our scan…

Get-BpaResult -ModelId Microsoft/Windows/UpdateServices |

Select Title,Severity,Compliance | Format-List

With the exception that I haven’t configured the WSUS server to use a required language pack (English in my case), everything else is compliant. Now it is time to finish configuring the WSUS server and get this synchronization kicked off.

First I’ll configure the languages and tell my server where I want to synchronize. In this case I want to sync up with Microsoft Updates. After I do that, I will perform an initial synchronization to pull down all of the available categories, classifications, and possible updates that can be approved.

Note For more information about some of the configuration properties that are set in the following code, see IUpdateServerConfiguration Properties on MSDN.

#Get WSUS Server Object

$wsus = Get-WSUSServer

#Connect to WSUS server configuration

$wsusConfig = $wsus.GetConfiguration()

#Set to download updates from Microsoft Updates

Set-WsusServerSynchronization –SyncFromMU

#Set Update Languages to English and save configuration settings

$wsusConfig.AllUpdateLanguagesEnabled = $false

$wsusConfig.SetEnabledUpdateLanguages("en")

$wsusConfig.Save()

#Get WSUS Subscription and perform initial synchronization to get latest categories

$subscription = $wsus.GetSubscription()

$subscription.StartSynchronizationForCategoryOnly()

While ($subscription.GetSynchronizationStatus() -ne 'NotProcessing') {

Write-Host "." -NoNewline

Start-Sleep -Seconds 5

}

Write-Host "Sync is done."

You may have noticed that I didn’t have to run Import-Module before using the UpdateServices module cmdlets. This is because Windows PowerShell 3.0 supports automatic loading of the modules when a specific cmdlet from a module is used.

Now that we have pulled down the classifications and platforms, it is time to filter the platforms for which I want updates and the classifications I want. Your preference for platforms and classifications will vary based on your environment and requirements.

When that is done, we will configure WSUS to synchronize once a day automatically at midnight, and kick off another synchronization to pull down the update metadata (not the actual update files) from the Microsoft Update server.

#Configure the Platforms that we want WSUS to receive updates

Get-WsusProduct | where-Object {

$_.Product.Title -in (

'CAPICOM',

'Silverlight',

'SQL Server 2008 R2',

'SQL Server 2005',

'SQL Server 2008',

'Exchange Server 2010',

'Windows Server 2003',

'Windows Server 2008',

'Windows Server 2008 R2')

} | Set-WsusProduct

#Configure the Classifications

Get-WsusClassification | Where-Object {

$_.Classification.Title -in (

'Update Rollups',

'Security Updates',

'Critical Updates',

'Service Packs',

'Updates')

} | Set-WsusClassification

#Configure Synchronizations

$subscription.SynchronizeAutomatically=$true

#Set synchronization scheduled for midnight each night

$subscription.SynchronizeAutomaticallyTimeOfDay= (New-TimeSpan -Hours 0)

$subscription.NumberOfSynchronizationsPerDay=1

$subscription.Save()

#Kick off a synchronization

$subscription.StartSynchronization()

It may take a while to complete the synchronization. When it has completed, you can begin reviewing the available updates that your systems require. Whether you want to keep everything installed and configured on a single server or you want to keep your SUSDB database on a remote SQL Server, you will find that it is easily accomplished by using Windows PowerShell.

That is all for today’s blog about working with WSUS on Windows Server 2012. The next blog I have lined up will deal with using the UpdateServices module to configure the clients and approve or decline updates. In addition, we will dip our toes into WSUS API to set up Computer Groups for the clients and to remove clients from WSUS.

~Boe

Thank you, Boe, for a great blog post. Join us tomorrow for a guest blog by Honorary Scripting Guy and Windows PowerShell MVP, Don Jones.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Windows Software Update Services

Anonymous — Tue, 02 Apr 2013 05:00:00 GMT

Summary: Honorary Scripting Guy, Boe Prox, shares an excerpt from his contribution to the book, PowerShell Deep Dives.

Microsoft Scripting Guy, Ed Wilson, is here. This week we will not have our usual PowerTip. Instead we have excerpts from seven books from Manning Press. In addition, each blog will have a special code for 50% off the book being excerpted that day. Remember that the code is valid only for the day the excerpt is posted. The coupon code is also valid for a second book from the Manning collection.

Today, the excerpt is from PowerShell Deep Dives
Edited by Jeffery Hicks, Richard Siddaway, Oisin Grehan, and Aleksandar Nikolic.

Whether you just started using Windows PowerShell or are at a more advanced level, there are two things you should always look at while writing a script: performance and execution time. With the introduction of Windows PowerShell 3.0 there are a lot of new modules and cmdlets available to you. What a lot of people don’t realize is that Microsoft also improves and expands already existing modules, and their cmdlets. This is especially the case with Windows PowerShell 3.0.

Here’s Boe…

Although the UI can be clunky and slow, there is an API with WSUS, a new module that is available in Windows Server 2012, and even an open source WSUS module that I wrote called PoshWSUS, which can more effectively allow you to quickly manage and generate reports by using Windows PowerShell.

Instead of looking at the existing cmdlets available in the 2012 Windows Server Update Services module, I will dive into the API and show you some tricks to further extend the reach of Windows PowerShell into WSUS. I’ll show how to:

Look at the WSUS configuration and events.
Provide reporting on various client and patch statuses.
Start and view synchronization progress and history.
Viewing and create automatic installation rules to simplify patch management by approving the common updates that your clients require.

WSUS server configuration and events

In WSUS, some of the most basic administration concepts are client management and patch management. Before Windows Server 2012, the only two solutions to this were working with the UI or digging into the API via scripts or the open source module, PoshWSUS. With Server 2012, we now have a WSUS module called UpdateServices that makes managing clients easier. The UpdateServices module is only available to use on the WSUS server, which isn’t bad if you plan to use Windows PowerShell remoting to manage the server. If you are not running Windows Server 2012, the module will not be available, and you need to use the API to manage a remote WSUS server.

Initial connection

To make a connection to the WSUS server locally or remotely with the API, you need the WSUS Administration console installed on the system that you will be making the connection from. After the console has been installed, you will have access to the required assemblies that you can the load and use for the WSUS connection. So with that, lets load the assembly, and then we can make the initial connection to the WSUS server.

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null

For the connection attempt, I will be using the Microsoft.UpdateServices.Administration.AdminProxy class along with the GetUpdateServer() method. This method accepts 1 of 3 parameter sets based on your WSUS configuration and if it is a remote or local connection. For the remote connection that I will be making, I need only supply the remote system name, a Boolean value that will say whether the connection is secure, and the remote port that I need to connect to on the WSUS server. (Acceptable ports for WSUS are 8080 and 8530 for non-secure ports and 443 and 8531 for SSL.)

$Wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer(

"Boe-PC",

$False,

"8530"

)

$Wsus

WebServiceUrl : http://BOE-PC:8530/ApiRemoting30/WebService.asmx

BypassApiRemoting : False

IsServerLocal : True

Name : BOE-PC

Version : 6.2.9200.16384

IsConnectionSecureForApiRemoting : True

PortNumber : 8530

PreferredCulture : en

ServerName : BOE-PC

UseSecureConnection : False

ServerProtocolVersion : 1.8

From here, you can see what version of the WSUS software you are running, among other things. The most important thing here is that you can now see that we have successfully connected to the WSUS server.

Viewing WSUS configuration

After the initial connection has been made, you can easily take a look at the internal configuration settings of the WSUS server by using the GetConfiguration() method of the Microsoft.UpdateServices.Internal.BaseApi.UpdateServer object.

$wsus.GetConfiguration()

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateServer

LastConfigChange : 9/17/2012 2:22:43 AM

ServerId : 64ad0f03-e81d-4539-883d-0c08066d1e82

SupportedUpdateLanguages : {he, cs, fr, es...}

TargetingMode : Server

SyncFromMicrosoftUpdate : True

IsReplicaServer : False

HostBinariesOnMicrosoftUpdate : False

UpstreamWsusServerName :

UpstreamWsusServerPortNumber : 8530

UpstreamWsusServerUseSsl : False

UseProxy : False

ProxyName :

ProxyServerPort : 80

UseSeparateProxyForSsl : False

SslProxyName :

SslProxyServerPort : 443

AnonymousProxyAccess : True

ProxyUserName :

ProxyUserDomain :

HasProxyPassword : False

AllowProxyCredentialsOverNonSsl : False

…

This is just a marginal number of the 121 properties that are returned with this method. The majority of these properties are settable, meaning that you can easily update these from Windows PowerShell. Use caution when making any changes to the properties because it could leave your server in an unusable state!

Viewing the WSUS database connection

You can take a look at the database connection and the database properties from your WSUS server by using the GetDatabaseConfiguration() method and the CreateConnection() method from the created Microsoft.UpdateServices.Internal.DatabaseConfiguration object.

$wsus.GetDatabaseConfiguration()

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateServer

ServerName : MICROSOFT##WID

DatabaseName : SUSDB

IsUsingWindowsInternalDatabase : True

AuthenticationMode : WindowsAuthentication

UserName :

Password :

$wsus.GetDatabaseConfiguration().CreateConnection()

QueryTimeOut : 150

LoginTimeOut : 60

ConnectionPooling : True

ApplicationName : WSUS:powershell:1824

UserLoginName :

UseIntegrated : True

ConnectionString :

MaxPoolSize : 100

DoRetry : False

DefaultRetryTimes : 3

ServerName : MICROSOFT##WID

DatabaseName : SUSDB

Password :

IsConnected : False

InTransaction : False

The amount of detail that you can get regarding the database is pretty nice. In fact, you could dive even deeper into the database if you wanted, but that is beyond the scope of this blog.

Viewing WSUS event history

If you are interested in viewing the event history of the WSUS server, it can be reached by calling the GetUpdateEventHistory(StartDate,EndDate) method and supplying a Start Date and an End Date. In this case, I just want to look at the events that have occurred during the past hour.

$wsus.GetUpdateEventHistory("$((Get-Date).AddHours(-1))","$(Get-Date)")

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateServer

HasAssociatedUpdate : False

UpdateId : Microsoft.UpdateServices.Administration.UpdateRevisionId

HasAssociatedComputer : False

ComputerId :

Status : Unknown

WsusEventId : ContentSynchronizationSucceeded

WsusEventSource : Server

Id : f01cb84f-9a0b-4da8-a12a-39a6866c5787

CreationDate : 9/23/2012 7:08:20 PM

Message : Content synchronization succeeded.

IsError : False

ErrorCode : 0

Row : Microsoft.UpdateServices.Internal.DatabaseAccess.EventHistoryTableRow

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateServer

HasAssociatedUpdate : True

UpdateId : Microsoft.UpdateServices.Administration.UpdateRevisionId

HasAssociatedComputer : False

ComputerId :

Status : Unknown

WsusEventId : ContentSynchronizationFileDownloadSucceeded

WsusEventSource : Server

Id : 0c7ade08-87d6-4019-b676-0f50ce486591

CreationDate : 9/23/2012 7:08:20 PM

Message : Content file download succeeded. Digest: Source File: /msdownload/update/v3-19990518/cabpool/w

indowsinstaller-kb893803-v2-x86_830994754ba721add8a13bd0266d2e092f21cab0.exe Destination File:

F:\WsusContent\B0\830994754BA721ADD8A13BD0266D2E092F21CAB0.exe.

IsError : False

ErrorCode : 0

Row : Microsoft.UpdateServices.Internal.DatabaseAccess.EventHistoryTableRow

With this information, you could audit for any possible failures that have occurred with a recent synchronization or some other issue that might be cause for a WSUS issue.

Automatic Approval Rules

With WSUS, you can automate your patch approvals simply by creating and configuring Automatic Approval Rules. You can specify categories, target groups among other things to use for the rules.

Locating approval rules

To find out what approval rules are currently on the WSUS server, use the GetApprovalRules() method from the Microsoft.UpdateServices.Internal.BaseApi.UpdateServer object created from the initial connection.

$wsus.GetInstallApprovalRules()

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateServer

Id : 2

Name : Default Automatic Approval Rule

Enabled : False

Action : Install

Deadline :

CanSetDeadline : True

This is not actually all of the information for the approval rules. To find out what Target Groups, Classifications, and Categories are contained in the Microsoft.UpdateServices.Internal.BaseApi.AutomaticUpdateApprovalRule object, you need to use the GetComputerTargetGroups(), GetUpdateClassifications(), and GetUpdateCategories() methods, respectively.

$approvalRules = $wsus.GetInstallApprovalRules()

#Get the Update Classifications

$wsus.GetInstallApprovalRules()[0].GetUpdateClassifications()

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateSer

ver

Id : e6cf1350-c01b-414d-a61f-263d14d133b4

Title : Critical Updates

Description : A broadly released fix for a specific problem

addressing a critical, non-security related bug.

ReleaseNotes :

DefaultPropertiesLanguage :

DisplayOrder : 2147483647

ArrivalDate : 9/23/2012 6:51:37 PM

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateSer

ver

Id : 0fa1201d-4330-4fa8-8ae9-b877473b6441

Title : Security Updates

Description : A broadly released fix for a product-specific

security-related vulnerability. Security

vulnerabilities are rated based on their severity

which is indicated in the Microsoft® security

bulletin as critical, important, moderate, or low.

ReleaseNotes :

DefaultPropertiesLanguage :

DisplayOrder : 2147483647

ArrivalDate : 9/23/2012 6:40:34 PM

#Get the Computer Target Groups

$wsus.GetInstallApprovalRules()[0].GetComputerTargetGroups()

UpdateServer Id Name

------------ -- ----

Microsoft.UpdateService... a0a08746-4dbe-4a37-9adf... All Computers

#Get the Categories

$wsus.GetInstallApprovalRules()[0].GetCategories()

Type : Product

ProhibitsSubcategories : True

ProhibitsUpdates : False

UpdateSource : MicrosoftUpdate

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateSer

ver

Id : a105a108-7c9b-4518-bbbe-73f0fe30012b

Title : Windows Server 2012

Description : Windows Server 2012

ReleaseNotes :

DefaultPropertiesLanguage :

DisplayOrder : 2147483647

ArrivalDate : 9/23/2012 6:47:20 PM

Creating approval rules

Creating an approval is a simple process that involves first creating the approval object with a name and then filling in the blanks for the rest of the configuration (Target Groups, Categories, Classifications, and so on) on the object before deploying it on the server. First, verify that the rule I am going to create (named “2012Servers”) doesn’t exist:

#Look at current rules

$wsus.GetInstallApprovalRules()

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateServer

Id : 2

Name : Default Automatic Approval Rule

Enabled : False

Action : Install

Deadline :

CanSetDeadline : True

No Rules exist with the name I plan to use, so I can continue with the creation of the new Approval Rule.

Listing 1: Creating an Approval Rule

[cmdletbinding()]

Param (

[parameter(ValueFromPipeline=$True,Mandatory=$True,

HelpMessage="Name of WSUS server to connect to.")]

[Alias('WSUSServer')]

[string]$Computername,

[parameter()]

[Switch]$UseSSL

)

[reflection.assembly]::LoadWithPartialName(

"Microsoft.UpdateServices.Administration"

) | out-null

$Wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer(

$Computername,$UseSSL,$Port

)

#Create New Rule Object

$newRule = $wsus.CreateInstallApprovalRule("2012Servers")

##Categories

#Get Categories for Windows Server

$updateCategories = $wsus.GetUpdateCategories() | Where {

$_.Title -LIKE "Windows Server 2012*"

}

#Create collection for Categories

$categoryCollection = New-Object Microsoft.UpdateServices.Administration.UpdateCategoryCollection

$categoryCollection.AddRange($updateCategories)

#Add the Categories to the Rule

$newRule.SetCategories($categoryCollection)

##Classifications

#Get all Classifications for specific Classifications

$updateClassifications = $wsus.GetUpdateClassifications() | Where {

$_.Title -Match "Critical Updates|Service Packs|Updates|Security Updates"

}

#Create collection for Categories

$classificationCollection = New-Object Microsoft.UpdateServices.Administration.UpdateClassificationCollection

$classificationCollection.AddRange($updateClassifications )

#Add the Classifications to the Rule

$newRule.SetUpdateClassifications($classificationCollection)

##Target Groups

#Get Target Groups required for Rule

$targetGroups = $wsus.GetComputerTargetGroups() | Where {

$_.Name -Match "All Computers"

}

#Create collection for TargetGroups

$targetgroupCollection = New-Object Microsoft.UpdateServices.Administration.ComputerTargetGroupCollection

$targetgroupCollection.AddRange($targetGroups)

#Add the Target Groups to the Rule

$newRule.SetComputerTargetGroups($targetgroupCollection)

#Finalize the creation of the rule object

$newRule.Enabled = $True

$newRule.Save()

#Run the rule

$newRule.ApplyRule()

Let’s make sure that the rule is now created.

$wsus.GetInstallApprovalRules()

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateServer

Id : 2

Name : Default Automatic Approval Rule

Enabled : False

Action : Install

Deadline :

CanSetDeadline : True

UpdateServer : Microsoft.UpdateServices.Internal.BaseApi.UpdateServer

Id : 6

Name : 2012Servers

Enabled : True

Action : Install

Deadline :

CanSetDeadline : True

Now we have a new Approval Rule that will run to approve only the updates I specified to only Windows Server 2012 systems. Keep in mind that the automatic approval rules only run after WSUS synchronizes, and only synched updates will be eligible for the rule unless you run the rule manually.

In today’s blog, I showed a number of things that you can do with Windows PowerShell to manage your WSUS server by using the available APIs, such as looking at the configuration settings of the WSUS server and auditing events. Auditing and building Automatic Approval Rules and providing more detailed reporting is easily accomplished by using the APIs.

With Windows Server 2012, you do have the option of using the Update Services module to perform some basic WSUS administration such as patch approvals, but for more advanced configurations and reporting, the APIs are definitely the way to go.

There is also a module that I wrote called PoshWSUS that provides cmdlets that allow for a more advanced administration. With multiple options for automating your WSUS server, you can’t go wrong. If you write some scripts for your own WSUS server, I hope that you will share those with the rest of the community.

Here is the code for the discount offer today at www.manning.com: scriptw2
Valid for 50% off PowerShell Deep Dives and SQL Server Deep MVP Dives

Offer valid from April 2, 2013 12:01 AM until April 3 midnight (EST)

Ed Wilson, Microsoft Scripting Guy

Expert Commentary: 2012 Scripting Games Advanced Event 2

Anonymous — Tue, 17 Apr 2012 05:00:00 GMT

Summary: Microsoft community contributor, Boe Prox, provides expert commentary for 2012 Scripting Games Advanced Event 2.

Microsoft Scripting Guy, Ed Wilson, is here. Boe Prox is the expert commentator for Advanced Event 2.

Boe is currently a senior systems administrator with BAE Systems. He has been in the IT industry since 2003, and he has been working with Windows PowerShell since 2009. Boe looks to script whatever he can, whenever he can. He is also a moderator on the Official Scripting Guys Forum. Check out his current projects published on CodePlex: PoshWSUS and PoshPAIG.

Blog: Learn PowerShell | Achieve More
Guest posts on Hey, Scripting Guy! Blog
Twitter: @proxb

This is an event that relates very nicely to something that would be done in the “real world.” Tracking your services on each server is something that should be done daily to ensure that everything is working normally and to make sure that there are no anomalies occurring.

This event requires us to perform a query against local and/or remote servers to pull back all of the services and write out the data to a CSV file. This is definitely a job for Windows PowerShell!

Requirements

This event is not without requirements to give you more of a challenge, so let’s take a look at the key requirements:

You need to present your findings in a spreadsheet that includes the following information: the server name, the service name, the start mode of the service, the user account used to start the service, and the current status of the service.
You should use the easiest method possible to display the information in a spreadsheet.
You must include the ability to run the script on a local computer and on a remote computer.
You must include the ability to run the script with alternate credentials when operating against a remote computer, and you should impersonate the logged on user when running locally.
You do not need to add comment-based Help for this scenario, but additional points are awarded if you do include appropriate comment-based Help such as the description, examples, and parameters.
If the script requires admin rights to run, you should check to ensure that the script is running with admin rights. If those rights are not present, you should display an appropriate message and exit.
For the purposes of this exercise, do not write a module. You should make your script completely standalone and have no external dependencies. Therefore, everything needed should be put in this script. Failure to do so will cost you points.

Now that we know what is required for this script, we can begin to dive into the code and see what is going on. I will take the code apart in chunks to explain what I am doing and point out the areas that meet each requirement in addition to other areas that I feel are worth mentioning. I included some extra features for this script, and I will explain my reasoning behind this when I get to them.

The code

Function Get-ServiceData {

.SYNOPSIS

Command used to find all services with option to write to a CSV File

.DESCRIPTION

Command used to find all services with option to write to a CSV File

.PARAMETER Computername

A single or collection of systems to perform the query against

.PARAMETER Credential

Alternate credentials to use for query of services

.PARAMETER ToCSV

Name of CSV to write the results of the query to

.PARAMETER Throttle

Number of asynchronous jobs that will run at a time

.PARAMETER ShowProgress

Displays the progress of the services query

.NOTES

Author: Boe Prox

Created: 14March2012

.EXAMPLE

Get-ServiceData

Description

-----------

Retrieves all services from the local system

.EXAMPLE

$Servers = 'Server1','Server2','Server3'

Get-ServiceData -Computername $Servers -ShowProgress

Description

-----------

Retrieves all services from the remote servers and displays a progress bar

.EXAMPLE

$Servers = Get-Content Servers.txt

$Servers | Get-ServiceData -ShowProgress -Throttle 10

Description

-----------

Retrieves all services from the remote servers while running 10 runspace jobs at a time

and displays a progress bar to show the status of each runspace job.

.EXAMPLE

$Servers = Get-Content Servers.txt

$Servers | Get-ServiceData -Credential (Get-Credential) -ToCSV (Join-Path $pwd report.csv)

Description

-----------

Retrieves all services for each system in the Servers.txt file while using the supplied

alternate credentials and outputs the data to a CSV file.

#Requires -Version 2.0

[cmdletbinding(

DefaultParameterSetName = 'NonCSV'

)]

Param (

[parameter(ValueFromPipeline = $True,ValueFromPipeLineByPropertyName = $True)]

[Alias('CN','__Server')]

[string[]]$Computername = $Env:Computername,

[parameter()]

[System.Management.Automation.PSCredential]$Credential,

[parameter(ParameterSetName = 'CSV')]

[ValidateNotNullOrEmpty()]

[String]$ToCSV,

[parameter()]

[int]$Throttle = 5,

[parameter()]

[switch]$ShowProgress

)

If you are going to create an advanced function, you definitely have to have inline Help within that function. This does not mean that you write your own Help function and offer that. It means that you use the Help in Windows PowerShell to accomplish this task. I included examples about how to use this function so others can reference it when trying to run the command.

Also included is [cmdletbinding()], which makes this advanced function advanced by adding extra parameters such as –Verbose and –WhatIf. I also make sure that I add a default parameter value for my ComputerName parameter to point to the local machine if nothing is given. Also, if no file name is given with ToCSV, it will throw an error until a file name is specified.

Begin {

#Function that will be used to process runspace jobs

Function Get-RunspaceData {

[cmdletbinding()]

param(

[switch]$Wait,

[switch]$ShowProgress

)

Do {

$more = $false

Foreach($runspace in $runspaces) {

If ($runspace.Runspace.isCompleted) {

$Script:Report += $runspace.powershell.EndInvoke($runspace.Runspace) |

Select SystemName,Name,State,StartMode,StartName

$runspace.powershell.dispose()

$runspace.Runspace = $null

$runspace.powershell = $null

$Script:i++

If ($PSBoundParameters['ShowProgress']) {

Write-Progress -Activity 'Services Query' -Status ("Processing Runspace: {0}" -f $runspace.computer) `

-PercentComplete (($i/$totalcount)*100)

}

} ElseIf ($runspace.Runspace -ne $null) {

$more = $true

}

If ($more -AND $PSBoundParameters['Wait']) {

Start-Sleep -Milliseconds 100

}

#Clean out unused runspace jobs

$temphash = $runspaces.clone()

$temphash | Where {

$_.runspace -eq $Null

} | ForEach {

Write-Verbose ("Removing {0}" -f $_.computer)

$Runspaces.remove($_)

}

} while ($more -AND $PSBoundParameters['Wait'])

}

Write-Verbose ("Performing inital Administrator check")

$usercontext = [Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()

$IsAdmin = $usercontext.IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")

#Counter for Write-Progress

$Script:i = 0

#Main collection to hold all data returned from runspace jobs

$Script:report = @()

Write-Verbose ("Building hash table for WMI parameters")

$wmihash = @{

Query = "SELECT SystemName,Name,StartMode,State,Startname FROM Win32_Service"

ErrorAction = "Stop"

}

#Supplied Alternate Credentials?

If ($PSBoundParameters['Credential']) {

$wmihash.credential = $Credential

}

#Define hash table for Get-RunspaceData function

$runspacehash = @{}

If ($PSBoundParameters['ShowProgress']) {

$runspacehash.ShowProgress = $True

}

#Define Scriptblock for runspaces

$scriptblock = {

Param (

$Computer,

$wmihash

)

Write-Verbose ("{0}: Checking network connection" -f $Computer)

If (Test-Connection -ComputerName $Computer -Count 1 -Quiet) {

#Check if running against local system and perform necessary actions

Write-Verbose ("Checking for local system")

If ($Computer -eq $Env:Computername) {

$wmihash.remove('Credential')

} Else {

$wmihash.Computername = $Computer

}

Try {

Get-WmiObject @wmihash

} Catch {

Write-Warning ("{0}: {1}" -f $Computer,$_.Exception.Message)

Break

}

} Else {

Write-Warning ("{0}: Unavailable!" -f $Computer)

Break

}

Write-Verbose ("Creating runspace pool and session states")

$sessionstate = [system.management.automation.runspaces.initialsessionstate]::CreateDefault()

$runspacepool = [runspacefactory]::CreateRunspacePool(1, $Throttle, $sessionstate, $Host)

$runspacepool.Open()

Write-Verbose ("Creating empty collection to hold runspace jobs")

$Script:runspaces = New-Object System.Collections.ArrayList

$totalcount = $computername.count

}

The Begin block is pretty meaty but it sets up a lot of the code that will be processed later in the function.

A few of the requirements are covered here with an initial check for Administrator rights and allowing the code to run on a local or a remote system. A gotcha is also presented here because the use of alternate credentials will not work against a local system.

If a local system is included with other remote systems, the alternate credentials are simply removed from the runspace.

Although I do not have time to dive into everything here, I will say that this is where I set up a script block that handles each client computer, use two hash tables for splatting parameters (one for the Get-WMIObject cmdlet and another for a function that will be defined later). I also make use of the [runspacefactory] accelerator that allows me to set up some background runspace jobs and also allows throttling those runspaces, which allows for quicker processing of the queries. I chose this over using the *-Job cmdlets because there is not an easy way to throttle jobs, and this is more of a lightweight method to run jobs in a background runspace.

To quickly jump into an example, the following screenshots show the amount of time it took to run this function by using the background runspaces versus using a more synchronous command, ForEach, against 132 systems.

Get-ServiceData Function

Using ForEach

As you can see, the difference is about 220 seconds. While not a massive amount of time, it is still a nice improvement over the synchronous way using ForEach. Credit for the throttling technique goes to Windows PowerShell MVP, Dr. Tobias Weltner, for his webcast, Speeding Up PowerShell: Multithreading, which explained the use of [runspacefactory] to provide throttling.

Process {

Write-Verbose ("Validating that current user is Administrator or supplied alternate credentials")

If (-Not ($Computername.count -eq 1 -AND $Computername[0] -eq $Env:Computername)) {

#Now check that user is either an Administrator or supplied Alternate Credentials

If (-Not ($IsAdmin -OR $PSBoundParameters['Credential'])) {

Write-Warning ("You must be an Administrator to perform this action against remote systems!")

Break

}

ForEach ($Computer in $Computername) {

#Create the powershell instance and supply the scriptblock with the other parameters

$powershell = [powershell]::Create().AddScript($ScriptBlock).AddArgument($computer).AddArgument($wmihash)

#Add the runspace into the powershell instance

$powershell.RunspacePool = $runspacepool

#Create a temporary collection for each runspace

$temp = "" | Select-Object PowerShell,Runspace,Computer

$Temp.Computer = $Computer

$temp.PowerShell = $powershell

#Save the handle output when calling BeginInvoke() that will be used later to end the runspace

$temp.Runspace = $powershell.BeginInvoke()

Write-Verbose ("Adding {0} collection" -f $temp.Computer)

$runspaces.Add($temp) | Out-Null

Write-Verbose ("Checking status of runspace jobs")

Get-RunspaceData @runspacehash

}

The Process block does just that: processes all of the computers and assigns each computer as a background runspace. More requirements are met here, including the finishing check of Administrator rights if running against remote systems. If there is only a local system and it is the only system in the collection, alternate credentials are not required nor are Administrator rights because any local user can perform a query against WMI.

End {

Write-Verbose ("Finish processing the remaining runspace jobs: {0}" -f (@(($runspaces | Where {$_.Runspace -ne $Null}).Count)))

$runspacehash.Wait = $true

Get-RunspaceData @runspacehash

Write-Verbose ("Closing the runspace pool")

$runspacepool.close()

If ($PSBoundParameters['ShowProgress']) {

#Close the Write-Progress bar so it does not affect the displaying of data when completed.

Write-Progress -Activity 'Services Query' -Status 'Completed' -Completed

}

If ($PSBoundParameters['ToCSV']) {

Write-Verbose ("Writing report to CSV: {0}" -f $ToCSV)

$Report | Export-Csv -Path $ToCSV -NoTypeInformation

} Else {

Write-Verbose ("Displaying Report")

Write-Output $Report

}

The End block finishes up the remaining runspace jobs, and depending on what the user chose for output (CSV or no CSV), the function will output the data to the console or write all of the data to a specified CSV file (meeting an important requirement). I chose to use Export-CSV because it meets the requirement for the easiest method possible to create a CSV file. If I was using Windows PowerShell 3.0, I could have thrown this in with the runspace script block and used the –Append parameter to further increase the performance of this function instead of holding all of the data until the end and writing out to the CSV file.

Let’s give it a quick run to see it in action and view the final output.

$Servers = Get-Content .\servers.txt

Get-ServiceStartMode -Computername $servers -ShowProgress -ToCSV "C:\users\boe\desktop\report.csv"

As you can see, all of the data that was required is on the spreadsheet to view.

The script is available to download from the Script Center Repository.

~Boe

2012 Scripting Games Guest Commentator Week will continue tomorrow when we will present the scenario for Event 3.

Ed Wilson, Microsoft Scripting Guy

Tips for Preparing for the 2012 PowerShell Scripting Games

Anonymous — Fri, 30 Mar 2012 05:00:00 GMT

Summary: Guest commentator, Boe Prox, talks about practical tips for preparing for the 2012 Windows PowerShell Scripting Games.

Microsoft Scripting Guy, Ed Wilson, is here. Guest blogger, Boe Prox, is with us today. He is going to talk to us about preparing for the 2012 Scripting Games. First, a little bit about Boe…

Boe Prox is currently a senior systems administrator with BAE Systems. He has been in the IT industry since 2003, and he has been working with Windows PowerShell since 2009. Boe looks to script whatever he can, whenever he can. He is also a moderator on the Hey, Scripting Guy! Forum. Check out his current projects published on CodePlex: PoshWSUS and PoshPAIG.
Boe’s blog: Learn PowerShell | Achieve More

Take it away Boe…

With the Scripting Games coming up on April 2, you might be asking yourself, “What do I need to do to be prepared for these games?” You are in luck because I am going to show some things that will help you in your quest for scripting glory!

These tips are in no particular order of importance, and they cover a wide variety of items that should be used to increase the readability of your code and to ease any issues that the people who are using your scripts may run into. So without further ado, let’s get started!

Variables that make sense

When you are deciding what you want to call the variables that are used in your code, keep in mind that others will be reading your code, whether it is in the Scripting Games or at your place of work. Or you might have to debug or add something to your code several months later, so using something like this for your code will only make the effort to read the code more difficult.

$strServers = 'server1','server2'

$d = Get-Date

ForEach ($C in $strServers) {

$objp = Get-WmiObject -computer $c Win32_Process

}

There are a couple of things here that can stand to be changed. First off, the $strservers that is using Hungarian notation is not needed. Although it is often used in VBScript script, it isn’t needed in Windows PowerShell script. Using something that lets you know what the variable is holding—in this case, servers—is suitable, rather than knowing the type of the variable.

Although, I would rather use ComputerName because that is a common parameter in Windows PowerShell cmdlets. $d, $objp, and $c are the remaining the variables that fail to make it easy to know what is being used for each variable. Given, this is a small snippet of code, but imagine if you are working with 100+ lines of code. It would be more difficult to back track and find out what each variable is. Something like this would be much easier to read and understand.

$Computername = 'server1','server2'

$date = Get-Date

ForEach ($computer in $Computername) {

$processes = Get-WmiObject -computer $computer Win32_Process

}

Error handling

If you are writing functions or scripts (or whatever), you need to be using some sort of error handling in your code. This will prevent unwanted errors from popping up and preventing your code from working. Now, I don’t mean to add $ErrorActionPreference = ‘SilentlyContinue’ at the top of your code and let it fly. If you are using that to solve your error handling, you are only fooling yourself. In other words, remove it immediately! It’s OK, I’ll wait.

What you should be doing is investing in using Try/Catch in your code to handle any potential errors that might pop up. All cmdlets have the ErrorAction parameter, and you can choose to use Stop. Or if you really don’t want to catch any errors (or even know about errors), you can use SilentlyContinue. The benefit of using this parameter is that it will only affect that command, not the all of the commands in the code. The following example of using this method will catch an error if something goes wrong.

ForEach ($Computer in $Computername) {

If (Test-Connection -ComputerName $Computer -Count 1 -Quiet) {

Try {

Get-WmiObject -Computer $Computer -Class Win32_Process -ErrorAction Stop

} Catch {

Write-Warning ("{0}: {1}" -f $Computer,$_.Exception.Message)

}

} Else {

Write-Warning ("{0}: Unavailable" -f $Computer)

}

A couple of other types of error handling use specific cmdlets to test for. Test-Connection checks if a system is online before making a connection for a query or some other operation. Test-Path checks to see if a folder or file exists.

Also, checking for Administrator rights is a useful thing to do within your code, especially when working with remote systems or accessing parts of a system that are otherwise off limits to a regular user account. It also helps if you have UAC enabled and are not running the script “as an Administrator.” I wrote a guest blog last year that talked about this: Check for Admin Credentials in a PowerShell Script.

Code formatting

Making your code readable can be just as important as making your code work properly to perform the action that you want it to do. Having code that is not readable makes it difficult to debug when something goes wrong. In addition, others trying to read the code may end up spending more time putting it into a proper format than actually debugging it or modifying it for their own environment. Things to consider when writing your code are:

Use spacing between areas of code to separate blocks of code.
Use natural line breaks: “|”,”{“.
Indent your code in areas where groups of code are being used logically, such as after an opening bracket “{“ or after a pipeline character is used. This ensures that all the lines of code within the construct are easy to identify and work with.
Use splatting for parameters where it threatens to force the use of a back tick (“`”) to enable a line break to continue the code.

Following is an example of poorly formatted code:

There is a lot wrong with this code, ranging from no spacing, to indenting blocks of code where it is incased in a {} construct, to cmdlets using enough parameters to warrant a line break to keep everything from going off of the screen. Also, there are areas in the code that really aren’t needed, such as saving the result of the Test-Connection cmdlet and then comparing the return when it is a Boolean value in the If statement.

This is what it should look like:

What you have now is something that is not only easier to read, but also takes advantage of other techniques, such as splatting the parameters for Get-WmiObject and taking advantage of the Boolean return value for using the Quiet parameter in Test-Connection for the If statement. Instead of using something like @{L='Computer';E={$_.__Server}},@{L='TimeGenerated';E={Get-Date}}} to add a couple extra properties to the output that is difficult to read, I used a ForEach loop and created my own object to make it easier to read. This really starts to show its usefulness when you are trying to add multiple properties to the output that are not available any other way.

There are more lines of code being used here. But trust me, it is worth it to have more readable code than taking shortcuts by cramming it all together.

Comment-based Help

Something that I saw last year (especially in the first few events), and I sometimes still see, are people writing their own Help in their code. Although it is great to see that some sort of Help is being added into their code so other people know what is going on with it, there is no reason to be doing this. The Windows PowerShell team has put together an amazing thing called comment-based Help that does practically all of the work for you. It has some great features such as displaying examples, viewing the full Help of the command, and looking at the details of a particular parameter. It is so simple that you can practically do it in your sleep! See this example:

Everything within “<#” and “ #>” that uses the appropriate keywords will be read by Windows PowerShell and used to format the Help correctly so it shows something similar to the following:

Get-Help Get-StoppedService

Everything that can help a person figure out what to do with this code is here. Want to know the specifics about the ComputerName property? Simple! Just do this:

Get-Help Get-StoppedService –Parameter Computername

How cool is that? This is much better than only getting one option when writing your own Help—which is typically to display everything at once. Need an example? Just do this:

Get-Help Get-StoppedService -Example

Remember, comment-based Help is your friend, and it should be used instead of writing your own Help. For more information about comment-based Help, run the following command:

Get-Help about_Comment_Based_Help

Other things to consider

I don’t have the time to dive into detail about these other items, but they are by no means any less important to think about and use while writing your code. It is just that I only have a limited amount of time and space to pick and choose which items to talk about.

Use output objects instead of text, and make it pipeline friendly.
Do not use aliases for anything (this includes cmdlets and parameters).
Use properly named functions (Verb-Singular noun).
Use Get-Verb to see approved verbs.
Keep inline comments to a minimum (consider using Write-Verbose instead).
Use [cmdletbinding()] and Param() in advanced functions; This allows the use of common parameters such as Verbose, Debug, WhatIf, and ErrorAction.
Consider using Write-Progress for long running tasks where you are looping through a collection; this allows the user to know where the script is and does not assume it has locked up.

Final thoughts

Keep in mind that during the Scripting Games you may not always get the score that you were hoping for. But don’t let that get you down! Keep writing code and submitting your scripts, learn from what the judges say, and look at the scripts your fellow scripters have submitted. You will improve on your current skills and continue to put together great scripts!

To quote myself from last year on twitter during the 2011 Scripting Games: “Remember that as long as you did your best on your script and are happy with what you did, then grading should be secondary.”

Good luck to all of the scripters this year!

~Boe

Thank you Boe. This is a great summary of things to keep in mind for the 2012 Scripting Games. Join us tomorrow for more Scripting Games prep week.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Automate SCOM Agent Installations

Anonymous — Mon, 13 Feb 2012 06:00:00 GMT

Summary: Guest blogger, Boe Prox, shows how to use Windows PowerShell to automate SCOM agent installations.

Microsoft Scripting Guy, Ed Wilson, is here. Last month, guest blogger, Boe Prox, wrote a series of blogs about WSUS. Today he is back to talk about SCOM.

Here’s Boe…

Recently, I was asked to write a script to run against our new SCOM servers that would automate the SCOM agent installation for servers that are being joined to the domain and provide a report on those that successfully installed and also for those that failed to install. This way our SCOM administrators have a report of new systems that are managed by the agents, and they will also have a way to troubleshoot and, if required, manually install the agents on the systems that report failures.

Although I was not completely familiar with SCOM like the SCOM admins are, I do know my way around Windows PowerShell, and I was able to put something together that would meet all of the requirements. So without further ado, let us dive into the script that I wrote, which is also available on the Script Repository: SCOM Agent Installation and Reporting Script.

Requirements for script

Our goal for this script is to query Active Directory for all servers, query SCOM for all currently monitored servers on the network, and then filter out all of the systems that are in Active Directory so we only have unmanaged servers to work with. We can then attempt to discover those servers (a requirement before we can push an agent installation), filter out failed discoveries so only the successes remain, and finally attempt the installation of the agent on the rest of the servers. Lastly, we need to generate a report that lists Successful Installations, Failed Installations, and Failed Discoveries, and email it to the system administrators. Simple enough with Windows PowerShell!

For this script to run properly and do what we need it to do, we need to make sure that we can connect to Active Directory to gather all of the servers. We also need to ensure that we are running the script from a server that has the SCOM snap-in available. You can find this by running the following command.

Get-PSSnapin –Registered

You should see the following item listed with everything else: Microsoft.EnterpriseManagement.OperationsManager.Client

This means that the SCOM snap-in is installed, and we can run this script from the server without worrying about it failing.

Digging into the script

Let us take a look at the first parts of the script.

$VerbosePreference = 'continue'

Function Get-Server {

$strCategory = "computer"

$strOS = "Windows*Server*"

$objSearcher = [adsisearcher]""

$objSearcher.Filter = ("(&(objectCategory=$strCategory)(OperatingSystem=$strOS))")

$objSearcher.pagesize = 10

$objsearcher.sizelimit = 5000

$objSearcher.PropertiesToLoad.Add("dnshostname") | Out-Null

$objSearcher.Sort.PropertyName = "dnshostname"

$colResults = $objSearcher.FindAll()

foreach ($objResult in $colResults) {

$objComputer = $objResult.Properties

$objComputer.dnshostname

}

Here, I set up the VerbosePreference to “Continue” so I can track what the script is doing and where it is, in case something goes wrong. It is always good to include some sort of verbose/debug output in your scripts, so that not only you, but whoever uses your script will know what is going on during its use. Using my Get-Server function is a quick and simple way to pull a list of servers from Active Directory, and I add the DNSHostName attribute that I can use in my comparison later on. I chose the DNSHostName attribute because it matches up with the data that I will later receive when performing the SCOM query.

###User Defined Parameters

Write-Verbose ("[{0}] Reviewing user defined parameters" -f (Get-Date))

#SCOM Management Server

$SCOMMgmtServer = 'SCOMMGMT.rivendell.com'

#SCOM RMS Server

$SCOMRMS = "SCOMMGMT.rivendell.com"

#Systems to Exempt from SCOM

$Exempt = @(Get-Content Exempt.txt)

$Emailparams = @{

To = 'boeprox@rivendell.com'

From = 'SCOMAgentAudit@rivendell.com'

SMTPServer ='Exch.rivendell.com'

Subject = "SCOM Agent Audit"

BodyAsHTML = $True

}

Here I have my “user defined” parameters, where you need to update the existing parameters that match your environment. Listed are places for the SCOM management and RMS server, in addition to an optional exempt parameter in case you have systems that you cannot (for various reasons) have the SCOM agent installed on. If you notice the $EmailParams parameter, you will see that it is actually a hash table of several parameters that will be used at the end of this script for an email notification. By the way, this is called “splatting.” Learn it, live it, love it.

#Get list of AD Servers

Write-Verbose ("[{0}] Getting list of servers from Active Directory" -f (Get-Date))

$ADServers = Get-Server | Where {$Exempt -NotContains $_}

#Initialize SCOM SnapIn

Write-Verbose ("[{0}] Loading SCOM SnapIn" -f (Get-Date))

Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client -ErrorAction SilentlyContinue

#Make SCOM Connection

Write-Verbose ("[{0}] Connecting to SCOM RMS Server: {1}" -f (Get-Date),$SCOMRMS)

New-ManagementGroupConnection -ConnectionString $SCOMRMS | Out-Null

#Connect to SCOM Provider

Write-Verbose ("[{0}] Connecting to SCOM Provider" -f (Get-Date))

Push-Location ‘OperationsManagerMonitoring::’

Write-Verbose ("[{0}] Connecting to SCOM Server: {1}" -f (Get-Date),$SCOMMgmtServer)

$MgmtServer = Get-ManagementServer | Where {$_.Name -eq $SCOMMgmtServer}

#Get all SCOM Agent Servers

Write-Verbose ("[{0}] Gathering all SCOM managed systems" -f (Get-Date))

$SCOMServers = Get-Agent | Select -Expand NetworkName | Sort

#Compare list to find servers not in SCOM

Write-Verbose ("[{0}] Filtering out all Non SCOM managed systems to audit" -f (Get-Date))

$NonSCOMTEMP = @(Compare-Object -ReferenceObject $SCOMServers -DifferenceObject $ADServers | Where {

$_.SideIndicator -eq '=>'

} | Select -Expand Inputobject)

Now we are starting to perform some actions to get this script rolling. First, I use my little function to grab a list of all of the servers in Active Directory and filter out all of the systems that I listed in my exempt list. The next part loads up the SCOM snap-in so we are able to make use of the SCOM cmdlets. Next, I make the connection to the SCOM management server that was specified earlier in the script. When we have that connection, I switch directories to the “OperationsManagerMonitoring::” provider, which is required to run the commands later in the script. After all of this, I begin my query of SCOM for all servers currently being managed via the SCOM agent, and I use Compare-Object to filter out the servers from my Active Directory list that are already listed in SCOM. We now have our list of servers that we need to focus on to install the SCOM agent.

#Attempt to Discover Systems

Write-Verbose ("[{0}] Configuring SCOM discovery prior to use" -f (Get-Date))

$Discover = New-WindowsDiscoveryConfiguration -ComputerName $NonSCOM -PerformVerification -ComputerType "Server"

$Discover.ComputerNameDiscoveryCriteria.getComputernames() | ForEach {Write-Verbose ("{0}: Attempting to discover" -f $_)}

Write-Verbose ("[{0}] Beginning SCOM discovery" -f (Get-Date))

$DiscResults = Start-Discovery -WindowsDiscoveryConfiguration $Discover -ManagementServer $MgmtServer

#Check Alert history for failed Discoveries

Write-Verbose ("[{0}] Checking for failed Discoveries" -f (Get-Date))

$alerts = @(Get-Alert -Criteria "PrincipalName = '$SCOMMgmtServer' AND MonitoringClassId='ab4c891f-3359-3fb6-0704-075fbfe36710'`

AND Name='An error occurred during computer verification from the discovery wizard'") | Where {

#Look for unresolved alerts

$_.ResolutionState -eq 0

}

Here I am setting up for my attempted discovery of the servers that need the SCOM agent installed. I use my current collection of servers that is supplied to the ComputerName parameter for New-WindowsDiscoveryConfiguration, which I save to $Discover. I then supply this variable to the Start-Discovery cmdlet, and save the results of this discovery to $DiscResults, which looks something like this:

This can be used later when I prepare to push out the SCOM agent installations.

Now that I went through the discovery process, a check is performed against the SCOM management server by using Get-Alert. I supply the principal name of the management server, filter to look only for failed discoveries, and save any results that are found so they can be parsed later and added to a collection for reporting.

If ($Alerts.count -gt 0) {

#Start processing the failed discovery alerts

$alert = $alerts | Select -Expand Parameters

$Pattern = "Machine Name: ((\w+|\.)*)\s"

$FailedDiscover = $alert | ForEach {

$Server = ([regex]::Matches($_,$Pattern))[0].Groups[1].Value

Try {

$ServerIP = ([net.dns]::Resolve($Server).AddressList[0])

} Catch {

$ServerIP = $Null

}

If (-Not ([string]::IsNullOrEmpty($Server))) {

New-Object PSObject -Property @{

Server = $Server

Reason = $_

IP = $ServerIP

}

Resolve the alerts for failed discoveries, otherwise we will have false positives that there were no failed discoveries.

Write-Verbose ("[{0}] Resolving active alerts" -f (Get-Date))

$Alerts | ForEach {

Resolve-Alert -Alert $_ | Out-Null

}

If failed discoveries are found in the alert log, the script digs out the Parameters property of the $alert collection, and the systems will get parsed from the log by using some regular expression magic. Then an attempt to get the IP address will be performed. The expanded Parameters property will look similar to this:

Computer verification failure for Machine Name: DC1.Rivendell.com is 0x800706BA. The RPC server is unavailable.

Any generated reports will be saved to the $FailedDiscover variable that will be sent in the email report at the end of the script. After this is done, all of the alerts that are found are resolved by the script.

If ($DiscResults.CustomMonitoringObjects.count -gt 0) {

#Install Agent on Discovered Servers

Write-Verbose ("[{0}] Beginning installation of SCOM Agent on discovered systems" -f (Get-Date))

$DiscResults.custommonitoringobjects | ForEach {Write-Verbose ("{0}: Attempting Agent Installation" -f $_.Name)}

$Results = Install-Agent -ManagementServer $MgmtServer -AgentManagedComputer: $DiscResults.custommonitoringobjects

Now for the installation of the systems that we were able to successfully discover! If you remember, I saved the results of the discovery to the $DiscResults variable. Now I am able to use that to supply the collection of systems for the agent installation by using the CustomMonitoringObjects property of the $DiscResults collection. Note that I have saved the results of this agent installation to $Results that will be parsed later in the script, and those results will be included in the email report.

#Check for failed installations

$FailedInstall = @{}

$SuccessInstall = @{}

Write-Verbose ("[{0}] Checking for Failed and Successful installations" -f (Get-Date))

$Results.MonitoringTaskResults | ForEach {

If (([xml]$_.Output).DataItem.ErrorCode -ne 0) {

#Failed Installation

$FailedInstall[([xml]$_.Output).DataItem.PrincipalName] = `

(([xml]$_.output).DataItem.Description."#cdata-section" -split "\s{2,}")[0]

} Else {

#Successful Installation

$SuccessInstall[([xml]$_.Output).DataItem.PrincipalName] = `

Get-Date ([xml]$_.output).DataItem.Time

}

And by later in the script, I mean now. I first create two empty hash tables that will hold the successes and failures that are found. The results of the agent installation were first split based on the error code that is in the XML data. From there, if a failure is detected, the code continues to parse the failure message from the XML and place it into the $FailedInstall hash table. A failed installation result will look similar to this:

The task will register as a success, so I have to dig into the output XML to pull the actual error code for the agent installation. If it is a successful installation, the system is added to the $SuccessInstall hash table, which will be sent in the email report at the end of the script.

$head = @"

<style>

TABLE{background-color:LightYellow;border-width: 1px;border-style: solid;border-color: black;border-collapse: collapse;}

TH{border-width: 1px;padding: 5px;border-style: solid;border-color: black;}

TD{border-width: 1px;padding: 5px;border-style: solid;border-color: black;}

</style>

If ($SuccessInstall.Count -gt 0) {

Write-Verbose ("[{0}] Adding {1} Successful installations to report" -f (Get-Date), $SuccessInstall.Count)

$html1 = @"

<html>

<body>

<h5>

Please view in html!

</font>

</h5>

<h2>

The following servers were found in Active Directory and had the SCOM Agent successfully installed:

</h2>

$($SuccessInstall.GetEnumerator() | Select Name, Value | Sort Name | ConvertTo-HTML -head $head)

</body>

</html>

} Else {

$html1 = $Null

}

If ($FailedInstall.Count -gt 0) {

Write-Verbose ("[{0}] Adding {1} Failed installations to report" -f (Get-Date), $FailedInstall.Count,)

$html2 = @"

<html>

<body>

<h5>

Please view in html!

</font>

</h5>

<h2>

The following servers are Active Directory and were discovered, but Failed to install the SCOM Agent:

</h2>

$($FailedInstall.GetEnumerator() | Select Name,Value | Sort Name | ConvertTo-HTML -head $head)

</body>

</html>

} Else {

$html2 = $Null

}

If ($FailedDiscover.Count -gt 0) {

Write-Verbose ("[{0}] Adding {1} Failed Discoveries to report" –f (Get-Date), $FailedDiscover.Count)

$html3 = @"

<html>

<body>

<h5>

Please view in html!

</font>

</h5>

<h2>

The following servers are Active Directory but Failed to be Discovered by SCOM:

</h2>

$($FailedDiscover | Sort Server | ConvertTo-HTML -head $head)

</body>

</html>

} Else {

$html3 = $Null

}

If ($html1 -OR $html2 -OR $html3) {

$Emailparams['Body'] = "$($Html1,$Html2,$Html3)"

} Else {

$Emailparams['Body'] = @"

<html>

<body>

<h5>

Please view in html!

</font>

</h5>

<h2>

All servers in Active Directory are currently being managed by SCOM Agents.

</h2>

</body>

</html>

}

Write-Verbose ("[{0}] Sending Audit report to list of recipients." -f (Get-Date))

Send-MailMessage @Emailparams

We are now at the end of the script where the data we have collected is compiled into HTML and added to the body of the email. Take note of the @EmailParams that is supplied to the Send-MailMessage cmdlet. This is “splatting” being used to supply all of the parameters to the cmdlet. Although I am sure that my HTML code could be a little better, it does well enough to provide a nice readable report to review. If there is nothing to report, an email will still go out. This is a reminder that if a report didn’t go out, it should be investigated for possible issues.

Script in action

Typically, this script is better run as a scheduled job to ensure that any server being brought into the domain receives the SCOM agent. But for this example, I am going to run it to show the verbose output that is generated and to show the email notification showing the HTML body.

The report that is emailed will look something like this, based on the data that was received during the duration of the script.

So there you go…

With a little research and testing against a platform that I was not all that familiar with at the time, I was able to put together a nice script. My script automated the installation of SCOM agents for new servers that were brought into the domain, and provided a report on the installations and failures.

~Boe

Thank you, Boe, for sharing. As always, it is an interesting and informative blog.

Ed Wilson, Microsoft Scripting Guy

Use the Free PoshWSUS PowerShell Module for WSUS Administrative Work

Anonymous — Sun, 22 Jan 2012 06:00:00 GMT

Summary: Learn how to use the free PoshWSUS Windows PowerShell module to administer your WSUS server.

Microsoft Scripting Guy, Ed Wilson, is here. We wrap up the weekend and the week with guest blogger, Boe Prox. In case you missed them, here are links for Boe’s blogs:

Day 1: Introduction to WSUS and PowerShell

Day 2: Use PowerShell to Perform Basic Administrative Tasks on WSUS

Day 3: Approve or Decline WSUS Updates by Using PowerShell

Day 4: Use PowerShell to Find Missing Updates on WSUS Client Computers

Day 5: Get Windows Update Status Information by Using PowerShell

Day 6: Introduction to PoshWSUS, a Free PowerShell Module to Manage WSUS

Take it away, Boe…

We are at the final stopping point in our week of WSUS and this final blog is all about WSUS administration using my PoshWSUS module. The past week has seen us create a WSUS server and managing the server by using Windows PowerShell and the WSUS assemblies, but now we are going to look at this using fewer commands by using the PoshWSUS module. I will now show some examples that use the module to perform some of the exact commands that were done earlier in the week.

Initial use of PoshWSUS

To download the module, see PoshWSUS in CodePlex. Unzip the files to your Modules directory—in my case for Windows 7, it is C:\Users\Boe\Documents\WindowsPowerShell\Modules. I saved the modules to a folder named PoshWSUS. This location is shown here.

Load the module by using the Import-Module cmdlet. This command is shown here.

Import-Module PoshWSUS

The following image shows me using the Get-Module cmdlet to view the available cmdlets and using the Import-Module cmdlet to import the module.

Make your initial connection to the WSUS server. To do this, use the Connect-WSUSServer cmdlet as shown here.

Connect-WSUSServer -WsusServer DC1

The following image shows the connection to the WSUS server named DC1.

Now you are set to go!

Client and group management

Let’s start by looking at some basic client and group administration commands that you may find yourself using when you administer the server. The following example lists all clients that are registered in the WSUS Server.

Get-WSUSClient

The output from the Get-WSUSClient cmdlet is shown here.

If you only want to list a specific client that is registered on the WSUS server, you can run the following command to get the data.

Get-WSUSClient -Computer boe-pc

The following image shows the result of running the Get-WSUSClient cmdlet. Note that it provides lots of good information about the client computer.

For some extra fun, you can even use the Group-Object cmdlet to group all of your clients by operating system. A command to do this is shown here.

Get-WSUSClient | Group OSDescription | Select Count,Name

The command and associated output are shown in the image that follows.

If you want to display all of the target groups that are in the WSUS server, you can run use the Get-WSUSGroup command.

Get-WSUSGroup

If you want to add a client into a specific group, you can run this one-liner:

Get-WSUSClient boe-pc | Add-WSUSClientToGroup -Group TESTGROUP

Let’s verify that my client is actually in that group by using Get-WSUSClientGroupMembership.

Get-WSUSClientGroupMembership -Computer boe-pc

Looking at the returned data, it would appear that the client is in the TESTGROUP group.

Removing a WSUS client from a group is just as simple as using Remove-WSUSClientFromGroup. This command is shown here.

Remove-WSUSClientFromGroup -Computer boe-pc -Group TESTGROUP

One more check to see if my client is no longer in TESTGROUP. The results are shown here.

As you can see, my client is now a member of Unassigned Computers, meaning that it is not a member of any group in WSUS other than the default All Computers group.

Creating a new group on WSUS is made simple by using New-WSUSGroup. Here, I create a new group named MyGroup.

New-WSUSGroup “MYGROUP” –PassThru

The results of creating the new MyGroup group are shown in the following image.

In addition to creating new groups, I can remove a WSUS group. It is just as easy to remove a group, as it is to create a group. I use the Remove-WSUSGroup cmdlet. An example of doing this is shown here.

Get-WSUSGroup -Name MYGROUP | Remove-WSUSGroup

Update administration

Now for some more fun stuff: using PoshWSUS to work with Update administration. I have two commands (Approve-WSUSUpdate and Deny-WSUSUpdate) that make approving and declining updates easy to do. Besides that, you can use Get-WSUSUpdate to look for updates on the WSUS server. Unfortunately, “Decline” is not an approved verb in Windows PowerShell, so I went with “Deny” instead.

Using Get-WSUSUpdate without any parameters will return every single update on the WSUS server. In this case, I want to see all of the Windows 7 updates.

$updates = Get-WSUSUpdate 'Windows 7'

$updates.count

$updates | Select -first 10

Approve-WSUSUpdate does take pipeline input from the Update object, so if you wanted to approve some updates that you queried, you could do the following:

$updates[1..10] | Approve-WSUSUpdate -Action Install -Group 'All Computers' –PassThru

In the same way, you can decline updates by piping the updates into Deny-WSUSUpdate. This command is shown here.

$updates[1..10] | Deny-WSUSUpdate

Here is a fun one! You can use Get-WSUSUpdate and New-WSUSUpdateScope to list all the updates that have been released on the last Patch Tuesday and are required by the clients, as shown here.

Get-WSUSUpdate -UpdateScope (New-WSUSUpdateScope -IncludedInstallationStates NotInstalled -FromArrivalDate "12/13/2011")

You can then pipe this output into Approve-WSUSUpdate:

Get-WSUSUpdate -UpdateScope (New-WSUSUpdateScope -IncludedInstallationStates NotInstalled -FromArrivalDate "12/13/2011") | Approve-WSUSUpdate -Action Install -Group 'All Computers' –PassThru

It is always a good idea to review each update to make sure that you want to approve it in your environment.

Reporting

So I have covered some administration examples that use this module, but what about some type of reporting capability? Well, I will show you some different types of reports that you can do with this module.

I can look for updates that have failed to install by using the following command:

Get-WSUSUpdatePerClient -UpdateScope (New-WSUSUpdateScope -IncludedInstallationStates Failed)

Fortunately for me (but unfortunate for this example), I do not have any updates that reported failures in the installation.

I can mimic what is shown in the following example of the Administration Console by using Get-WSUSUpdateSummaryPerClient.

Get-WSUSUpdateSummaryPerClient -ComputerScope (New-WSUSComputerScope) -UpdateScope (New-WSUSUpdateScope)

The output is shown here:

We can even generate a report of update approvals by using Get-WSUSUpdateApproval if you want to go back to see what has been approved and/or who approved a specific update. In this case, let’s go back and look at my update approvals for all of the updates from this Patch Tuesday.

$updatescope = New-WSUSUpdateScope -FromArrivalDate "12/13/2011"

Get-WSUSUpdateApproval -UpdateScope $updatescope

If you wanted to get a report of patches that are needed by clients in a specific group, you can give this command a run:

Get-WSUSUpdateSummaryForGroup -GroupName 'All Computers' -UpdateObject $updates[200..300]

Other commands to use

Besides the commands that I have shown in this blog post, there are other commands that you may find useful during your administration of a WSUS server. So, without further ado, here are some command examples:

Show the current synchronization schedule by using Get-WSUSSubscription:

Get-WSUSSubscription

Listing all Install Approval rules on your WSUS server is also easy by using Get-WSUSInstallApprovalRule. For those of you who are not familiar with Install Approval, basically it allow you set up automatic approvals of specific products for specific computer target groups. Pretty nice if you know that you want to approve critical security updates for all of your clients every month.

Get-WSUSInstallApprovalRule

In the same way, you can configure a new Install Approval rule by using New-WSUSApprovalRule and Set-WSUSApprovalRule.

$group = Get-WSUSGroup -Name 'All Computers'

$class = Get-WSUSUpdateClassification | Where {$_.Title -eq "Updates"}

New-WSUSInstallApprovalRule -Name "Rule1" -Category $cat -Classification $class -Group $group –Enable –PassThru

You can even run the Install Approval rules by using Start-WSUSInstallApprovalRule.

Start-WSUSInstallApprovalRule -Name "Rule1"

If you wanted to locate the files for each update and their location on the server, you can run the Get-WSUSInstallableItem command.

$updates[0] | Get-WSUSInstallableItem

You can dig into the files a little deeper to see how many files and where exactly they are located:

$updates[0] | Get-WSUSInstallableItem | Select –Expand Files

That wraps it up for my week with WSUS and Windows PowerShell and also talking about my PoshWSUS module. I have more updates planned, including adding more commands (such as publishing non-Microsoft updates to WSUS) and updating existing commands. Remember that if you see something that you would like to see added to the module or you find a bug in it, please log your issues and ideas in the CodePlex Issue Tracker. Thank you everyone for checking out my blogs and thanks to Ed for allowing me to take over a week of Hey, Scripting Guy! to talk WSUS and Windows PowerShell!

~Boe

Thanks, Boe, for an awesome week of Windows PowerShell goodness. Join us tomorrow for a new week on the Hey, Scripting Guy! blog.

Ed Wilson, Microsoft Scripting Guy

Introduction to PoshWSUS, a Free PowerShell Module to Manage WSUS

Anonymous — Sat, 21 Jan 2012 06:00:00 GMT

Summary: Guest blogger, Boe Prox, discusses the development of the free Windows PowerShell module that he wrote to manage WSUS.

Microsoft Scripting Guy, Ed Wilson, is here. Today we are celebrating our 2000^th Hey, Scripting Guy! blog. I think that in the spirit of community, it is appropriate that today we also have a guest blogger, Boe Prox, who is talking about a project that he developed and shared on CodePlex.

I will let him speak for himself—take it away Boe…

After a week of working with Windows PowerShell and WSUS and showing you some pretty cool things that you can do with the two, I am going to talk about a project that I have been working on that will make administering a WSUS server easier with Windows PowerShell.

Here are the blogs from the past week if you would like to catch up:

Day 1: Introduction to WSUS and PowerShell

Day 2: Use PowerShell to Perform Basic Administrative Tasks on WSUS

Day 3: Approve or Decline WSUS Updates by Using PowerShell

Day 4: Use PowerShell to Find Missing Updates on WSUS Client Computers

Day 5: Get Windows Update Status Information by Using PowerShell

My plan today is to give an overview of what PoshWSUS is and why I built it the way I did, plus show a couple of small examples. Tomorrow I will show you more examples of using PoshWSUS to accomplish some of the same tasks that I have been showing earlier in the week in addition to a few new things.

What is PoshWSUS?

PoshWSUS is a module that I designed and built to help a system administrator manage a WSUS server easily by using Windows PowerShell. To download the module, see PoshWSUS in CodePlex.

Currently, there are 60 commands that are available in version 2.0, which was recently released on Dec. 18, 2011. There are various commands that one can use with this module. Although a majority of commands are query-type commands, there are other commands that allow you to approve or decline updates, create groups, add clients to groups, and work with synchronizations (to name a few). Here is a full list of the commands available:

PoshWSUS originally started as one module file (.psm1) that contained approximately 45 commands. This file was over 2000 lines long, which made it extremely difficult to work with, especially when it came time to troubleshoot one of the commands.

When it came time to work on version 2.0 of PoshWSUS, I made the decision to separate each of the commands into its own file to make it much easier to work with. I can then use the module file to go through each of the files and dot source the functions from those files.

Why PoshWSUS?

I work with WSUS almost daily, and wanted a way to quickly perform a query or quick update approval against WSUS without having to jump onto the Administration Console and click, click, click my way to victory. Another piece of motivation that I used in writing this module is that there was no module for WSUS at all. Sure, there are various scripts available that perform various queries, approvals, and so on—but never a module that really tied everything together and covered a wide threshold of things to do in WSUS. Thus, PoshWSUS comes into play to fill in that gap and allow people to manage their WSUS server from the command line.

So with that, I will talk a little about some of the new things that my latest version brings into play.

Working with custom types

One of the things that I was determined to change was the way that the output from any command would be displayed in the console. By default, if you run a command that would list a client or update, you would be crushed by a sea of data for each client and update that was returned unless you used Select-Object or Format-Table and listed only the properties that you wanted to see. Obviously, I couldn’t add this into my commands because I would lose the object type and also limit the amount of data that was available to a user.

Here is an example of such output from an update query:

Pretty wild, isn’t it? Well, thanks to custom-type formatting, I can dictate what is displayed by each output while still preserving the object type. Now, I won’t go into detail about how this works because that would be a blog (or two) in itself. But as you can see in the following example, it greatly simplifies the display of the output while still retaining the object’s type.

So it looks better AND retains the object type.

Even if you use Format-List, it will not show every property unless you specify by using the “*”. This is shown here.

Adding properties to an existing type

While most of the data that is returned by a query is useful, sometimes you get some properties that aren’t as helpful in their current state. For instance, let’s look at the following output:

The Updated is not exactly something that we can use because we have no idea what update it is referring to. By adding some extra properties for this type (Microsoft.UpdateServices.Internal.BaseApi.UpdateSummary), we can translate that ID into the following:

As you can tell, there are a couple of properties that are null, and this is by design for this object. How this query is performed will determine which of the UpdateTitle, ComputerGroup, and Computer properties would be populated. This technique is used with several types to provide clearer data that is returned on various queries.

Most of the information about working with type formatting was via Jeffery Hicks and my time at the PowerShell Deep Dive where he presented on the subject. Here is some information about Jeff:
Blog: The Lonely Administrator
Twitter: https://twitter.com/JeffHicks
YouTube video of Deep Dive session: Mastering Format and Type Extensions

Removing plural nouns

Another thing that I changed was some of the names of the commands in the module. Originally, I had several modules that were named with a plural noun and another that was singular, such as Get-WSUSClient and Get-WSUSClients. It is poor practice in Windows PowerShell to have a plural-named noun for a command, so I made sure to merge those commands into one that used a singular noun.

Providing feedback

Feedback from the community drives any project, and this module is no different. I encourage anyone who uses this module to please let me know what they like and don’t like about it. Any bugs that you find or anything that you feel would make a good feature is always helpful to the growth of PoshWSUS. You can log issues and ideas in the CodePlex Issue Tracker.

That pretty much sums up my module, PoshWSUS and gives you a little more information about its beginnings and some of the new things I did with version 2.0. Tomorrow I will go into how to use PoshWSUS, explore some of the commands, show you how to achieve some of the same results from some of the commands we have been using during the past week, and show you a few new things. See you tomorrow!

~Boe

Ed Wilson, Microsoft Scripting Guy

Get Windows Update Status Information by Using PowerShell

Anonymous — Fri, 20 Jan 2012 06:00:00 GMT

Summary: Learn how to use the WSUS Update Scope with Windows PowerShell to get update status information for client computers.

Microsoft Scripting Guy, Ed Wilson, is here. What a week. Boe Prox has certainly been sharing quite a bit of Windows PowerShell goodness. In case you have missed them, here are links to the blog series thus far. You can also see Boe’s biography in the Day 1 blog.

Day 1: Introduction to WSUS and PowerShell

Day 2: Use PowerShell to Perform Basic Administrative Tasks on WSUS

Day 3: Approve or Decline WSUS Updates by Using PowerShell

Day 4: Use PowerShell to Find Missing Updates on WSUS Client Computers

Today we are moving from working with the Computer Target Scope and generating some cool reports to working with the Update Scope on the WSUS server. Much like yesterday, I will dive into some of the objects that we have worked with throughout the week and make use of some of the methods that require the Update Scope object to work properly.

If you are asking, “What is the Update Scope?”

…As the name implies, this is a scope that can be used to filter a list of updates on the WSUS server.

Creating the Update Scope object

Much as we did with the Computer Target Scope object, we need first to create the Update Scope object so we can then look at its properties and make adjustments, if needed. To create this object, we need to use the Microsoft.UpdateServices.Administration.UpdateScope class. For more information about this class, see UpdateScope Class on MSDN. The code that follows creates an instance of the UpdateScope.

$updatescope = New-Object Microsoft.UpdateServices.Administration.UpdateScope

OK, let’s take a look at these properties. The image that follows displays this information.

Here is a list of the editable properties for the Update Scope object:

ApprovedStates	Gets or sets the approval states to search for. An update will be included only if it matches at least one of the specified states. This value may be a combination of any number of values from ApprovedStates. Defaults to Any.
ExcludedInstallationStates	Gets or sets the installation states to exclude. An update will be included only if it does not have any computers in any of the specified states. This value may be a combination of any number of values from UpdateInstallationStates. Defaults to 0.
ExcludeOptionalUpdates	Gets or sets whether to exclude optional updates from the list.
FromArrivalDate	Gets or sets the minimum arrival date to search for. An update will be included only if its arrival date is greater than or equal to this value.
FromCreationDate	Gets or sets the minimum creation date to search for. An update will be included only if its creation date is greater than or equal to this value.
IncludedInstallationStates	Gets or sets the installation states to search for. An update will be included only if it has at least one computer in one of the specified states. This value may be a combination of any number of values from UpdateInstallationStates.
IsWsusInfrastructureUpdate	Gets or sets whether or not to filter for WSUS infrastructure updates. If set to true, only WSUS infrastructure updates will be included. If set to false, all updates are included. Defaults to false.
TextIncludes	Gets or sets the string to search for. An update will be included only if its Title, Description, Knowledge Base articles, or security bulletins contains this string.
TextNotIncludes	Gets or sets the string to exclude. An update will be not be included if its Title, Description, Knowledge Base articles, or security bulletins contains this string.
ToArrivalDate	Gets or sets the maximum arrival date to search for. An update will be included only if its arrival date is less than or equal to this value.
ToCreationDate	Gets or sets the maximum creation date to search for. An update will be included only if its creation date is less than or equal to this value.
UpdateApprovalActions	Gets or sets the update approval actions to search for. An update will be included only if it is approved to at least one computer target group for one of the specified approval actions. This value may be a combination of any number of values from UpdateApprovalActions. Defaults to All.
UpdateApprovalScope	Gets or sets the UpdateApprovalScope object that can be used to filter updates based on their approval properties.
UpdateSources	Gets or sets the update sources to search for. An update will be included only if its update source is included in this value. This value may be a combination of any number of values from UpdateSources.
UpdateTypes	Gets or sets the update types to search for. An update will be included only if its update type is included in this value.

Yes, that is a fairly large list of properties that we can modify to suit our filtering needs. For the sake of simplicity, I am only going to update ApprovedStates, IncludedInstallationStates, and FromArrivalTime to show how you can see all of the updates that are needed by all of the clients since the last patch Tuesday. The code that follows updates these three properties.

$updatescope.ApprovedStates = [Microsoft.UpdateServices.Administration.ApprovedStates]::NotApproved

$updatescope.IncludedInstallationStates = [Microsoft.UpdateServices.Administration.UpdateInstallationStates]::NotInstalled

$updatescope.FromArrivalDate = [datetime]"12/13/2011"

Note: For the purposes of this blog, the last patch Tuesday was December 13. I set the ApprovedStates property to NotApproved because I only want to see updates that are required by the clients that are not already approved for installation. I set the IncludedInstallationStates to NotInstalled. This will tell the filter to look for only updates that are required by the clients, but have not been installed yet. This works fine for us because these updates are new to us and because we only want those for the most recent patch Tuesday.

First, I am going to show you the Administration Console and look at all updates that are required by the clients on the network since patch Tuesday. This is shown in the image that follows.

Note the number of updates (30) and some of the titles listed here. Although not all of the updates are listed in the image, I will show you a couple of methods that we can use to pull the exact same information by using Windows PowerShell!

GetUpdateCount()

This method, as you can probably tell, will allow us to view the number of updates that are returned by using the previously configured Update Scope.

$wsus.GetUpdateCount($updatescope)

Look at that, 30 updates—just as if it showed on the console.

I am going to expand on this slightly by using another method similar to one I showed you yesterday for the Computer Target Scope.

GetUpdateStatus()

This will return a little more information about the updates, as you will see. Besides supplying the Update Scope object, I need to supply a Boolean value for whether to include DownStream Computers.

$wsus.GetUpdateStatue($updatescope,$False)

That is pretty cool, but we want to see those updates as well. Sure enough, we can use the GetUpdates() method and supply our Update Scope object to pull this information.

$wsus.GetUpdates($updatescope) | Select Title

And there you have it! You can compare the screenshots and you will see that the titles in the console match the titles from our query.

Now I will show you how to view the update approvals by using the Update Scope object and the GetUpdateApprovals() method. To make this work and to provide some useful information, I will make a couple of adjustments to the existing Update Scope. This revision is shown here.

$updatescope.FromArrivalDate = [datetime]"10/01/2011"

$updatescope.ApprovedStates = [Microsoft.UpdateServices.Administration.ApprovedStates]::LatestRevisionApproved

Now we can use this scope in the method and pull some information. To do this, I use the GetUpdateApprovals method, and pass it the Update Scope. This technique is shown in the code that follows.

$wsus.GetUpdateApprovals($updatescope)

The result from the previous command is shown in the following image.

Let us clean this up a little so it is more readable and not just a bunch of GUIDs. The code that follows produces an easier to read output.

$wsus.GetUpdateApprovals($updatescope) | Select @{L='ComputerTargetGroup';E={$_.GetComputerTargetGroup().Name}},

@{L='UpdateTitle';E={($wsus.GetUpdate([guid]$_.UpdateId.UpdateId.Guid)).Title}},GoLiveTime,AdministratorName,Deadline

The result of the previous code is shown here.

The last two things I will show you in this blog are a couple of methods that require the Update Scope object and the Computer Target Scope object to work properly. They provide some nice reporting features similar to what you would see in the Administration Console.

GetSummariesPerComputerTarget()

This method gets per-computer summaries for each of the specified computers, summed across all of the specified updates.

Let’s see this in action, where I use the following code to gather this information.

$computerscope = New-Object Microsoft.UpdateServices.Administration.ComputerTargetScope

$updatescope = New-Object Microsoft.UpdateServices.Administration.UpdateScope

$wsus.GetSummariesPerComputerTarget($updatescope,$computerscope) |

Format-Table @{L='ComputerTarget';E={($wsus.GetComputerTarget([guid]$_.ComputerTargetId)).FullDomainName}},

@{L='NeededCount';E={($_.DownloadedCount + $_.NotInstalledCount)}},DownloadedCount,NotApplicableCount,NotInstalledCount,InstalledCount,FailedCount

The output from the previous code produces a nice table, as shown here.

Let’s see how this compares to what you would see in the console. One thing you do not have available in the console is the DownloadedCount, which our previous code nicely displayed.

Lastly, let’s look at the GetSummariesPerUpdate() method to get per-update summaries for each of the specified updates, summed across all of the specified computers. The following code uses this method.

$updatescope.ApprovedStates = [Microsoft.UpdateServices.Administration.ApprovedStates]::NotApproved

$updatescope.IncludedInstallationStates = [Microsoft.UpdateServices.Administration.UpdateInstallationStates]::NotInstalled

$updatescope.FromArrivalDate = [datetime]"12/13/2011"

$wsus.GetSummariesPerUpdate($updatescope,$computerscope) |

Format-Table @{L='UpdateTitle';E={($wsus.GetUpdate([guid]$_.UpdateId)).Title}},

@{L='NeededCount';E={($_.DownloadedCount + $_.NotInstalledCount)}},DownloadedCount,NotApplicableCount,NotInstalledCount,InstalledCount,FailedCount

Note: I changed the Update Scope to what I had at the beginning of this blog. This is so I can more accurately compare the output here with what is in the Administration Console.

The output from the previous code is shown here.

Now compare the previous image, with the console (shown here), and you will see that they match up as planned.

So there you have it. We spent the week starting out with a WSUS server installation, then doing some basic administration, and we finished by providing some reports using Windows PowerShell—and we haven’t even begun to scratch the surface of what we can do. But working with WSUS doesn’t end here! This weekend I will talk about update 2.0 to my WSUS module, PoshWSUS, which you can use to more easily manage and maintain a WSUS server.

~Boe

Boe, this is great stuff. Thank you for sharing with us. WSUS Week will continue tomorrow.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Find Missing Updates on WSUS Client Computers

Anonymous — Thu, 19 Jan 2012 06:00:00 GMT

Summary: Learn how to use the computer target scope with Windows PowerShell to find WSUS client computers that are missing updates.

Microsoft Scripting Guy, Ed Wilson, is here. We are halfway through WSUS Week and some really good stuff from Boe Prox. You can see Boe’s biography in the Day 1 blog. In case you need to catch up with the series on Windows Software Update Services (WSUS), the following blogs will get you up to speed:

Day 1: Introduction to WSUS and PowerShell

Day 2: Use PowerShell to Perform Basic Administrative Tasks on WSUS

Day 3: Approve or Decline WSUS Updates by Using PowerShell

Now, here is Boe…

Over the past few days, I have been showing you some basic administration examples of what you can do by using Windows PowerShell to manage a WSUS server. During the course of some of these examples, I alluded to some methods that required a Computer Target Scope object. Well, today is the day that I get to show you how you can build a Computer Target Scope object and use that with some of the existing objects we have already created.

“What is the Computer Target Scope?” you ask? The Computer Target Scope is, as the name implies, a scope that that can be used to filter a list of clients. For more information about this class, see ComputerTargetScope Class on MSDN.

Creating the Computer Target Scope object

The first thing we need to do is create the scope object, which we can then use in some of the methods we have seen. To do this will require us to create the new object from the Microsoft.UpdateServices.Administration.ComputerTargetScope class.

$computerscope = New-Object Microsoft.UpdateServices.Administration.ComputerTargetScope

Simple enough to do, and we can choose to leave the default properties that are already set for this object if we want to.

So as a default object, this will reference all clients on the WSUS server. Fortunately, you can edit most of these properties to narrow down the clients that you want to use. Here is a list of the editable properties:

ExcludedInstallationStates	Gets or sets the installation states to exclude.
FromLastReportedStatusTime	Gets or sets the earliest reported status time.
FromLastSyncTime	Gets or sets the earliest last synchronization time to search for.
IncludedInstallationStates	Gets or sets the update installation states to search for.
IncludeDownstreamComputerTargets	Gets or sets whether or not clients of a downstream server, not clients of this server, should be included.
IncludeSubgroups	Gets or sets whether the ComputerTargetGroups property should include descendant groups.
NameIncludes	Gets or sets a name to search for.
OSFamily	Gets or sets the operating system family for which to search.
ToLastReportedStatusTime	Gets or sets the latest last reported status time to search for.
ToLastSyncTime	Gets or sets the latest last synchronization time to search for.

Working with the Computer Target Scope

Now, if you remember from the previous posts, there are some methods from the Update object (Microsoft.UpdateServices.Internal.BaseApi.Update) and from the WSUS object (Microsoft.UpdateServices.Internal.BaseApi.UpdateServer) that require a computer scope object to work.

Let’s take a look at some of these methods from the respective objects and see what we are able to pull.

[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")

#Connect to the WSUS Server and create the wsus object

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer('dc1',$False)

#Create a computer scope object

$computerscope = New-Object Microsoft.UpdateServices.Administration.ComputerTargetScope

#Find all clients using the computer target scope

$wsus.GetComputerTargets($computerscope)

By leaving the default properties, we will pull every client from the WSUS server.

Another method that we can use, which provides a report on the computers that match the scope filter is GetComputerStatus(). This method requires that you have a computer scope object and that you define a Microsoft.UpdateServices.Administration.UpdateSources object, which consists of All, Microsoft Update, or Other. Let’s give it a look.

$Wsus.GetComputerStatus($computerscope,[ Microsoft.UpdateServices.Administration.UpdateSources]::All)

You might be wondering why we are seeing mostly 0s here. If you look closely, you can see that only the areas where it mentions the computer targets are populated. This is by design for this object’s method because we only specified to get the status of the computers that match the scope filter.

Now, looking at the update object’s method, I can see a couple of methods that are available and require the computer scope.

GetSummary()

This will give us a summary of whether the clients that are specified in the scope require the update.

$updates = $wsus.SearchUpdates('Update for Windows Server 2003 (KB938759)')

$update = $updates[0]

$update.GetSummary($computerscope)

UnknownCount : 0

NotApplicableCount : 2

NotInstalledCount : 0

DownloadedCount : 1

InstalledCount : 0

InstalledPendingRebootCount : 0

FailedCount : 0

IsSummedAcrossAllUpdates : False

UpdateId : c2cdd066-7a03-4e7f-976c-139b5de943ed

ComputerTargetGroupId : 00000000-0000-0000-0000-000000000000

ComputerTargetId :

LastUpdated : 12/10/2011 7:08:29 AM

By looking at the data provided, I can see that only 1 client out of the 3 require this update and that it has already been downloaded to that client. This is a nice way of providing a report of a specific update’s status for clients. But the problem is…which client requires the update? I will show you how to use the GetUpdateInstallationInfoPerComputerTarget() method on the Update object.

$update.GetUpdateInstallationInfoPerComputerTarget($ComputerScope)

Although it does tell you which client ID requires the update, it’s not what I would call “humanly readable” by any means. But this is Windows PowerShell, after all, and we can certainly make this better for us to read.

$update.GetUpdateInstallationInfoPerComputerTarget($ComputerScope) |

Select @{L='Client';E={$wsus.GetComputerTarget(([guid]$_.ComputerTargetId)).FulldomainName}},

@{L='TargetGroup';E={$wsus.GetComputerTargetGroup(([guid]$_.UpdateApprovalTargetGroupId)).Name}},

@{L='Update';E={$wsus.GetUpdate(([guid]$_.UpdateId)).Title}},

UpdateInstallationState,UpdateApprovalAction

Much better! Now we have something that not only tells us which client, but actually gives us the name of the client without giving us a GUID to try to guess with. I also translated the Target Group ID and the Update ID so that everything is much easier to read.

Well, that wraps it up for today. Tomorrow I will jump into working with the Update Scope object and performing queries that use that object.

~Boe

Boe, thank you for another great blog about using the WSUS object model. WSUS Week will continue tomorrow.

Ed Wilson, Microsoft Scripting Guy

Approve or Decline WSUS Updates by Using PowerShell

Anonymous — Wed, 18 Jan 2012 06:00:00 GMT

Summary: Guest blogger, Boe Prox, shows how to use Windows PowerShell to approve or to decline updates for WSUS.

Microsoft Scripting Guy, Ed Wilson, is here. Welcome to the third day of Boe Prox as our guest blogger talking about using Windows PowerShell with WSUS.

Day 1: Introduction to WSUS and PowerShell

Day 2: Use PowerShell to Perform Basic Administrative Tasks on WSUS

Here’s Boe…

Continuing on from yesterday’s post where we looked at managing clients and groups, it is time to look at that one thing that really defines the WSUS server. I am talking about updates, of course! We will start by performing a basic query to locate updates and explore the update object to see what methods we have available, and then we will go into approving and declining updates.

Update queries

Using our existing connection from the previous day’s examples, let’s look at the possible methods related to locating updates on the WSUS server.

GetUpdates()

This method will give you back EVERY SINGLE UPDATE on your WSUS server. (This is assuming that you have completed a successful synchronization—if not, synchronize your WSUS server now.) This method is painfully slow to run and it is not a recommended method to gather information about updates.

$wsus.GetUpdates()

…Well, this is awkward. Oh wait, since I just installed this WSUS server, I have not performed a critical task that will allow me to start viewing updates. I need to synchronize this WSUS server with the Microsoft upstream server and get all of my update data.

WSUS synchronization

Let’s take a detour on our little trip through working with updates to get this server synced up and ready to go. To get this going, we need to look at the GetSubscription() method to see when the last synchronization was and also to use that object’s method to work with the synchronization. The object that is returned when you use this method is Microsoft.UpdateServices.Internal.BaseApi.Subscription.

$wsus.GetSubscription()

Take a look at LastSynchronizationTime, and you will see that this WSUS server has not been synced yet. Synching this server is pretty simple. We will use this object’s method, which is conveniently named StartSynchronization(). Let’s go ahead and kick this off.

$subscription = $wsus.GetSubscription()

$subscription.StartSynchronization()

Nothing is returned when you kick this off, so we need a way to track this process and find out when it is finished. Enter the GetSynchronizationProgress() method, which will tell us exactly where we are with the sync process.

$subscription.GetSynchronizationProgress()

It is slowly getting there. I will check back shortly and see if it has completed yet.

There we go. Now we are ready to jump back into working with updates.

Let’s try this again…

$updates = $wsus.GetUpdates()

That’s more like it. Now I have over 5500 updates to work with.

As you can see, calling GetUpdates() will get every single update on the server. But, what if we only want to get a specific update or updates? Instead of getting all of the updates and using Where-Object to filter them, you can use one of the following methods to accomplish that goal. (By the way, there is one more thing that we can use with GetUpdates() to get specific updates, but I am leaving that piece out until later in the week.)

$wsus.GetUpdate()

This method is quick to get the update that you are looking for. The only issue is that this method requires you to know the update ID, which is a GUID. Not exactly something a person will know off of the top of one’s head, but it is an option regardless.

$wsus.GetUpdate([guid]” fc08b450-6bdd-400e-9a1a-2f86e23ce462”)

Now, on to the last way to get more specific updates—this time using the following method:

SearchUpdates()

This method is very flexible to use because it only requires a string for input. This string can be anything from the KB number for the patch, the actual patch name, or even something as simple as the type of system that the patch would be installed on (such as Exchange Server). Let’s look at a few examples of performing some searches:

$SQL = $wsus.SearchUpdates(‘SQL’)

$SQL.count

$SQL | Select Title

$update = $wsus.SearchUpdates('943485')

$update.count

$update | Select Title

$patches = $wsus.SearchUpdates(‘Windows 7’)

$patches.count

$patches | Select Title

Now that we know how to find updates on the WSUS server, we can start to explore the update object (Microsoft.UpdateServices.Internal.BaseApi.Update).

There quite a few methods that are available for the update object, so we will focus on three methods that are pretty useful for administering updates on the server.

Accepting license agreements

You might be asking me why accepting license agreements would be one of the three things that I would want to focus on. Well, this is not an issue…until it becomes an issue when you are trying to approve an update. There is a property that has a Boolean value called RequireLicenseAgreementAcceptance that we can use in our filtering to locate any updates that require a license acceptance before you can approve the updates.

$license = $updates | Where {$_.RequiresLicenseAgreementAcceptance}

$license | Select Title

We can use the method AcceptLicenseAgreement() to accept the agreement for the update.

$license | ForEach {$_.AcceptLicenseAgreement()}

With that, all of the updates that had a requirement to accept a license agreement have been taken care of, allowing us to start approving some updates!

Approving updates

There are three ways that you can approve updates on the WSUS server by using PowerShell—one by using ApproveForOptionalInstall() and two by using Approve(). They require that we use the TargetGroup object to tell the server what group we will approve each update for. Yesterday, I talked about how to get a target group; now we can easily grab a group to use for each type of approval. The Approve method also requires that you pick an installation action (I will go into more detail when we get to that method).

The main difference between ApproveForOptionalInstall and Approve is that ApproveForOptionalInstall will approve the update for the target group, but the update will not actually install. However, it is made available to the user for installation via Add/Remove Programs. Approve will approve the update with or without a deadline (your choice—I will explain later how to do this).

Let’s start with the optional installation first…

$update = $wsus.SearchUpdates('Windows 7 for x64-based Systems (KB2639417)')

$group = $wsus.GetComputerTargetGroups() | where {$_.Name -eq 'TESTGROUP'}

$update[0].ApproveForOptionalInstall($Group)

Here I approved a Windows 7 update for my TESTGROUP in which my laptop is currently a member. Notice that it returns another object called Microsoft.UpdateServices.Internal.BaseApi.UpdateApproval. This object tells you when it was approved, the time that the update will “go live,” and who approved the update. It is important to note that the update object you get is a collection, even if you only get one item back. Therefore, I had to be sure to use the first index of the collection to use this method for approval.

By using Approve() method, we have two ways in which to approve the updates. Both require that you have the target group object, but one also has the requirement of setting a deadline by using the [datetime] object.

Do you remember when I mentioned using an installation action for the approval? Well, now it is time to use one of those actions for this approval. But how do we know what installation actions we can use? We will find out what our options are by using Microsoft.UpdateServices.Administration.UpdateApprovalAction.

[Microsoft.UpdateServices.Administration.UpdateApprovalAction] | gm -static -Type Property | Select –expand Name

The installation actions that are returned are:

All

Install

NotApproved

Uninstall

Now that we know what kinds of actions we can use, let’s make an approval without using a deadline.

$update = $wsus.SearchUpdates(‘Update for 2007 Microsoft Office System (KB932080)')

$group = $wsus.GetComputerTargetGroups() | where {$_.Name -eq 'TESTGROUP'}

$update[0].Approve(“Install”,$Group)

Again, the same object type is returned with the same data that we would expect.

We can set a deadline on our next update for approval. Basically, setting a deadline on a patch will force that update to be installed at that specific time. For instance, I will approve an update that will get installed on Dec. 15 at 11:00 PM.

$update = $wsus.SearchUpdates(‘932080’)

$group = $wsus.GetComputerTargetGroups() | where {$_.Name -eq 'TESTGROUP'}

$update[0].Approve(“Install”,$Group,[datetime]”12/15/2011 11:00PM”)

Notice that the Deadline is set to the time that I specified instead of it being way out in the year 9999. Now the update will install on the server at that specific time without manual intervention.

You might be asking, “How were you able to determine what updates were required by your systems?” Well, besides jumping into the WSUS Administration Console to view those updates, there is another way that I can locate updates, but that will have to wait until later this week when I introduce another object and way to search for updates.

Declining an update

So we have approved updates, but we also need to know how to decline updates that are not needed by any system or are deemed unneeded by us for various reasons. Luckily, declining an update is as simple as using the Decline() method.

$update = $wsus.SearchUpdates(‘932080’)

$update[0].Decline()

Unlike the approvals, no object is returned when you decline an update. Regardless, this is a simple and effective way to decline updates that you do not need.

That wraps it up for today’s blog focusing on update management by using Windows PowerShell. Although I really only scratched the surface of working with updates, I hope I was able to give you enough information to make the leap into patch management using Windows PowerShell. Tomorrow I will dive into working with the computer scope object and how you can use that object with some of the objects we have seen this week and some of their associated methods that only accept the computer scope object.

~Boe

Boe, thank you once again for a very useful and informative blog about using Windows PowerShell and WSUS. WSUS Week will continue tomorrow.

Ed Wilson, Microsoft Scripting Guy