Wednesday, January 7, 2015

WSUS, 3rd Party Update and Local Publishing to a DFS or UNC

I'm not going to get elaborate with this post.  Mostly because I don't post often.  However this is one of those "Woohoo!" moment when you get something working despite everyone else saying it does not work or there is no workaround.

I'm referring to a "bug" in the WSUS Publishing API when your WSUS Content folder resides on a UNC or DFS path.

http://blogs.msdn.com/b/minfangl/archive/2014/01/29/system-center-update-publisher-2011-troubleshoot-series-3-publish-fail-when-scup-2011-is-remote-and-wsus-is-using-unc-as-content-folder.aspx

In this scenario your WSUS servers have a registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup\ContentDir

This points to the UNC path were all your content is published to.  The problem is that this information is not available if your using SCUP on a remote system or your 3rd party updating tool is on a different server from your WSUS server.

Honestly after beating my head on a wall for a few days I just exported the whole key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup

Then imported that onto the system where your running SCUP.  I expect the same would work for other 3rd party patching tools like from SolarWinds or others.
http://www.solarwinds.com/patch-manager.aspx

I'm guessing that the WSUS Console expects these registry keys to be available.  All the 3rd party patching just called it a bug.  I bet if you ran Process Monitor you could identify the specific registry keys that are needed rather than exporting all the sub-keys.
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx