Hi all,
I suspect I may end up logging this as a support case with LD, but I'm not sure of the scale of the problem yet, and wanted to run it past you lovely lot first.
Scenario: Patch push task. Targets a custom group with a handful of MS patches. Task specifes a S&R behaviour. Behaviour is set to:
- Reboot if needed
- Prompt user before rebooting
- If no one is logged in, reboot immediately without prompting or delay
- Allow user to defer reboot (4 hours / 25 times)
- Do not allow user to cancel
- After timeout, automatically snooze (20 min timeout)
I've had a report that someone snoozed the reboot before going home last night, and came in today to find their machine had rebooted. They claim to have left themselves logged in.
I've found the vulscan.log corresponding to the incident. It's using the correct S&R behaviour. Extract from the log:
Last status: Terminé. Redémarrage requis
HKLM\Software\LANDesk\ManagementSuite\WinClient\VulscanReboot exists. reboot is required.
Checking a reboot action...
AutoRebootTimeout: 1200
DefaultRebootTimeoutAction: snooze
Found no active WTS sessions. Looking for the logged on user process token
No one is logged in. Returning "reboot now"
Last status: En attente
Last status: Terminé
got mutex
Last status: Terminé. Redémarrer maintenant
To me, it looks like vulscan is incorrectly determining that no one is logged in and skipping the prompt to reboot.
Some context: Of the 400+ machines patched last night, this could be the only troublemaker, but it's difficult to tell. We've never used LDPM on this scale before, but have run numerous small scale tests and trials. I've had this reported to me at least once before but couldn't really find useful evidence in the logs at the time.
So, has anyone seen anything like this before? I could disable "If no one is logged in, reboot immediately without prompting or delay" as a safety net, but I'd rather get to the bottom of this one and determine if it's a freak case or other. The machine in question is actually one of pilot devices, so it probably had the task pushed to it twice, without a reboot - once as a pilot, one as a site-wide. I don't see how that might cause this behaviour though.
Richard