Powershell: WSUS clients inventory

May 31 2011

Powershell: WSUS clients inventory

In this post we will describe how to make a WSUS clients inventory, we will search for the computers in your domain which are not able to receive MS security updates because they are not supported any more or because there is a misconfinguration on the WSUS client. Below is a tab listing supported OS and Service Packs versions:

We will assume that Windows Vista SP1 is not supported anymore, because support ends on July 12, 2011. Firstly we will search with PowerShell for computers which have an out of date OS and service pack version, we will use the same query as described in this AskDS post:

$base = 'OU=Servers,DC=ldap389,DC=info'
$d = [DateTime]::Today.AddDays(-30)
 
$computers = Get-ADComputer -Filter 'PasswordLastSet -ge $d' -Searchbase $base -Properties OperatingSystemVersion,OperatingSystemServicePack,dNSHostName,OperatingSystem
 
foreach($computer in $computers) {
 
if (($computer.OperatingSystemVersion -lt "5.1") -or (($computer.OperatingSystemVersion -like "5.1*") -and ($computer.OperatingSystemServicePack -ne "Service Pack 3")) -or (($computer.OperatingSystemVersion -like "5.2*") -and ($computer.OperatingSystemServicePack -ne "Service Pack 2")) -or (($computer.OperatingSystemVersion -like "6.0*") -and ($computer.OperatingSystemServicePack -ne "Service Pack 2")))
{$computer.Name + ';' + $computer.OperatingSystem + ';' + $computer.OperatingSystemServicePack  | Out-file NOK-OSVersion.csv -append}
}

This portion of script searches for computer accounts which are not stale, i.e. which renewed their password with a domain controller within the last 30 days. These computer objects, located in the “Servers” Organizational Unit, are listed in the NOK-OSVersion.csv file and cannot receive any security updates because their OS or Service Pack version are not supported anymore, you should upgrade these clients.

Secondly, we will search for computers which are eligible to receive security updates (i.e. OS and Service Pack version is supported) but do not show up on your WSUS console. For those computers there might be a problem on the WSUS client or the computer is not configured to download updates from your WSUS server: Security patches are directly downloaded from the internet, which is not advised in a business environment, because you cannot control their deployment.

With WSUS 3.0 SP2 you can use PowerShell to manage WSUS, you can read this article written by Boe Prox for more information: We will use the Microsoft.UpdateServices.Administration namespace to manage WSUS. We will retrieve all the computers included in our WSUS groups (except the All Computers group, which contains all the WSUS groups) and compare the result with the previous Active Directory query ($computer), which contains all the computers eligible to receive security updates:

$wsusserver = "WSUS-server"
 
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($wsusserver,$False)
$groups = $wsus.GetComputerTargetGroups()
 
foreach($group in $groups) {
if ($group.Name -ne "All Computers"){
($wsus.getcomputertargetgroup($group.Id)).GetComputerTargets() |%{if ($_.FullDomainName -eq $computer.dNSHostName){ ....}}
}
}

The computer FQDN is the common key between the computer object in WSUS (FullDomainName attribute) and the computer object in Active Directory (DNSHostName attribute). The computers for which there is a matching between AD and WSUS are written in a file named after the WSUS group the computer belongs to ($file). The computers that do not show up in your WSUS console are listed in the NOK-wsus.csv file. For these machines you should check if the WSUS client is configured to receive updates from your WSUS server, or if the WSUS client has a problem.

To download the full script just click on the image below:

You should change the following variables:

$wsusserver: Name of your WSUS server.
$base: The distinguished name of the search base object. defines the location in the active directory from which the LDAP search begins

This post is also available in: French

Tags: PowerShell, wsus

Filed in scripts, security, tools | ldap389

7 Comments

By CTXBLOG, June 1, 2011 @ 11:45 pm

Nice script, for PDT team ?
By ldap389, June 6, 2011 @ 2:53 pm

No for SECOP team, but they rewrote the code in assembly language… 😉
By Christian, March 7, 2012 @ 8:55 pm

Thank you! Exact what i’m looking for.
By eytan, February 13, 2013 @ 9:12 am

Hi
I am using ssl autentication on wsus port 443
the next error appear
can not establish trust relationship for the ssl/tls secure channel
By ldap389, February 13, 2013 @ 10:00 am

Hi Eytan,

Use this command when initializing the connection to the WSUS server instead:
$wsus=[Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($wsusserver,$True,443)

See this post for an example.

Regards
By James, July 5, 2017 @ 8:34 pm

I know this is an old post. I needed to update it to include Windows 7 SP1 and Windows 10. The Windows 10 computers show up in the NOK-OSVersion.csv file because the OperatingSystemVersion value is being read by powershell (Server 2012R2) as a number less than 2. So I just added a ‘($computer.OperatingSystem -notlike “Windows 10*”)’ at the tail end of the OS version check filters to get them to properly be placed in the WSUS group files.
By ldap389, August 28, 2017 @ 10:49 pm

Hi James,

Thanks for the update 🙂

ldap389

Leonard Savina - @ldap389