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
Embûches

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.
Téléchargez cette ressource

Rapport Forrester sur les solutions de sécurité des charges de travail cloud (CWS)
Dans cette évaluation, basée sur 21 critères, Forrester Consulting étudie, analyse et note les fournisseurs de solutions de sécurité des charges de travail cloud (CWS). Ce rapport détaille le positionnement de chacun de ces fournisseurs pour aider les professionnels de la sécurité et de la gestion des risques (S&R) à adopter les solutions adaptées à leurs besoins.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
- Les PME attendent un meilleur accès aux données d’émissions de la part des fournisseurs
- Fraude & IA : Dr Jekyll vs. Mr Hyde, qui l’emporte ?
