WSUS playing up

rickjames

rickjames

rickjames

Soldato
Joined
27 Oct 2011
Posts
4,176
Location
London
Howdy.

In the middle of cleaning up our server which runs WSUS, primarily because it's carrying and pushing out 32bit updates for stuff when we don't need it at all.

Running the cleanup wizard in WSUS I get the following error

The WSUS administration console was unable to connect to the WSUS Server Database.

Verify that SQL server is running on the WSUS Server. If the problem persists, try restarting SQL.


System.Data.SqlClient.SqlException -- Internal Query Processor Error: The query processor encountered an unexpected error during execution (HRESULT = 0x80040e19).

Source
.Net SqlClient Data Provider

Stack Trace:
at System.Windows.Forms.Control.MarshaledInvoke(Contr ol caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at Microsoft.UpdateServices.UI.SnapIn.Wizards.ServerC leanup.ServerCleanupWizard.OnCleanupComplete(Objec t sender, PerformCleanupCompletedEventArgs e)
Click to expand...

This is all pretty new to me (learning Server 2012 for the first time) so I've no idea what on Earth to do. Any help would be massively appreciated.
 
Try cleaning it up in powershell, see if the same error occurs. Is your WSUS server actually using SQL or is it using WID?
 
this also happens when you connect locally and the servier is under strain (wsus has performance issues!)

I always install WSUS on a 2nd server and add the 1st to the console.

as stated though check if its SQL or WID and if SQL makes sure the service is running and the firewall ports are allowed (1433)
 
Running -CleanupObsoleteUpdates reveals the same error as above, pah.

How would I be able to tell if it's using WID or SQL? Again, this is real, real new to me, never gone near any SQL stuff in my life.
 
how large is your domain? it may just be easier to reinstall it? you might find that the domain is too large for WID which is why its gone boing!
 
in which case I would uninstall WSUS and reinstall using SQL express as the DB. WID is pretty useless.

Do you use client-side targeting in GPO'S to push updates? if you are a single site then probably not.

in my experience when WSUS goes wrong, it goes very wrong. so just start it again. If possible run this on server 2012 R2 with SQL Express 2012.

I cant imagine a new install with "selective" product and classifications will take up 207gb of space. We look after a domain for a 3rd party that use wsus for Win 2000 - 2012 R2 in 9 languages and it takes 156gb of space.

In short, blow it away and start again.
 
Ploppy2k3 said:
in which case I would uninstall WSUS and reinstall using SQL express as the DB. WID is pretty useless.

in my experience when WSUS goes wrong, it goes very wrong. so just start it again. If possible run this on server 2012 R2 with SQL Express 2012.

In short, blow it away and start again.
Click to expand...
Agreed. I recently had a similar issue with our WSUS server - I tried to repair the install without realising that somebody else was working on it at the same time, so between us we killed it - so I blew it away and set it up again. This also had the advantage of getting rid of the expired and superseded updates, and also the updates for products we no longer use, such as Office 2007 and Windows XP.
 
I think my boss wants to avoid the uninstall scenario and rather look at repairing whatever SQL stuff needs to be seen? Again, my knowledge of SQL is zero.
 
rickjames said:
Ah, looks like it's WID, what now?
Click to expand...

Don't have much experience of troubleshooting WSUS as haven't had too many issues with my server at home.

Are you able to run the configuration wizard and point it to WID. Might be easier using Powershell.
 
The time you waste troubleshooting now, plus the future time required to troubleshoot the problems you will keep having, are just not worth it. Re-installing WSUS from scratch is so easy, and you end up with a nice clean install. What's not to like?

- Build new WSUS
- Copy settings across
- Modify GPO to point stuff at the new WSUS
- Decomm the old WSUS

Easy peasy.
 
also if you have a mashed WID version you cant just move it to SQL so a clean install is needed.

Reinstall, select the languages and products and provided the GPO is correct wait 72 hours while all the pc's check in and then approve the updates.

You will be back to a working and updated WSUS install within a week without wasting time. Just remember that nothing happens quickly in a WSUS world.
 
rotor said:
The time you waste troubleshooting now, plus the future time required to troubleshoot the problems you will keep having, are just not worth it. Re-installing WSUS from scratch is so easy, and you end up with a nice clean install. What's not to like?

- Build new WSUS
- Copy settings across
- Modify GPO to point stuff at the new WSUS
- Decomm the old WSUS

Easy peasy.
Click to expand...

This tbh - you're looking at an hour to bang out another WSUS server and slot it in over your old one.
 
Right, got the go ahead to do this during half term next week, hoorah. Sounds like we might just give WSUS it's own dedicated server, currently it runs alongside antivirus/KMS amongst other things.

So, it's relatively straightforward? What settings will this involve copying across?
 
It's a doddle.

- Add the role to your new WSUS server.
- Run through the Wizard (sync from MS Update / select products to DL updates for / select whether to use Group Policy to add computers, or manually from console).
- Configure your target groups (just copy the structure from your existing WSUS server)
- Use group policy to set your clients / servers to use the new wsus server.

If your existing WSUS server was configured in line with best practice, you'll already be using group policy to configure settings. If this is the case, you'll just need to find the policy where the setting "Specify intranet Microsoft update service location” is set - simply change the URL to reflect the new WSUS server, and then wait for the computers to start reporting in to your new server (can take a few hours).

If you can't find a policy with this setting in, simply use GP Modelling on a client machine to see if it's set, or log on to a client and run either rsop or gpresult /v from a cmd prompt. Either of those methods will show you exactly what GP settings are being applied and from which policy they are set. If it's not listed, create a new GP to apply to your clients, not your new WSUS server, which sets the policy mentioned (there's others that you can set too to help automate everything - google will bring up thousands of guides for this).

If you're impatient, you can speed things up by running the following command on each client:

wuauclt /resetauthorization /detectnow

Once you're happy that your new server is in place and servicing updates for the necessary clients, simply remove the WSUS role from your old server.

You're looking at an hour or two to get it all up and running.

Edit - First hit of google is a video taking you through the process: https://www.youtube.com/watch?v=luPy3lxbBKE

https://mizitechinfo.wordpress.com/...nstalling-configuring-wsus-in-server-2012-r2/
 
Last edited:
when you find the WSUS GPO there is a setting for detection time. By default it is 22 hours (I think) you might want to lower this to start with.

Nothing happens quickly in the WSUS world otherwise :)
 
Assuming your current WSUS server is still capable of pushing updates, it might be wise to use it as an upstream server for the initial sync.
 
Looks like I now have to remove/add again rather than a completely new VM for it, does the same above still apply in regards to going through it?
 
You must log in or register to reply here.
Back
Top Bottom