Local Publishing to WSUS on Server 2012
-
Friday, January 04, 2013 7:54 PMWondering what the supported scenarios are in terms of local publishing from remote clients to WSUS running on server 2012. Up until now I have relied on the official Remote Console installation to take care of installing the API. With the release of Server 2012 there seems to be a new version of the WSUS API but I don't see a new specific remote console installer for it. It would seem that for Windows 8 clients you use RSAT but is there a supported method to install the new API on Windows 7 or earlier machines?
All Replies
-
Tuesday, January 08, 2013 3:36 AMModerator
Hi,
It seems there is no supported method. RSAT For Windows 7 doesn't support Server 2012.
regards,Clarence
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
- Marked As Answer by Clarence ZhangModerator Tuesday, January 22, 2013 2:27 AM
-
Tuesday, January 08, 2013 10:51 PMModerator
Wondering what the supported scenarios are in terms of local publishing from remote clients to WSUS running on server 2012. Up until now I have relied on the official Remote Console installation to take care of installing the API. With the release of Server 2012 there seems to be a new version of the WSUS API but I don't see a new specific remote console installer for it. It would seem that for Windows 8 clients you use RSAT but is there a supported method to install the new API on Windows 7 or earlier machines?
Greetings Bryan.
Welcome to the nightmares that are WSUS v6. :-)
The only way to do local publishing to WSUS v6 (on Win2012) is either:
- From the WSUS v6 server console itself, or
- From a Windows 8 system running RSAT.
Presumably one could also install the WSUS v6 console on a Win2012 system, but there seems to be no documentation for this, and nobody (to my knowledge) has yet identified a method to do so. (In fact, a pending question in this forum is exactly about that point.)
The API dependency still requires a local installation of the console, and there's no way around that that I'm aware of. And, to complicate the matters, those who wrote the Local Publishing API actuallly put a "build number check" in the code, which not only requires that the server/console are the same Release of WSUS, but they have to be exactly the same build. For example, a Remote Console which does not yet have KB2720211 installed (because the stupid update isn't coded to detect console-only installations) also cannot publish to a WSUS v3 server that does have a KB2720211 installed, because the console is v3.2.7600.226 and the server is v3.2.7600.251.
I continue to be appalled at the lack of the Win2012 RSAT (for Windows 7) -- and even more so given the radical differences in Win8 vs Win7, but given that the Win2008 RSAT was never released for Windows XP, I have no hope for the former either. Given that Windows Server 2008 R2 extended support is still many years out, my take on all of this is that the safer bet is to continue using WSUS v3 until somebody comes up with a better solution for the WSUS v6 fiasco.
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
SolarWinds Head Geek
Microsoft MVP - Software Distribution (2005-2012)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.- Marked As Answer by Clarence ZhangModerator Tuesday, January 22, 2013 2:27 AM
-
Thursday, January 10, 2013 7:10 PMModerator
but I don't see a new specific remote console installer for it.
I am told by my developer colleagues here at SolarWinds who have been working on the next release of Patch Manager, that the WSUS v6 console-only installation is achieved by installing the "Windows Update Services" feature via Server Manager. I've not yet had the chance to personally confirm this (still working on getting my first Win2012 server installed), but given that Patch Manager is wholly dependent upon the WSUS console (for the WSUS API, as is LUP), that seems to me to be very solid information.Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
SolarWinds Head Geek
Microsoft MVP - Software Distribution (2005-2012)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds. -
Thursday, January 10, 2013 8:43 PM
Thanks Clarence and Lawrence. I was waiting to respond until I confirmed it myself but what your colleges describe seems to be the case in regards to running on the server itself. I was trying to run against the API remotely from a client that predates Windows 8 but failing ... it's always nice to know I'm not just doing it wrong.
I too have had the pleasure of dealing with the the build number check. What, to me, is the real kicker is that a mismatched version will connect and perform most functions of the API but not the subset related to local publishing. Since it's not an all-or-nothing deal it becomes confusing for users since they can connect just fine.
This does bring up a tangentially related question. How does one reliably compare the API version of the client against that of the server? I would think that the file version of the Microsoft.UpdateServices.Administration.dll file but that doesn't strictly seem to be the case either.
- Edited by Bryan Dam Thursday, January 10, 2013 8:43 PM
-
Saturday, January 12, 2013 12:53 AMModerator
I would think that the file version of the Microsoft.UpdateServices.Administration.dll file but that doesn't strictly seem to be the case either.
Yeah.. cuz somebody forgot to update the File Version for that file in SP2 for WSUS v3. :-//
and even though the file is updated with KB2720211 ... it doesn't update the File Version in that patch either.
I'll check with our DEVs for the exact process. We have a tool in Patch Manager that automates this check, so my guess is that it's being done via an API call that's identifying the actual internal build number of the Microsoft.UpdateServices.Administration.dll assembly.
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
SolarWinds Head Geek
Microsoft MVP - Software Distribution (2005-2012)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

