WSUS Connection Error for Computer Groups – Unicode Character

When using the WSUS console, from time to time I will get the following error when selecting a particular Computer Group:

When copying the error out to notepad and reviewing, the key indicator for this issue is something along the lines of:

System.Xml.XmlException — ‘’, hexadecimal value 0x16, is an invalid character.

Upon seeing this I know that a unicode character in the database is at fault, so to the database I go.  If you have your database deployed using WID, see this post for connecting to it.  If you are working with a SQL database, make sure you are running the following queries against the “SUSDB” database.

Run the query found in the image below and copy/past the results to a notepad document.

Look for the unicode character(s) at fault.  It should look like what you see below:

Take note of the row number and run the following query where 3023 is the row with your unicode character:

Typically you will see the unicode character under the ComputerModel column and the BiosVersion Column will be Unknown.  Run the following query to clear the unicode character where 3023 is the row with your unicode character:

Next run the following query to get information about that computer object (hostname, IP, etc.) where 3023 is the row with your unicode character:

Go update the BIOS on that machine to the latest version to prevent the issue from reoccurring.

Server 2016 WSUS Clients: Windows Update Client failed to detect with error 0x8024401c.

So I just got done deploying WSUS on Server 2016 and everything seemed to be going fine.  Got my client side targeting rocking and a rolling, got the automatic update check time interval shortened up (I prefer 12 hours to the 22 hour default), and all the other nonsense.  A few machines report in no problem so I decide to add in all the servers for one of my customers.  And so down the rabbit hole I went.

About two of the ten machines I added would actually report in.  The eight that did not would show up in the MMC console, in the appropriate Computer Group, but would not report their status.  I went to one such client and was faced with this error: Windows Update Client failed to detect with error 0x8024401c.  I went and checked out the log at C:\Windows\SoftwareDistribution\ReportingEvents.txt and found essentially the same thing (see below).

I did some digging around and followed all the troubleshooting steps from Microsoft’s Support Page to no avail.  At long last I stumbled upon this serverfault article.  Granted the client machines I was working with were Server 2016 and the article pertains to Windows 10, but in the end the kernel isn’t all that different so I figured it applied.  As the answer recommended I made the following changes to the IIS App Pool on the WSUS box:

I wasn’t out of the woods yet, it was still only working intermittently; I went from two reporting in successfully to four.  So I started digging around the boxes that were not working and noticed that BITS was set to manual.  I’ve found this is normal on Server 2016 (strangely), but I said “Hey, let’s try getting that running and try reporting in.”  Sure enough that did the trick.  Checked for updates successfully and reported in seconds after running wuauclt /reportnow.

It’s been a couple days since and I’ve added a few hundred client machines with no issues.  Updates are running smooth (knock on wood).

Connect to WSUS Database

Had an instance the other day where I needed to connect to the database for WSUS on Server 2012R2, but I actually had no idea how to do it!  Luckily, we have the internet at our disposal.

First things first (although quite obvious) we are going to need to make sure that SQL Server Management Studio is installed on the WSUS box, available to download from Microsoft for free from here.  Once you have that installed, open it up as administrator and connect to the following using Windows Authentication:


Select connect and wa-lah you should get connected assuming you are an administrator.  You will find a database named SUSDB, this is your WSUS database.

WSUS Trials and Tribulations

Recently I have been working on a WSUS deployment with 2012R2.  Let’s just say it isn’t the smoothest deployment of a feature/role that I have ever done.  With that fun little preface, let’s dig into the challenges that I have faced with this.

For starters, the initial installation of the WSUS role and it’s additional features went off without a hitch.  I synced the server up with Microsoft, did my initial approvals, and set my GPO’s as needed.  It wasn’t until I realized that I had no client machines in my Unassigned/All Computers OU that something was up.  And down the rabbit hole I went for a frustrating amount of time.  The first issue I came across and resolved was my GPO settings.  For record, you need the following two GPO’s applied:

•Configure Automatic Updates

•Specify intranet Microsoft update service location

My issue was with the latter.  I had the format of “Set the intranet update service for detecting updates: ” and “Set the intranet statistics server” as “http://server>”.  This should have included the port number (8530 for non SSL) “http://server:8530“.

Following getting this GPO change applied I finally started (albeit be quite slow) getting client machines connecting.  Great!  Except all the Windows 10 machines in my environment were showing as Windows Vista…how insulting!  So after some digging all over I found a Windows update to correct that little oversight (KB3095113), which you can download here.

We seem to be getting somewhere eh?  Nope!  I saw that my WSUS server had grabbed some updates since I installed the role, so I figured why not install it right?  Might be a useful patch (which in reality, it was).  But naturally it broke stuff.  Post installing the update (KB3159706) I could no longer connect to the WSUS server via the WSUS Console.  Yay!  After digging through Event Viewer logs and hating all things Microsoft, I found the error that led me to the solution: ID 507 “Update Services failed its initialization and stopped.”  I did some Googling and found out that there were manual configuration steps to complete the update (Maybe a little notification for something like that next time Microsoft?  Please?).  Below is the manual steps required to complete the installation for the update:

•Open an elevated CMD and run the following command:

It will take a little while, but eventually you will see “Post install has successfully completed.”

•Add the “HTTP Activation” feature found at “.NET Framework 4.5 Features > WCF Services > HTTP Activation.”

•Restart the WSUS service and you should be able to connect with the WSUS Console again.

After all that heartache, I finally have a functioning WSUS deployment.