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

Introduction

Cet article permet de montrer la gestion des certificats via Powershell au travers d'un problème concret rencontré sur une infrastructure Exchange. Une solution basée sur un script Powershell sera détaillée.

Erreur rencontrée

Contexte : Infrastructure Exchange 2010 avec plusieurs dizaine de milliers de contacts Active Directory importés et mis à jour par un outil tierce.

Dans l’observateur d’événements de nombreux événements 9323 apparaissent.

Ces derniers sont liés à la génération de l'OAB. Exchange détecte un utilisateur dont un certificat est expiré. Ces événements n'apparaissent que sur des objets de type "Contact"  La solution doit contrôler tous les objets Active Directory de ce type.

Solution

La soluton proposée pour purger les certificats invalides des contacts Active Directory se base sur un script Powershell V2. Ce dernier analyse l'attribut UserCertificate (il s'agit d'une liste de certificat).

Avec le type d'objet "System.Security.Cryptography.X509Certificates.X509Certificate2", il est possible d'obtenir des informations sur les certficats contenus dans cet attribut sous forme lisible (et non pas un tableau de bytes ou de valeur hexadécimal comme sur la console Active Directory Users and Computers).

Ci-dessous, un exemple de donn��es récupérées sur les certificats d'un objet Active Directory (ici, il n'y a qu'un seul certificat et la variable $User est un utilisateur Active Directory).

On remarque qu'on accède à des renseignements comme l'émetteur ou le sujet. Les informations qui nous interessent (dates de validité du certificat) sont aussi présentes. Il suffit donc de comparer la date d'expiration contenue dans l'attribut "notAfter" avec la date du jour en cours pour détecter les certificats expirés.

Grâce à la cmdlet "Set-ADObject", il sera ensuite possible de supprimer les certificats qui ne sont plus valides.

Script

En amont de ce script, un transcript est lancé afin de loguer toute les opération effectuées. Une vérification de la présence du module ActiveDirectory ainsi que son chargement sont ensuite réalisées.

Le script appelle une fonction créée pour traiter tout objet AD (ou tableau d'objets AD) qui lui est passé. Pour ma part, je transmets en paramètre tous les contacts présents dans Active Directory. Cependant cette fonction peut très bien être utilisée avec des utilisateurs. Voici l'algolrithme mis en place dans la fonction Test-CertExpiration :

Ci-dessous, vous trouverez le script intégralement commenté. A noter, que le compte exécutant ce script doit posséder les droit suffisants à la modifications des objets AD concernés (via une délégation par exemple).

$ADObjets est un tableau d'objets Active Directory.

Dans ce cas, un tableau d'objets AD est retourné. Pour chaque objet, les attributs CertExpired et CertValid sont ajoutés.

Quelques points clés du fonctionnement de la fonction Test-CertExpiration :

Les paramètres Export et DeleteExpired sont de type switch et ne peuvent apparaître ensemble. Le paramètre ExportPath est dynamique et n'est disponible que si le paramètre Export a été choisi.

Pour information, il n'est pas nécessaire de paralléliser le processus de contrôle du certificat. Après un test effectué sur plus de 90000 contacts Active Directory, il s'avère que ce dernier a duré moins de 5 minutes. Utiliser du multi thread (workflow ou job Powershell) alourdirai le script et ralentirai le processus au lieu de l'accélérer.

Symptômes

Ce type d’erreur peut se rencontrer sur un serveur multi-rôles (Client Access et Mailbox) en version Exchange Server 2013 CU1 ou Exchange Server 2013 CU2.

Les symptômes sont les suivants :

• Les services Web Exchange (OWA, Outlook Anywhere…) dysfonctionnent
• L’erreur 503 (source WAS) est présente en boucle dans le journal d’évènement Système

Voici le détail de l’erreur concernée :

Journal : System
Source: Microsoft-Windows-WAS
Event ID : 5203
Level : Error
Description: A process serving application pool 'MSExchangeRpcProxyAppPool' reported a failure trying to read configuration during startup. The process id was '27620'.  Please check the Application Event Log for further event messages logged by the worker process on the specific error.  The data field contains the error number.

Explication

Cette erreur est généralement due à la présence d’un fichier de configuration IIS corrompu.

Cela peut être mis en évidence en lançant la console d’administration IIS Manager.

Dans notre exemple, la console fait très clairement référence à un fichier de configuration nommé applicationHost.config et stocké dans le répertoire C:\Windows\System32\Inetsrv\Config.

Lorsque l’on tente d’éditer le fichier, ce dernier peut apparaitre remplis d’espace blancs ou bien ma formaté (selon les cas de figure).

Résolution

Pour résoudre ce problème il suffit de recopier le fichier sur le serveur applicationHost.config à partir d’un autre serveur Exchange en même version ou bien à partir d’une sauvegarde.

Dès le fichier copié, il devient  possible de démarrer les services IIS et les services Web sont de nouveau opérationnels.

Problématique

Lors du déploiement d’une nouvelle infrastructure Lync Server 2013 (sur un socle Windows Server 2012), le problème suivant peut apparaître sur les clients Lync :

Can’t sign in to Lync
We’re having trouble connecting to the server. If this continue, please contact your support team.

En lançant une analyse du composant SIPStack sur les serveurs front-End Lync via les outils Lync Server Diagnostic Tool et Snooper pendant la connexion d’un client, on observe l’erreur suivante :

0x80090331 SEC_E_ALGORITHM_MISMATCH

Remarque : Dans Lync Server 2013, l’outil de logging n’est plus intégré au déploiement. Pour l’installer, il faut déployer le pack d’outil Lync Server 2013 Debugging Tools disponible à l’adresse suivante : http://www.microsoft.com/en-us/download/details.aspx?id=35453

Explication

L’erreur SEC_E_ALGORITHM_MISMATCH se produit durant la phase de négociation du protocole TLS (le flux client –> serveur étant sécurisé en SIP over TLS).

Il semble que le service Lync Server Front-End ou bien le client Lync 2013 ne gère pas correctement les certificats signés numériquement en SHA512.

Résolution

Dans ce cas la résolution a consisté à déployer sur les serveurs Lync 2013 front-end un nouveau certificat signé avec les algorithmes SHA1/RSA en remplacement de l’ancien certificat signé en SHA512/RSA.

Ce comportement est assez étrange car le protocole SHA512 est intégré au système depuis Windows Vista pour les postes de travail et Windows Server 2008 pour les serveurs.

Symptôme

Suite à la mise en place de la supervision SCOM sur une plateforme Exchange 2010 SP2 RU5v2, des erreurs se produisent toutes les 5 minutes sur les serveurs jouant le rôle CAS.

Ces erreurs ont pour source MSExchange Control Panel et correspondent aux ID 4 et 38. Voici le détail de l’erreur 38 (avec en rouge les éléments intéressants) :

Du côté de IIS, une erreur 500 est déclenchée et visible dans les logs W3C.

Explication

Ces erreurs se produisent à intervalles réguliers (toutes les 5 minutes) lorsque le compte de service utilisé par SCOM (extest_<id>) tente d’exécuter la commande PowerShell Test-EcpConnectivity.

Lorsque l’on effectue des recherches sur ces erreurs ont tombe très rapidement sur une fiche support indiquant qu’il s’agit d’un bug Exchange 2010 résolu dans la mise à jour RU3v3 du SP1 d’Exchange 2010.

Unnecessary events are logged in the Application log when you run the "Test-EcpConnectivity" cmdlet in an Exchange Server 2010 environment
http://support.microsoft.com/kb/2494389/en-us

Néanmoins dans notre cas, l’environnement est déjà mis à jour en version SP2 RU5v2 ce qui rend cette solution caduque.

Après investigation il s’avère que la commande Test-EcpConnectivity ne supporte pas les URL possédant des majuscules.

La solution au problème consiste à modifier les URL internes et externes du service Web ECP (Exchange Control Panel) de manière à remplacer le /ECP par un /ecp.

Ce problème est donc totalement indépendant de la supervision SCOM qui est dans ce cas un simple révélateur du problème (car SCOM exécute régulièrement la cmdlet Test-EcpConnectivity).

Résolution

Dès la correction des URL (via la cmdlet Set-EcpVirtualDirectory), les erreurs ne se produisent plus et il est possible d’exécuter sans erreur la commande Test-EcpConnectivity.

Remarque : La correction prend effet immédiatement. Un petit délai peut être nécessaire dans certains environnements, le temps que la réplication Active Directory ait lieu. Il n’est pas nécessaire de redémarrer IIS.

Cette solution a déjà été testée avec succès sur plusieurs environnement Exchange 2010 SP2.

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

Suite à la migration d’une boîte aux lettres Exchange Server 2003 SP2 vers un DAG Exchange 2010 SP1 RU6 (en environnement intra-organisationnel),  l’utilisateur ne peut plus synchroniser ses emails via ActiveSync et l’erreur suivante se produit régulièrement dans le journal Application du serveur CAS :

Voici le détail de l’erreur rencontrée :

De plus l’utilisateur ne peut pas voir son téléphone lorsqu’il accède à l’interface ECP (Exchange Control Panel) dans le menu Phone, puis Mobile Phone.

Explication

Avec Exchange Server 2003 les partenariats ActiveSync sont stockés dans un dossier caché au sein de la boîte aux lettres de l’utilisateur.

Ce dossier se nomme Microsoft-Server-ActiveSync et est visualisable à l’aide d’un outil tel que MFCMAPI (http://mfcmapi.codeplex.com/).

Avec Exchange Server 2010 les partenariats ActiveSync sont stockés directement dans l’annuaire Active Directory sous la forme d’un objet de type msexchangeActiveSyncDevice.

Lors de la migration de la boîte aux lettres vers Exchange Server 2010 le serveur Exchange possédant le rôle CAS doit donc créer un conteneur nommé CN=ExchangeActiveSyncDevices dans le compte utilisateur. Le serveur CAS créé ensuite un objet de type msexchangeActiveSyncDevice dans ce conteneur pour chaque partenariat ActiveSync établit.

Voici un exemple d’objet msexchangeActiveSyncDevice généré dans un environnement Exchange Server 2010 :

Dans notre exemple l’héritage des autorisations étaient désactivé sur le compte utilisateur. Cela a empêché la descente des ACL nécessaires au bon fonctionnement d’Exchange et donc a provoqué le message d’erreur 1053 Access is Denied sur le serveur CAS.

Cette désactivation était engendrée dans notre cas à cause de l’appartenance du compte utilisateur au groupe “Server Operators” qui est l’un des groupes protégé par le mécanisme AdminSDHolder.

Pour mémoire ce mécanisme a pour but de contrôler les ACL appliquées sur les objets (comptes utilisateurs, comptes ordinateurs…) membres des groupes protégés.

La liste des groupes protégés par le mécanisme AdminSDHolder dans les différentes versions de Windows (de Windows 2000 Server à Windows Server 2008 R2) est disponible sur le site de Microsoft à l’adresse suivante :

http://technet.microsoft.com/en-us/query/ee361593

Remarque : Dans notre cas le téléphone touché était un Sony Ericsson sous Symbian avec l’application RoadSync. Cependant ce problème étant dû à une configuration au niveau du compte Active Directory tout autre téléphone pourrait en être victime.

Résolution

Pour résoudre ce problème il faut se connecter à l’ADUC (Console “Utilisateurs et ordinateurs Active Directory”), puis dans les propriétés de l’utilisateur concerné choisir “Security”, “Advanced” puis cocher la case “Include inheritable permissions from this object’s parent”.

Suite à cette manipulation la synchronisation “initiale” (comprendre celle engendrant la génération des objets dans l’annuaire Active Directory) du téléphone fonctionnera ainsi que toutes les synchronisations ultérieures.

Une fois la première synchronisation effectuée l’utilisateur pourra visualiser et gérer ses partenariats ActiveSync dans l’interface ECP (la capture d’écran ci-dessous est un exemple).

Remarque : Il est intéressant de noter que le mécanisme AdminSDHolder remodifiera automatiquement les ACL (et donc re-désactivera l’héritage des autorisations) dans un délai d’une heure maximum (en effet le processus s’exécute toutes les 60 minutes par défaut).

La problématique

J’ai récemment rencontré la problématique suivante sur un serveur TMG 2010 SP2 : suite à des problèmes matériels (plantages répétés du serveur) le service pare-feu refuse de démarrer.

La base de données AD LDS étant toujours accessible, il est toujours possible de se connecter à la console TMG et donc je réalise un export de la configuration de la ferme de serveurs.

Le dépannage du problème de démarrage sur le service TMG semblant complexe à résoudre décision est prise de désinstaller TMG, puis de le réinstaller et enfin d’importer la configuration précédemment sauvegardée au format XML.

Lors de l’import de la configuration sur le serveur fraichement réinstallé, l’erreur suivante s’est produite dans l’assistant d’importation de TMG :

Import Failed

The value specified for the parameter Scope is not valid for standalone mode.

Résolution apportée

La solution apportée n’est pas une solution très académique est plutôt à classer dans la catégorie des contournements :

Pour résoudre l’ensemble des balises Scope ont été supprimées manuellement dans le fichier de configuration à l’aide d’un éditeur de fichier XML (ici Notepad++).

La balise complète a été supprimée à chaque fois.

Suite à cette modification l’importation s’est terminée correctement et l’ensemble des services et des règles ont pu repartir en production.

Ce problème étant très spécifique je suppose que l’erreur rencontrée était due à la présence d’un reliquat de configuration ISA Server 2006 dans le fichier XML précédemment exporté.