WSUS clients not reporting in? No problem check this out.

Are you having difficulty with your WSUS clients not reporting in? I recently posted about running Microsoft Baseline Security Analyser to check your systems are getting the right patches in this post. If your haveing issues with clients not checking in this may help. If you have gone through the basic troubleshooting steps and believe you have everything in place continue on. In this instance we have recognised that our Automatic update agent store is corrupt or that your clients may have a matched susclient ID in WSUS. More info on troubleshooting the basics first can be read about in this article by Microsoft.

This script will help your clients check back in to WSUS. If the agent store is corrupt or the client agent susclient id is botched. In my experience that a few other issues this tends to be the most common issue that crops up. Issues with Clients having the Same SUSclient ID usually happens as a result of an imaging process.

Save the below txt into a batch file, then run with elevated privileges in an Administrative command prompt on your target machine.

REM stop the Windows Updates service
net stop wuauserv
REM Delete SusClientID and AccountDomainSid registry keys
SET WU_KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
reg delete %WU_KEY% /v SusClientID /f
reg delete %WU_KEY% /v  AccountDomainSid /f
REM Delete registry keys may contain old SUS info
reg delete “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update” /f
REM Start the Windows Updates service
net start wuauserv
REM Initiate the WU Client…
wuauclt /resetauthorization /detectnow

Hope this helps as this can be frustrating waiting for clients to check back in.

6th May 20176th May 2017

Are you using MBSA, you should be! This post is all about how to use MBSA – Microsoft Baseline Security Analyser

In this post I will walk through how to use MBSA – Microsoft Baseline Security Analyser. We can use MBSA to baseline our systems to ensure they are receiving the correct patches. This should be done regularly.

The classic screen that tells us Windows is up to date should not be relied upon.

Most enterprise client machines will be checking into a WSUS or SCCM type update/package distributor. Its status will be based on what packages are available from the local server not Microsoft or a 3rd party entity. If WSUS is not configured correctly; for example, the correct product selection isn’t maintained there will be gaps. Or if your clients are not checking in properly. Worse your clients and servers are not being patched with the latest security updates! The above screen really isn’t good enough to know whether all updates are actually installed. MBSA can help you resolve issues like this by evaluating what patches are needed against Microsoft directly. ie the latest set of Microsoft updates.

So here is a quick run down on how to install MBSA and how to use it.

A quick search in Google for ‘MBSA’ will reveal the following page, follow the link and download your language.

On to the install – super easy next next next … etc.

The install couldn’t be easier.

This should leave you with a desktop icon, double click on this to launch MBSA. From here it is a simple case of selecting the right PC or Server that want to check. Remember for the machine you want to scan you will need administrative privileges.

To scan a machine, select ‘scan a computer’:

The results will then look something similar to the below (well hopefully not as this machine is out of date specifically to show you how it may look, hopefully yours is right up to date):

As you can see the there are 6 security updates missing, click on result details to see the missing patches:

This is what it should look like with a clean bill of health:

From here you should investigate why the patches are missing if you are missing any. If you are using WSUS this could be due to the product selection or even classification not being correctly selected. You can check for these in your WSUS console. In Options – Products and Classifications – in a screen that looks like this:

WSUS Products and Classifications

Note in this screen shot there is a selection for Office updates that you can apply. Don’t forget these type of applications in your selection, they are commonly missed!

Dig a bit deeper into your wsus and windows config to see whats going on. Ideally you should baseline your build images regularly to ensure they are getting the correct patches!

If you still find you are having issues with clients not being up to date check out the following script I posted about here. This can be run on a client or server machine, this helps clients check back into WSUS.

14th June 20165th November 2016

Running MBSA on a remote machine.

Running MBSA on remote machine that is in a workgroup or different domain.

I thought I would share my findings on using MBSA (Microsoft Baseline Security Analyser) for targeting remote machines that are not part of the same domain or in a workgroup. This really is a great tool for enumerating OS patch levels.

We have two scenarios to run through; the first, running MBSA on remote machine that is in a different domain from the machine that it is installed on. The second, running MBSA on a machine that is in a workgroup. Ok no problem. Here is what we do.

First Scenario

In the first scenario our target machine is a Windows Server 2012 R2 machine that is in a different domain to our MBSA host (Windows 7 Pro 64bit). Fire up a cmd prompt with admin privileges from the machine that you are running MBSA from, and run the following syntax:

runas /netonly /user:test\administrator "mbsacli.exe /target 192.168.56.104 /nvc /nd /wi"

A second command prompt will pop up and run, running the syntax as above:

MBSA remote1

If you wait a short while the MBSA command prompt will disappear when finished, from here you can open up MBSA and view the report:

mbsa remote2

In this example the target machine was in my virtualbox lab, in a domain called ‘Test’. The machine I ran MBSA from was a Windows 7 Pro machine in a workgroup (no relationship) other than IP connectivity. The cli syntax I used here was used to speed up the check, clearly only use this if you have the latest scan catalogue:

/wi – Show all updates even if not approved by wsus.
/nvc – Do not check for a new version of MBSA.
/nd – Do not download any files from MS update site when scanning.

Additional options:

/target <Target-IP>

/listfile C:\tmp\targets.txt

/catalog C:\tmp\wsusscn2.cab

Add: ‘>C:\tmp\MBSADC1.txt’ to the end of the syntax for a handy output to a text file.

As an example you might use:

runas /netonly /user:test\administrator "mbsacli /catalog C:\tmp\wsusscn2.cab /target 192.168.56.104 /nvc /nd /wi"

The Second Scenario

The second scenarios is a Windows Server 2003 machine that is in workgroup. The syntax is actually the same however your specifying the local machine name rather than the domain name. I have mixed this one up a little here by not using the cli, by just specifying MBSA the command simple fires up MBSA GUI as the account specified. The only thing to remember here is to add the IP address into the GUI.

runas /netonly /user:test\administrator mbsa

mbsa remote3

And again after the scan has finished the results can be view in the GUI.

mbsa remote4

I haven’t successfully managed to do this from a Windows 10 client yet, various forums would suggest it isn’t supposed to work with 10 however if you know please feel free to drop me an email or comment.