Upgrading the App Control Server

Products

• Carbon Black App Control

Issue/Introduction

Steps for upgrading the App Control Server installation.

Environment

• App Control Server: All Supported Versions
• Microsoft Windows: All Supported Versions

Resolution

Important Version Specific Notes

• Before upgrading to version 8.12.0 or higher, first upgrade the Rules Installer to version 1.32 or higher to prevent issues with package generation.
• Before upgrading to version 8.11.0 or higher, prevent accidental lockout by verifying the Server License is not expired in Settings > System Configuration > Licensing.
• The first upgrade to version 8.10.2 or higher may take longer than normal, which is expected.

Required Pre-upgrade Activities

• Verify the Server Upgrade Path is supported.
• Verify SQL Server is on the latest Cumulative Update.
• Verify the OER for the version upgrading to: Tech Docs > Carbon Black > App Control Server > Server OER.
• Verify the Service Account has all required SQL & Windows permissions.
• Download the latest App Control Server installer.
• Take a new, known-good, full backup of the DAS database.

Upgrade Steps

1. Log in to the App Control Server as the App Control Service Account.
2. If an Agent is installed on the application server it is recommended to temporarily:
   1. Disable Tamper Protection.
   2. Move the Agent to Local Approval.
   3. For other security software on the system make sure Server Exclusions are in place. 
3. Temporarily stop the services:
   • Carbon Black App Control Reporter
   • Carbon Black App Control Services
4. Make sure any external jobs or tasks that rely on the Server are temporarily disabled during the upgrade, examples may include:
   • SQL backups or external SQL scheduled tasks running against the das database
   • Agent deployments or upgrades via Deployment Tools (MECM, Intune, Jamf, etc)
5. Execute the ParityServerSetup.exe file to initiate the upgrade.
6. After the upgrade completes
   1. Validate the Carbon Black App Control Server and Reporter Services are started.
   2. Log in to the Console and verify Agents are beginning to show as Connected.

Considerations When Using Always On Availability Groups

Leaving the Sync enabled during the upgrade... Could contribute to upgrade delays/performance impacts. Could cause network saturation due to large amounts of Transaction Logs being sent between Primary and Secondary. A failed upgrade on the Primary could result in a failed upgrade on the Secondary with both databases in a corrupted state. Leaving das in the Availability Group but just with the Sync paused during the upgrade... The Primary must maintain all entries in the Transaction Log until Sync is resumed. If the drive where the Maintenance Log is kept runs out of space, the upgrade could fail leaving the database in a corrupted state. Limitations with supportability.... While the use of a SQL Server Availability Group Listener has been verified as a valid Database Server option, no testing is conducted in-house. Design, implementation and maintenance of a SQL Server Always On Availability Group is outside the scope of Support. The following steps are a best effort.

1. Before upgrading the Primary
   1. Remove the das database from the Always On Availability Group
   2. Change the Recovery Mode to Simple
2. Follow the Upgrade Steps above to upgrade the Primary.
3. After successfully upgrading the Primary, take a full database backup from the Primary and restore on the Secondary.
4. Verify MultiSubnetFailover Configuration.
5. Re-enable the sync.

 

Note: Upgrading the App Control Server software does not upgrade the Agent or Rules Installers. This is done through a separate process.

Additional Information

• Some upgrades require a reclassification of rules.
  • This takes place automatically after an upgrade, the Console could be down for 5-30 minutes on average while this classification takes place.
• During the Server upgrade:
  • The Console will be unavailable.
  • Agents will continue to enforce based on the Disconnected Enforcement Level specified in the Policy.
  • By default, this is the same as the Connected Enforcement Level.
  • Event information is stored locally in the Agent's cache and reported to the Server once the connection is restored.
• Newer Server versions can communicate with older Agents, and Agents typically don't need to be upgraded at the same time.
• App Control Server Install logs can be found here.
• For more detailed instructions, please refer to Tech Docs > Carbon Black > App Control Server > Server Installation Guide
• How to Collect Logs for Server Upgrade Failures