PI Services

Contexte

Lors d’une migration d’Exchange 2007 vers Exchange 2013 CU6 (dernière version en date) certains problèmes sont rencontrés lors de la coexistence entre les deux systèmes.

Problématique

Les problèmes rencontrés sont les suivants :

• Problèmes de cohabitation sur le protocole ActiveSync
• Bascule des bases de données Exchange de façon aléatoire

Ces deux problèmes sont résolus par deux hotfix que Microsoft délivre seulement sur demande au support :

• http://support.microsoft.com/kb/2997847/en-us
• http://support.microsoft.com/kb/2997209/en-us

Cependant le passage de ces correctifs peut engendrer deux nouveaux problèmes :

• Impossibilité d’accéder à l’OWA
• Impossibilité d’écrire un mail dans OWA

Solution

Pour résoudre ces problèmes il faut se connecter sur le serveur Exchange puis identifiez les deux dossiers suivants :

• Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.31
• Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.29

Le contenu des dossiers doit être identique. Sauvegardez le contenu du dossier 15.0.995.31 puis copiez les éléments du dossier 15.0.995.29 vers le dossier 15.0.995.31.

N.B : Le CU7 d’Exchange 2013, disponible très prochainement, devrait intégrer les deux correctifs (KB2997847 et KB2997203).

Après une migration de boites aux lettres depuis une organisation Exchange 2003 vers une organisation Exchange 2007, il peut arriver que l’attribut “Recipient Type Details” ne soit pas défini en tant que “User Mailbox”

Voici différent cas rencontrés :

Legacy Mailbox

Ceci est typiquement le type de boite aux lettres créé avec les outils Exchange 2003. Ce type de boite aux lettres fonctionne sous Exchange 2007 mais afin d’éviter la perte de certaines fonctionnalités d'Exchange 2007, il est préférable de la convertir.

Pour cela, une simple commande Powershell suffit :

Linked Mailbox

Ceci indique que la boite aux lettre disposait d’un compte externe associé (autre que le compte SELF) avant la migration.

Pour résoudre le problème, il faut modifier les attributs de l’utilisateur en question (avec ADSIEdit) et modifier la valeur de l’attribut msExchRecipientTypeDetails de la valeur 2 à la valeur 1.

http://technet.microsoft.com/en-us/library/cc164371.aspx

Shared Mailbox

Ceci indique que le compte SELF est configuré en tant que compte externe associé sur la boite aux lettres.

Après la migration de la boite aux lettres, supprimer l’association du compte SELF en tant que compte externe associé. Ceci modifiera l’attribut msExchMasterAccountSid et lui donnera la valeur <Not Set>. Ensuite, lancer la commande Powershell suivante :

http://technet.microsoft.com/en-us/library/bb201749.aspx

Avec la console d’Administration d’Enterprise Vault, ou avec l’option de Reporting SQL, il est assez simple d’obtenir un état des lieux du stockage utilisé, et par Archives par exemple.

Mais qu’en est-il du ratio d’instance unique (SIS) ?

Lors des phases de définition d’architecture d’un projet d’archivage avec cette solution, certains facteurs sont pris en considération afin de dimensionner les espaces de stockage à moyen termes, et des estimations sont mises en avant, y compris concernant le ratio d’instance unique. Mais en réalité, comment visualiser cette proportion une fois en production ?

Un des outils inclus dans la solution permet entre autre cette visualisation: EVSVR

Cet outil fonctionnant en mode commande, et donc scriptable, permet pour l’instant deux types d’opérations:

• Report : génère un rapport sur le stockage
• Verify : permet une vérification de son stockage
• L’option “Repair” fera son apparition prochainement…

Dès son lancement, et suite à la demande d’aide avec la commande “?”, un certain nombre d’informations sont déjà disponible:

• Nom du compte de service
• Nom du Site EV
• Site ID
• Version

Exemple d’utilisation:

Afin d’obtenir les informations de Reporting désirées, il va falloir commencer par générer un fichier de Configuration XML permettant de spécifier les champs de recherche, avec la commande “EDIT”. Une fenêtre de paramétrage s’ouvrira :

Elle permettra notamment de spécifier :

• Le ou les espace(s) de stockage(s) désiré(s)
• Toutes les archives ou une archive spécifique
• Les facteurs temporels d’examen
• L’emplacement du fichier LOG (par défaut, il s’agit du dossier d’installation de la solution “\Reports\EVSVR”)
• L’opération désirée : Report ou Verify ainsi que ses options
• Et bien entendu le nom du fichier XML contenant tous ces paramètres

Une fois le fichier XML généré, l’opération est prête a être lancée :

• Tout d’abord exécuter la commande “LOAD” permettant de charger le fichier XML

• Puis exécuter la commande “START”, et attendre la fin de l’opération (cela peut durer plusieurs heures et il faudra alors s’armer de patience avant d’obtenir les résultats) :

N.B.: un document PDF d’utilisation de cet outil est disponible à l’adresse suivante :

• ftp://exftpp.symantec.com/pub/support/products/Exchange_Mailbox_Archiving_Unit/316525.pdf

La problématique

Suite au déploiement d'Exchange 2010 Release Candidate dans un environnement mixte Exchange 2007 / 2010, l'erreur suivante se produit dans la console Exchange Management Console (EMC) d'Exchange 2010 lorsque l'on souhaite configurer les paramètres du serveur d'accès client (CAS) :

Voici l'intitulé exact de l'erreur :

An IIS directory couldn't be created. The error message is Access is denied. HResult = -2147024891 It was running the command 'Get-OwaVirtualDirectory'.

Une fois que l'on clique sur le bouton OK, il est impossible de configurer les services Web Exchange (OWA, ECP, OAB...) car les répertoires virtuels n'apparaissent pas dans la console EMC (cf. capture d'écran ci-dessous).

Le retour de la commande PowerShell Get-OwaVirtualDirectory renvoi également une erreur (cf. capture d'écran ci-dessous).

La résolution

Pour résoudre ce problème, il ne faut pas travailler au niveau du serveur Exchange 2010 ou bien au niveau des options IIS comme on pourrait le penser à première vue mais plutôt aller vérifier le contenu du groupe administrateurs local (ou "Administrators" sur une version US) du serveur Exchange 2007 !

Si le groupe "Exchange Security Groups" n'est pas présent dans le groupe administrateurs local du serveur Exchange 2007 il sufit de l'y rajouter pour résoudre le problème !

Remarque : La modification est quasiment immédiate pour la commande PowerShell Get-OwaVirtualDirectory. Si vous utilisez la console EMC, il peut être nécessaire de la relancer afin de pouvoir lister et configurer les répertoires virtuels.

A titre informatif, le groupe Exchange Trusted Subsystem est créé lors de la phase de préparation de l'annuaire opérée lors du déploiement du SP2 d'Exchange 2007 (pour rappel le déploiement du SP2 d'Exchange 2007 est obligatoire avant de déployer Exchange 2010 dans un environnement Exchange 2007 pré-existant).

Remarque : En principe ce groupe est automatiquement placé dans le groupe "Administrateurs" local de tous les serveurs Exchange 2007 par l'installeur du SP2.

Ce groupe est un groupe universel de sécurité situé dans l'unité d'organisation Microsoft Exchange Security Groups. Il est utilisé par de nombreuses commandes PowerShell ayant besoin d'accéder à des informations situées sur des serveurs distants... comme récupérer la liste des répertoires virtuels (opération notamment effectuée par la commande Get-OwaVirtuelDirectory).

Si vous souhaitez obtenir plus d'informations, n'hésitez pas à consulter ce billet sur le Blog des développeurs Exchange :

http://msexchangeteam.com/archive/2009/08/28/452209.aspx

Le contexte :

A l'instar de son prédécesseur, Forefront Threat Management Gateway 2010 (TMG) intègre un assistant de publication pour Exchange 2007.

Cet assistant permet de publier les divers services Web intégrés à Exchange 2007 :

• Le Webmail Outlook Web Access
• Le push mail ActiveSync
• Le mode Outlook Anywhere (RPC over HTTP)
• Les services Web Outlook 2007 (OAB Web, Autodiscover...)

Cet assistant génère des règles "sécurisées" dans le sens où seuls les répertoires virtuels associés à ces services Web sont publiés (/OWA, /EWS, /Autodiscover...). Il vous est aussi possible de paramétrer une authentification au niveau du périmètre à l'aide du port d'écoute Web.

Il est possible d'augmenter encore plus le niveau de sécurité de la publication en utilisant le filtre HTTP intégré à ISA/ TMG. Cette fonctionnalité, méconnue ou du moins très peu mise en valeur au sein d'ISA/TMG, permet d'effectuer un filtrage plus fin sur les requêtes HTTP.

Fonctionnement du filtre HTTP

Le filtre HTTP permet d'agir à différents niveaux :

• Limitation de la longueur des URL, des en-têtes et du corps des requêtes HTTP
• Blocage de certaines méthodes HTTP / Webdav
• Blocage d'extensions de fichiers et de types MIME
• Blocage de certains en-têtes HTTP
• Modification à la volée de l'en-tête "Server" ou de l'en-tête "Via"
• Blocage de "signatures" (une signature correspond à une application cliente reconnue grâce au contenu de l'en-tête HTTP "User-Agent")
• Etc.

Le filtre HTTP se configure indépendamment au niveau de chaque règle d'accès ou de publication Web. Dans une règle de publication Web, il est possible de lancer l'interface de configuration via le bouton Filtering de l'onglet Traffic (cf. capture d'écran ci-dessous).

Sinon il est également possible d'effectuer un clic droit sur la règle, puis de cliquer sur Configure HTTP.

Règles de publication pour Exchange 2007

Les outils d'analyse des requêtes HTTP comme Fiddler ou HTTPWatch permettent de mettre en valeur les méthodes HTTP utilisées par chacun des services Web Exchange.

Ainsi le Webmail Outlook Web Access n'utilise que les méthodes GET et POST alors que le mode Outlook Anywhere d'Outlook 2003/2007 utilise les méthodes Webdav RPC_IN_DATA et RPC_OUT_DATA.

Pour autoriser de manière très fine les bonnes méthodes sur chacun des types d'accès Web, il suffit de créer plusieurs règles de publication Web.

Le tableau ci-dessous est un exemple dans lequel six règles sont définies (une règle par service Web). Pour chaque règle sont indiquées les méthodes HTTP et les répertoires virtuels à autoriser.

Remarque : La sécurisation de ces flux passant également par l'authentification des utilisateurs, il est également intéressant d'implémenter une authentification au niveau du serveur ISA / TMG avec une délégation des informations d'identification vers le serveur CAS.

Sauvegarde de la configuration

Attention, la configuration du filtre HTTP n'est pas sauvegardée lorsque l'on effectue un export ou une sauvegarde dans la console MMC !!!

Pour sauvegarder la configuration du filtre HTTP il faut utiliser le script HttpFilterConfig.vbs fournit dans le SDK du produit ! Ce script prend en paramètre l'action (backup ou restore) ainsi que le nom de la règle.

Cela signifie qu'il faudra exécuter le script six fois pour sauvegarder la configuration de six règles. Dans ces conditions la création d'un batch est appréciable ! (ce batch peut également sauvegarder le reste de la configuration à l'aide du script ImportExport.vbs lui aussi présent dans le SDK).

A titre informatif, les SDK d'ISA Server 2006 et de Forefront Threat Management Gateway 2010 Beta3 sont disponibles aux adresses suivantes :

• SDK ISA : http://www.microsoft.com/downloads/details.aspx?familyid=16682c4f-7645-4279-97e4-9a0c73c5162e&displaylang=en
• SDK TMG : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dff77975-84bf-484f-a3bd-9d8dd800e220#filelist

N'hésitez pas à laisser vos commentaires sur cette procédure !