Embûches

Comme n’importe quelle procédure relativement complexe, le changement de nom de domaine comporte certaines embûches à prendre en compte dans votre planification. Heureusement, hormis les redémarrages nécessaires pendant le processus (et la perte consécutive de connectivité aux systèmes lors du redémarrage), ces embûches ne devraient pas

affecter les clients, mais il existe quelques problèmes connus pour les serveurs. Les stations de travail et serveurs Windows NT constituent une exception car vous devez les retirer du domaine d’origine et les rattacher au domaine renommé.

La documentation Microsoft explique comment renommer des contrôleurs avec les domaines proprement dits.Cette opération prend tout son sens si les contrôleurs incluent le domaine dans leur nom (la gestion sera peut-être facilitée si les noms de contrôleur reflètent le changement de nom). Néanmoins, le fait de renommer des contrôleurs de domaine affecte le service de mise à jour de destinataire (RUS) car il doit les contacter pour récupérer des informations sur les objets activés pour la messagerie nouveaux ou mis à jour, notamment les comptes. Si vous renommez les contrôleurs de domaine, assurez-vous que le service RUS pointe ensuite vers un contrôleur valide ou il deviendra impossible d’activer les objets pour la messagerie en les mettant à jour avec les adresses de messagerie proxy. Si vous avez mis en place DSAccess (comme décrit dans l’article Microsoft « Directory service server detection and DSAccess usage », à l’adresse http://support.microsoft.com/?kbid=250570

afin que les serveurs Exchange utilisent des contrôleurs de domaine spécifiques (définis via l’onglet Directory Access dans la boîte de dialogue des propriétés du serveur, comme l’illustre la figure 1), vous devez vérifier que ces contrôleurs de domaine sont encore valides après le changement de nom. Si les problèmes persistent et si DSAccess retourne l’erreur 2075 dans le journal des événements sur un serveur Exchange qui essaie de trouver une liste de contrôleurs de domaine et de serveurs de catalogue global, il sera peut-être nécessaire de vider le cache sur ce serveur, comme indiqué dans l’article « Event ID 2075 Occurs When You Try to Obtain a List of the Global Catalog Servers »

(http://support.microsoft.com/?kbid =312425). Les changements de noms de contrôleurs de domaine et le bouleversement résultant au niveau de DNS peuvent aussi interrompre le traitement SMTP. Par conséquent, consultez les files d’attente de messages afin de vérifier si, après un changement de nom, les messages s’accumulent pour un domaine spécifique. S’il y a plus de 50 messages dans une file d’attente, arrêtez et redémarrez le service SMTP afin de forcer les serveurs virtuels SMTP à vider leur cache et à détecter les nouvelles informations mises en cache par Exchange sur les contrôleurs de domaine.

Enfin, l’article Microsoft « Supplemental steps for using the Exchange Server Domain Rename Fixup tool together with the Windows Server 2003 domain rename tools » (http://support.microsoft.com/?kbid=842116) décrit un changement de la valeur ValidPorts au niveau de la sous-clé de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy. Cette modification peut être nécessaire pour les serveurs proxy RPC sur HTTP si vous renommez un des serveurs spécifiés dans le Registre. En fait, comme celuici peut contenir des noms de serveur codés en dur, il est judicieux d’y rechercher les serveurs Exchange, afin de vérifier si des modifications sont nécessaires. Par exemple, les administrateurs peuvent avoir entré un nom de contrôleur de domaine pour l’interface NSPI (Name Service Provider Interface) à employer sur un cluster (comme décrit dans l’article Microsoft « DSProxy configuration for static ports on Exchange cluster », à l’adresse http://support.microsoft.com/?kbid=282446) et, si ce nom change, il faudra naturellement ajuster la valeur sur le cluster.