Esta declaración de soporte la proporciona el equipo de administración de productos.
En este artículo se explica el escenario en el que los clientes tienen un servidor DE ePolicy Orchestrator (ePO) existente que administra los sistemas cifrados y desean migrar esos sistemas a otro servidor de ePO.
Nota: DE 7.1 la actualización 3 ( 7.1.3 ) y posterior proporciona al administrador de ePO la capacidad de transferir sistemas de un servidor de ePO a otro mientras conservan las asignaciones de usuarios y los datos de usuario. Para obtener más información, consulte la siguiente documentación:
IMPORTANTE:
La siguiente información se aplica a las versiones antes DE 7.1 la actualización 3:
IMPORTANTE:
- Si el servidor de ePO también gestiona DE los sistemas, la migración al servidor de ePO no es compatible antes 7.1.3 de las limitaciones de ePO.
- Con versiones anteriores, le recomendamos encarecidamente que primero intente reparar el servidor o la base de datos de ePO actuales, en caso de que haya fallado.
- Esta declaración se aplica a la función de transferencia de sistemas ePO o a la recomendación de KB79283-cómo transferir equipos de un servidor de EPolicy Orchestrator a otro.
Los siguientes casos se muestran con frecuencia en entornos de ePO:
- El hardware del servidor de ePO debe mejorarse para administrar más sistemas.
- Se publica una versión posterior de ePO y se prefiere una nueva instalación en un nuevo servidor.
- El servidor de ePO actual tiene problemas que requieren que se genere un nuevo servidor de ePO y que se transfieran los datos del sistema.
Problemas tras la migración
Es posible que una migración inicial no muestre ningún problema, pero existen consideraciones que se deben tener en cuenta debido a los problemas que pueden materializarse tras la migración de ePO:
- Las siguientes opciones no se transfieren: etiquetas, directivas y tareas asignadas a un solo sistema, información de auditoría y generación de informes, y árbol de sistemas ubicación.
- las configuraciones del servidor de ePO no se transfieren. Cualquier valor que se haya modificado de la opción predeterminada requeriría una actualización. Por ejemplo:
- Reglas de asignación de directivas
- Tareas de servidor
- Atributos LDAP
- Tamaño de PBFS
- Palabras sencillas
- Temas personalizados
- La Directiva DE producto no se puede transferir de un servidor de ePO a otro porque la Directiva contiene el ePO Clave pública para ese servidor de ePO específico. La transferencia de la Directiva provoca que el equipo y la clave de recuperación se cifren con la clave incorrecta, lo que elimina la capacidad de realizar una recuperación del lado del cliente.
NOTA: Para obtener información, consulte KB82120-administración de desafío de recuperación de administrador devuelve un nombre de nodo de un cliente diferente.
- La configuración de directiva basada en usuario en la página DE: usuarios la consulta se debe reforzar para todos los usuarios que la necesiten.
- Se deben volver a crear las asignaciones de usuarios y grupos de seguridad realizadas en un nivel de grupo para los usuarios de cifrado.
- El equipo cliente debe recibir una Directiva activa o cifrada cuando se conecte al nuevo servidor o se iniciará el descifrado. Hacemos no recomienda aplicar una Directiva activa o cifrada a todos los sistemas del entorno para evitar la activación accidental en sistemas no deseados, tales como los servidores.
Una vez que un cliente empieza a comunicarse con el nuevo servidor de ePO, su
Machine ID en la base de datos de ePO cambia. Cuando el sistema anota el cambio en DE, el cliente carga su clave de cifrado en el nuevo servidor de ePO.
IMPORTANTE: Ninguno de los siguientes valores de datos se transfiere del ePO original al nuevo servidor de ePO, lo que provoca que esta migración no sea compatible con las versiones actual DE ePO o DE:
- Asignaciones de usuario
- Datos de token
- Datos de inicio de sesión único
Agregar usuarios del dominio local (AUDL) asigna usuarios del dominio
solo a los nuevos
machine object en ePO en una instancia. Esa instancia se debe a que el sistema cliente o el servicio DE se reinicie antes de que el sistema reciba y complete una implementación de directivas desde el nuevo servidor de ePO. AUDL ejecuta un AUDL completo solo después de reiniciar el servicio. Todas las demás rutinas de AUDL después del primer reinicio de AUDL Post Service son incrementales. Solo los usuarios del dominio que nunca han iniciado sesión en el sistema antes de agregarlos. Todos los usuarios asignados directamente al sistema se eliminan.