La problématique

Lors de l’installation de Windows Azure Active Directory Synchronization (aka “DirSync”) sous Windows Server 2012 R2, l’erreur suivante peut apparaitre :

The minimum version of Windows Powershell required is 2,0.
Please install the minimum version required (or higher) and try again.

Cela peut sembler étrange d’autant plus que Windows Server 2012 R2 intègre nativement la version 4.0 de PowerShell.

Explication

Il semble que ce problème soit dû à la localisation du système d’exploitation. En effet sur un système d’exploitation installé en langue française, le caractère séparateur entre les entiers et les décimales est la virgule et non le point.

Or on peut remarque que le message d’erreur indique un problème pour détecter la version PowerShell 2,0 et non 2.0.

Solution

La solution consiste tout simplement à modifier les formats de date, d’heure et de nombre et à les passer sur le format anglais.

Il suffit ensuite de fermer, puis de relancer l’installeur de DirSync pour que la modification soit prise en compte et que PowerShell soit bien détecté.

N.B. : Ne pas oublier de lancer dirsync.exe avec des droits administrateur (clic droit, puis Run As Administrator), sinon une exception .net apparaît

INSTALLATION DU DAG (DATA AVAIBILITY GROUP)

Tout d’abord il faut connaitre le rôle du DAG, son but est tout simplement la haute disponibilité des BASES MAIL.

petit rappel sur les bases mail, c’est une base de donnée qui contient  les boites aux lettres (BAL) des utilisateurs de messagerie exchange et dont la limite est de 2 TB.

Tout d’abord il faut renommer les bases mail pour plus de clarté prévoir une convention de nommage

1) renommer les bases de données (avec convention de nommage simple)

2) création d’un compte ordinateur que l’on désactive et attribue les droits

Full control, celui va servir pour le DAG

3) Le serveur File Server Witness (FSW01) joue le rôle de QORUM

Il doit être ajouter au groupe (Exchange Trusted Subsystem ) dans Active Directory puis le groupe Exchange Trusted Subsystem ajouter au groupe local administrator du serveur FSW01.

Le FSW doit être créé car si le cluster passe de serveur impair à pair

On n’aura toujours 1 votant supplémentaire.

Installer la fonctionnalité du serveur de fichier

Puis ouvrir niveau pare-feu avancé et paramétrer

4) créer un groupe de disponibilité,

Figure 1

Figure 2

Figure 3 : mettre une ip pour le DAG 192.168.1.10 sur le réseau MAPIDAGNetwork

5) parametrer le réseau dedié au DAG01, dans notre cas

Figurer 1

Figure 2 : décocher register this connection’s adresses in DNS.

Pour regarder les configuration du DAG sur EXCH01 et EXCH02 taper la commande suivante sous Exchange management shell:

Voici les résultats :

EXCH01

EXCH02

6) Par defaut les reseaux mapidagnetwork et ReplicationDAG Network

Se configurer en auto avec la carte reseau en prod et l’autre pour REPLICA avec aucune passerelle activé et décocher registrer this connection in DNS, il fait la différence et les bascule automatiquement.

Pour modifier manuellement les configuration du DAG sur EXCH01 et EXCH02 faire comme ci-dessous.

Figure1 : cocher configurer manuellement les réseaux.

Figure 2 : soit désactiver la réplication soit afficher les détail pour modifier la configuration.

7) Creation de la copie passive sur les 2 serveurs EXCHANGE :

- Copie des Bases mail De EXCH01 vers EXCH02 et EXCH02 vers EXCH01

Figure1 : voir ci-dessous

Figure2 : ajouter le serveur EXCH02 puis cliquer ENREGISTRER

Taper la commande suivante pour fixer la configuration :

Set-DatabaseAvailabilityGroup DAG01 -ManualDagNetworkConfiguration $false

Tester le réplication avec le commande let : Test-ReplicationHealth

Ou Test-ReplicationHealth | fl

Vérification de la copie de base de données avec PowerShell:

EXCH01

EXCH02

8) Test de la bascule de la base de données

Vérification de l’utilisateur créé (kouasti) sur quelle base ? :

Eteindre le serveur EXCH01 sur lequel la base MBX-DAG01-DB01 est actif

Cela prend quelques secondes.

9) Test de la bascule de la base de données en mode maintenance

Effectuer ses manipulations sur le serveur ou les bases sont actives

MBX-DAG01-DB01

MBX-DAG01-DB02

Aller dans C:\Program Files\Microsoft\Exchange Server\V15\Scripts puis

Taper :

[PS] C:\Program Files\Microsoft\Exchange Server\V15\Scripts>.\StartDagServerMaintenance.ps1 -servername exch02

RESULTAT

Sur Exch01 faire get-mailboxdatabasecopystatus

Sur Exch02 faire get-mailboxdatabasecopystatus

POUR REMETTRE EN PLACE il faut stopper la maintenance:

.\StopDagServerMaintenance.ps1 -servername exch02

J’espère que le blog vous a éclairé sur la mise en plce sdu DAG exchange 2013

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.

Lorsqu’on se contente de supprimer un compte dans Office365, que ca soit via la console Web ou via powershell, il n’est pas réellement totalement détruit et cela peut occasionner des comportements étranges s’ils sont resynchronisés par la suite.

Afin d’y remédier, il est possible de forcer la suppression totale de ce compte via powershell.

Commencer par supprimer de facon classique le compte :
Remove-MsolUser -UserPrincipalName utilisateur@domaine.com

Puis forcer le nettoyage :
 Get-MsolUser -ReturnDeletedUsers -UserPrincipalName utilisateur@domaine.com | Remove-MsolUser RemoveFromRecycleBin -Force

Il est maintenant possible de relancer un DirSync et l’utilisateur sera intégralement resynchronisé comme s’il n’avait jamais existé.

Cet article a pour objectif de vous informer sur l’exploitation des fichiers de journalisation lors d’un déploiement d’un poste de travail via MDT.

Emplacement des fichiers logs

En fonction de l’état d’avancement de votre déploiement, la localisation du répertoire contenant les fichiers de journalisation sera différente.

Si votre déploiement s’est arrêté avant la fin de la phase de déploiement de l’image. Le répertoire se situe au niveau le lecteur virtuel X chargé en mémoire. Le chemin complet pour accéder au répertoire est le suivant : X:\MININT\SMSOSD\OSDLOGS

En revanche si une erreur est survenue après la copie de l’image de l’OS, les logs seront stockés dans le disque système. Voici le chemin complet pour accéder au répertoire : C:\MININT\SMSOSD\OSDLOGS.

Enfin si votre déploiement s’est terminé correctement, le répertoire à utiliser est le suivant : C:\Windows\TEMP\DeploymentLogs.

Découverte des fichiers logs

Vous connaissez les différents emplacements, je vous propose maintenant de passer en revue les différents fichiers disponibles. Vous trouverez ci-dessous les deux principaux axes pour l’analyse de vos déploiements :

BDD.log

Regroupe l’ensemble des logs de tous les scripts exécutés durant la séquence de tâche.

SMSTS.log

Retourne les informations après l’exécution de chaque étape de la séquence de tâches.

De plus, vous trouverez pour chaque script MDT un fichier de journalisation dédié (intégralement repris dans le BDD.log).

Vous trouverez par exemple :

ZTIDiskpart.log

Logs liés au partitionnement du disque

ZTIDomainJoin.log

Logs liés à l’intégration du poste dans un domaine Active Directory

ZTIDrivers.log

Logs liés à l’installation des drivers

Enfin si vous avez ajouté des scripts dans votre séquence de taches, sachez qu’un fichier log est créé pour chaque script (le fichier Log associé portera le nom de votre script).

Outil pour exploiter les fichiers logs

Après avoir fait un tour d’horizon des différents fichiers de journalisation, voyons à présent comment en optimiser leur exploitation.

Il est tout à fait possible d’ouvrir les fichiers avec un simple éditeur de texte. Cependant, les fichiers contiennent différentes informations qui rendent la compréhension délicate. Plutôt que d'utiliser Notepad, je ne peux que vous conseiller d’utiliser un outil plus adapté.

Microsoft met à disposition Configuration Manager Trace Log Tool. L'outil est dédié à l'exploitation des fichiers logs générés par MDT ou ConfigMgr. L’exécutable pèse moins de 700 Ko et ne nécessite pas d’installation sur le système. Il sera donc très facile de l’exécuter sur les postes dont le déploiement aura échoué.

CMTrace remplace SMSTrace qui était la précédente version de l'outil (disponible dans le Toolkit ConfigMgr 2007 R2). Notez que le code couleur permet de détecter rapidement les actions échouées :

· Rouge : Erreur

· Jaune : Avertissement

· Blanc : Observation

Avec ses informations, vous devrez rapidement identifier les actions qui ont posé problème lors du déploiement.

CM Trace fait partie du System Center Configuration Manager 2012 R2 Toolkit. Il est disponible gratuitement depuis le lien suivant : http://www.microsoft.com/en-us/download/details.aspx?id=36213

Cet article indique les étapes à réaliser pour exécuter un script PowerShell durant vos déploiements.

Ajout des fonctionnalités

La première étape consiste à mettre à jour votre image de boot pour la rendre compatible avec l’exécution des scripts PS. Pour ce faire, il est nécessaire d’ajouter des fonctionnalités à votre environnement Win PE. Rendez-vous donc dans les propriétés de votre « Deployment Share ».

Sélectionner l’onglet « Windows PE », puis l’architecture de votre plateforme (x86 ou x64) et enfin cliquer sur « Features »

Cette fenêtre vous permet de visualiser les fonctionnalités disponibles. Dans notre cas, pour permettre l’utilisation des scripts PowerShell, il est nécessaire d'ajouter les composants suivants :

• Microsoft Data Access Components (MDAC/ADO) support
• NET Framework
• Windows PowerShell

Mise à jour de l’image Win PE

Maintenant que les composants ont été sélectionnés, il faut mettre à jour votre Deployment Share. Cette opération va régénérer votre image WinPE avec les nouvelles fonctionnalités. Pour ce faire : Clic droit sur « Deployment Share » puis sélectionner « Update Deployment Share »

Sur l’assistant de mise à jour, vous pouvez laisser les options proposées par défaut.

Cliquez sur Next. L’assistant affiche un résumé. Cliquez une nouvelle fois sur Next pour démarrer le processus de mises à jour de l’image.

La durée de l’opération peut prendre quelques instants. Patienter jusqu’à la fin du processus.

Après avoir vérifié que l’opération s’est déroulée correctement, cliquez sur Finish pour fermer la fenêtre.

Je vous invite à vous rendre sur la seconde et dernière partie. Celle-ci traite l’ajout de l’image Wim dans WDS et l’ajout d’un script Powershell dans une séquence de tâches.

Importer la nouvelle image WinPE dans WDS

Grâce à la première partie, votre nouvel environnement est maintenant capable d’exécuter des scripts Powershell. Cependant, la nouvelle image WinPE n’est pas encore disponible sur votre serveur WDS (et donc pas pour vos clients Windows). Pour mettre en ligne votre image, rendez-vous dans la console WDS.

Sélectionner votre serveur de déploiement, puis le dossier « Boot Image ». Faite un clic droit sur celui-ci et sélectionner « ADD Boot Image »

La première étape de l’ajout d’une nouvelle image consiste à indiquer le chemin de votre image WinPE.

Par défaut, les images se trouvent dans le chemin suivant :

« CheminDuDeploymentShare\Boot»

Sélectionner votre image (portant l’extension « .wim » et cliquez sur « Next ».

Sur la page suivante, vous avez la possibilité de saisir un nom et la description. Cliquez sur « Next ».

La dernière page vous résume la configuration avant de lancer l’import de l’image.

À la fin de l’opération, vérifier que tout s’est déroulé correctement puis fermer cette fenêtre. À présent, vous devriez voir votre image de boot dans la console.

Ajouter un script PowerShell à votre séquence de tâche

La dernière étape consiste à ajouter un script PowerShell dans une séquence de tâche.

Pour ce faire : Rendez-vous dans la console « Deployment Workbench », puis déplier l’arborescence de votre « Deployment Share » et enfin « Task Sequences ».

Sélectionner votre séquence de tâches et aller dans les propriétés de celle-ci.

Une nouvelle fenêtre s’ouvre, allez dans l’onglet « Task Sequence ». Maintenant, cliquer sur « Add » puis sur « General » et sélectionner « Run Powershell Script ».

Une nouvelle étape d’exécution d’un script PowerShell a été ajoutée à votre Task Sequence. Vous devez remplir les champs : Name, description (optionnel), PowerShell script et parameters (optionnel).

Tips 1 : Dans mon exemple, %DEPLOYROOT% est une variable qui représente l’emplacement de mon « Deployment Share ».

Tips 2: Durant le déploiement, MDT se charge d’autoriser l’exécution des scripts Powershell sur l’environnement client.

Tips 3 : Notez également qu’un fichier log est généré pour chaque script exécuté dans une TS.

A présent vous êtes maintenant capable de déployer vos propres scripts dans votre environnement.

Si vous utilisez Office 365 dans votre infrastructure, il y a de fortes chances que vous soyez déjà utilisateur de DirSync pour synchroniser votre AD local.

Synchronisation d’utilisateurs locaux en utilisateurs distants ou de Mail Enabled Users locaux en MailUser distants ne vous posent évidemment aucun souci particulier.

Mais comment faire si vous souhaitez sortir des sentiers battus et synchroniser vos utilisateurs en mailuser distants (ce qui constitue un prérequis à l’utilisation de certains outils de migration)?

Commençons par le début : qu’est-ce qui définit un MailUser? Ce blog technet nous apprend qu’il suffit que les attributs mailNickName, DisplayName et TargetAddress soient peuplés.

Seulement voilà : si vos utilisateurs disposent normalement déjà d’un mailnickname et d’un displayname, il en va tout autrement de la targetaddress qui est normalement utilisée afin de rediriger les mails qui leur sont adressés : aucune chance donc que leurs comptes comportent déjà cet attribut, encore moins paramétré vers leur propre adresse, ce qui créerait des boucles de routage.

Il faut donc trouver un moyen de rediriger l’adresse mail de l’utilisateur local vers le champ targetadress de son compte synchronisé dans office 365.

Et cette solution, c’est DirSync : moyennant quelques paramétrages, il va nous permettre ce tour de passe-passe.

Lancez la console MIIS DirSync (elle se trouve par défaut ici : "C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe" ) et ouvrez l’onglet Management Agents

Double-cliquez sur Active Directory Connector puis cliquez sur l’onglet Configure Attribute Flow

Déplier la catégorie Object Type : user.

Dans le menu déroulant Data source object type, sélectionner user puis dans la liste Data source attribute, sélectionner mail.
Dans mapping type, cocher Direct.
Dans Flow Direction, cocher Import
Dans le menu déroulant Metaverse object type, sélectionner person
Dans la liste Metaverse attribute, sélectionner targetAddress

Cliquer sur New puis sur OK

Et… c’est tout. Désormais, lorsque les utilisateurs seront synchronisés depuis l’AD vers la metaverse (base de donnée intermediaire de DirSync), l’attribut targetAddress sera peuplé avec leur adresse mail; puis quand DirSync synchronisera la metaverse vers Office365, les utilisateurs seront synchronisés en tant que MailUser.