Who is this article for?
CrashPlan for Enterprise, yes.
Code42 for Enterprise, yes.
CrashPlan for Small Business, no.
This article applies to on-premises authority servers.
Other available versions:
Code42 platform administrators can use block, deauthorize, and deactivate actions to control access to data and manage accounts. This article explains the impact each of these actions has on organizations, users, devices, and plans in your Code42 environment.
- You must have administrative role permissions to perform block, deauthorize, and deactivate actions from the Code42 console.
- You should understand the basic information hierarchy of the Code42 platform, including the definitions below:
A single account in your Code42 environment. A user account has a single set of sign-in credentials (username and password) and a single encryption key for all backups. A user always belongs to one (and only one) organization.
The hierarchical level in the Code42 environment for users and their devices. Each user can belong to only one organization. You can define many settings at the organization level; different organizations can have different settings. An organization can contain child organizations, and an organization can exist without containing any users.
Blocking, deauthorizing, and deactivating at a glance
- Blocking is a non-destructive action that prevents access to the Code42 app. A blocked user or device cannot sign in.
- Deauthorizing is a non-destructive action that simply signs a user out of a specific device. Users can sign in again at any time.
- Deactivating is a destructive action that removes a device, user, organization, or plan from your Code42 environment. An active user can sign in again to a deactivated device, but a deactivated user cannot sign in.
The following table shows how blocking, deactivation, and deauthorization can be applied to devices, users, organizations, and plans:
|Devices||Users||Organizations||Possible Data Loss|
Watch the video below to learn more about how to deauthorize and block a device. For more videos, visit the Code42 University.
Blocking prevents access to the Code42 environment but is not destructive to existing data. Specific implications for devices, users, and organizations are detailed below.
- When you block a device, the user is signed out of the Code42 app on that device and cannot sign in again on that device.
- Users can continue to use other devices.
- Data on the device is still protected on the Code42 server.
- The Code42 service continues backing up, but users cannot access the Code42 app on the device to restore data or change settings.
- When you block a user, that user cannot sign in to any part of your Code42 environment:
- Users cannot sign in to the Code42 app from any device.
- Online access to the Code42 console is also blocked.
- User data is still protected on the Code42 server.
- The Code42 service continues backing up all of the user's devices, but the user cannot access the Code42 app to restore data or change settings.
When you block an organization, all users in the organization are blocked, as well as all users in child organizations.
Blocks and licenses
Blocked devices still use a license.
Use case examples
- Theft or loss: you may want backups to continue while searching for the device, but want to prevent unauthorized access to backup archives.
- Licensing: if you are managing backups for a third party, you may need to block a user for billing purposes.
- Legal: in legal proceedings, you may need to restrict access to data due to a legal hold. Users on legal hold cannot be deactivated, but they can be blocked.
When you unblock a device, user, or organization, normal access to the Code42 app is restored.
Deauthorization only applies to devices. Users and organizations cannot be deauthorized.
- When you deauthorize a device, the current user is signed out of the Code42 app. Users can sign in again at any time.
- Deauthorization is not destructive, and no data is deleted when a device is deauthorized.
- The Code42 service stops backing up, and users cannot access the Code42 app to restore data or change settings without signing in again.
Deauthorizations and licenses
Deauthorized devices still use a license.
Use case examples
- Troubleshooting: deauthorization is sometimes requested by our Customer Champions.
- Testing: deauthorizing a device can be used to test a user's credentials or other behavior.
- Theft or loss: the device will be unable to back up or restore files until the user has signed back in to the device.
Deactivation is a destructive action that prevents access to the Code42 environment and removes user data from devices. Specific implications for devices, users, organizations, and plans are detailed below.
Permanent Data Loss Warning
Deactivation can destroy data, unlike blocking or deauthorizing.
- Deactivated archives on a Code42 server destination are placed into cold storage for the configured cold storage period. Once the cold storage period has passed, the archive is permanently deleted.
- Archives backed up to a local folder or other account device are immediately deleted upon deactivation. Cold storage is only available for Code42 server destinations.
For step-by-step recommendations on deactivation, see Deactivate and reactivate users and devices.
- When you deactivate a device, the user is signed out of the Code42 app on that device.
- The user can sign in again at any time, but archives previously associated with the device will no longer be present.
- The Code42 service stops backing up and restores are not available.
- Backup archives are removed from all backup destinations and the device's backup archive is sent to cold storage. Archives in cold storage do not continue to back up, do not undergo regular archive maintenance, and by default will be deleted after 365 days.
- For Code42 environments that use customized Code42 app installers configured to auto-register users, Code42 recommends blocking the device before deactivating. Without first blocking the device, it may reactivate automatically.
- When you deactivate a user, the user is signed out of all devices and online sessions, and the deactivated user cannot sign in to any part of your Code42 environment:
- Users cannot sign in to the Code42 app from any device.
- Online access to the Code42 console is also prohibited.
- The user cannot sign in to any device until being reactivated.
- Backup archives are removed from all backup destinations and all of the user's backup archives are sent to cold storage. Archives in cold storage do not continue to back up, do not undergo regular archive maintenance, and by default will be deleted after 365 days.
If a user is placed under legal hold, the user cannot be deactivated. Their data is retained for the legal hold process.
Depending on your Code42 server version, Code42 responds in the following ways when you mark a user for deactivation (either during an LDAP sync or by manually deactivating a user from the Code42 console):
- Code42 version 6.5.x and later: Users are blocked instead of deactivated. Once the user is released from legal hold, they are automatically deactivated.
- Code42 version 6.0.x and earlier: User is not deactivated. You must manually deactivate the user once they are released from legal hold.
Reactivating a user: In version 6.5.2 and earlier, if you deactivate users while they are on legal hold, and then wish to reactivate those users, you must reactivate each user and reattach their deactivated archive. In 6.7.2 and later, unblock the user.
When you deactivate an organization, all users in the organization are deactivated, as well as all users in child organizations.
Deactivation and licenses
Use case examples
- Reclaiming licenses: deactivation is the only action that can free licenses that are being used.
- Offboarding: deactivate a user account when an employee leaves the company.
- Device recycling: deactivate a device when permanently removing it from service.
Reactivation restores access to the Code42 environment and makes deactivated archives available for use once again by affected users, devices, and the Code42 server. For step-by-step instructions on reactivating a deactivated user or device, see Deactivate and reactivate users and devices.
Recovering a deactivated archive is only possible if the device or user is reactivated before the end of the cold storage period. Please contact our Customer Champions for support if you need assistance recovering deactivated archives.
When you reactivate a device, the deactivated archives are made available once again by the device. The device must be reactivated before the end of the cold storage period.
When you reactivate a user, the deactivated user's archives are made available for use once again by each device associated with the user, and all devices associated with this user account are reactivated immediately. The user must be reactivated before the end of the cold storage period.
When you reactivate an organization, all users in the organization are reactivated, as well as all users in child organizations.
Watch the video below to learn more about how to deactivate users. For more videos, visit the Code42 University.