Ivanti Agent May Continually Prompt to Reboot
Ivanti EPM uses the vulnerability scanner process (vulscan.exe) to evaluate and conduct necessary reboots. Vulscan considers your agent settings and references Windows API and two specific registry keys to determine whether or not a Windows device needs a reboot. Having the agent installed on your devices allows them to present a reboot GUI to your end users if a reboot is pending and if your Agent Settings configuration allows. Depending on your agent settings options and the tasks you are deploying, vulscan may cause the device to prompt for reboots multiple times.
Under some circumstances multiple reboot prompts may appear in short order, even after allowing a reboot. Distribution and Patch agent settings, along with Reboot settings, are very flexible and can be configured in many different ways. Sometimes the combination of options chosen causes unexpected behavior. This document provides an overview of the applicable systems and settings, and discusses some common reasons and configurations that may result in multiple reboots or reboot prompts.
This document focuses on reboots triggered via patching instead of a software deployment task (sdclient) but for the most part the lessons herein apply to sdclient as well
Detecting a Pending Reboot
It is normal expected behavior for vulscan to detect if a reboot is pending. It does so during every scan job by evaluating the presence of the below registry keys:
Pending File Rename Operations
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager]
"PendingFileRenameOperations"
The vulscan log will contain this text:
Pending file rename data is present. Reboot is needed.
Vulscan Reboot Registry Key
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\WinClient\VulscanReboot ]
The vulscan log will contain this text:
Vulscan reboot key exists. Reboot is needed.
Detecting that a reboot is pending does not automatically cause vulscan to process that reboot.
When is Vulscan Allowed to Reboot?
Vulscan detects when reboots are pending during any job but will only process a reboot when all of the below conditions are met:
- One of the above registry keys indicates a reboot is pending
- Vulscan attempted to install patches (a scan-only job will not trigger reboot processing)
- The applied agent settings give vulscan permission to reboot the device (vulscan will still process any end user prompts, honor automatic reboot conditions, and honor the automatic reboot window (if configured)).
Whether a reboot is pending will be detected anytime vulscan runs but scan only tasks will not cause reboot conditions to be evaluated or a reboot to be triggered. Vulscan must actually process the install phase due to a repair task or autofix in order to subsequently process the reboot phase.
Common Causes
"Stuck" registry key
The keys mentioned previously are set by the OS or by vulscan. They are volatile and should be removed when the device reboots. Under some circumstances (for example if either key is manually set) they aren't removed upon reboot. This causes vulscan to detect a pending reboot again the next time it runs, although as mentioned previously detecting that a reboot is pending is not enough by itself to cause a reboot to happen.
If you determine that either key is stuck, it's usually sufficient to manually delete the key. Afterward, it should be volatile when the OS or vulscan next set the key.
You may also find at times that faulty applications constantly re-set the Pending File Rename Operations key. The key identifies the files in question that are pending and you can use this info to identify the misbehaving application. You may need to work with the application vendor's support team to identify and solve why it keeps setting reboot keys.
Continuation
Your distribution and patch settings contain a 'continuation' option:
Continuation allows vulscan to automatically continue a repair task after the computer reboots or other necessary prerequisites are met. A common situation that triggers continuation is when patching must halt due to a pending reboot, or when some patches fail due to a necessary reboot. After the reboot occurs, vulscan can automatically continue and may repair additional patches. If vulscan attempts an install, even if it's due to continuation, it will evaluate your reboot settings and if allowed, may reboot or prompt the user to reboot. By default Continuation is allowed up to 5 additional repairs.
Important note: continuation only applies if you have started a repair task. Continuation cannot give vulscan permission to install patches unless you granted this permission to the original repair task
User Error
It is unfortunately true that many end users don't understand technology as well as we'd like, and sometimes misunderstand or misinterpret what they see and experience. Our support teams have encountered many of these situations. One common example is when an end user gets the reboot prompt and chooses to defer. Sometimes the user will log off or lock their computer, or go home for the day, or otherwise forget that they deferred the reboot. The prompt later appears again according to agent settings, and the end user assumes that they are being prompted to reboot again, when in reality they never completed the first reboot.
Beyond educating the user there isn't a lot that can be done to fix this. It is helpful as a first step to determine if\when the computer rebooted and which process was responsible for it. You can most easily see this by opening event viewer and filtering the Windows Application logs by event ID 6006 and 6008:
The timestamp of the applicable restarts can be matched up to vulscan logs to get more information
In some cases you may find that the computer did not reboot, or did not reboot due to any Ivanti process.