PI Services

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

Symptôme

Lors d’un déploiement d’Exchange Server 2010 SP2 avec RU4v2 (rollup stocké dans le sous-dossier Updates des sources Exchange), j’ai rencontré l’erreur suivante durant l’installation du rôle Hub :

Service “MSExchange Transport” failed to reach status “Running” on this server.

Voici le détail de l’erreur dans le journal Application :

Cette erreur à l’installation peut être considéré comme un “classique” d’Exchange 2010 lorsqu’une mauvaise configuration IPv6 est positionnée sur le serveur (cf. ce billet réalisé peu après la sortie d’Exchange 2010 : http://blog.piservices.fr/post/Exchange2010-Erreur-lors-de-linstallation-du-role-de-transport-Hub.aspx).

Néanmoins dans ce cas précis l’erreur n’était pas liée à la configuration IPv6 (interface réseau et clé de registre DisableComponents correctement configurés).

Après investigation l’erreur d’installation s’accompagnait de plusieurs évènements autour du service AD Topology dont le suivant :

Event ID: 2080
Source: MSExchange ADAccess
Task Category: Topology
Level: Information
Error:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=2386). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
dc01.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc02.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc03.domain.lan CDG 1 7 7 1 0 0 1 7 1
Out-of-site:
dc05.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc06.domain.lan CDG 1 7 7 1 0 0 1 7 1

Explication

Après investigation il s’avère que le problème d’installation est dû à un droit manquant sur la stratégie de groupe Default Domain Controllers Policy  pour le groupe Exchange Servers.

Pour rappel le groupe Exchange Servers est créé lors de la phase de préparation de l’annuaire Active Directory pour Exchange 2010 (ou Exchange 2007) et plus exactement via la commande setup.com /PrepareAD.

Lors de la phase de préparation des domaines via la commande setup.com /PrepareDomain la GPO Default Domain Controllers Policy de chaque domaine est modifiée de manière à donner le droit Manage auditing et security log au groupe Exchange Servers.

Dans le cas rencontré ici ce droit était manquant (d’où la présence d’un zéro dans la colonne SACL right lors de la détection des contrôleurs de domaine par le service de détection de la topologie Active Directory).

Résolution

Pour résoudre le problème rencontré la stratégie de groupe GPO Default Domain Controllers Policy est éditée via la console Group Policy Management Editor. Le droit manquant est situé dans l’emplacement suivant :

Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / user Rights Assignments

Il faut modifier le paramètre Manage auditing and security log et y ajouter le groupe nommé “Domaine racine \ Exchange Servers”.

Une fois la modification de stratégie de groupe prise en compte (comptez quelques minutes), l’instalation du rôle Hub Transport peut être relancée et cette fois-ci se déroule sans encombres.

Pour aller plus loin, vous pouvez consulter les articles suivants :

http://blogs.technet.com/b/richardroddy/archive/2010/06/16/msexchange-adaccess-dsaccess-errors-and-the-manage-auditing-and-security-right.aspx

http://jasonshave.blogspot.fr/2010/04/dscenosuitablecdc-error-with-exchange.html

http://blog.mattsampson.net/index.php/exchange-hogging-dc-s-and?blog=1

Symptôme

Lors de l'installation d'Exchange 2010 sous Windows Server 2008 R2 ou Windows Server 2008 x64 SP2, le message d'erreur suivant peut apparaître :

De plus l'évènement suivant est enregistré dans le journal "Application" du serveur :

Event ID : 1002
Source : MSExchangeSetup
Task Category : Microsoft Exchange Setup
Level : Error
Error : The following error was generated when "$error.Clear(); if ($RoleStartTransportService) { start-SetupService -ServiceName MSExchangeTransport }" was run: "Service 'MSExchangeTransport' failed to start. Check the event log for possible reasons for the service start failure.".
Service 'MSExchangeTransport' failed to start. Check the event log for possible reasons for the service start failure.

Explication

Cette erreur indique que le service de transport Hub s'est bien installé mais qu'il n'arrive pas à démarrer.

Cette erreur apparaît lorsque le service IPv6 est désactivé au niveau de la carte réseau mais pas au niveau du système.

Résolution :

Pour résoudre le problème deux options sont envisageables :

• Réactiver l'IPv6
• Désactiver l'IPv6 au niveau du système en créant une clé de registre

Cette clé doit être créée avec les paramètres suivants :

• Ruche : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
• Type de clé : DWORD (32 bits)
• Nom de la clé : DisabledComponents
• Valeur de la clé : 0xffffffff hex (4294967295)

Suite à cela les services de transport Hub d'Exchange 2010 acceptent de démarrer. Cette solution est tirée de l'article 952842 de la base de connaissance Microsoft (cette KB n'est pour le moment validée que pour Exchange Server 2007).

http://support.microsoft.com/kb/952842/en-us

A quoi ressemble l’installation d’un agent SCOM sur une version Core de Windows 2008 R2?

Et bien, pas de différence au niveau de l’installation de l’agent (du moins à distance):

1) Découverte

2) Installation

La spécificité du système d’exploitation (version Core) n’est pas indiquée dans le nom du système d’exploitation détecté (Microsoft Windows Server 2008 R2 Enterprise):

mais un nouveau type d’objet permet de les distinguer:

Notons au passage qu’il en est de même pour les Windows 2008 et que les Windows 2008 R2 sont également inclus dans la catégorie Windows Server 2008 Operating System (ce qui paraît logique)

Les administrateurs SCOM le savent: la mise à jour des managements packs peut s'avérer longue et rébarbative.

Pour chaque management pack, il est en effet nécessaire:

1. de vérifier la version du management pack installée depuis la console d'administration en comparant avec la version du catalogue http://technet.microsoft.com/en-us/opsmgr/cc539535.aspx
2. télécharger le management pack (s'il existe une version plus récente)
3. installer le management pack (.msi) à l'emplacement désiré (l'emplacement par défaut variant de temps à autres)*
4. consulter la documentation
5. effectuer les éventuelles tâches pré-installation (éventuellement une désinstallation de l'ancien management pack, export des overrides...)
6. importer le management pack dans SCOM
7. finaliser l'installation du management pack (personalisation, overrides...)

La 3ème étape* est une étape relativement consommatrice en temps et peu intéressante (d'autant plus que le nombre de management pack à mettre à jour est important).
Il est en effet nécessaire de suivre les étapes de l'assistant d'installation du management pack (Emplacement cible...), et surtout, l'installation laisse des traces sur la machine (dans Ajout/Suppression de programme) qui à mon sens, n'est pas justifié. Il s'agit ni plus ni moins que d'une extraction de fichier!
Pour palier à ce problème et réduire le temps nécessaire à la mise à jour des managements packs, j'ai développé un script (batch) permettant d'extraire le contenu des .msi sans avoir à les installer.
Il suffit de mettre les .msi des managements packs téléchargés au même emplacement que le script (fourni en pièce jointe) avant de l'exécuter:

Le script va alors, pour chaque .msi présent, extraire le contenu dans un sous dossier respectif, en supprimant les éventuelles sous arborescences que pourrait créer le .msi.

On se retrouve ainsi avec un seul niveau de sous arborescence par Management Pack, contenant chacun l'essentiel:

Il ne reste ensuite plus qu'à consulter les documentations et importer les Management Pack.

Pour télécharger le script, c'est ici: extract_MP_MSI.bat (868,00 bytes)