Who is this article for?
Incydr Professional, Enterprise, Gov F2, and Horizon, no.
Incydr Basic, Advanced, and Gov F1, no.
CrashPlan Cloud, no.
Retired product plans, yes.
CrashPlan for Small Business, no.
This article provides our recommended best practices for upgrading devices in Code42 environments version 5.2.x and earlier. For Code42 server version 5.3 and later, see Upgrade the Code42 apps in your environment.
Test the upgrade
We always recommend testing all software upgrades in a test environment before rolling out to your production environment. To do so, prepare a test environment for your Code42 servers and devices: Code42 environments with multiple Code42 servers
Plan your bandwidth consumption
Devices download the upgrade files for the Code42 app directly from your authority server. Prior to upgrading, you can estimate the total download size across the deployment. Estimate the total size by multiplying the number of your devices by the size of the upgrade file.
The size of the upgrade file varies from version to version, so determine it by locating the upgrade file on your authority server's file system.
To better control when bandwidth consumption occurs, pre-stage the upgrade files on Code42 app devices.
Plan for device upgrade duration
Once you allow your devices to automatically upgrade, the devices download upgrade files from the master server at a randomized interval between 1 and 15 minutes. If the download attempt is unsuccessful, devices retry after one hour. The speed of your overall device upgrade depends on a number of factors:
- Load on the master server
- Load on the network
- Reliability of the device's connection
- Whether devices are powered on and connected when you enable Auto-upgrade devices
- Size of the upgrade
Plan for performance of your master server
If your administration console shows poor performance while devices are upgrading:
- Check the master server system's process monitor to make sure that the Code42 server service is still running.
- Check to see if the Code42 server service is resource-constrained. If so:
- Block TCP port 4282 inbound on your host server to prevent CrashPlan app devices from connecting to retrieve the upgrade.
- Gradually add IP range exceptions to allow groups of CrashPlan app devices to connect and upgrade, while minimizing resource consumption on the master server.
Identify devices that have not upgraded
The best way to identify devices that have not yet upgraded is to use the Code42 API to identify the versions of devices in your Code42 environment. For more information about using the Code42 API, see our Code42 API documentation.
Wait before you perform sequential upgrades
When performing multiple upgrades in sequence, we recommend that you allow time for devices to complete one upgrade before beginning a later upgrade.