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.
update
I've learned a few things.
- KB2919355 installs fine on a 2012 R2 Core server. Just make sure you have plenty of disk space available! (ha)
- 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.
My suggestion is:
This should get you started.
I have installed KB2919355 sucessfully on a Server Core installation.
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.
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.
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.