Reboot Requirements - Windows Agents

When installing the agent for the first time or upgrading from a previous version, read this entire topic to understand what conditions in the runtime environment will result in a required reboot of the computer in order for the install/upgrade to be completed properly and the agent to function properly. Failing to understand the reboot requirements in relation to your environment may result in the application control service or other components of the agent failing to function properly.

The Verify Privilege Manager agent for Window is composed of a mix of .NET managed code and native C++ code built into various binary format EXE and DLL files. Some of the binaries run as native NT services, such as Thycotic Agent (Core Agent) and Thycotic Application Control (ACS), while others run on the user’s interactive desktop, such as the Agent Utility, JIT Mode Manager, and the various “helper apps” which display the justify/approval UI or the application denied/blocked messages. Additionally, some of the DLLs are loaded into PowerShell as modules when various scheduled tasks are executing, while others are loaded into processes running applications which have had various actions applied to them such as Restrict File Dialogs or Block Local User/Group Management, or were launched with Admin rights under JIT, were subjected to justify/approval requirements, etc. Finally, there is a DLL that gets loaded into Microsoft’s AppInfo (Application Information) service, where the majority of UAC functionality is implemented, so that the agent can intercept the UAC consent prompt when performing elevation operations.

When the agent is installed for the first time, there are no concerns about existing agent-related files being held open such that a reboot is required to replace them with newer versions. However, the AppInfo service will not have our DLL loaded into it to intercept the UAC consent prompt until a reboot has been performed. It is not sufficient to simply stop the AppInfo service and then restart it. This effectively means that a reboot is always required. It should be noted that by default, the AppInfo service, which is implemented in a DLL and loaded by an instance of SVCHOST.EXE, is configured to run in a shared process which also hosts other native NT services. Attempting to avoid the reboot by simply killing the service host process to force the service to be restarted will cause undesirable collateral damage that only further necessitates a reboot.

When the agent is upgraded, the native NT services for Thycotic Agent and Thycotic Application Control are both stopped by the installer. However, the AppInfo service does not get stopped and cannot be stopped by the installer. Also, the number of application processes running on the computer that may have other agent-related DLLs held open because of application control logic having been inserted into them is completely non-deterministic. To further complicate things, it is possible for a scheduled task to execute in a non-deterministic manner while the agent installer is running. The result is that any upgrade of the agent is guaranteed to have one or more files held open which cannot be replaced until the computer is rebooted. Attempting to restart the Thycotic Agent and Thycotic Application Control services will result in either or both failing to function properly because of loading a mixture of outdated and updated DLLs. One frequent problem that has been observed is that the Thycotic Application Control service starts but does not function properly and consumes excessive amounts of CPU time. Additionally, if the AppInfo service is still running with the old agent-related DLL loaded into it, the handling of elevation operations involving interception of the UAC consent prompt may fail to function properly.

It should be noted that the interactive combined installer will prompt for a reboot if it detects that certain files are locked, but due to some quirky behavior in how MSIEXEC.EXE works, there are times when the installer will not report a reboot as required when one is required. For the separate or combined MSI packages, there are command line parameters that can be provided to suppress an automatic reboot when one has been determined to be required, but the same caveats apply regarding the agent’s various components failing to function properly until a reboot has been performed.

This behavior is 100% normal and has been common to the Windows platform going all the way back to 16-bit Windows 3.1. As such, it is not a defect with the agent nor its installer. Bug reports should never be filed due to a reboot being required to complete an install/upgrade. When planning to deploy the agent in an enterprise environment, the need to reboot the computer should be accounted for up front to minimize downtime and interruptions for end users.