Set a client's WSUS client service to debug mode

Topics: Enhancement Request
Feb 24, 2014 at 5:47 PM
I'd love to have the feature to be able to set a WSUS client's service to debug mode to troubleshoot (set registry keys to debug then restart service). And once done be able to have them be in non-debug mode. I would think the best place would be when you right click on the client in the package status window.

Feb 25, 2014 at 2:15 PM
Do you really think this feature can be needed often ?
I think that most of Wsus Clients issue can be solved by other ways.
Marked as answer by DCourtel on 5/8/2014 at 2:55 AM
Feb 25, 2014 at 5:17 PM
The reason for the request is from this "adventure" I had last week:

I had spent about 3 days trying to setup the proper Installable, Installed rules for Trend Micro Officescan. I was only able to actually see the reason why Installable was false and Installed was false after I enabled debugging of the WSUS client service and hammered on the rules.

Turns out Trend Micro includes a installed & installable rule where the MSI code matches an existing code found it won't install despite the version of each package being different. Only after running a client in debugging did I see a package rule show up (didn't see them in the WSUS package Publisher publishing view, but then again I've never seen a package have rules already defined). I deleted the package rules during the initial publishing (the second time I published it) and it fixed that issue.

The second issue was a Reg_SZ key wasn't being evaluated when set to "equal" as opposed to "contains" when comparing the registry key against a DisplayVersion "10.6.5162". The debugging showed it completely fail attempting to validate the installed rule and instead report an error about the "C:\Program Files\Update Services\v4\xml" was corrupt on the client, which made no sense. In a blind guess I flipped it to "contains" and it successfully reported it matched therefor was installed already.
Feb 26, 2014 at 9:34 AM
I suppose that the Wsus client have tried to compare "10.6.5162" with "10.6.5162.0" which is totally different (from the point of view of a computer :-) )
Feb 26, 2014 at 10:54 AM
Ha- I tried that out of desperation. The number the pack was comparing was 10.6 so I was rather urked when it still failed even after I changed the value in the registry to the same thing (10.6).

If any option would be helpful it would possibly be something that takes the deployment's Installable, Installed logic and compares it to a test machine(s) of your choosing (similar to Active Directory's Group Policy Modeling Wizard ) but this request would be a rather huge lift coding wise.