• This allows you to use the Patch Management UI as is.
• If you have fixed maintenance windows, this can be a set and forget process.

At first, I thought there were two other methods that would work:

1. Edit the Repair scripts produced by the Patch Management UI and located in LDMAIN\SCRIPTS. Copy the vulscan.exe command line into new .BAT files and use Pre and Post packages in the Scheduled Task.
   
2. Same idea could be done as a dependency chain... Copy the vulscan.exe command line into a new .bat file, but create a dependency chain. Your task would then schedule "blockreboot-after-group123.bat", which would rely on "repair-group123.bat", which would rely on "allowreboot.bat".
   • Either method causes all three .BAT files to be copied to the sdcache directory and executed in order, surviving reboot.
   • On the downside, it would have to be done for each repair job; Custom Groups could make it less onerous though. This is done by putting the vulns to be repaired into a custom group and then using the command: %LD_CLIENT_DIR%\vulscan.exe /repair /vulnerability group="123".
   • As a pre/post package set, If the repair goes wrong for any reason, the reboot-blocking .bat file will still run and turn off vulscan's ability to reboot the server. As a dependency chain, the chain would stop if anything unexpected happened during patching, leaving the server in a reboot-enabled state.

However, further testing showed that this will not work, because vulscan looks for instances of itself or software distribution running... and since doing it as a software distribution job means that software distribution is running.

It should be obvious that Process Manager is the more sensible way to handle this problem, so that there's approval around the changes and alerting if something goes sideways. But if you don't gots it, you don't gots it. However, once you've built these packages, it's theoretically possible to use them in the built-in patch process.

Remember, scheduled tasks are running as local system, which may or may not be able to do all the things those batch files do. If it doesn't work, try one of these ideas for making it go:

• on the package definition, specify it should run as the logged in user (assuming someone's logged in and that they're an admin)
• allow the computer accounts access to the network share
• define a Preferred Server entry with stored credentials for the network share
• on the package definition, specify the .reg file as an additional file, then modify the .bat file to call it from  LDClient\SDMCache.