This support statement is provided by the Product Management Team.
This article covers the scenario wherein customers have an existing ePolicy Orchestrator (ePO) server that manages DE encrypted systems, and they want to migrate those systems to a different ePO server.
NOTE: DE 7.1 Update 3 (7.1.3) and later provide the ePO Administrator with the capability to transfer systems from one ePO server to another while they preserve user assignments and user data. For more information, see the following documentation:
IMPORTANT:
The following information applies to releases before DE 7.1 Update 3:
IMPORTANT:
- If the ePO server also manages DE systems, migration to the ePO server isn't supported before DE 7.1.3 because of DE and ePO limitations.
- With earlier releases, we strongly recommend that you first try to repair the current ePO server or database, if it has failed.
- This statement applies to the ePO Transfer Systems feature, or the advice in KB79283 - How to transfer computers from one ePolicy Orchestrator server to another.
The following scenarios are often seen in ePO environments:
- The ePO server hardware needs to be enhanced to manage more systems.
- A later version of ePO is released and a fresh installation on a new server is preferred.
- The current ePO server has issues that require a new ePO server to be built and the system data transferred.
Issues after migrating
An initial migration might not show any issues, but there are caveats to consider because of issues that can materialize after ePO migration:
- The following are not transferred: Tags, policies, and tasks assigned to a single system, audit and reporting information, and System Tree location.
- ePO server configurations aren't transferred. Any values that have changed from the default would require an update. For example:
- Policy Assignment Rules
- Server Tasks
- LDAP attributes
- PBFS size
- Simple words
- Custom themes
- The DE Product policy can't be transferred from one ePO server to another because the policy contains the ePO Public Key for that specific ePO server. Transfer of the policy results in the computer and Recovery Key being encrypted with the wrong key, which removes the ability to perform a client-side recovery.
NOTE: For information, see KB82120 - Admin Recovery challenge code input returns a node name from a different client.
- The User Based Policy setting in the DE: Users query must be reinforced for all users who need it.
- User and Security Group assignments made at a Group level for Encryption Users need to be re-created.
- The client computer must receive an Active or Encrypted policy when it connects to the new server, or it starts decrypting. We do not recommend applying an active or encrypted policy to all systems in the environment to prevent accidental activation on unintended systems, such as servers.
After a client begins to communicate with the new ePO server, its
Machine ID in the ePO database changes. When the system notes the change in DE, the client uploads its encryption key to the new ePO server.
IMPORTANT: None of the following data values are transferred from the original ePO to the new ePO server, which results in this migration being unsupported with the current ePO or DE releases:
- User assignments
- Token data
- Single Sign On data
Add Local Domain Users (ALDU) assigns domain users
only to the new
machine object in ePO in one instance. That instance is if the client system or DE service restarts before the system receives and completes a policy enforcement from the new ePO server. ALDU runs a full ALDU only after a service restart. All other ALDU routines after the first ALDU post service restart are incremental. Only domain users that have never logged into the system before are added. All users assigned directly to the system are removed.
