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