Search results for 'app:weblogs' matching tags 'Scripting Guy!', 'WSUS', 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

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

Introduction to WSUS and PowerShell

Anonymous — Mon, 16 Jan 2012 06:00:00 GMT

Summary: Guest blogger, Boe Prox, shows how to use Windows PowerShell to install WSUS and conimage clients for updates.

Microsoft Scripting Guy, Ed Wilson, is here. You are in for a treat this week. Boe Prox has written a week’s worth of goodies, and we will share them here.

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

Now, without further ado, here is Boe!

For those of you who are unfamiliar with Windows Software Update Services (WSUS), I am going to start with a brief description of what WSUS is and how it is used to manage patching in an environment. Then I will dive into installing the server by using Windows PowerShell, configuring clients via GPO or the registry to report to the WSUS server and to receive the updates from the server. Lastly, I will discuss how to use Windows PowerShell with the associated assemblies for the WSUS Administrator Console to connect to the WSUS Server.

What is WSUS?

Windows Software Update Services (WSUS) is used by system administrators to manage the distribution of updates and hotfixes that are released by Microsoft for an environment. Currently, the most recent version is WSUS 3.0 with Service Pack 2, and it is available to download. This installation allows you to install the full server installation option or only the console installation (which can be installed on any client or server). It also has the assemblies required to use Windows PowerShell to manage the WSUS server. To determine the version of WSUS, refer to Appendix G: Detect the Version of WSUS on Microsoft TechNet.

Installing a WSUS Server

Before you begin the installation of WSUS, make sure you install the following on the selected server:

Internet Information Services (IIS)
At a minimum, .NET Framework 2.0

You could install WSUS 3.0 with SP2 on your server by using the file specified in the previous download link and running through the UI installation. But c’mon, this is a scripting blog, so surely we can script something out…right? Right!

Because there are several switches available with the executable file, we can easily script an unattended installation of the WSUS server along with specific configurations that meet our requirements. For more information about those switches, see Appendix A: Unattended Installations. The script I wrote that will allow a local or remote installation of a WSUS server or to install only the WSUS Administration Console is called Install-WSUSServer.ps1.

Note: I chose to require a dependency for PSExec.exe to complete the remote installation requirements. There were a number of reasons why I chose to do this, but the main reason is that I wanted to make sure that if an issue occurs that cancels the installation, an error would returned in the script that lets you know something happened.

You can run this script against only one computer at a time. This is because only one SUSDB database can be used for each SQL Server instance (unless you are setting up a WSUS server as a front-end server). You can specify whether to install a console or a server core installation, and it allows for using the internal database installation or a local/remote SQL Server instance to write data to. Lastly, if the required installation file (WSUS30-KB972455-x86.exe or WSUS30-KB972455-x64.exe) is not in the same directory as the script, you will be given a prompt to download the required file to use for installation. I also wrote an Uninstall-WSUSServer.ps1 script that performs exactly like the Install-WSUSServer.ps1 script.

So enough talking about this script and let’s see it in action. First, let’s install our WSUS server and make sure that we save the content locally and save that content on the D drive. I am also going to make sure that I do not have the updates made available so it asks me to download the update prior to the installation.

. .\Install-WSUSServer.ps1 -Computername DC1 -StoreUpdatesLocally -ContentDirectory "D:\WSUS" -InternalDatabasePath "D:\" –CreateDatabase –Verbose

The command and the associated output are shown in the following image.

The following image shows the newly created folders.

Now let’s fire up the console. To do this, I make an RDP connection to my DC1 server as shown in the following image.

Yep, it’s all there! OK, now let’s install the Administration Console on my laptop so I can make use of the assemblies for Windows PowerShell integration. Here is the command line that I use to install only the console.

. .\Install-WSUSServer.ps1 –ConsoleOnly -verbose

The following image shows the command that I use to install the console, and the output from the Install-WSUSServer.ps1 script.

This was a little simpler because I already had the installation file that I needed to complete the Administration Console installation.

Conimage clients to use WSUS

OK, we have our WSUS server installed and running, and we have our Administration Console installed on the laptop. The next step is to conimage my laptop and the server to communicate to the WSUS application so we can image the patches that are required for each client. There are a couple of ways to accomplish this task. If the client is in an Active Directory environment, all you have to is use Group Policy to make the configuration changes.

Note: For non-domain systems, you can make this change by using gpedit.msc.

For the sake of simplicity, I am just going to conimage the GPO to point my client to the WSUS server (Specify intranet Microsoft update service location), set the update client to only download (Conimage Automatic Updates) the approved updates, and change the detection to every four hours (Automatic Updates detection frequency). The changes are reflected in the following image.

Another way is to do some registry hacking to make the changes, which leads me to my next set of Windows PowerShell scripts that accomplish this task. The first script allows you to view the settings in the registry and the other script allows you to change the registry settings to conimage the client. You can find these scripts in the Script Center Repository:

To view the registry settings: Get-WSUSClientSetting
To set the registry settings: Set-ClientWSUSSetting

For more information about the registry information that I used in these scripts, see Configure Automatic Updates in a Non–Active Directory Environment.

First, let’s see the settings that we will be changing to talk to our WSUS server on DC1. To do this, I use the Get-ClientWSUSSetting command as shown here.

Get-ClientWSUSSetting | Select WUServer,WUStatusServer,DetectionFrequency,AUOptions

The following image shows the output from this command.

Now let’s change these to reflect the same GPO we conimaged for the domain. Here is the command that does that.

Set-ClientWSUSSetting -Options DownloadOnly -DetectionFrequency 4 -UpdateServer 'http://DC1' -Verbose

The image shown here illustrates the output from the command.

Now, I use the Get-ClientWSUSSetting command to verify that the changes worked properly. As shown in the following image, it worked just fine.

Perfect. Now our clients are talking to the WSUS server, and they will begin reporting what patches are needed to be compliant.

WSUS and Windows PowerShell

Now we are at the point where we can begin working with the assemblies by using Windows PowerShell, and make our initial connection to the WSUS server. We want to use the Microsoft.UpdateServices.Administration assembly. Here is the command that I use to load that assembly.

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | Out-Null

Now it is time to make the initial WSUS connection by using the .NET accelerator [Microsoft.UpdateServices.Administration.AdminProxy] and the static method getUpdateServer(), which requires two values: the WSUS server name and a Boolean value for a secure connection. Because I am not using a secure connection for the WSUS server, we will set it for False. Here is the command.

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer(‘DC1’,$False)

$wsus

The output from the command is shown in the following image.

Here you can see some information regarding the remote WSUS server, such as the port number that is being used and the version of the WSUS server.

That is all for today with WSUS. I have shown the beginnings of using Windows PowerShell to make the initial connection to the WSUS server. Tomorrow I will expand on this by showing how you can use Windows PowerShell to perform some basic administration for your WSUS server.

~Boe

Thanks Boe, that is a great introduction to WSUS. WSUS Week will continue tomorrow.

Ed Wilson, Microsoft Scripting Guy