Behaviour has been observed whereby after upgrading the CCA and any other AppSense agents to 10.1 the endpoint will reboot without prompting the logged in user. This occurs even though the Deployment Installation setting for Agents is set to "At next system restart".
This has only been seen by a single customer and was not reproducible by Support or by the customer using different Deployment groups.
An "In-place" upgrade involves taking a copy of an existing Management Server 8.7 database and restoring it to a different SQL instance. A server with Management Server 10.1 is then used to connect to this copy and is upgraded using the Server Configuration Portal. This creates a scenario where you have two separate Management Server environments that share the same endpoint machines in their respective databases.
All machines in this scenario will continue to poll to the 8.7 environment as that is the server URL contained in their registry. Upon polling the endpoint from the 10.1 environment the affected endpoints forced a rebooted without prompt. When the behaviour was observed this only occurred in a single Deployment group. All other endpoints in other groups did not reboot without prompt. The behaviour was isolated to a lack of addresses for the new environment in that Deployment group's Failover Server list.
An important step in ensuring this kind of upgrade is successful is that you must add the new server address(es) into the Failover Server list of the Deployment groups before you create a copy of the database. In the Deployment group were the endpoints were forcing a reboot they did not have the new Management Server addresses in their Failover Server list which prompted unexpected behaviour. After adding the 10.1 Management Server addresses to the Failover Server List within the old 8.7 environment and polling those affected endpoints the unexpected reboots were not seen again.
There has been multiple attempts to reproduce the behaviour by Support and attempts to do so with the customer that was affected using similarly configured Deployment groups however the issue seems to have been unique.
No further specifics of this issue that identify a root cause can be determined at this time. In order to ensure this type of behaviour would not likely be encountered it would be recommended to have your new Management Server addresses contained with your Failover Server lists before beginning this type of upgrade.