Translate

mardi 26 avril 2011

[INFO]: Où l'on reparle d'Exchange 2010 SP1 et du Kerberos...

Il y a quelques mois, le 15 juillet 2010 précisément (pfuiiiii que le temps passe vite!), j'avais publié un tutoriel sur ~ Comment activer le protocole Kerberos avec Exchange 2010 SP1 ~

Depuis, la DevTeam Exchange a officialisé la recommendation d'activer Kerberos dans le SP1 et la documentation Technet mise à jour en ce sens.

Mais avant de vous précipiter sur vos claviers et souris pour créer le compte utilisateur ou d'ordinateur requis pour la configuration du AlternateServiceAccount (ASA) sur vos serveurs d'accès client, sachez qu'il existe encore quelques ratés, même dans Exchange Server 2010 SP1... 

Prérequis 

Cher lecteur, l'hypothèse est prise que vous êtes familiers avec la mise en œuvre du Kerberos pour Exchange Server 2010 SP1, avec la définition d'un Client Access Array et avec les commandes Set-xxxVirtualDirectory, qui permettent de définir la propriété InternalURL des services Web. 

Le problème 

Le fait est que pour que l'authentification Kerberos fonctionne, les services Exchange s'exécutent dans le contexte particulier du service MSExchangeServiceHost. C'est ce service qui utilise le fameux AlternateServiceAccount configuré à l'aide de la commande Set-ClientAccessServer et qui permet par conséquent d'utiliser un ou plusieurs noms génériques et/ou associés à une ou plusieurs adresses IP (répartiteur de charge).
Dès lors, lorsque la configuration est effectuée et que les servicePincipalNames sont définis, les accès aux services suivants sont "négociables" en Kerberos:
  • Accès via le protocole MAPI sur Rpc (RpcClientAccess) via le Fqdn du Client Access Array
  • Accès aux service de carnet d'adresses (AddressBook) via le Fqdn du Client Access Array
  • Accès aux services Web (via IIS) via le (ou les) Fqdn des services Web tels que définis dans les propriétés InternalURL des différents WebServices.
Comme je le disais précédemment, tous ces services s'exécutent dans le contexte du MSExchangeServiceHost, tous sauf un. 

Le gagnant est... 

Le service d'Offline Address Book (OAB), qui est part définition un simple répertoire virtuel dans IIS. En effet, lorsque l'on configure l'OAB derrière un répartiteur de charge, un client Outlook 2007 ou 2010 va se connecter à l'URL http(s)://fqdn.domaine.local/OAB/GUID/oab.xml. Or ce fichier n'est accessible qu'aux utilisateurs authentifiés, et dès lors, une négociation est effectuée lors de l'accès à l'URL.

Et alors... ? Le fait est que pour que l'authentification intégrée fonctionne, l'URL http(s)://fqdn.domaine.local est ajoutée dans la zone "Intranet" d'Internet Explorer. Dès lors, l'authentification Kerberos est tentée entre le client et le serveur. Étant donné que le répertoire /OAB est juste un répertoire virtuel comme un autre, c'est le serveur, via le service IIS, qui négocie et valide la requête de service HTTP lors d'un téléchargement de l'OAB... et bien sûr celle-ci échoue puisque le Fqdn présent dans l'InternalURL dans la configuration de l'OAB Virtual Directory (fourni aux clients par l'Autodiscover) n'est pas utilisable. 

Résultat: des popups d'authentification apparaissent sur les postes clients ! Sachez qu’apparemment, cela dépend de la version du système d’exploitation et d'Outlook. Typiquement, des clients WinXP/Outlook 2007 "se plaignent moins" et échouent plus silencieusement (ou réussissent parfois à utiliser les Dossiers Publics, lorsque disponibles), tandis que des clients Win7/Outlook 2010 génèrent des popups systématiquement lors du téléchargement de l'OAB (reproductible). 

La solution 

Il en existe plusieurs:
  1. Configurer les OAB Virtual Directories (via Set-OabVirtualDirectory) afin de ne pas utiliser le Fqdn du répartiteur de charge. Loin d'être idéal et souhaité, mais fonctionne. Si HTTPS est utilisé pour l'OAB, complexifie un peu la gestion des certificats.
  2. Ne plus utiliser Kerberos (pas vraiment une solution :/ mais si la configuration Kerberos vous semble insurmontable, ne "tentez" pas!)
  3. Solution officieuse (pour l'instant), voir ci-dessous :)
La solution "officieuse" est de convertir le répertoire /OAB en Application Web. Il est recommandé de créer un nouvel Application Pool similaire à celui utilisé pour les Exchange Web Services par exemple.

Une communication officielle sera faite par Ross Smith IV bientôt, et la documentation Technet mise à jour en ce sens. Le tout sera accompagné d'un petit script.

[EDIT]: Ceci a été officialisé dans la nuit par Ross, sur le blog de la DevTeam.

 

mercredi 9 mars 2011

[INFO]: Exchange Server 2010 SP1 Update Rollup #3 disponible

Microsoft vient de publier le Rollup #3 d'Exchange Server 2010 SP1. Outre la correction de quelques bugs et les mises à jour fonctionnelles introduites dans le rollup #2 (cf mon article précédent sur le sujet), ce rollup réactive les notifications UDP à destination des clients Outlook 2003 en mode en-ligne (comprendre: qui ne sont pas en mode cache). Non pas que je sois fan des notifications UDP, mais il faut bien avouer que, malheureusement, beaucoup de sociétés utilisent encore Outlook 2003 dans ce mode (en particulier sur de vieilles fermes Citrix/TSE...).
Pour activer les notifications UDP, il faut installer le Rollup #3 et ajouter une valeur de registre sur vos serveurs d'accès client:
  • Clef: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
  • Nom: EnablePushNotifications
  • Type: REG_DWORD
  • Valeur: 1
En parallèle, et toujours dans la même logique de sortie de mises à jour trimestrielle, le Rollup #3 d'Exchange Server 2007 SP3 est aussi disponible au téléchargement.
Comme à l'accoutumée, je vous souhaite de bonnes mises à jour :)

    vendredi 18 février 2011

    [INFO]: Lync Server 2010 Best Practices Analyzer (BPA)

    Microsoft vient de publier la première version officielle/RTM de l'outil BPA pour Lync Server 2010. Si vous ne connaissez pas déjà les outils "BPA" (Best Practice esAnalayzer), il s'agit d'outils fournis par Microsoft effectuant une analyse plus ou moins poussée de votre environnement et le compare à des règles pré-définies de meilleurs pratiques afin de générer un rapport.

    Il est recommandé d'exécuter cet outil après tout déploiement, puis régulièrement (et éventuellement de manière automatisée) afin de détecter tout changement pouvant mettre en danger la stabilité de la solution. Toutefois, n'oubliez pas que le BPA n'est qu'un outil et qu'il arrive parfois qu'il ne soit pas "intelligent" :). Il appartient à vos experts de jauger la criticité d'une alerte et d'effectuer une analyse complémentaire en cas de doute...

    Téléchargement: http://go.microsoft.com/fwlink/?LinkID=211230 

    Documentation

    Bons déploiements !!!

    mardi 8 février 2011

    [INFO]: Lync Server 2010 Planning Tool

    Wooooooooot!

    Microsoft vient de publier la version RTM de Lync Server 2010 Planning Tool (version 7577.115). Cet outil permet de plannifier la mise en oeuvre de Lync Server 2010 et ressemble fortement à son précédesseur pour OCS 2007 R2 :) ... sauf qu'il permet bien sûr d'exporter la topologie gérée pour import dans le Topology Builder.

    Liens:
    Bon téléchargement!

    jeudi 27 janvier 2011

    [INFO]: Exchange Server 2010 SP1 Rollup 2 et la redondance des Dossiers Publics

    Le Cumulative Rollup 2 d'Exchange Server 2010 SP1 est disponible depuis le 31 décembre 2010. Mais saviez-vous qu'outre la correction usuelle de petits bugs, celui-ci apporte une nouveauté non négligeable concernant la redondance d'accès aux Dossiers Publics ?

    En effet, comme vous le savez probablement, Exchange 2010 apporte des options de haute disponibilité très avancées, mais au regard des Dossiers Publics, cela a toujours été un problème. En effet, il n'était pas possible dans Exchange 2010 de bénéficier d'une haute disponibilité native et dès lors qu'un serveur hébergeant des Dossiers Publics était hors service ou devait être mis hors-ligne pour une raison ou une autre, les clients perdaient l'accès (ce qui, outre les Dossiers Publics "normaux", impactait le téléchargement de l'OAB, les Free/Busy, etc.). En fonction de la situation et de la durée de l'arrêt de service, il pouvait donc être nécessaire de reconfigurer les Bases de Données de Boite aux Lettres afin de les faire pointer sur une autre Base de Données de Dossiers Publics.

    Avec le Rollup 2 d'Exchange 2010 SP1, l'équipe produit a réactiver une vieille fonctionnalité qui était présente dans MAPI depuis très longtemps (depuis les temps d'Exchange 5.0 je crois), mais qu'Exchange 2010 ne supportait plus. En gros, ce mécanisme est utilisé ici afin de permettre à un client de se connecter à une autre Base de Données de Dossiers Publics, si toutefois il en existe 1) une de disponible et 2) que celle-ci est correctement répliquée. La bascule prend toutefois un peu de temps puisqu'il faut attendre le délais d'attente maximum de connexion (timeout) avant d'être redirigé. Le plus beau, c'est qu'il n'y a aucune mis à jour à effectuer sur les clients. L'article lié au Rollup 2 et qui décrit le problème et sa résolution est accessible ici.

    Une petite vidéo d'un client essayant de se connecter à un serveur hors-ligne puis basculant sur un serveur qui est en ligne:


    Une excellente raison donc de mettre à jour vos serveurs!

    vendredi 21 janvier 2011

    [INFO]: Premier fix Cumulatif pour Lync 2010

    C'est parti! Microsoft vient de publier un premier fix cumulatif (CU) pour le Lync 2010. Les articles de la base de connaissance Microsoft ne sont pas encore très à jour et seront complétés au fur et à mesure.
    Liens de téléchargement:

    Bonnes mises à jour !