This would be preferred to manually overriding them every month.
I’ve seen this pop up a few times in forums and even in a few SCCM implementations. Here it is: If you notice the 2 GUIDs in red, they match the GUID above in the white line. We know we’re having some issues between components, but where is the actual error coming from? Remember those two log files I mentioned above and said that shows which SUP the Primary Site is dealing with. It is able to talk to WSUS on the web ports (80/443 or 8530/8531). I know recently that the SUP points had been rebuilt.
Since you’ve probably been looking in the Monitoring workspace of SCCM and check out the component status, you’ve probably come across that the SMS_WSUS_SYNC_MANAGER was red and unhappy. OK OK, you might have already found this, but you’ve been searching the internet for the answer. Now that we are on that server, have we looked at the Event Log? As you see below, the anonymous Check is where it should be. We need to look at the Content Dir key in the HKLM\Software\Microsoft\Update Services\Server\Setup location. Well we can change the value in a few places, but I’m sure someone usually has an issue with WSUS, tries to fix it via blog posts and just fat fingers the POSTINSTALL command.
If the management point doesn't receive a message after 5 minutes, the client is considered offline.When the post install updates the IIS Virtual Directory Content, it strips out the \ of the server name and only puts SERVERNAME\WSUS\Wsus Content\.You need to edit this and add the \ to the start of the server name.With the new 'cumulative updates' model I think it would be a good idea to change the maximum run time of cumulative updates to 30 minutes (or whatever is best suited).I have noticed more timeout issues with patching in the last couple of months due to the default 10 minutes not being enough time to install 'X' patches as a single CU.