Voici un article de Christophe Guerre, PFE Active Directory, Azure et AD dans Azure.

Cet article a pour but de regrouper les principales recommandations sur la virtualisation d’un contrôleur de domaine afin d’en tirer les meilleures performances, plutôt orienté Hyper-v mais certaines recommandations sont aussi valables pour d’autres hyperviseurs.

Ce post est dédié à la virtualisation d’un DC dans un cloud On Premise, un deuxième post sera dédié aux spécifications de virtualisation d’un DC dans un cloud public

Commençons par les basiques de la virtualisation d’un contrôleur de domaine

https://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(v=ws.10).aspx#operational_considerations_for_virtualized_domain_controllers

• Ne pas utiliser la fonction pause ou save
• Ne pas faire un Power Off sauf si contraint (comme une machine physique) et ce même si l’hôte doit être éteint.
  • Vous devez configurer la VM pour qu’elle ne soit pas mise en pause par l’hôte lors de l’arrêt mais éteinte « Shutdown the guest operating system”
• Ne pas restaurer de Checkpoints (Snapshots) de la machine virtuelle (surtout pour des contrôleurs de domaine inférieur à Windows Server 2012)Ne pas effectuer de conversion P2V (Physical to Virtual) alors que le DC est démarré. Cela pour les mêmes conséquences que la restauration d’un Checkpoint, le plus courant : l’USN roll back ! et ne pas remettre le DC Physique sur le réseau de production.
  • La notion de Checkpoint pour un DC est prise en charge à partir de Windows Server 2012 via l’option VM GenerationID(suivant la version de l’hyperviseur). Malgré cela, il n’est pas recommandé d’utiliser les Checkpoints comme une méthode de sauvegarde, elle prémunie d’une mauvaise utilisation de ces derniers.
  • Les versions d’hyperviseurs suivantes permettent d’exposer le VM GenerationID
    • A partir de Windows Server 2012 https://technet.microsoft.com/en-us/library/hh831734.aspx
    • A partir de VMware vSphere 5.0 Update 2 (vCenter Server and ESXi must both be at 5.0 Update 2)
    • A partir de VMware vSphere 5.1 (ESXi must be at least 5.0 Update http://blogs.vmware.com/apps/2013/01/windows-server-2012-vm-generation-id-support-in-vsphere.html
• Ne pas effectuer de clone d’un disque dur virtuel d’un contrôleur de domaine quelque soit la version de l’OS. Depuis Windows Server 2012, vous pouvez cloner un contrôleur de domaine mais ce dernier doit être préparé pour que cela soit supporté et fonctionnel.
• Ne pas exporter la VM
• Ne pas synchroniser le service de temps de la VM avec l’hôte. Arrêter la VM et décocher Time synchronization dans le menu Integration Services.
• Lors de la création de la VM, choisir la version de l’OS (ex : Windows Server 2012 R2). Cela peut influer sur le choix des tools et des optimisations.

Maintenant intéressons-nous à la configuration matérielle de la VM

https://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(v=ws.10).aspx#deployment_considerations_for_virtualized_domain_controllers

• 2 vCPU au minimum, afin de garantir une performance optimale de l’Active Directory pendant que le système traite les autres tâches.
• 4Go de mémoire au minimum pour la mémoire de démarrage. L’utilisation de la mémoire dynamique est supportée. Ma recommandation sur ce sujet est de mettre la mémoire minimum égale à la mémoire nécessaire pour mettre la base de l’AD en cache afin d'éviter au maximum les entrées sorties disque et ainsi réduire de manière significative les temps de réponse aux requêtes. On peut prendre comme base 3 Go + taille de la base Active Directory à affiner en fonction de l’utilisation du DC.
• Ne pas mettre de lecteur de DVD. Cela permet d’empêcher l’utilisation d’une ISO, de l’autoplay ou de démarrer dessus. On pourra à la demande en installer un sans redémarrage si celui-ci est en SCSI.
• Préférer le format vhdx pour les disques virtuels.
• Séparer le disque système du disque contenant l’Active Directory. Le cache en écriture est désactivé sur le disque contenant les fichiers de l’Active Directory. Dans cette configuration, on peut différencier la configuration du disque système, du disque hébergeant l’AD. 60 Go au minimum pour le disque Système.  Pour le disque hébergeant l’AD cela dépend de la taille de votre base et des logs.
• Afin de garantir la performance et de durabilité (c’est-à-dire éviter la corruption) des fichiers de données relatif à l’Active Directory (ntds.dit, logs et sysvol), vous devez les placer sur un disque virtuel attaché à un contrôleur SCSI. Le contrôleur SCSI permet d’utiliser FUA (Forced Unit Access) permettant à l’OS de bypasser tous mécanismes de cache et ainsi lire et écrire directement depuis le disque.
  • Pour les DCs existants ayant les fichiers de l’Active Directory sur un disque IDE, assurez-vous d’avoir désactivé le cache sur ce disque.
  • Pour Windows Server 2012, appliquer le hotfix KB2855336 pour résoudre le problème.

• Utiliser de préférence des VM de Génération 2, proposant par défaut un contrôleur disque SCSI et l’UEFI (Secure Boot) ainsi que des disques au format vhdx
• L’utilisation de disque en Pass-through est l’utilisation préférée mais pas forcément la plus optimale dans un environnement à forte densité (nécessite la présence d’un disque physique ou d’une LUN).
• Utiliser de préférence des disques ayant la totalité de la taille allouée (Thick Disk)
• Ne pas utiliser de disque différentiel

Recommandations sur les règles de placement

• Afin de garantir le maximum de disponibilité pour l’authentification du domaine/Foret, il est nécessaire de mettre les DCs dans des domaines d’upgrades différents. C’est-à-dire que les DCs doivent être sur des hôtes différents (un cluster de préférence), sur des Racks différents, sur des périodes de mise à jour différentes. Pour ce faire, on utilisera la fonctionnalité d’anti-affinité des clusters.
• Noter qu’il est fortement recommandé de conserver au moins un contrôleur de domaine physique par domaine afin de garantir une authentification même si l’infrastructure virtuelle est en panne. Noter que depuis 2012 il est possible de démarrer un cluster Hyper-V sans que l’Active Directory soit disponible : http://blogs.technet.com/b/wincat/archive/2012/08/29/windows-server-2012-failover-cluster-enhanced-integration-with-active-directory-ad.aspx
• De manière générale, la VM ne doit pas être placée sur un hôte ayant un système disque fortement utilisé ou ayant des ressources faibles. Vous pouvez utiliser un ressource pool/ Cloud spécifique ou augmenter les métriques de la VM (CPU, Memory Priority), utiliser la QoS pour le réseau ou le System Disk.
• Je vous recommande de minimiser le déplacement des disques à chaud (Storage Migration) des DCs et de ne pas le faire pour ceux en version inférieure à Windows Server 2012.

Recommandations sur la sauvegarde

• La sauvegarde d’un DC virtuel ne diffère pas de la sauvegarde d’un DC physique. Il est recommandé de faire une sauvegarde Bare Metal Recovery (BMR, option -allcritical) et non une sauvegarde de l’enveloppe. On préférera une sauvegarde BMR plutôt qu’une sauvegarde System State. Une sauvegarde BMR permettra de restaurer le DC sans devoir réinstaller un OS. Quelque soit la méthode choisie, la génération (ou version) de la VM d’origine doit être respectée ainsi que le nombre de CPU, la taille de la mémoire et la taille des disques.
• La recommandation actuelle est une sauvegarde d’au moins 2 DCs par domaine (dont 1 virtuel pour une non dépendance au matériel) ou plus précisément 2 DCs par partitions (attention aux partitions applicatives crées).
• Pour ma part, je mets généralement en place une sauvegarde BMR avec Windows Server Backup sur un disque local dédié (Pour bénéficier de l’historique des sauvegardes) puis sauvegarder ce dernier par avec un outil tiers permettant l’externalisation.
• Souvent assimilé comme une solution de sauvegarde, la fonctionnalité Hyper-V Replica est supporté pour des DCs virtuels à partir de Windows Server 2012, néanmoins seuls certains scénarios de restauration sont possibles.

Recommandations sur la sécurité

• Ce point est souvent négligé ou tout simplement non abordé, pourtant la virtualisation d’un DC introduit un nouvel axe de piratage. Il est très facile pour un administrateur du système de stockage ou de l’infrastructure virtuelle de copier ou manipuler le disque virtuel contenant l’AD et ainsi faire une attaque offline ou d’introduire un cheval de Troie.
• Le DC virtuel doit être considérer comme un DC physique, l’hôte (l’hyperviseur) doit être considéré comme un DC physique. Ce qui implique des considérations particulières pour les Administrateurs gérant l’hôte ou le système de disque. Ils doivent être considérés comme des administrateurs du domaine ou de la forêt. Il en va de même pour les administrateurs du stockage qui ont accès aux disques, voir aux sauvegardes.
• Pour maximiser la sécurité des DC virtuels, nous avons principalement 3 possibilités :

• • La mise en place de Bitlocker sur les disques physiques de l’hôte contenant ceux de la VM.

Noter que Bitlocker le disque virtuel système n’est pas supporté. Il est possible de Bitlocker le disque virtuel de data hébergeant l’Active Directory mais vous aurez un problème lors du reboot du DC. La partition sera verrouillée donc le service Active Directory ne pourra pas démarrer et aucun moyen de l’automatiser.

• • Dédier les hôtes et le stockage aux DCs virtuels
  • Configurer les DCs Virtuels en RODC si nécessaire. (Il n'y a pas de raison que ce soit systématique).
• La recommandation la plus simple, est de mettre à jour régulièrement l’OS en utilisant Windows Update ou un serveur WSUS.
• L’utilisation de serveur en mode Core peut aussi être une bonne pratique. Ils exposent moins de surface d’attaque, sont moins sujets aux mises jour et sont plus rapides au démarrage (surtout dans une VM de génération 2). Néanmoins, l’utilisation du mode Core nécessite une certaine expérience de PowerShell et de l’invite de commandes. Pour concilier les 2 modes on pourra choisir l’installation minimale.
• Une bonne pratique, qui n’est pas propre aux DCs Virtuels, est de renforcer leurs sécurité en s’inspirant des recommandations de l’outil Security Compliance Manager, en désactivant le stockage des mots de passe ou l’autoplay et le document Best Practices for Securing Active Directory
• Sécuriser l’accès aux carte ILO de l’hyperviseur
• Sécuriser l’hyperviseur (hardening). Pour Hyper-V le guide est disponible ici.
• Et tout simplement restreindre et surveiller l’accès à la machine physique ainsi qu’aux disques.

Recommandations sur la surveillance des DCs Virtuels

En tout point identique aux DCs physiques, on surveille les principaux métriques (la liste suivante n’est pas exhaustive, il est conseillé d’utiliser un outil de monitoring actif) :

Processor Utilization

• Processor : %Processor Time : _Total
• Process : %Processor Time : LSASS
• System\Processor queue length

Memory Utilization

• Memory : Available Megabytes
• Memory : Committed Bytes
• Memory : Pool Paged Bytes
• Memory : Pool NonPaged Bytes
• Memory : Pages/Sec

Page File : %Usage Total

Process : Virtual Bytes

Database :

• Database cache Size (MB) (for lsass)
• Database cache hit % (for lsass)
• I/O Database Reads/Sec
• I/O Database Writes/Sec

Security System-Wide Statistics :

• Kerberos authentication
• NTLM authentication

Directory Services :

• LDAP Searches/Sec
• AB Client Sessions
• LDAP Bind Time
• DRA Pending Replication Operation

Disk Utilization

• LogicalDisk : Free Megabytes : (All Instances except _Total)
• LogicalDisk : Disk Sec/read : (All Instances except _Total) – Primarily used for trending or troubleshooting, no defined thresholds.
• LogicalDisk : Disk Sec/write : (All Instances except _Total) – Primarily used for trending or troubleshooting, no defined thresholds.
• LogicalDisk : Avg. Disk Sec/Reads : (All Instances except _Total)
• LogicalDisk : Avg. Disk Sec/Write : (All Instances except _Total)

Network Utilization

• Network Interface : Output Queue Length : (Appropriate Instances)
• Network Interface : Outbound Discarded : (Appropriate Instances)
• Network Interface : Outbound Errors : (Appropriate Instances)
• Network Interface : Packets Received Discarded : (Appropriate Instances)
• Network Interface : Packets Received Errors : (Appropriate Instances)
• Network Interface : Packets Received Unknown : (Appropriate Instances)

Redirector : Errors/Sec

• Server Service
• Server : Errors System
• Server : File Directory Searches
• Server : Files Open
• Server : Sessions
• Server : Sessions Errored Out
• Server Work Items : Available Work Items : (All Instances)

Référence : Monitoring Performance in Active Directory

A noter qu’il est préférable de prendre en compte les compteurs spécifiques de chaque hyperviseur (des compteurs dédiés existent pour VMWare au niveau de l’OS Guest) et plus généralement les compteurs propres à l’hôte.

Pour vous aider dans la surveillance de ces compteurs vous pouvez utiliser System Center Operation Manager, des outils tiers mais aussi Microsoft Operations Management Suite hébergé dans Azure.

Vous devez aussi surveiller votre hyperviseur afin qu’il garantisse les ressources nécessaires aux DCs. Vous pouvez vous inspirer du document de Tuning de Windows Server 2012 R2 et un futur article présentera les compteurs les plus importants à surveiller.

A suivre ...

Pour conclure, la virtualisation des DC est maintenant une alternative fiable et maîtrisée aux DC physiques coûteux et moins flexibles.

Même s’il y a des précautions à prendre et des limitations, cela ne nous prive pas de la mobilité de la VM, de la facilité de sauvegarde ou de la faculté de modifier la capacité des VMs.

Il ne vous reste plus qu’à vous lancer !

A bientôt :)

Christophe

Bonjour à tous

Aujourd’hui nous allons étudier le fonctionnement des communications réseau au sein d’un cluster, ce qui devrait vous permettre de trouver plus facilement la meilleure configuration réseau pour vos clusters en fonction de vos contraintes d’infrastructure.

Failover Cluster Virtual Adapter (Netft)

Netft est un adaptateur réseau virtuel qui établit des connexions TCP sur toutes les interfaces réseau du cluster. Il apparaît via ipconfig /all, avec une adresse APIPA

NetFT permet au cluster d'utiliser tous les "cluster networks" disponibles pour ses communications

• Priorités sur les routes, et routage entre différents sous réseaux
• Bascule sur un autre chemin réseau en cas de perte d'un chemin
• Compatible avec le teaming de cartes

Si les communications clusters ne sont plus possibles sur un réseau, NetFT bascule sur un autre réseau (en utilisant les priorités en place).
NetFT reçoit une adresse MAC créée automatiquement, avec détection et résolution de conflits automatique depuis Windows Server 2012. Aucune configuration manuelle n'est nécessaire.

Les communications cluster passent par le port 3343 :

• ClusSvc communique avec NetFT (via IP et NDIS) sur le port TCP 3343
• NetFT communique avec le réseau externe (via IP, NDIS et NIC) sur le port UDP 3343

NetFT utilise les optimisations réseau telles que RSS (réduction de la charge CPU pour le traffic entrant) et SMB multi-channel (utilisation de plusieurs réseaux en parallèle pour transporter un même flux) depuis Windows Server 2012. Il supporte IPv4 et IPv6, mais IPv6 est utilisé en premier si disponible, c’est pourquoi, si IPv6 est activé sur les serveurs, il ne faut surtout pas qu’un firewall bloque les trames IPv6.
Le cluster crée un maillage de toutes les interfaces réseaux de tous les hôtes (il n'y a plus de réseau dédié au "heartbeat").
Le fonctionnement de ce maillage est configurable via la commande PowerShell :
(get-cluster).PlumbAllCrossSubnetRoutes = X

Interactions avec Network Topology Manager

Network topology manager établi pour Netft les routes à prendre en compte
Netft indique à NTM les changements d'états des routes (déconnexions)
NTM indique à Netft la nouvelle route à utiliser
NTM indique sur quelles routes les ressources IP du cluster sont mises en ligne

Netft Virtual Adapter Performance filter

Le NetFT Virtual Adapter Performance Filter est ajouté aux cartes réseaux physiques des nœuds de cluster.
Il améliore les performances réseau du cluster en contournant la pile UDP / IP pour délivrer le trafic du port 3343 de la carte réseau directement à Netft, ceci incluant les redirections CSV.
Il doit être désactivé en cas de cluster de VMs, sinon les heartbeats des nœuds virtualisés seront perdus.

Configuration des « heartbeats »

Chaque hôte envoi un “heartbeat” à chacun des autres hôtes pour détecter ceux indisponibles. Quand un serveur ne répond plus, les opérations de récupération du cluster sont lancées (par exemple la bascule des ressources hébergées par cet hôte).
Les requêtes se font en unicast et en mode requête - réponse pour la fiabilité et la sécurité : ce ne sont pas de simples pings.
Une interface est considérée déconnectée quand le nombre de heartbeats perdus dépasse le seuil configuré.
Le nœud est considéré hors ligne par le cluster quand toutes ses interfaces sont considérées comme déconnectées.

Les paramètres sont les suivants :

La configuration se fait par Powershell, par exemple :
(get-cluster).SameSubnetDelay = 2 enverra un heartbeat toutes les 2 secondes au lieu de toutes les secondes.

Pour compenser une mauvaise qualité de réseau, il est recommandé d’augmenter le seuil et non le délai.
Exemple : Pour avoir une durée de 10 secondes, conserver le délais à 1s et monter le seuil à 10 au lieu de laisser le seuil à 5 et monter le délais à 2 secondes.
Ces valeurs ne sont modifiables qu’une fois le cluster créé.
Si les latences réseaux perturbent la création du cluster, il est possible de modifier une clé de registre pour rendre les tests exécutés à la création du cluster plus tolérants :

• La modification est à faire sur chaque noeud
• Dans la clé HKLM\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters
• Créer une valeur DWORD « SetHeartbeatThresholdOnClusterCreate »
• La configurer à 10 permet de perdre 10 heartbeats avant de considérer le nœud injoignable
• Cette valeur est prise en charge dans Windows Server 2012 et 2012 R2

Augmenter le délai avant de considérer un réseau comme déconnecté permet de compenser un réseau à forte latence mais ne résout pas le problème : cela ne fait que le masquer.

3 Types de communications Cluster

On peut identifier 3 types de communications intra-cluster différentes

Heartbeats

Usage :

• Monitore l'état des interfaces réseau
• Envoyés sur tous les réseaux clusters autorisés

Pré requis :

• Bande passante très faible (134bytes / nœud / secondes)
• Sensible à la latence (si les heartbeats passent par une carte saturée, ils peuvent être perdus, et le nœud éjecté du cluster)

Il est inutile d’allouer de la bande passante à ces communications, mais la QOS doit protéger ces trames.

Synchronisation Intra-cluster

Usage :

• Mises à jour de la database cluster, synchronisation de la configuration
• Utilise une seule carte réseau à un instant t

Pré requis :

• Le trafic dépend de l'usage du cluster : faible sur un cluster de fichiers ou Hyper-V, plus important sur un cluster SQL ou exchange
• Sensible à la latence : la latence va ralentir les changements d'état du cluster, par exemple les bascules

Il est inutile d’allouer beaucoup de bande passante à ces communications, mais la QOS doit protéger ces trames.

CSV I/Os

Usage :

• Synchronisation d’I/Os (Mises à jour de metadatas)
• Ensemble des I/O en mode redirigé
• Même réseau que les communications intra cluster
• Le SMB multi-channel peut équilibrer la charge sur plusieurs cartes

Pré requis :

Il y a 2 cas à prendre en compte :

Synchronisation d’I/Os :

• Léger et rare
• La latence va diminuer les performances I/O
• La QOS est le plus important

Redirection d’I/Os :

• Toutes les I/O sont forwardées via le réseau au nœud coordinateur
• Une bande passante importante est nécessaire pour limiter l'impact sur les performances

Utilisation de la QOS pour gérer la priorité et la bande passante des réseaux

Windows Server 2012 R2 intègre un profil QOS pour les communications cluster.
Pour donner une haute priorité et affecter au minimum 30% de la bande passante à ces communications (surtout utile pour les redirections d’I/O CSV), on utilisera la commande PowerShell suivantes :

• New-NetQosPolicy “Cluster Policy” -Cluster –Priority 6 –MinBandwidthWeightAction 30

Windows Server 2012 n’intègre pas le profil « -cluster », on va donc simplement appliquer la policy QOS au trafic utilisant le port 3343 :

• New-NetQosPolicy “Cluster Policy” -IPDstPort 3343 –Priority 6 –MinBandwidthWeightAction 30

On pourra compléter ces règles de QOS avec celles pour le SMB (utilisé par le CSV) et les live migrations avec les paramètres suivant par exemple:

• New-NetQosPolicy “Live Migration Policy” –LiveMigration –Priority 5 –MinBandwidthWeightAction 20
• New-NetQosPolicy “SMB Policy” -SMB –Priority 3 –MinBandwidthWeightAction 50

L’exemple ci-dessous convient spécialement si vous avez l’intention de dédier un teaming de 2x1Gb ou 2x10Gb pour l’administration du cluster.

Un autre article présentera plus de configurations possibles.

Gestion des rôles des Cluster Network

Un Cluster network peut avoir une de ces 3 configurations :

Par défaut, une configuration automatique est proposée selon les règles ci-dessous :

• Si le réseau est utilisé par un Initiateur iSCSI, il sera désactivé
• Si un réseau n’a pas de passerelle par défaut, il sera considéré comme un réseau privé
• Si un réseau a une passerelle par défaut, il sera considéré comme un réseau public

La configuration peut se faire graphiquement :

Ou par Powershell via la commande (Get-ClusterNetwork « Cluster Network 1 »).role = X

Gestion de la priorité entre les différents réseaux

Lors de la configuration automatique des réseaux du cluster, une métrique est affectée à chaque réseau utilisable (ce qui exclut donc les réseaux dont le rôle est à 0).
Les réseaux Privés ont une métrique partant de 40000 et pouvant descendre jusqu’à 0, les réseaux Publics ont une métrique partant de 80000 et descendant jusqu’à 40001.
Plus la métrique est basse et plus le réseau sera prioritaire, le cluster utilisera donc en premier ses réseaux privés pour ses communications et pour la redirection CSV.

La règle de calcul est la suivant :
(40000 si Rôle 1 ou 80000 si Rôle 3) – (19200 si compatible RDMA) – (9600 si compatible RSS [les bonus RSS et RDMA ne sont pas cumulatifs]) – ((16 (utilisé pour constituer les groups de load balancing NetFT) * (10 si réseau 10Gb/s, 1 si réseau 1Gb/s, 0 si bande passante < 1Gb/s) = Valeur de la métrique

(Ouf !!)

Exemple :

- Prenons 2 réseaux sans passerelle, carte 10Gb/s, compatible RDMA :

• Pour le 1^er : 40000 – 19200 – (16*10) = 20640
• Pour le 2^ème : 39999 – 19200 – (16*10) = 20639

- Un 3eme réseau sans passerelle est disponible, une carte 1Gb/s ni compatible RDMA ni RSS :

• 39998 – (16*1) = 39982

- Enfin, un réseau avec passerelle, carte 1GB/s, non compatible RDMA ou RSS :

• 80000-(16*1) = 79984

SMB multi-channel peut utilise en parallèle tous les réseaux ayant la même bande passante et offrant les mêmes fonctionnalités.

Contrairement à 2008R2, dans le fonctionnement normal du cluster, il est inutile de toucher à ces métriques :

• Les réseaux utilisés par le cluster se choisissent via les rôles attribués
• Les réseaux de live migration sont configurés dans le cluster (en powershell ou via l’interface graphique)
• SMB multi-channel cherchera la meilleure solution parmi les réseaux privés pour les I/Os CSV
• Seulement si le SMB multi-channel est désactivé, NetFT utilisera les métriques pour les I/Os CSV
• SMB Multi-channel peut-être désactivé via la commande “Set-SMBClientConfiguration –EnableMultichannel $False” à exécuter sur chacun des nœuds.

Attention : Si vous créez des interfaces virtuelles sur un teaming de cartes réseaux, ces interfaces sont présentées avec une bande passante de 10Gb/s, quelle que soit la bande passante réelle des cartes utilisées et du teaming créé. Ces cartes seront donc prioritaires pour SMB multi-channel par rapport à des cartes 1Gb/s. Ce point est à prendre en compte dans le design de la configuration réseau du cluster.

Jumbo Frames

Si l’ensemble de la chaine réseau les supportent, les jumbo frames améliorent les performances des Live Migrations et ne font pas de mal sur les I/Os CSV, même si le gain n’est pas si flagrant.

Les jumbo frames sont à configurer dans les paramètres avancées des cartes réseau, la méthode va donc varier selon le constructeur de la carte, le paramètre peut s’appeler MTU, Jumbo packets ou différemment. Par défaut ce paramètre est à 1500, et il peut être augmenté à 9000 ou 9014 selon les constructeurs.

Il est très important de vérifier que les switches physiques supportent ce paramètre, pour cela, réaliser un ping entre 2 hôtes ayant un MTU de 9000 (ou 9014) via la commande : ping X.X.X.X –f –l 8000. Ceci va envoyer un ping avec une trame de 8K qui ne passera que si les jumbo frames sont activées partout.

Pour être utilisés par une machine virtuelle, les Jumbo frames doivent être activées dans les cartes réseau concernées de la VM, il n’y a rien à configurer sur le Switch virtuel.

Conclusion

Nous avons parcouru le fonctionnement et la configuration avancée des réseaux clusters.

Comme nous l’avons vu, en usage régulier, le plus important est de bien gérer la priorité sur le port 3343 pour s’assurer que les heartbeats et les ordres de mises à jour de la configuration du cluster soient correctement diffusés. De plus, SMB multi-channel va aider à optimiser la bande passante allouée aux I/Os CSV.

Tous ces mécanismes imposent de bien penser la répartition des cartes réseaux disponibles dès le début pour offrir la meilleure redondance et les meilleures performances possibles même en fonctionnement dégradé.

Arnaud Torres

Bonjour, je suis Christophe Guerre, PFE AD et Hyper-V.

Je vous propose aujourd'hui une traduction d'un article de Doug Symalla, ce post est la 1ière étape de votre chemin de migration vers l'Active Directpry 2012:

• Construisez votre plan de migration ou de mise à jour vers un Active Directory Sous Windows Server 2012.
• Mise à jour de votre AD vers Windows Server 2012 - Etape 1 : L'évaluation
• Mise à jour de votre AD vers Windows Server 2012 - Etape 2 : Construisez votre plan

Si vous avez en charge de gérer une infrastructure Active Directory depuis les 5 à 10 dernières années, vous avez sans doute remarqué une augmentation conséquente du rythme de changement. Après avoir survécu à la migration de Windows NT à Windows 2000 puis ensuite vers Windows 2003, nous avons vécu une belle accalmie pendant environ 5 ans. Soudainement, 3 versions de Windows Server (Windows Server 2008, Windows Server 2008 R2 et Windows Server 2012) ont été publiées en l'espace de quatre ans, [et depuis cette année une 5ième version Windows Server 2012 R2.]

Comme tout amoureux de technologie, toutes ces nouveautés sont excitantes. Mais comme tout professionnel du support technique qui a pour mission d'aider les clients à mettre en œuvre tous ces changements, je peux comprendre que vous pouvez vous sentir accablé. Imaginez-vous un instant gérer et mettre à niveau une infrastructure AD disposant de contrôleurs de domaine exécutant un mélange d'un ou plusieurs, voir tous les OS server 2003, server 2008, server 2008 R2 et Server 2012 ?

Maintenant est venu le temps de commencer à planifier et construire votre feuille de route pour aller de l'avant. Ne vous inquiétez pas, nous sommes ici pour vous aider. AskPFEPlat vous a déjà donné un bel aperçu de Windows Server 2012. Greg vous a même donné des informations pratiques sur le déploiement de votre premier contrôleur de domaine sous Windows Server 2012.

Ce que nous allons vous détailler maintenant (et dans les blogs suivants), est tout ce que vous devez savoir sur le processus de mise à niveau en général ainsi que quelques spécificités. Je sais qu'il existe déjà de bonnes informations sur TechNetet ailleurs sur internet. Ce que nous vous offrons ici, ce sont des informations complètes et pratiques basées sur nos expériences, qui ont aidé des centaines de clients par le biais de ce processus.

Un aperçu du processus de migration

Commençons par parler du Framework pour gérer le processus :

Évaluer votre environnement

Commencez par évaluer l'état actuel de votre infrastructure Active Directory et plus précisément :

• Documenter votre Architecture, votre design ainsi que votre dimensionnement actuel. C.-à-d. : Où, combien et de quelle taille sont vos contrôleurs de domaine actuel ?
• Rechercher et documenter vos dépendances. Quelles applications dans votre environnement dépendent de l'Active Directory ? Quelles applications sont sensibles pour votre entreprise, et le cas échéant leurs dépendances avec l'Active Directory ?
• Documenter votre configuration de contrôleurs de domaine actuelle. Toutes les configurations qui ne sont pas par défaut que vous devrez reporter ?
• Recherche les modifications du comportement par défaut dans les « nouvelles » versions de Windows. Savez-vous comment elles peuvent affecter votre environnement ?
• Inventorier tous autres services/applications qui s'exécutent sur vos contrôleurs de domaine. n'oubliez pas que ceux-ci devront peut-être être migrés comme ils devront disparaître avec vos anciens contrôleurs de domaine.

Planifier votre mise à niveau

Pensez maintenant où vous vous voulez aller et ce que vous devez faire pour y arriver. Utilisez vos données d'évaluation pour piloter vos plans et plus précisément :

• Décider quelle sera votre version de Windows Server – Windows Server 2012/R2 ?
• Déterminer si vous êtes prêt pour cette nouvelle version de Windows. L'avez-vous évaluée et testée ?
• Documenter votre architecture cible. Souhaitez-vous reporter votre architecture actuelle ? Avez-vous le bon nombre de contrôleurs de domaine à la bonne place et ayant la bonne capacité ?
• Décider si le type de DC que vous déploierez va changer. Qu'en est-il des DCs en lecture seule (RODC), ou des contrôleurs de domaine virtuels ? Est-ce qu'ils devraient jouer un rôle dans votre nouvelle infrastructure ?
• Déterminer si les dépendances à l'AD sont compatibles avec ces nouveaux types de contrôleurs de domaine.
• Déterminer quels applications/clients doivent être testés avec ces nouveaux contrôleurs de domaine.
• Planifier et gérer le changement de comportement par défaut dans la configuration des nouveaux OS. Reviendrez-vous sur ces changements (pouvez-vous revenir dessus ?), avant de déployer les nouveaux contrôleurs de domaine, ou vous les laisserez s'appliquer avec les nouveaux contrôleurs de domaine lors du déploiement ?
• Séquencer l'introduction des nouveaux contrôleurs de domaine. Par où allez-vous commencer, ainsi que la vitesse à laquelle vous allez les introduire ?
• Séquencer le démantèlement de vos vieux DCs. Comment allez-vous migrer « les autres » services de ces contrôleurs de domaine ? Avez-vous besoin de reprendre les adresses IP (ou le noms d'hôte) de ces anciens DCs vers les nouveaux contrôleurs de domaine ?

Tester

Idéalement, vous devez tester chaque modification proposée. En pratique, vous devez déterminer ce que vous devez tester et ce que vous pouvez tester et comment vous allez les tester. Dans certains cas, vous allez les tester dans un environnement de lab mais dans d'autres cas, vous n'aurez pas d'autre choix que de les tester en production (avec un déploiement pilote ou limité, par exemple).

• Si vous n'avez pas déjà introduit le nouveau système d'exploitation dans votre environnement de production, tester votre version de serveur pour ce nouvel OS.
• Vous devez vraiment tester les extensions de schéma et les autres modifications apportées à la base de données Active Directory (aka ADPREP), surtout qu'elles sont irréversibles.
• Décider quels sont les applications ou clients dépendant de Active Directory qui doivent être testés.
• Tester votre plan de migration pour les autres services tels que DHCP, WINS ou IAS qui pourraient s'exécuter sur vos contrôleurs de domaine actuels (conseil : migrer les vers des serveurs membres).

Déployer

Maintenant que vous avez fait vos devoirs, définissez les étapes de votre déploiement . Les étapes que vous allez définir doivent inclure :

• Préparer la base de données Active Directory pour les nouveaux contrôleurs de domaine (aka ADPREP).
• Déployer le premier contrôleur de domaine exécutant le nouvel OS.
• Déployer des contrôleurs de domaine supplémentaires et démanteler les anciens DCs.
• Déployer le DC final et retirer tous les anciens.
• Monter le niveaux fonctionnels des domaines et le niveaux fonctionnel de la forêt et mettre en œuvre les nouvelles fonctionnalités apportées par le nouvel OS.

Je sais que c'est beaucoup de choses à prendre en compte, et nous ne partageons pas les détails techniques dans cet article. Cependant, une fois que vous avez le Framework pour le processus de mise à niveau, il vous suffit de remplir les cases blanches. Restez à l'écoute pour les futurs articles qui couvriront ces phases avec beaucoup plus de détails.

A suivre …

Christophe Guerre

Traduit depuis

http://blogs.technet.com/b/askpfeplat/archive/2013/04/29/upgrading-or-migrating-active-directory-to-windows-server-2012-build-your-roadmap-now.aspx

Bonjour c'est Olivier Berline pour le deuxième post de Venkat Kalyanasundaram au sujet d'IPv6.

La version originale de cet article se trouve ici http://blogs.technet.com/b/askpfeplat/archive/2013/11/18/ipv6-for-the-windows-administrator-the-2002-6to4-tunnel-address-and-its-impact.aspx

Nous avons vu ensemble dans mon post précédent IPv6 pour l’administrateur Windows : Comment fonctionne la résolution de nom en environnement mixte IPv4/IPv6la coexistence IPv4 IPv6 quand la plage d'adresse IP est privée.

Aujourd'hui nous allons discuter d'un scénario spécial se produisant quand des plages d'adresses IP publiques sont utilisées au sein de votre réseau d'entreprise.

Rappel des notions IP

Les groupes suivantes d'adresses IP dans la technologie IPv4 sont considérés comme privés.

10.0.0.0 - 10.255.255.255 (10/8 prefix)

172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

En résumé, ces adresses ne peuvent être utilisées pour un trafic de bout en bout sur Internet.

Elles sont destinées par contre à être déployées en interne, au sein d'un réseau d'entreprise pour du trafic Intranet.

Si vous avez la patience le temps de lire la RFC, vous pouvez trouver plus d'infos au lien suivant http://www.faqs.org/rfcs/rfc1918.html.

Si les adresses de votre réseau interne ne sont pas pas comprises dans les plages listées plus haut, vous avez sûrement utilisé des plages d'adresses publiques. Cette configuration n'est pas la plus recommandée, mais déployer des adresses publiques en interne peut être justifié pour un grand nombre de raisons.

Techniquement il faut savoiur que rien ne s'oppose au déploiement d'adresses IPv4 au sein d'un réseau interne.

Si c'est votre cas, ce qui va suivre vous concerne.

Le comportement par défaut de la double pile IPv4/IPv6 et les adresses de Tunneling 6to4

Les machines en configuration Double Pile (couches IPv4 IPv6 activées) possédant une adresse IPv4 située dans une plage publique ont un comportement par défaut spécifique.

Elles génèrent une adresse IPv6 associée à l'interface de tunneling 6to4.

Si vous vous demandez ce qu'est une adresse de tunneling 6to4, vous avez besoin de comprendre le concept de technologies de transition avec IPv6. De façon générale, cela permet d'encapsuler un paquet IPv6 dans un paquet IPv4 pour en permettre le transport sur un réseau purement IPv4.

Il y a différents types de mécanismes de tunneling disponibles ISATAP,6to4, Teredo. Leur utilisation dépend du type de réseau IPv4 configuré.

Si vous êtes intéressés pour apprendre plus sur les technologies de tunneling IPv6, vous pouvez consulter le lient Technet suivant http://technet.microsoft.com/en-us/library/bb726951.aspx

Illustrons cela par un exemple.

Une machine Windows est configurée avec une adresse IP 131.107.23.20, qui se situe dans une plage d'adresses publique. IP¨v6 est aussi activée sur cette machine mais sans adresse globale explicitement configurée.

Par défaut, Windows va générer dans ce cas de figure une adresse pour le tunnel 6to4.

L'adresse générée est visible dans la section 6to4 du résultat de la commande ipconfig.

L'adresse de tunnel 6to4 commence toujours par 2002. Les digits restants sont générés à partir de l'adresse IPv4 de la machine. La même séquence est reprise dans la partie Interface de l'adresse IPv6.

Il s'agit en fait de la représentation hexadécimale des nombres de l'adresse IPv4.

131 s'écrit 83 en hexadécimal, 107 s'écrit 6B, et ainsi de suite.

Pour rappel, le lien Technet http://technet.microsoft.com/en-us/library/bb726951.aspxdétaille en profondeur les mécanismes de tunneling.

Impact sur la production et Active Directory

Avec la génération d'adresses de tunnel 6to4, voyons maintenant l'impact engendré.

Une adresse 6to4 est considérée comme une adresse IPv6 classique et elle sera enregistrée dans le DNS en tant que record AAAA.

Souvenons nous que le comportement par défaut de Windows est de privilégier IPv6 par rapport à IPv4 quand les enregistrements des deux types A et AAAA sont disponbiels entre deux machines Windows.

La communication va s'établir mais le traffic sera en réalité de l'IPv6 encapsulé dans de l'IPv4. Les équipements réseaux transmettront ces paquets tout à fait cohérents en tant que paquets IPv4.

La plupart des administrateurs ne se rend pas compte de ce comportement qui se produit au sein de leur réseau quand ils utilisent les paramètres par défaut et une plage d'adresses IP publiques. Il est surprenant de voir des records AAAA apparaître dans les zones DNS alors qu'aucun paramètre en ce sens n'a été démarré.

Une des solutions de contournement est d'enrichir la définition des sites et services Active Directory en définissant la plage d'adresses IPv6 correspondante et en l'associant au site AD correct.

Car l'impact effectif de cette situation est le suivant : problèmes de performance liés à l'Active Directory.

Sans une définition précise de ces subnets IPv6 apparus via le mécanisme 6to4, vous pourriez observer des clients Windows qui essaient de communiquer avec des Domain Controllers situés hors de leur site alors que des DCs locaux sont présents et opérationnels.

Au lieu de définir ces Subnets IPv6 non désirés (si vous n'utilisez pas la technologie 6to4 bien sûr) dans l'Active Directory, il est plus logique de désactiver la génération automatique de ces adresses de tunnel IPv6.

Désactiver le mécanisme 6to4 correctement

Vous pouvez utiliser les paramètres de Group Policy Computer Configuration->Administrative Templates->Network->TCPIP Settings-> IPV6 Transition Technologies pour empêcher la génération automatique de ces adresses.

La valeur Set 6to4 State doit être positionnée à disable.

Une autre possibilité est d'utiliser la clé de registre DisabledComponents qui pilote le fonctionnement de la pile IPv6.

La KB http://support.microsoft.com/kb/929852décrit les options possibles.

Pour rappel, cette configuration n'est pas nécessaire si vous avez déployé des plages IPv4 privées dans votre réseau.

Olivier Berline

La version anglaise de cet article se trouve au lien http://blogs.technet.com/b/askpfeplat/archive/2013/11/18/ipv6-for-the-windows-administrator-the-2002-6to4-tunnel-address-and-its-impact.aspx

L'article original se trouve ici : http://blogs.technet.com/b/askpfeplat/archive/2013/12/16/domain-and-dc-migrations-how-to-monitor-ldap-kerberos-and-ntlm-traffic-to-your-domain-controllers.aspx

Cette fois-ci, je voudrais parler d'un scénario sur lequel j’ai beaucoup de questions : la migrations de domaine / contrôleur de domaine.

Un élément très (si ce n’est le plus) important d'une migration réussie est de savoir s’il y a un système ou une application qui utilise encore les services de votre domaine avant la mise hors service de votre domaine / contrôleur de domaine.

Habituellement les services informatiques auront la visibilité des applications les plus importantes dans l'environnement ainsi que de toutes les configurations spécifiques (adresses IPs codées en dur, noms de serveur, etc.). Toutefois, il est très fréquent d'avoir des services "pas-aussi-important" utilisant l’AD et ne pas avoir de documentation (ou même connaissance) à leur sujet. Il est aussi très courant de n’avoir aucune documentation pour des services importants :).

La question la plus commune que je reçois de clients est: « Comment puis-je surveiller s’il y a des applications qui utilisent encore mon domaine? »

Cette question s'étend sur beaucoup de scénarios tels que la migration de domaine, la consolidation ou par simple curiosité.
Peut-être voulez-vous écrire la documentation manquante.
Sérieusement, faites-le, s'il vous plaît !

Quel que soit votre scénario, il est très important de savoir quels systèmes utilisent vos contrôleurs de domaine et pourquoi.

Un ensemble de collecteurs de données ou data collector set,  est un composant qui exploite et regroupe différentes sources d'information de performance dans une seule vue.
Un ensemble de collecteurs de données peut être créé puis enregistré individuellement, regroupé avec d'autres ensembles de collecteurs de données et incorporé dans les journaux, vu dans l'analyseur de performances, configuré pour générer des alertes lorsque des seuils sont atteints, ou utilisés par d'autres applications non Microsoft.
En d'autres termes : génial !

Je n’irai pas dans les détails sur le fonctionnement des Data Collector Set, mais je vais vous montrer comment les utiliser pour obtenir des informations AD clés sur vos contrôleurs de domaine.
Nous pourrons profiter des avantages du tracing ETW qui est très puissant, vous pouvez vous renseigner à ce sujet ici.

Remarque: pour que cela fonctionne correctement, vous devrez exécuter cette partie du processus à partir d'un contrôleur de domaine.
Dans cet exemple, j'utilise un contrôleur de domaine 2012 R2 mais le processus doit être la même pour 2008 et 2008 R2. Malheureusement ce processus ne s'applique pas aux contrôleurs de domaine 2003 sur lesquels vous pouvez utiliser SPA et obtenir des informations similaires mais de toutes façons vous allez vous débarrasser de ces vieux DCs 2K3, n’est-ce pas ?

Les ensembles de collecteurs de données sont très utiles, il y a des collecteurs intégrés et le reporting est détaillé.
Par exemple, je peux commencer le collecteur de diagnostics intégré Active Directory et il s’exécutera pendant 5 minutes (si vous voulez changer ça, vous aurez besoin de créer votre propre DCS)
Une fois la collecte terminée, vous pouvez voir ces rapports impressionnants qui vous montreront des informations très importantes sur les performances de votre contrôleur de domaine.

Cela semble magnifique mais le seul problème est que ces rapports sont limités à un nombre maximum de résultats, toutefois les données des traces ETW sont là donc il doit y avoir un moyen d'en profiter... nous allons voir comment.

Tout d'abord commencer par démarrer l'analyseur de performances ou performance Monitor :

Développez Data Collector Set :

Faites un clic droit User Defined – New – Data Collector Set

Tapez le nom que vous voulez ajouter en tant que Data Collector Set, sélectionnez create manually (advanced) et cliquez sur Next :

Sélectionnez Event Trace data :

Sur les Event Providers (fournisseurs d'événements), cliquez sur Add.. et sélectionnez les providers suivants :

- Active directory Domain Services : Core

- Active Directory : Kerberos KDC

- NTLM Security Protocol

Remarque : il existe de nombreux autres providers disponible, vous pouvez personnaliser votre suivi avec tout ce que vous voulez inclure, gardez juste à l'esprit que plus vous ajouterez de providers plus votre fichier sera volumineux.

Cliquez sur Next, sélectionnez le chemin d'accès où vous souhaitez enregistrer le fichier et cliquez sur Finish.

Sur la console Perfmon faire un clic droit sur votre Data Collector Set nouvellement créé et sélectionnez Properties :

Dans cette fenêtre, vous pouvez configurer plusieurs options, mais nous nous intéressons à la condition d'arrêt qui indique à votre système la durée de la collecte d'informations.

ATTENTION : La trace ETW croît  très rapidement dans un système fortement utilisé,  5 minutes de trace consomme ~ 100 Mo d’espace disque donc soyez prudent par rapport à l’emplacement où que vous placez ce fichier. De plus, vous souhaiterez exécuter ce processus lorsqu'il y aura le plus d'activité utilisateur afin d’avoir un échantillon représentatif.

Dans notre cas, je vais exécuter mon test pendant 1 heure :

Après avoir créé votre collecteur, sélectionnez-le et cliquez sur Démarrer dans la barre d'outils :

Une fois les données collectées, vous aurez un fichier nommé datacollector01.etl, si vous essayez de l’ouvrir vous ne verrez que du brouillage car ce fichier est au format binaire.
Alors que pouvons-nous faire pour le lire ?

Ne vous inquiétez pas, « Après un certain temps, vous ne verrez même plus le code ».

Si vous n'êtes pas aussi avancé que Cypher dans ce cas vous pouvez toujours utiliser tracerpt pour convertir ces fichiers en fichier CSV lisible et convenable pour un humain.

Pour cela, ouvrez une invite de commande élevée sur le contrôleur de domaine et exécutez la commande suivante :

Tracerpt – l « file.etl » –of CSV

Si vous exécutez cette commande sur une autre machine, les providers ne sont peut-être pas disponibles et les événements de décodage seront incomplets.

Lorsque le processus est terminé, vous aurez 2 fichiers :

- Summary.csv – vous pouvez utiliser ce fichier pour valider que tous les providers ont été trouvés : il suffit pour cela de vérifier que toutes les lignes sur la colonne eventname sont remplies. Si vous avez une ou plusieurs lignes vides, le système que vous avez utilisé n'a pas les providers corrects (ce qui ne devrait pas se produire si vous l’exécutez sur le contrôleur de domaine car il les a tous)

- Dumpfile.csv : ce fichier contient des informations lisibles par un être humain (vraiment ??)

Pas de panique, vous pouvez ouvrir ce fichier avec Excel et vous verrez un document bien formaté qui permet de filtrer et de trier comme il vous plaît ...
Mais ce n'est pas pratique si je dois revoir tous mes contrôleurs de domaine manuellement.
Par conséquent une macro simple, créée par un collègue PFE, Adrian Corona, vous permet de traiter ce fichier et vous donner un format plus agréable (cette macro peut traiter un seul fichier à la fois), la seule chose que vous devez faire est de suivre ces étapes :

1. Télécharger le document import-DC-Info.xlsm joint en bas de ce post. Il fonctionne avec Excel 2010 et 2013.
2. Placez le document dans le même dossier que le fichier dumpfile.csv
3. Ouvrez le fichier et si nécessaire activez les macros.
4. Cliquez sur Importer un fichier (import files).
   
   
5. Asseyez-vous et détendez-vous.

Une fois ce processus exécuté, vous aurez un fichier excel appelé DCInfo.xlsx avec quelques onglets et les tableaux croisés dynamiques créés :

LDAP

Il contient une liste de toutes les requêtes LDAP exécutées sur votre DC avec une liste d'adresses IPs (avec doublons supprimés), la combinaison IP: port et aussi la requête exécutée. Avec cela vous pouvez voir qui demande quelles infos, et à partir de quelle IP cette requête était originaire.

Kerberos-Pivot

Il s'agit d'un tableau croisé dynamique peuplé depuis l'onglet Kerberos qui est trié par le nombre total d'accès à un service particulier. Ce tableau est utile pour avoir un rapide coup d’œil sur les services qui s’authentifient toujours sur le DC en Kerberos. Pour obtenir cette information j'ai filtré et nettoyé les requêtes TGS-Start, j'ai exclu les demandes AS puisqu'ils pourraient potentiellement augmenter le nombre de résultats et nous ne gagnerions pas beaucoup d'informations supplémentaire en les incluant.

Kerberos

Ce tableau est une synthèse (et doublons supprimés) listant toutes les demandes TGS faites, vous allez utiliser cet onglet si vous voulez voir plus en détail depuis le tableau croisé dynamique, plus précisément la colonne utilisateur (User) vous montrera le compte utilisateur/ordinateur/service réel qui demande un service tandis que la colonne de service indique quel service est requis. Prenons par exemple la ligne suivante :

FabrikamDC3 est un contrôleur de domaine qui demande un ticket Kerberos pour accéder à un partage de fichiers sur fabrikamdc (probablement le contenu Sysvol)

NTLM-Pivot

Ce tableau est très similaire à Kerberos-Pivot, il vous donnera le nombre total de demandes NTLMValidateUser en cours depuis les clients vers des services.

NTLM

Une liste complète de chaque requête NTLMValidateUser , semblable à l'onglet Kerberos.

Comme je l'ai expliqué plus tôt, ce processus doit être effectué de tous vos contrôleurs de domaine  de préférence au cours de la même fenêtre de temps, ainsi vous aurez des demandes d'authentification et requêtes enregistrées uniques. Si vous vous enregistrez des informations de contrôleurs de domaine différents à des moments différents, vous pourriez obtenir des informations du même client sur différents contrôleurs de domaine, et par conséquent des informations dupliquées.

Si vos fichiers csv exportés ne sont pas très grands, une suggestion est de manuellement consolider toutes les données exportées dans un csv unique... Mais attention au fait qu'un énorme fichier peut consommer beaucoup de mémoire et prendra plus de temps à être traité. Si le temps n'est pas nécessairement une préoccupation, allez-y !

La macro n'a pas beaucoup de contrôle d’erreur mais elle fonctionnera si elle est utilisée conformément aux instructions. La bonne nouvelle est que même si vous n'utilisez pas la macro, vous avez toujours des informations qui peuvent être exploitées de la manière que vous préférez.

Restez à l’écoute.

Stéphane Gonzalez

Traduit à partir de : http://blogs.technet.com/b/askpfeplat/archive/2013/12/16/domain-and-dc-migrations-how-to-monitor-ldap-kerberos-and-ntlm-traffic-to-your-domain-controllers.aspx

Import-DC_Info.zip

Bonjour, je suis Olivier Berline, PFE chez Microsoft France.

Aujourd'hui je vous propose la traduction d'un article de Venkat Kalyanasundaram.

La version originale de cet article se trouve ici : 
http://blogs.technet.com/b/askpfeplat/archive/2013/11/11/ipv6-for-the-windows-administrator-how-name-resolution-works-in-a-dual-ipv4-ipv6-scenario.aspx

Travaillant beaucoup sur IPV6 dans le cadre de mon travail, on me soumet régulièrement les mêmes questions sur cette technologie.

Je veux prendre un peu de temps pour répondre aux questions les plus fréquentes et essayer de balayer le mystère autour de IPv6. Ce post sera le premier d'une série donc n'hésitez pas à vérifier régulièrement l'apparition des publications futures.

Je vais répondre maintenant aux deux questions suivantes, qu'on me pose fréquemment en clientèle.

"Comment fonctionne le processus de résolution de nom dans un scénario Dual Stack (piles IPV4 et IPV6 activées) sous Windows? "

"Nous aimerions savoir l'impact sur notre infrastructure réseau quand IPV6 est activé dans Windows".

Commençons par cela. Tout d'abord Microsoft ne recommande pas de désactiver IPv6.

Pour plus de détails, consulter le lien http://technet.microsoft.com/en-US/network/cc987595.aspx

Le point clé ici est d'acquérir une compréhension basique sur la façon dont la résolution de noms fonctionne quand IPV4 et IPV6 sont activés sur une machine Windows.

Dans le monde d'IPv4, nous sommes habitués à gérer la résolution de noms via les services DNS et WINS.

Dans le monde d'IPv6, WINS n'est plus opérationnel. En d'autres termes, les adresses IPv6 ne sont jamais enregistrées sur un serveur WINS, elles sont uniquement prises en charge au sein des mécanismes DNS.

IPv6 est représenté dans DNS par un enregistrement de type AAAA similaire à celui d'un record type A qui associé un nom à une adresse IPv4.

Le mécanisme d'enregistrement PTR (pour la résolution de nom inversée) marche aussi pour IPv6 dans DNS.

Avec IPv4, dans la plupart des cas, nous sommes habitués à voir une seule adresse IP enregistrée dans DNS pour une machine donnée.

Avec IPv6, il faut composer avec trois types d'adresses différents (Les type sont Link local, Global et Site Local. Voir le Post suivant de Mark et Ray pour plus d'explications

http://blogs.technet.com/b/askpfeplat/archive/2013/06/24/ipv6-for-the-windows-administrator-ipv6-fundamentals.aspx).

Notez que tous les types d'adresses IPv6 ne sont pas enregistrées dans le DNS.

En particulier, les adresses de type "Link Local" identifiables par leur début FE80: ne sont pas enregistrées dans le DNS. Ces adresses sont actives uniquement dans leur sous réseau local et ne sont pas routables.

Les adresses "type Global" sont enregistrées dans le DNS en tant que record AAAA.

S'agissant des technologies de transition, les adresses Teredo ne sont pas non enregistrées dans le DNS. L'article Technet DNS Client behaviorexplique ce comportement en détail.

Regardons quelques scénarios concrets d'une infrastructure IPV4 standard dans laquelle des machines Windows avec la double pile IPv4-IPV6 (Dual Stack) activée se localisent et communiquent sur le réseau.

Scenario #1:

Comme vous pouvez le voir dans le diagramme ci-dessus, nous avons deux machines ( un Windows 7 client et un serveur AppServer1 2008R2) situés dans deux sous-réseaux différents, chacun ayant IPv4 et IPv6 activés.

Lorsque vous activez IPv6 sur une carte réseau (en ayant la case IPV6 cochée dans les propriétés de la carte), l'adresse "Link Local" (commençant par FE80 : vérifiable avec la sortie IPCONFIG) sera automatiquement configurée par Windows.

Nous n'aborderons pas ici les mécanismes détaillés de la génération de l'adresse "Link Local" générée automatiquement. Ceci fera l'objet d'un prochain post.

Pour en revenir à notre scénario, supposons qu'aucune adresse IPv6 n'est configurée dans ce réseau. , qu'elle soit de type Global ou configurées dans les protocoles de transition entre IPv4 et IPv6 (Teredo, etc..)

Lors de l'enregistrement dynamique dans DNS de la machine AppServer1

l'adresse IPV4 est enregistrée (comportement classique).

L'adresse Link Local IPv6 n'est pas enregistrée puisqu'il s'agit d'une adresse non routable et limitée en portée au sous réseau local.

En d'autres termes dans les enregistrements DNS il n'existe qu'un record type A (IPv4) pour AppServer1 bien que IPv4 et IPv6 soient activés sur cette machine.

Supposons que le client Windows 7 ait besoin de communiquer avec le server AppServer1 et voyons comment les choses se passent au niveau de la résolution de noms.

Le client envoie une requête de résolution de noms au serveur DNS. Celui-ci renvoie le seul enregistrement présent à savoir le record A IPV4 10.1.0.2.

Ainsi, la communication va se dérouler totalement en IPv4 entre ces deux machines bien que la double pile IPv4 IPv6 soit activée sur les deux. Il n'y a ici d'un point de vue réseau aucun changement dans la configuration et dans les performances de la communication.

Si IPv6 était désactivé sur une des deux machines (voire les deux), le comportement serait le même que celui-ci.

Scenario #2:

Enrichissons le premier scénario décrit plus haut.

Le client possède toujours une double pile IPv4 IPv6, avec une adresse Link Local IPv6.

Le serveur lui a une adresse IPV6 de type Global.

Dans le mécanisme Dynamic DNS, le serveur va enregistrer cette fois ci un record A 10.1.0.2 et un record AAAA pour l'adresse globale IPV6. Notons qu'il possède encore une adresse Link Local qui ne sera pas enregistrée au niveau DNS comme prévu.

Que se passe-t-il lors de la résolution de noms?

Le Client va envoyer une requête au serveur DNS uniquement de type A.

En effet, le client sait que son adrese IPv6 est Link Local et qu'il lui est impossible de communiquer en dehors de son subnet via IPv6. Il ne demandera pas de record AAAA.

Le Serveur DNS répond par le record classique A IPv4.

La communication s'exécute uniquement en IPv4 comme dans le scénario 1.

Scenario #3:

Dans le troisième scénario, le client et le serveur ont des adresses IPv6 "Global" configurées.

De plus le routage a été activé sur les équipements réseaux pour permettre un traffic IPv6 natif entre les sous-réseaux.

Cela suppose d'avoir fait une série d'actions explicites pour configurer des adresses IPv6 globales au sein du réseau d'entreprise.

Ceci peut être fait manuellement, ou depuis le serveur DHCP, ou depuis le routeur. (voir le lien http://blogs.technet.com/b/askpfeplat/archive/2013/07/08/ipv6-for-the-windows-administrator-more-ipv6-subnetting-zones-address-autoconfiguration-router-advertisements-and-ipv4-comparisons.aspxpour en savoir plus sur la configuration par routeur)

Dans ce scénario les deux machines enregistrent leurs records A (IPv4) et AAAA (IPv6) dans DNS.

Cette fois ci , lors de la résolution de noms, les deux types d'enregistrement sont retournés au client.

Avec ces deux valeurs , le comportement par défaut de Windows est d'utiliser IPv6.

Dans ce scénario, la communication se fera en IPv6.

Résumé

Comme nous venons de le voir, c'est seulement dans le scénario 3 que le client et le serveur vont communiquer en IPV6.

Cette communication est la conséquence d'une série d'actions spécifiques pour configurer des adresses IPV6 "Global" cohérentes dans l'ensemble du réseau d'entreprise, aussi bien sur les machines que sur les routeurs.

SI vous n'effectuez aucune action spécifique sur IPv6 tout en laissant la pile IPv6 activée sur vos machines Windows avec les paramètres par défaut, l'impact sur votre production sera minimal comme vous avez pu le voir dans les scénarios 1 et 2.

Comme vous avez pu le remarquer, les adresses IPv4 utilisées se trouvent dans une plage privée.

Si votre réseau utilise des adresses IPv4 appartenant à des plages publiques, autres que 10.x.y.z,172.16.x.y,192.168.x.y des comportements différents sont à prendre en compte.

C'est ce qui fera l'objet d'un prochain Post.

La version originale par Venkat Kalyanasundaram de cet article se trouve au lien http://blogs.technet.com/b/askpfeplat/archive/2013/11/11/ipv6-for-the-windows-administrator-how-name-resolution-works-in-a-dual-ipv4-ipv6-scenario.aspx

Nous sommes un groupe de Premier Field Engineers (PFE) experts sur les OS serveurs.

Nous travaillons sur les environnements des clients Premier quotidiennement et l'objectif de ce blog est de vous transmettre notre expérience et nos astuces au travers d'articles originaux et de rendre accessible l'expérience de nos collègues du monde entier en vous offrant des articles issus du blog Ask PFE Platforms US traduits en français.

Notre expertise couvre les technologies Active Directory, Cluster, Hyper-V, RDS/VDI, WSUS, System Center, entre autres.

Bienvenue sur notre blog, nous espérons démarrer quelque chose de passionnant.

Arnaud Torres
Christophe Guerre
Nicolas Ghirardi
Olivier Berline
Stéphane Gonzalez