Cette déclaration de support est fournie par l'équipe de gestion des produits.
Cet article traite du scénario dans lequel les clients disposent d’un serveur ePolicy Orchestrator (ePO) existant qui gère les systèmes chiffrés et qui souhaitent migrer ces systèmes vers un autre serveur ePO.
Remarque : DE 7.1 mise à jour 3 ( 7.1.3 ) et versions ultérieures fournissent à l’administrateur ePO la possibilité de transférer des systèmes d’un serveur ePO à un autre, tout en préservant les affectations d’utilisateur et les données utilisateur. Pour plus d’informations, reportez-vous à la documentation suivante :
IMPORTANT :
Les informations suivantes s’appliquent aux versions antérieures 7.1 à la mise à jour 3 :
IMPORTANT :
- Si le serveur ePO gère également des systèmes, la migration vers le serveur ePO n’est pas prise en charge avant l’installation 7.1.3 de et des limitations d’ePO.
- Avec les versions antérieures, Nous vous recommandons vivement de tenter d’abord de réparer le serveur ePO ou la base de données en cours, en cas d’échec.
- Cette affirmation s’applique à la fonctionnalité de transfert de systèmes ePO ou aux conseils de KB79283-comment transférer des ordinateurs d’un serveur ePolicy Orchestrator vers un autre.
Les scénarios suivants sont souvent observés dans les environnements ePO :
- Le matériel du serveur ePO doit être amélioré pour gérer davantage de systèmes.
- Une version ultérieure d’ePO est publiée et une nouvelle installation sur un nouveau serveur est préférable.
- Le serveur ePO actuel rencontre des problèmes qui nécessitent la construction d’un nouveau serveur ePO et le transfert des données du système.
Problèmes après la migration
Il se peut qu’une migration initiale n’affiche aucun problème, mais qu’il existe des avertissements à prendre en compte en raison de problèmes pouvant se concrétiser après la migration d’ePO :
- Les éléments suivants ne sont pas transférés : marqueurs, stratégies et tâches affectés à un seul système, audit et rapports, ainsi que arborescence des systèmes emplacement.
- les configurations du serveur ePO ne sont pas transférées. Toutes les valeurs qui ont changé par rapport à la valeur par défaut nécessitent une mise à jour. Par exemple :
- Règles d'affectation de stratégie
- Tâches serveur
- Attributs LDAP
- Taille système PBFS
- Mots simples
- Thèmes personnalisés
- La stratégie DE produit ne peut pas être transférée d’un serveur ePO à un autre car la stratégie contient ePO Clé publique pour ce serveur ePO spécifique. Le transfert de la stratégie entraîne le chiffrement de la clé d’ordinateur et de la clé de récupération avec la mauvaise clé, ce qui supprime la possibilité d’effectuer une récupération côté client.
REMARQUE : Pour plus d’informations, voir la rubrique KB82120-admin récupération Challenge code Input renvoie un nom de nœud à partir d’un autre client.
- Le paramètre de stratégie utilisateur de la base de DE : utilisateurs la requête doit être renforcée pour tous les utilisateurs qui en ont besoin.
- Les affectations de groupe de sécurité et d’utilisateur effectuées au niveau d’un groupe pour les utilisateurs de chiffrement doivent être recréées.
- L’ordinateur client doit recevoir une stratégie active ou chiffrée lorsqu’il se connecte au nouveau serveur ou démarre le déchiffrement. Nous ne pas vous recommandons d’appliquer une stratégie active ou chiffrée à tous les systèmes de l’environnement afin d’empêcher l’activation accidentelle sur des systèmes involontaires, tels que des serveurs.
Une fois que le client a commencé à communiquer avec le nouveau serveur ePO, son
Machine ID dans la base de données ePO est modifié. Lorsque le système remarque la modification apportée à, le client charge sa clé de chiffrement sur le nouveau serveur ePO.
IMPORTANT : Aucune des valeurs de données suivantes n’est transférée de l’ePO d’origine vers le nouveau serveur ePO, ce qui entraîne la non-prise en charge de cette migration avec les versions actuelles d’ePO ou DE.
- Affectations d’utilisateurs
- Données de jeton
- Données d’authentification unique
Ajouter des utilisateurs du domaine local (ALDU) : permet d’affecter des utilisateurs de domaine
uniquement au nouveau
machine object dans ePO en une seule instance. Ce instance est que le système client ou le service DE déservice redémarre avant que le système n’envoie et ne termine une mise en œuvre de stratégie à partir du nouveau serveur ePO. ALDU exécute un ALDU complet uniquement après un redémarrage du service. Toutes les autres routines ALDU après le premier redémarrage du service post ALDU sont incrémentielles. Seuls les utilisateurs du domaine qui ne se sont jamais connectés au système avant l’ajout sont ajoutés. Tous les utilisateurs affectés directement au système sont supprimés.