You receive word that some end users were prompted to reboot multiple times. This document is intended to help you identify what reboots occurred and why.
MORE INFORMATION
The most common reason for reports of multiple reboots is user error. If your reboot settings are such that they prompt the user but do not force an automatic reboot, many end users will snooze the reboot multiple times. They leave for the day locking or logging out of their computer and come in the next day to see a new reboot prompt. They assume that they are being prompted for an additional reboot when in fact they are being prompted for the same reboot that they snoozed the day before.
The first questions you should ask the end user is, "Did you snooze the reboot?" and, "When did your computer actually reboot?"
The Ivanti EPM agent does not track reboots. If you view the Security and Patch information for a device, the Clean/Repair History section will show when the device logged out and logged in, and rebooting the device does show up as a logout event, but you can't tell from this information whether the device actually rebooted or just logged out. For this reason this information should not be relied on or considered an accurate log of rebooting.
HOW TO TELL WHEN A DEVICE LAST REBOOTED
To rule out user error you can check to see the last time the device rebooted. If you have physical access to the device, just open a CMD prompt and run this command:
systeminfo | find /i “Boot Time”
You will see the date and time of the last reboot or shutdown:
From the Ivanti EPM console, you can right-click the device and go to Inventory. Select OS from the options on the left and you will see the Last Start Up Time. Keep in mind this is the last time the device started, which may have been a shutdown event that took place earlier and not necessarily from a reboot:
It is also helpful to see how many times a device has rebooted and when. To do this you'll need to search the Event logs on the device. Look at Windows Logs -> System. Filter the current log and look for Event ID 13 (shutdown event):
PATCH INSTALL & CONTINUATION
If you determine that the device did actually reboot multiple times, the next step is to determine why. Continuation is one legitimate reason why Ivanti EPM would cause multiple reboots. If some patches were installed, but a reboot is required before additional installs can take place, the vulnerability scanner (vulscan.exe) will set a continuation task in the LANDESK local scheduler so that vulscan starts again after the reboot. When vulscan runs again, it may cause an additional reboot. By default, Continuation is allowed for up to 5 additional repairs. This can be configured or disabled in your Distribution and Patch settings:
PATCH DETECTION ERRORS & AUTOFIX
Another possible cause for multiple reboots is incorrect patch detection. If you are using Autofix and a vulnerability has a specific kind of detection error, the patch could be detected as vulnerable and install, only to be detected as vulnerable again when vulscan runs the next day and prompt for another reboot. This is a rare situation but it is possible. If you see this happening, move that vulnerability to the Do Not Scan folder to halt the loop and log a case at support.landesk.com to fix the detection issue. Please include a vulscan log showing the detection when logging a case.
LOGS TO REVIEW
If none of these situations are occurring then we will look at the logs to find out what happened. If rebooting happened due to a Patching task, the vulscan.log files in c:\programdata\landesk\log will be the most helpful. Please note - if the user has snoozed a reboot, vulscan will run every 10 minutes to determine if any of the automatic reboot conditions in your Reboot settings have been met. By default 10 vulscan logs are retained before being overwritten. This makes it very important to review the logs shortly after the reboot occurs, otherwise, the log which shows the event that originally triggered the reboot will be overwritten. If it's not possible to retrieve the logs in a timely manner, you can instead increase the default amount of logs that are retained. This document explains how:
How to: Retain more vulscan logs before they are overwritten
The beginning of the vulscan log will tell you what type of vulscan task was running and how it started. Pay attention to the "Command line:" and "Parent process:" sections which can tell you the type of task (repair task vs. scheduled scan only vs. autofix vs. continuation etc.). The section dealing with rebooting is usually close to the bottom of the log. If you skip to the bottom and search upwards for "reboot" you will quickly find the relevant information.
While reviewing the vulscan log, pay attention to the agent setting for reboot that was used for the task at hand. The vulscan log will show the setting by name and ID, and lists the revision number. If this doesn't match exactly with the setting ID and revision number on your core, then this device is using an out of date or incorrect reboot behavior and you will need to troubleshoot why vulscan is not properly updating agent settings.
If the vulscan logs don't indicate reboots with timestamps that match up to the shutdown events in the Event Viewer, then a process other than Patching caused the reboot. The next logs to look at are the sdclient_taskxxx.log files located at %LDMS_LOCAL_DIR%. These are the logs created by software distribution tasks. Again, the relevant reboot info can be found by skipping to the bottom of the log and searching upward.
If the reboot was not caused by patching or software distribution, then most likely it happened due to a non-Ivanti Endpoint Manager process.