How to transfer computers from one ePolicy Orchestrator server to another
Technical Articles ID:
KB79283
Last Modified: 2023-07-25 09:51:04 Etc/GMT
Environment
ePolicy Orchestrator (ePO) 5.x
Summary
IMPORTANT: Note the differences between Automatic Sitelist Import and Manual Sitelist Import.
Automatic Sitelist Import:
- This option has limitations. An automated import doesn't add any Remote Handlers.
- When you transfer a system, the destination Remote Agent Handler details aren't included in the sitelist file. Only the ePO Server information is included.
- When the sitelist is imported, it checks the eposerverinfo table on the destination ePO server. So, before the transfer is initiated, make sure that all clients can reach the destination ePO server.
- When you need to add a Remote Agent Handler entry, you must manually import the SiteList.xml.
- Obtain a copy of the SiteList.xml. The file is stored in the folder below on the server where the agents are being transferred to:
ePO_Installation_Folder\DB\SiteList.xml
- To import the SiteList.xml manually, follow the steps listed in the ePO 5.10 Product Guide.
General advice:
- The Transfer systems option only moves the entries for the systems and causes the agents to report to the new ePO server. You must manually update System Groups, Policies, Assignments, Product Extensions, and Packages on the new server.
The transfer of policies doesn't occur automatically when you transfer systems from one ePO server to another. You must manually apply policy assignment for managed products to the respective group on the new ePO server.
It's recommended that you first transfer one system. Verify that it's correctly reported to the Lost and Found group on the new server. Then, verify that the policies are correctly applied before you transfer many systems.
- The following applies if you manage Drive Encryption (DE) systems:
DE 7.1 Update 3 (7.1.3) provides the ePO administrator with a new capability. This feature allows systems to be transferred from one ePO server to another while preserving user assignments and user data. For details, see the following documentation:
The following applies to Management of Native Encryption (MNE) systems:
With MNE in the environment, the same applies whether you manage Microsoft BitLocker or Apple FileVault (Mac OS X 10.3 and later).
Key points to observe:
- The MNE FileVault or BitLocker policy must be enabled on the destination ePO server before you transfer systems.
- FileVault example:
- If the MNE FileVault policy is not enabled on the destination ePO server:
- The Endpoint Protection for Mac Console status under Encryption and Management Mode shows FileVault as not managed.
- The Recovery Key Status shows as Client has not escrowed the key in ePO.
- If the MNE FileVault policy is enabled after the system is transferred, and policy enforcement has occurred:
- The Endpoint Protection for Mac Console status under Encryption and Management Mode shows FileVault as managed.
- The Recovery Key Status shows as Client has not escrowed the key in ePO.
- The system can be transferred back to the source ePO server, and then to the destination ePO server, which allows the key to be escrowed.
Problem
You might see the following error when you register the servers and enable the Transfer Systems option with Automatic Sitelist Import:
ERROR: Master agent-server key(s) must be imported into the remote server prior to importing the sitelist. Go to Server Settings to export security keys from this server. Note that visiting this link now will cause you to lose any unsaved changes to this registered server.
Import both keys ( 1024 and 2048) from the ePO server for successful registration. The Automatic Sitelist Import can then be saved without any issues.
Solution
IMPORTANT:
- Don't transfer systems with DE 7.1.1 or earlier between servers because encryption keys and user assignments aren't moved from one server to another. Doing so disassociates the client from its keys and removes users from systems. This action causes users to get locked out.
- You might consider consolidating ASCI keys between ePO servers so that both (all) servers use the same ASCI keys. Consolidating ASCI keys is useful if you intend to keep all ePO servers live in production and transfer agents back and forth between them. Large numbers of ASCI keys on an ePO server can result in delays in data channel requests and agent wakeup calls. The reason is because each outbound connection must be tried with each ASCI key present. For more details, see KB82022 - Excessive delays in processing newly entered data channel requests in larger environments with numerous data channel activities.
NOTE: Before you transfer systems, make sure that there are no duplicated systems on the old ePO server. In this way, you can avoid issues with reporting. Run the default query with the name Duplicate Systems Names.
The following procedure describes how to transfer managed computers from Server A to Server B, where Server A = Old ePO 5.x and Server B = New ePO 5.x:
- Export the security keys from Server A (old server):
NOTE: Only ASCI keys are needed. You must export only the 2048-bit and 1024-bit keys.
- Log on to the ePO 5.x console (old Server A).
- Click Menu, Configuration, Server Settings.
- Click Security Keys under the Setting Categories column, and click Edit on the right pane at the bottom of the page.
- For the 2048-bit keys listed under the Agent-server secure communication keys, perform the following:
- Click the key identified as 2048-bit and click Export.
- Click OK. This action confirms the export key confirmation message.
- Click Save.
- Type or browse to a path where you want to save the security key (.zip) file, and then click Save again.
- Repeat step 1d for the 1024-bit keys.
- Import the security keys from Server A (old server) to Server B (new server):
NOTE: Only ASCI keys are needed. You must import only the 2048-bit and 1024-bit keys.
- Log on to the ePO 5.x console (new server B).
- Click Menu, Configuration, Server Settings.
- Click Security Keys under the Setting Categories column, and click Edit on the right pane at the bottom of the page.
- Click Import.
- For the 2048-bit key, perform the following:
- Click Browse, locate the exported 2048-bit security key (.zip) file, and click Open.
- Click Next.
- Click Save on the Summary tab.
- Repeat step 2e for the 1024-bit keys.
- Register Server B (new server) to Server A (old server):
- From Server A, log on to the ePO console.
- Click Menu, Configuration, Registered Servers.
- Click New Server.
- Select ePO from the Server type drop-down list, type a name for this server in the Name section, and click Next.
- To reach Server B (ePO database), type the credentials, and click Test Connection. If the test fails, look in the orion.log for errors, and search the Knowledge Base for a solution.
- If the test is successful, click Enable for the Transfer systems entry. Make sure that Automatic sitelist import is selected, and click Save.
NOTES:
- The Manual sitelist import option is also available. It can be used if you want to do a manual import by selecting an existing Sitelist.xml file. See the ePO 5.10 Product Guide for details about how to use this option.
- You can obtain the Sitelist.xml file for this process. It's stored in the folder below on the ePO server where the agents are being transferred to:
<ePO_Installation_Directory>\DB\SiteList.xml
- After you've imported the keys and ePO Server B is registered, Server A allows the option for transfer to be selected:
- Log on to the ePO console.
- Click System Tree.
- Click the Systems tab on the right pane and select the computer to transfer.
- Click Actions, Agent, Transfer Systems.
- Select the entry for Server B (new server) and click OK to transfer.
NOTE: Make sure that the selected computer communicates to ePO Server A before the transfer.
- Verify the status of transferred computers after two ASCI triggers. After the process is complete, you can see the computer listed in the Server B (new server) System Tree.
NOTE: The computer is not expected to display in the Server A System Tree. To confirm, send an agent wake-up call from Server B and confirm that the computer is communicating.
|
