Rubrique précédente: Relation avec l'opération de déplacementRubrique suivante: Message d'administration personnalisé


Restrictions de l'opération RAC

Seuls les ordinateurs cibles dotés du mécanisme UUID sont soumis à une réinstallation après un arrêt brutal (RAC), ce qui signifie que tous les environnements d'exploitation Windows 32 et 64 bits et toutes les plates-formes Linux/UNIX sont couvertes. Toutefois, l'unité d'ancrage est exclue de l'opération RAC, puisqu'elle communique l'UUID de l'ordinateur hôte.

L'opération RAC sur les ordinateurs cibles configurés à l'aide du téléchargement DTS a recours au téléchargement interne non-NOS. Ceci est dû principalement au fait que les packages envoyés sont transférés vers l'ordinateur cible, dont le disque sera écrasé lors de la réinstallation du système d'exploitation. D'autre part, DTS n'est pas intégré à l'agent Software Delivery, mais envoyé en tant que job.

L'opération RAC sur les serveurs de modularité (y compris leur bibliothèque) est possible uniquement si le serveur est installé en premier lieu. En d'autres termes, il n'est pas possible de restaurer le serveur de modularité à partir d'une installation d'agent. Les enregistrements de distribution sont alors marqués comme étant supprimés. Seule la partie de la bibliothèque connue du gestionnaire de domaines est restaurée.

Aucune synchronisation n'est disponible entre l'opération RAC pour les cibles ordinateur et l'opération RAC pour les cibles de profils d'utilisateur. Par exemple, si un job de profil utilisateur dépend d'un job d'ordinateur, il n'existe aucun mécanisme, excepté l'utilisation des conditions préalables des procédures.

L'ordre de l'historique des jobs est conservé, à une exception près. Pour les serveurs de modularité, les jobs de livraison sont configurées en premier lieu, suivis de tous les autres jobs. Toutefois, l'ordre des distributions, de même que l'ordre des autres types de jobs, est conservé.