Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

It seems that WSUS isn't smart enough to know which updates are actually appropriate for Windows Server Core installs. For example, WSUS wants to install Server 2012 R2 Update (KB2919355) but it fails (gave it a shot but didn't have confidence it would succeed.) And WSUS believes there are still 14 updates this server needs. Four of those are Silverlight.

Now, I don't truly know whether Core edition needs Silverlight (that's sarcasm) nor do I know whether the recent "Update" for 8.1/2012 R2 is needed for Core (not sarcasm) but on the surface it would appear to be inappropriate.

I'd rather not let this server live its life as continually having need for 14+ updates and 1+ failed updates.

Thoughts on how to handle this? I'm a bit surprised that MS has not made better accommodations for handling updates on Core since that's what they are pushing.


I've learned a few things.

  1. KB2919355 installs fine on a 2012 R2 Core server. Just make sure you have plenty of disk space available! (ha)
  2. The server itself knows better when it comes to which updates need to be installed. In the case of Silverlight, WSUS reported that my Core server needed them even though they were set to "Not Approved" and when it came down to it the server didn't have them on its list of needed updates. As it stands, WSUS says the server still needs 4 updates but this is inaccurate because they are all for Silverlight.
share|improve this question
By "the server didn't have them on its list of needed updates", do you mean that this was the result when you check WU on the server against Microsoft's servers, or your WSUS server? Because if you have it marked as not approved, it won't show up in the "list of needed updates." The only way to make that claim valid is to approve the update and show that the update still doesn't show up as a needed update on the server! –  austinian Jul 14 at 22:33

3 Answers 3

up vote 3 down vote accepted

My suggestion is:

  • Move the Core Servers into their own Computer Group in WSUS
  • Decline any updates not appropriate for that Server edition (e.g. Silverlight!) (Well, Silverlight actually does not belong on a server at all - other story)
  • WSUS only does what you tell it to do - you approved Silverlight for the Server (or at least you did not decline it)

This should get you started.
I have installed KB2919355 sucessfully on a Server Core installation.

share|improve this answer
I'm working on a WMI filter to get these servers in a better group. But how do you decline an update for a single group? It seems the best you can do is leave it at "Not Approved." Also, Silverlight is appropriate for RDSH servers but I made a special group for those servers and specifically approve Silverlight on that group. –  idon'twearsuits Apr 19 '14 at 15:36
You're right, you can't decline per group. –  MichelZ Apr 19 '14 at 15:57

You can't decline an update for one computer group, as far as I can tell: you can only not approve it. A not-approved update still shows up as failed or needed.

share|improve this answer

If this is truly bothering you, you have several options available to you, none of them easy or straightforward, but some consider them to be well worth it:

  • Build separates WSUS servers for Servers and Workstations.

  • Hide the column in the interface and use update categories to see if important updates haven't been applied to your systems.

  • Decline the offending updates and reintroduce them as locally published updates. Provide them with different detection logic than was in the original update, that way you can craft detection logic that is appropriate for your environment.

Caveats: this will require either using SCCM/SCUP, or some third party tool like LUP or WSUSPackagePublisher or learning the WSUS API and developing your own method of publishing updates. This also means you'll have to research proper installation commands and detection methods for the updates you wish to overrule in this manner.

Added benefits: This would be having more control over the software in your environment, as you can manage how updates get installed that might have weird side-effects. Also, you can actually manage more than just Microsoft products using this method; I've used this to provide updates to just about every user application in one mid-sized business. There are also companies that provide updates for third party applications for use with WSUS. Adobe, for example, provides updates for at least Acrobat, Reader, and Flash Player through its catalogs.

  • Abandon the reporting tools included with WSUS. Create your own reports (which can be set up to ignore certain conditions, such as Silverlight lingering like the world's longest lasting fart waiting to be approved for a server group).

Caveats: This will also require you to either dig into the inner workings of WSUS or use a third party tool/script/solution to give you what you're looking for.

Added benefits: The flexibility this provides may amaze you: you can have reporting that answers the questions you ask of WSUS instead of settling for what's offered in the reporting package.

  • If none of the above are satisfactory, then learn to let go of that lofty feeling 100%. The cake is a lie.
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.