Contexte

Cet article présent la configuration du RPC/HTTP dans une architecture de type mono-serveur l’unique serveur ayant les rôles suivants :

• Contrôleur de domaine,
• Catalogue global,
• Serveur Exchange,
• Proxy RPC.

RPC/HTTP permet à une entreprise de relier ses clients Outlook mobile sans mettre en danger son environnement de production par l’ouverture de plusieurs ports (qui sont susceptibles d’être bloqués en sortie dans le réseau du client mobile) les seuls ports utilisés sont les ports TCP 80 ou TCP 443 dans le cas d’une utilisation avec SSL.

Installation du proxy RPC

– Dans « Panneau de configuration » choisir « Ajouter ou supprimer des programmes »

• Choisir « Service de mise en réseau » puis « Détails » :

– Sélectionner « Proxy RPC sur HTTP » puis lancer l’installation (le CD de Windows Server 2003 ou le dossier i386 est requis) :

Configuration du répertoire RPC depuis IIS

– Depuis la console IIS (Gestionnaire des Services Internet), afficher les propriétés du dossier RPC :

– Dans l’onglet « Sécurité du répertoire », cliquer sur le bouton Modifier de la partie « Authentification et contrôle d’accès » :

– Dans les Méthodes d’Authentification, décocher la case « Activer la connexion anonyme » et cocher « Authentification de base » :

(Une fois cette modification faite, un message d’information apparait vous signalant que le mot de passe est envoyé en clair via une connexion non-cryptée et est donc visible en utilisant un outil d’analyse de trames, bien sûr, si le SSL est déjà activé sur le site, ce message ne nous concerne pas.)

Activation du SSL pour le répertoire RPC

ATTENTION ! : Cette partie nécessite que la configuration d’SSL sur le Site par Défaut IIS soit fonctionnelle, avec un certificat de paramétré. Si SSL n’est pas utilisé cette étape peut être passée.

– Depuis la console IIS (Gestionnaire des Services Internet), afficher les propriétés du dossier RPC,

– Dans l’onglet « Sécurité du répertoire », cliquer sur le bouton Modifier de la partie « Communications sécurisées » :

– Cocher les cases « Requérir un canal sécurisé » ainsi que « Exiger le cryptage 128 bits »:

Activation du RPC-http depuis la console Exchange

– Depuis la console « Gestionnaire système Exchange » dans le dossier « Serveurs » sur le serveur RPC-http faire clique-droit puis « Propriétés » puis cocher la case « Serveur principal RPC-http :

Une erreur spécifiant qu’aucun serveur frontal Exchange n’existe est susceptible d’apparaitre. Ignorer ce message.

Configuration des ports utilisé par le serveur Proxy RPC

ATTENTION ! : Cette partie touche au registre. Avant toute modification du registre, il est fortement conseillé de sauvegarder le registre

La configuration des valeurs de registre suivantes est automatiquement exécutée lors du redémarrage suivant l’installation du Proxy RPC-HTTP (pour Exchange Server 2003 SP2). Cette partie est utile, si un reboot n’est pas envisageable ou si vous souhaitez vérifier la bonne configuration de ces valeurs.

– Chercher la clé de registre « HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy » :

– L’attribut « ValidPorts » doit être configuré comme il ceci (le texte surligné en jaune doit être modifié en fonction de vos nom de serveurs :

Par exemple :

• Domaine : TEST.lab
• NomNETBIOSduServeur : EXCHANGE-SRV
• FQDNInterneduServeur : EXCHANGE-SRV.TEST.lab
• FQDNExterneduServeur : mail.TEST.lab

Soit :

Contexte

Suite à la restauration d’un snapshot ou d’une sauvegarde d’un contrôleur de domaine virtuel, l’erreur USN Rollback peut apparaître.

L’USN (Update Sequence Number) permet un versionning des objets utilisé par l’annuaire Active Directory, chaque modification d’un objet AD depuis un contrôleur de domaine va incrémenter le numéro USN de l’objet. En comparant entre les différents DCs leur numéro d’USN il est possible de déterminer quelle base est la plus à jour.

Lors d’une restauration d’un DC virtuel, et si l’outil de sauvegarde utilisé ne supporte pas la restauration Active Directory, il est probable qu’une erreur USN soit provoquée.

Les autres contrôleurs de domaine – en comparant leur numéro USN – vont détecter le DC restauré comme n’étant pas à jour en ne répliqueront pas avec lui.

Eviter l’USN Rollback

Les solutions suivantes permettent d’éviter une situation d’USN Rollback :

1. Utiliser une solution de sauvegarde avec prise en charge de l’AD,
2. Ne pas restaurer des backup dont la date excède le “Tombstone lifetime” qui est de 60 jours par défaut,
3. Utiliser un contrôleur de domaine virtuel sous Windows Server 2012 ou ultérieur. Windows Server 2012 ajoute au contrôleurs de domaine un attribut supplémentaire (qui est géré par Hyper-V 2012) et qui évite l’USN rollback lors de la restauration d’un snapshot.

Symptômes de l’USN Rollback

• La commande ”repadmin /showutdvec” retourne de différents numéros d’USN,
• Le service NETLOGON est en pause,
• La valeur de la clé “DSA Not Writable” est à “4”,
• Les erreurs 2095 (NTDS Replication), 2013 (NTDS General), 2103 (USN Rollback),
• Les réplication entrantes/sortantes sont désactivées (visible à l’aide de la commande repadmin /showrepl ),

Résolution

Microsoft préconise (après l’apparition d’un USN Rollback) de retirer le contrôleur de domaine défaillant, après avoir transféré les éventuels rôles FSMO qu’il héberge (NTDSUtil permet de transférer les rôles ou de les saisir s’il est impossible de les transférer correctement).

Egalement dans le cas où la de-promotion du contrôleur de domaine ne se passe pas correctement, il faudra s’aider du switch “/forceremoval” de al commande DCPromo. Il faudra aussi bien penser à nettoyer les métadonnées du contrôleur de domaine défaillant, depuis un contrôleur de domaine fonctionnel.

L’idéal est – lorsque l’on souhaite restaurer le snapshot d’un contrôleur de domaine alors que le snapshot ne supporte pas la VM-GenerationID – de démarrer le contrôleur de domaine directement en mode DSRM. Une fois démarré en mode DSRM, mettre la valeur de registre “database restored from backup” à “1”.

Si le contrôleur de domaine a déjà été démarré en mode “normal”, il faudra le retirer (après avoir pris soin de récupérer les rôles hébergés).

(Source :

http://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-8cd1-5fbaa6740ffe%28v=ws.10%29#backup_and_restore_considerations_for_virtualized_domain_controllers)

Contexte

Afin de suivre l’état des partages répliqués en DFS-R – comme par exemple le partage SYSVOL depuis Windows Server 2008 – il est possible d’utiliser la fonction intégrée à DFS Management et qui permet de générer une page HTML synthétisant l’état de la réplication.

Voici les trois tests proposés par la fonction de diagnostique de DFS Management :

• Test de propagation : Permet de vérifier la bonne réplication d’un fichier de test,
• Rapport de propagation : Génère le rapport de propagation du fichier de test utilisé lors du Test de propagation,
• Rapport de santé : Génère un rapport présentant les éventuels erreurs/warnings des serveurs membres ainsi que le bon fonctionnement de la réplication (en affichant par exemple le gain réseau par rapport à une réplication classique de type FRS).

Cet article ne traitera que de la fonction “Health Report”.

Créer un rapport de santé (GUI)

Depuis la console “DFS Management” dans la partie “Replication”, choisir le lien de réplication que l’on souhaite vérifier, puis faire clique-droit et choisir “Create Diagnostic Report” :

La page suivante propose les trois tests mentionnés plus haut, choisir “Health Report” :

La page suivante affiche le nom du rapport qui sera généré, et nous permet d’en choisir l’emplacement :

Choisir les membres que l’on veut voir apparaitre dans le rapport de santé dans la partie “Included members” :

La page suivante permet de spécifier deux points importants dans l’exécution du rapport (dans cet exemple, seule l’option “Count backlogged files” sera utilisée) :

1. Les “backlogged files” (qui sont les fichiers à répliquer) doivent-ils être comparés pour vérifier que tous les serveurs répliquent correctement les nouveaux changements ?

Pour ce test, un membre de référence doit être indiqué, il s’agira du membre dont les fichiers sont les plus à jour.

2. “Count the replicated files and their sizes in each member” cette option permet de comparer tous les fichiers répliqués ainsi que leurs tailles entre tous les serveurs. Ce qui permet de confirmer que les fichiers sont bien les mêmes entre les différents serveurs.

Dans le cas où plusieurs fichiers sont présent, le comptage de tous les fichiers peut se montrer lent et consommateur en ressources.

Terminer l’assistant de création de rapport puis le rapport s’affiche via votre navigateur par défaut (le rapport au format HTML est disponible à l’emplacement spécifié à la seconde page de l’assistant).

Créer un rapport de santé (PowerShell)

Il est également possible d’utiliser PowerShell pour la création de rapport de santé dont la génération peut être automatisée à l’aide d’une tâche planifiée.

Voici la commande utilisée :

• /RgName : Il faut ici préciser le nom du groupe de réplication que l’on souhaite monitorer.
• /RefMemName : Ce switch permet de déclarer le membre de référence, celui le plus à jour.
• /RepName : Emplacement de stockage du rapport généré,
• /FsCount : Permet de spécifier si une comparaison des fichiers ainsi que de leur taille doit être faite ou pas.