Partager via

Nouveautés relatives à l’installation et à la suppression des services de domaine Active Directory

  • Article

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Le déploiement de services AD DS (Active Directory Domain Services) dans Windows Server 2012 est plus simple et plus rapide que dans les versions précédentes de Windows Server. Le processus d’installation des services AD DS repose à présent sur Windows PowerShell et est intégré au Gestionnaire de serveur. Le nombre d’étapes requises pour introduire des contrôleurs de domaine dans un environnement Active Directory existant est en baisse, ce qui rend le processus de création d’un environnement Active Directory plus simple et plus efficace. Le nouveau processus de déploiement des services AD DS réduit au minimum le risque d’erreurs susceptibles de bloquer l’installation.

Par ailleurs, vous pouvez installer les binaires du rôle serveur AD DS (c’est-à-dire le rôle serveur AD DS) sur plusieurs serveurs en même temps. Vous pouvez également exécuter l’Assistant Installation des services de domaine Active Directory à distance sur un serveur individuel. Ces améliorations offrent plus de souplesse au niveau du déploiement de contrôleurs de domaine exécutant Windows Server 2012, en particulier pour les opérations globales à grande échelle qui nécessitent le déploiement d’une multitude de contrôleurs de domaine vers des bureaux situés dans des régions différentes.

L’installation des services AD DS comprend les fonctionnalités suivantes :

  • Intégration d’Adprep.exe dans le processus d’installation AD DS. Certaines étapes jugées peu pratiques et qui étaient requises pour préparer un annuaire Active Directory existant, comme la nécessité d’utiliser une série d’informations d’identification différentes, la copie des fichiers Adprep.exe ou encore la connexion à des contrôleurs de domaine spécifiques, ont été simplifiées ou sont effectuées automatiquement. Il en résulte une réduction du temps nécessaire à l’installation des services AD DS et une réduction du risque d’erreurs susceptibles de bloquer la promotion du contrôleur de domaine.

    Concernant les environnements dans lesquels il est préférable d’exécuter des commandes adprep.exe préalablement à l’installation d’un nouveau contrôleur de domaine, vous pouvez toujours exécuter les commandes adprep.exe séparément de l’installation des services AD DS. La version Windows Server 2012 d’adprep.exe s’exécutant à distance, vous pouvez exécuter toutes les commandes nécessaires à partir d’un serveur qui exécute une version 64 bits de Windows Server 2008 (ou version ultérieure).

  • La nouvelle installation des services AD DS repose sur Windows PowerShell et peut être appelée à distance. De par l’intégration de la nouvelle installation des services AD DS au Gestionnaire de serveur, vous pouvez utiliser la même interface pour installer les services AD DS que celle que vous utilisez pour installer d’autres rôles serveurs. Pour les utilisateurs Windows PowerShell, les applets de commande de déploiement des services AD DS offrent plus de fonctionnalités et une flexibilité accrue. Une parité fonctionnelle existe entre les options d’installation de ligne de commande et celles de l’interface graphique utilisateur.

  • La nouvelle installation des services AD DS inclut la validation des conditions préalables. Les erreurs potentielles sont identifiées avant le début de l’installation. Vous pouvez corriger les conditions d’erreur avant qu’elles ne se produisent et éviter ainsi les problèmes résultant d’une mise à niveau partiellement terminée. Par exemple, si la commande adprep /domainprep doit être exécutée, l’Assistant Installation vérifie que l’utilisateur dispose des droits suffisants pour exécuter l’opération.

  • Les pages de configuration sont regroupées en une séquence qui reflète les exigences des options de promotion les plus courantes avec des options associées regroupées dans moins de pages de l’Assistant. Cela offre un meilleur contexte pour les choix d’installation.

  • Vous pouvez exporter un script Windows PowerShell qui contient toutes les options qui ont été spécifiées pendant l’installation graphique. À la fin d’une installation ou d’une suppression, vous pouvez exporter les paramètres vers un script Windows PowerShell pour automatiser la même opération.

  • Seule la réplication critique se produit avant le redémarrage. Nouveau commutateur permettant la réplication des données non critiques avant le redémarrage. Pour plus d’informations, voir Arguments de l’applet de commande ADDSDeployment.

Assistant Configuration des services de domaine Active Directory

À partir de Windows Server 2012, l’Assistant Configuration des services de domaine Active Directory remplace l’Assistant Installation Active Directory Domain Services hérité et sert d’option d’interface utilisateur pour spécifier les paramètres durant l’installation d’un contrôleur de domaine. L’Assistant Configuration des services de domaine Active Directory est lancé au terme de l’exécution de l’Assistant Ajout de rôles.

Avertissement

L’utilisation de l’Assistant Installation Active Directory Domain Services hérité (dcpromo.exe) est dépréciée à partir de Windows Server 2012.

Dans Installer les services Active Directory Domain Services (niveau 100), les procédures d’interface utilisateur vous montrent comment démarrer l’Assistant Ajout de rôles pour installer les binaires du rôle serveur AD DS, puis exécuter l’Assistant Configuration des services de domaine Active Directory pour terminer l’installation du contrôleur de domaine. Les exemples Windows PowerShell montrent comment effectuer les deux étapes à l’aide d’une applet de commande de déploiement AD DS.

Intégration d’Adprep.exe

À partir de Windows Server 2012, il n’existe qu’une seule version d’Adprep.exe (la version 32 bits, adprep32.exe, n’existe pas). Les commandes Adprep sont exécutées automatiquement selon les besoins quand vous installez un contrôleur de domaine exécutant Windows Server 2012 sur une forêt ou un domaine Active Directory existant.

Bien que les opérations adprep soient exécutées automatiquement, vous pouvez exécuter Adprep.exe séparément. Par exemple, si l’utilisateur qui installe les services AD DS n’est pas membre du groupe Administrateurs de l’entreprise (une condition requise à l’exécution d’Adprep /forestprep), vous devrez peut-être exécuter la commande séparément. Cependant, vous devez uniquement exécuter adprep.exe si vous prévoyez d’effectuer une mise à niveau sur place de votre premier contrôleur de domaine Windows Server 2012 (en d’autres termes, vous prévoyez d’effectuer une mise à niveau sur place du système d’exploitation d’un contrôleur de domaine exécutant Windows Server 2012).

Adprep.exe se trouve dans le dossier \support\adprep du disque d’installation de Windows Server 2012. La version Windows Server 2012 d’adprep peut s’exécuter à distance.

La version Windows Server 2012 d’adprep.exe peut s’exécuter sur n’importe quel serveur exécutant une version 64 bits de Windows Server 2008 (ou version ultérieure). Le serveur doit bénéficier d’une connectivité réseau au contrôleur de schéma pour la forêt et au maître d’infrastructure sur lequel vous voulez ajouter un contrôleur de domaine. Si l’un de ces rôles est hébergé sur un serveur Windows Server 2003, adprep doit être exécuté à distance. Le serveur sur lequel vous exécutez adprep ne doit pas forcément être un contrôleur de domaine. Il peut soit être joint à un domaine, soit se trouver dans un groupe de travail.

Remarque

Si vous essayez d’exécuter la version Windows Server 2012 d’adprep.exe sur un serveur exécutant Windows Server 2003, l’erreur suivante apparaît :

Adprep.exe n’est pas une application Win32 valide.

What's new

Pour plus d’informations sur la résolution d’autres erreurs retournées par Adprep.exe, voir Problèmes connus.

Vérification de l’appartenance aux groupes par rapport aux rôles de maître d’opérations Windows Server 2003

Pour chaque commande (/forestprep, /domainprep ou /rodcprep), Adprep vérifie l’appartenance aux groupes pour déterminer si les informations d’identification spécifiées représentent un compte dans certains groupes. Pour effectuer cette vérification, Adprep contacte le propriétaire du rôle de maître d’opérations. Si le maître d’opérations exécute Windows Server 2003 et que vous exécutez Adprep.exe, vous devez spécifier les paramètres de ligne de commande /user et /userdomain pour vous assurer que la vérification de l’appartenance aux groupes est effectuée dans tous les cas.

/user et /userdomain sont de nouveaux paramètres pour Adprep.exe dans Windows Server 2012. Ces paramètres spécifient respectivement le nom du compte et le domaine de l’utilisateur qui exécute la commande adprep. L’utilitaire de ligne de commande Adprep.exe vous empêche de ne spécifier qu’un seul des deux paramètres (/userdomain ou /user).

Toutefois, les opérations Adprep peuvent également être exécutées dans le cadre d’une installation des services AD DS à l’aide de Windows PowerShell ou du Gestionnaire de serveur. Ces expériences partagent la même implémentation sous-jacente (adprep.dll) qu’adprep.exe. L’entrée des informations d’identification, qui s’effectue séparément pour Windows PowerShell et le Gestionnaire de serveur, n’impose pas les mêmes conditions que celles requises par adprep.exe. Si vous utilisez Windows PowerShell ou le Gestionnaire de serveur, il est possible de passer une valeur pour /user mais pas /userdomain à adprep.dll. Si /user est spécifié et que /userdomain n’est pas spécifié, le domaine de l’ordinateur local est utilisé pour effectuer la vérification. Si l’ordinateur n’est pas joint à un domaine, l’appartenance aux groupes ne peut pas être vérifiée.

Lorsque l’appartenance aux groupes ne peut pas être vérifiée, Adprep affiche un message d’avertissement dans les fichiers journaux adprep et continue :

Adprep was unable to check the specified user's group membership. This could happen if the FSMO role owner <DNS host name of operations master> is running Windows Server 2003 or lower version of Windows.

Si vous exécutez Adprep.exe sans spécifier les paramètres /user et /userdomain et que le maître d’opérations exécute Windows Server 2003, Adprep.exe contacte un contrôleur de domaine dans le domaine de l’utilisateur actuellement connecté. Si l’utilisateur actuellement connecté n’est pas un compte de domaine, Adprep.exe ne peut pas effectuer la vérification de l’appartenance aux groupes. Il en va de même si des informations d’identification de carte à puce sont utilisées, et ce même si vous spécifiez /user et /userdomain.

Si l’exécution d’Adprep se termine correctement, aucune action n’est requise. En cas d’échec de l’exécution d’Adprep avec des erreurs d’accès, spécifiez un compte avec une appartenance correcte. Pour plus d’informations, voir Informations d’identification requises pour exécuter Adprep.exe et installer les services de domaine Active Directory.

Syntaxe pour Adprep dans Windows Server 2012

Utilisez la syntaxe suivante pour exécuter adprep séparément d’une installation des services AD DS :

Adprep.exe /forestprep /forest <forest name> /userdomain <user domain name> /user <user name> /password *

Utilisez /logdsid dans la commande afin de générer une journalisation plus détaillée. Le journal adprep.log se trouve à l’emplacement suivant : %windir%\System32\Debug\Adprep\Logs.

Exécution d’adprep à l’aide d’une carte à puce

La version Windows Server 2012 d’adprep.exe autorise l’utilisation d’une carte à puce en guise d’informations d’identification, mais aucune méthode ne permet de spécifier facilement les informations d’identification de carte à puce par le biais de la ligne de commande. Une façon d’y parvenir consiste à d’obtenir les informations d’identification de carte à puce par le biais de l’applet de commande PowerShell Get-Credential. Ensuite, il suffit d’utiliser le nom d’utilisateur de l’objet PSCredential retourné, celui-ci apparaissant sous la forme @@.... Le mot de passe est le code confidentiel de la carte à puce.

Adprep.exe requiert /userdomain si /user est spécifié. Pour les informations d’identification de carte à puce , /userdomain doit être le domaine du compte d’utilisateur sous-jacent représenté par la carte à puce.

La commande adprep /domainprep /gpprep n’est pas exécutée automatiquement

La commande adprep /domainprep /gpprep n’est pas exécutée dans le cadre de l’installation des services AD DS. Cette commande définit les autorisations requises pour le mode de planification du jeu de stratégie résultant (RSoP). Pour plus d’informations sur cette commande, voir l’article 324392 de la Base de connaissances Microsoft. Si la commande doit être exécutée dans votre domaine Active Directory, vous pouvez l’exécuter séparément de l’installation des services AD DS. Si la commande a déjà été exécutée en préparation du déploiement de contrôleurs de domaine exécutant Windows Server 2003 SP1 ou version ultérieure, il est inutile de réexécuter la commande.

Vous pouvez ajouter des contrôleurs de domaine exécutant Windows Server 2012 à un domaine existant de manière sûre, sans exécuter adprep /domainprep /gpprep, mais le mode de planification RSoP ne fonctionnera pas correctement.

Validation des conditions préalables à l’installation des services AD DS

L’Assistant Installation des services de domaine Active Directory vérifie que les conditions préalables suivantes sont remplies avant de démarrer l’installation. Cela vous donne la possibilité de corriger les problèmes susceptibles de bloquer l’installation.

Parmi les conditions préalables liées à Adprep, citons les suivantes :

  • Vérification des informations d’identification d’adprep : si l’exécution d’adprep s’avère nécessaire, l’Assistant Installation vérifie que l’utilisateur dispose de droits suffisants pour exécuter les opérations Adprep requises.
  • Vérification de la disponibilité du contrôleur de schéma : si l’Assistant Installation détermine que la commande adprep /forestprep doit être exécutée, il vérifie que le contrôleur de schéma est en ligne ; sinon, il échoue.
  • Vérification de la disponibilité du maître d’infrastructure : si l’Assistant Installation détermine que la commande adprep /domainprep doit être exécutée, il vérifie que le maître d’infrastructure est en ligne ; sinon, il échoue.

Voici d’autres vérifications des conditions préalables qui sont issues de l’Assistant Installation des services de domaine Active Directory hérité (dcpromo.exe) :

  • Vérification du nom de la forêt : vérifie que le nom de la forêt est valide et qu’il n’est pas déjà utilisé.
  • Vérification du nom NetBIOS : vérifie que le nom NetBIOS fourni est valide et qu’il n’est pas en conflit avec des noms existants.
  • Vérification des chemins d’accès des composants : vérifie que les chemins d’accès pour la base de données Active Directory, les journaux et SYSVOL sont valides et que l’espace disque nécessaire pour les prendre en charge est suffisant.
  • Vérification du nom du domaine enfant : vérifie que les noms du parent et du nouveau domaine enfant sont valides et qu’ils ne sont pas en conflit avec des domaines existants.
  • Vérification du nom du domaine de l’arborescence : vérifie que le nom de l’arborescence spécifié est valide et qu’il n’existe pas actuellement.

Configuration système requise

La configuration requise pour Windows Server 2012 est la même que celle requise pour Windows Server 2008 R2. Pour plus d’informations, consultez Configuration requise pour Windows Server 2008 R2 avec SP1 (https://www.microsoft.com/windowsserver2008/en/us/system-requirements.aspx).

Il est possible que des conditions supplémentaires soient associées à certaines fonctionnalités. Par exemple, la fonctionnalité de clonage du contrôleur de domaine virtuel exige que l’émulateur de contrôleur de domaine principal exécute Windows Server 2012 et nécessite un ordinateur exécutant Windows Server 2012 sur lequel le rôle Hyper-V est installé.

Problèmes connus

Cette section présente certains problèmes connus qui affectent l’installation des services AD DS sur Windows Server 2012. Pour découvrir d’autres problèmes connus, voir Résolution des problèmes de déploiement de contrôleur de domaine.

  • Si l’accès WMI au maître de schéma est bloqué par le Pare-feu Windows lorsque vous exécutez à distance adprep /forestprep, l’erreur suivante est enregistrée dans le journal adprep à l’emplacement %systemroot%\system32\debug\adprep :

    Adprep encountered a Win32 error.
Error code: 0x6ba Error message: The RPC server is unavailable.

    Dans ce cas, pour contourner cette erreur, vous pouvez soit exécuter adprep /forestprep directement sur le contrôleur de schéma, soit exécuter l’une des commandes suivantes pour autoriser le trafic de WMI à travers le Pare-feu Windows.

    Pour Windows Server 2008 ou version ultérieure :

    netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

    Pour Windows Server 2003 :

    netsh firewall set service RemoteAdmin enable

    Une fois adprep terminé, vous pouvez exécuter l’une des commandes suivantes pour bloquer de nouveau le trafic WMI :

    netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=no

    netsh firewall set service remoteadmin disable

  • Vous pouvez appuyer sur CTRL+C pour annuler l’applet de commande Install-ADDSForest. L’annulation arrête l’installation, et toutes les modifications apportées à l’état du serveur sont annulées. Toutefois, après l’émission de la commande d’annulation, le contrôle n’est pas retourné à Windows PowerShell et l’applet de commande peut se bloquer indéfiniment.

  • L’installation d’un contrôleur de domaine supplémentaire au moyen d’informations d’identification de carte à puce échoue si le serveur cible n’est pas joint au domaine avant l’installation.

    Le message d’erreur retourné dans ce cas est le suivant :

    Impossible de se connecter au contrôleur de domaine source de réplication nom du contrôleur de domaine source. (Exception : Échec de l’ouverture de session : nom d’utilisateur inconnu ou mot de passe incorrect)

    Si vous joignez le serveur cible au domaine, puis effectuez l’installation à l’aide d’une carte à puce, l’installation aboutit.

  • Le module ADDSDeployment ne s’exécute pas sous les processus 32 bits. Si vous automatisez le déploiement et la configuration de Windows Server 2012 à l’aide d’un script qui comprend une cmdlet ADDSDeployment et toute autre cmdlet qui ne prend pas en charge les processus 64 bits natifs, le script peut échouer avec une erreur indiquant que la cmdlet ADDSDeployment est introuvable.

    Dans ce cas, vous devez exécuter l’applet de commande ADDSDeployment séparément de l’applet de commande qui ne prend pas en charge les processus 64 bits natifs.

  • Windows Server 2012 comprend un nouveau système de fichiers nommé Resilient File System. Ne stockez pas la base de données Active Directory, les fichiers journaux ou SYSVOL sur un volume de données au format ReFS. Pour plus d’informations sur ReFS, consultez Génération du système de fichiers de prochaine génération pour Windows : ReFS.

  • Dans le Gestionnaire de serveur, l’état des serveurs qui exécutent les services AD DS ou d’autres rôles serveur sur une installation minimale et qui ont été mis à niveau vers Windows Server 2012 peut apparaître en rouge, même si les événements et l’état sont collectés comme prévu. Les serveurs qui exécutent une installation minimale d’une version préliminaire de Windows Server 2012 peuvent également être impactés.

L’installation des services de domaine Active Directory se bloque si une erreur empêche une réplication critique.

Si l’installation des services AD DS se heurte à une erreur lors de la phase de réplication critique, l’installation peut se bloquer indéfiniment. Par exemple, si des erreurs réseau empêchent l’achèvement de la réplication critique, l’installation ne continue pas.

Si vous effectuez l’installation à l’aide du Gestionnaire de serveur, il est possible que la page de progression de l’installation reste ouverte sans qu’aucune erreur ne soit signalée à l’écran et que la progression reste inchangée pendant environ 15 minutes. Si vous utilisez Windows PowerShell, la progression affichée dans la fenêtre Windows PowerShell n’évolue pas pendant plus de 15 minutes.

Si vous rencontrez ce problème, examinez le fichier dcpromo.log dans le dossier %systemroot%\debug sur le serveur cible. Le fichier journal indique généralement des échecs répétés à répliquer. Parmi les causes connues de ce problème, citons les suivantes :

  • Des problèmes réseau empêchent la réplication critique entre le serveur cible qui est promu et le contrôleur de domaine source de réplication.

    Par exemple, le journal dcpromo.log affiche ce qui suit :

    05/02/2012 14:16:46 [INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1963
Internal event: The following local directory service received an exception from a remote procedure call (RPC) connection. Extensive RPC information was requested. This is intermediate information and might not contain a possible cause.
Process ID:
500
Reported error information:
Error value:
Could not find the domain controller for this domain. (1908)
directory service:
<domain>.com
Extensive error information:
Error value:
A security package specific error occurred. 1825
directory service:
<DC Name>

    Étant donné que le processus d’installation retente la réplication critique indéfiniment, l’installation du contrôleur de domaine se poursuit si les problèmes réseau sous-jacents sont résolus. Étudiez le problème réseau à l’aide d’outils tels qu’ipconfig, nslookup et netmon, si nécessaire. Vérifiez l’existence d’une connectivité entre le contrôleur de domaine que vous promouvez et le partenaire de réplication sélectionné pendant l’installation des services AD DS. Vérifiez également que la résolution de noms fonctionne.

    La configuration requise pour l’installation des services AD DS pour la connectivité réseau et la résolution de noms est validée pendant la vérification de la configuration requise, avant le début de l’installation. Certaines conditions d’erreur peuvent néanmoins se produire entre le moment de la validation préalable et la fin de l’installation, par exemple si le partenaire de réplication devient indisponible pendant l’installation.

  • Au cours de l’installation du contrôleur de domaine réplica, le compte d’administrateur local du serveur cible est spécifié pour les informations d’identification d’installation et le mot de passe du compte d’administrateur local correspond au mot de passe d’un compte d’administrateur de domaine. Dans ce cas, vous pouvez suivre l’Assistant Installation et commencer l’installation avant que l’échec « Accès refusé » ne se produise.

    Par exemple, le journal dcpromo.log affiche ce qui suit :

    03/30/2012 11:36:51 [INFO] Creating the NTDS Settings object for this Active Directory Domain Controller on the remote AD DC DC2.contoso.com...
03/30/2012 11:36:51 [INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1963Internal event: The following local directory service received an exception from a remote procedure call (RPC) connection. Extensive RPC information was requested. This is intermediate information and might not contain a possible cause.
Process ID:
508
Reported error information:
Error value:
Access is denied. (5)
directory service:
DC2.contoso.com

    Si l’erreur est causée par la spécification d’un compte et d’un mot de passe d’administrateur local, vous devez, pour corriger le problème, réinstaller le système d’exploitation, effectuer un nettoyage des métadonnées du compte pour le contrôleur de domaine qui n’a pas réussi à effectuer l’installation, puis réessayer l’installation des services de domaine Active Directory à l’aide d’informations d’identification de l’administrateur de domaine. Le redémarrage du serveur ne corrige pas cette condition d’erreur, car le serveur indique que les services AD DS est installé même si l’installation ne s’est pas terminée correctement.

L’Assistant Configuration des services de domaine Active Directory vous avertit si un nom DNS non normalisé est spécifié.

Si vous créez un domaine ou une forêt et que vous spécifiez un nom de domaine DNS contenant des caractères internationaux qui ne sont pas normalisés, l’Assistant Configuration des services de domaine Active Directory affiche alors un avertissement indiquant l’échec possible des requêtes DNS pour le nom. Bien que le nom de domaine DNS soit spécifié dans la page Configuration de déploiement, l’avertissement apparaît dans la page Vérification de la configuration requise plus loin dans l’Assistant.

Si un nom de domaine DNS est spécifié avec un nom non normalisé comme füßball.com ou 'ΣΤ'.com (les versions normalisées sont : füssball.com et βστα.com), les applications clientes qui tentent d’y accéder avec WinHTTP normalisent le nom avant d’appeler les API de résolution de nom. Si l’utilisateur tape « 'ΣΤ'.com » dans une boîte de dialogue, la requête DNS est envoyée sous la forme « βστα.com » et aucun serveur DNS ne la met en correspondance avec un enregistrement de ressource pour « 'ΣΤ'.com ». L’utilisateur ne sera pas en mesure de résoudre le nom.

L’exemple suivant explique l’un des problèmes pouvant se produire lors de l’utilisation d’un nom IDN qui n’est pas normalisé :

  1. Le domaine qui utilise un nom non normalisé est créé et inscrit sur le serveur DNS : füßball.com
  2. La machine « nps » est jointe au domaine et son nom est inscrit : nps.füßball.com
  3. Une application cliente tente de se connecter au serveur nps.füßball.com
  4. L’application cliente tente de résoudre le nom nps.füßball.com en appelant des API de résolution de nom.
  5. En raison de la normalisation, le nom est converti pour devenir nps.füssball.com et est recherché sur le réseau en tant que nps.füßball.com
  6. L’application cliente ne peut pas résoudre le nom, car le nom inscrit est nps.füßball.com

Si l’avertissement apparaît dans la page Vérification de la configuration requise de l’Assistant Configuration des services de domaine Active Directory, retournez à la page Configuration de déploiement et spécifiez un nom de domaine DNS normalisé. Si vous installez un nouveau domaine à l’aide de Windows PowerShell, spécifiez un nom DNS normalisé pour l’option -DomainName.

Pour plus d’informations sur les noms IDN, voir Traitement des noms de domaines internationaux.