Vous avez dit "Unifiées" ?

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

2011-04-26T22:11:00.001+02:00

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:

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.
Ne plus utiliser Kerberos (pas vraiment une solution :/ mais si la configuration Kerberos vous semble insurmontable, ne "tentez" pas!)
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.

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

2011-03-09T00:17:00.001+01:00

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 :)

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

2011-02-18T07:40:00.001+01:00

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

Technet: http://technet.microsoft.com/en-us/library/gg558584.aspx
Blog NextHop: http://blogs.technet.com/b/nexthop/archive/2011/02/17/best-practices-analyzer-for-lync-server-2010-now-available.aspx

Bons déploiements !!!

[INFO]: Lync Server 2010 Planning Tool

2011-02-08T18:37:00.000+01:00

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!

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

2011-01-27T13:23:00.004+01:00

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!

[INFO]: Premier fix Cumulatif pour Lync 2010

2011-01-21T10:23:00.002+01:00

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.

Côté clients: Ce fix contient un certain nombre de résolution de bugs techniques mineurs, mais aussi beaucoup de corrections de petits bugs "fonctionnels".

Lync 2010 Client: http://support.microsoft.com/kb/2467763
Lync 2010 Attendant: http://support.microsoft.com/?kbid=2467760
Lync 2010 Attendee: http://support.microsoft.com/?kbid=2467762
Lync 2010 Group Chat client: http://support.microsoft.com/?kbid=2467765

Côté serveurs: Un bug existait dans les composants Web Conferencing qui obligeait les administrateurs à redémarrer certains services périodiquement. Ce CU corrige d'autres petits bugs, en particliuer un bug d'interopérabilité du Desktop Sharing avec OCS 2007 R2.

Lync 2010 Server: http://support.microsoft.com/?kbid=2493736

Liens de téléchargement:

Lync 2010, 32-bit: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f27546af-c390-4ee8-a55e-fd56848c2394&displaylang=en
Lync 2010, 64-bit: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0fd94d10-fe84-4c84-a387-91afe24fb5b8&displaylang=en
Attendant Console: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e96bd908-87bb-4d8a-a2e4-f9f47cea045d
Attendee, Admin Install : http://www.microsoft.com/downloads/en/details.aspx?FamilyID=084db99c-7bd7-4f4e-803b-85f24a3b5884
Attendee, User Install: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ef3101fa-f4ac-4a96-9aae-dfc5c6d0934d
Lync Group Chat client: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=843d773b-5734-4843-ac8c-763712e7ff9e
Lync Server 2010 CU1 (individuels): http://www.microsoft.com/downloads/en/details.aspx?FamilyID=796480cd-daf4-4463-b418-7391cc46a5e1

Bonnes mises à jour !

[INFO]: Terminaison SSL avec Exchange 2010 SP1 et bug avec le Web Service UM pour clients Outlook 2007

2010-12-27T23:40:00.000+01:00

Cela faisait longtemps que je n'avais pas posté un petit article. En cette trève de Noël, me voici donc avec un peu de temps libre afin de partager un problème recontré avec le Web Service permettant un client Outlook 2007 d'accéder aux options de Messagerie Unifiée.

Avant d'entrer dans l'explication du bug, je vais défendre la cause de la terminaison SSL sur un répartiteur de charge, et de "pourquoi cela est-ce une bonne idée" :)

Lorsque l'on met Exchange Server 2010 en production, il est pour ainsi dire presque obligatoire d'utiliser un répartiteur de charge externe (autrement dit, un load-balancer aussi appelé HLB pour "Hardware Load-Balancer" bien qu'en définitive, il s'agisse de logiciels :)). Ceci pour deux raisons:

Performance: afin de s'assurer que l'on peut répartir les accès clients de manière équitable entre les Serveurs d'Accès Client (Client Access Server, ou CAS);
Haute-disponibilité: un autre aspect important est de permettre aux clients - ou applications faisant usage de la messagerie - de basculer de manière plus ou moins transparente d'un serveur à l'autre si celui qu'ils utilisaient venait à tomber en panne, ou même devait être placé sous maintenance (ex: application d'un Service Pack ou autre opération un peu longue)

Bref, lorsque l'on met une application en balance de charge, on se pose la question de savoir comment...

En effet, lorsque vient la question d'un Serveur d'Accès Client (CAS) avec Exchange 2010, il faut effectuer la répartition de charge à minima au niveau 4 (TCP) et au mieux au niveau 7 (Application, autrement dit pour Exchange, l'HTTP).

Voici une liste résumant les modes de répartition de charge pour Exchange 2010:

Mapi/Rpc: couche 4 (tcp)
POP/POPS:couche 4 (tcp)
IMAP/IMAPS: couche 4 (tcp)
HTTP/HTTPS: couche 4 (tcp) ou couche 7 (http)

Ce qui nous interesse ici, c'est la balance de charge au niveau HTTP: elle concerne tous les Web Services d'Exchange, qu'il s'agisse d'Outlook Web App (OWA) et de l'Echange Control Panel (ECP), d'Exchange ActiveSync (EAS), de l'Autodiscover (ADS), de l'OAB, du RPC/HTTP, et bien sûr des Web Services "utilitaires" regroupés dans ce que l'on appelle "EWS" (Exchange Web Services).

Lorsque l'on décide de faire de la balance de charge HTTP se pose souvent la question de la terminaison SSL, c'est à dire, qui prend en charge l'encryption des flux transitant entre les clients et les serveurs. Par défaut, celle-ci s'effectue au niveau des serveurs. Historiquement, on utilisait des matériels dédiés afin de décharger les serveurs des calculs nécessaires à l'encryption des données. De nos jours les serveurs sont des milliers de fois plus performants et la question légitime est "ai-je vraiment besoin de terminer le SSL pour réduire la charge sur mes serveurs ?" - la réponse est bien évidemment non pour 99.99% des cas.

Cependant, avec les répartiteurs de charge l'interêt du déchargement SSL est ailleurs: en effet, lorsque l'on fait du déchargement SSL au niveau 7, il est possible d'interpréter les flux entre les clients et les serveurs au niveau du répartiteur de charge (qui agit donc comme un proxy inversé (reverse proxy) et cela donne la liberté d'introduire une "intelligence" sur la façon de gérer la balance de charge et la persistance d'une connexion cliente à destination de tel ou tel serveur).

A titre d'exemple, imaginez une balance de charge HTTP effectuée au niveau 4: la seule persistance possible ici est par adresse IP source... ce qui est bien dans la plupart des cas, mais largement insuffisant voire problématique dans certains autres: lorsque des clients arrivent par un mécanisme réseau ne présentant qu'une seule adresse IP (NAT, reverse proxy entres autres), ils sont systématiquement tous redirigés vers le même serveur cible. Imaginez que 10,000 clients traversent ce NAT ou Reverse Proxy (imaginez par exemple 10,000 teminaux ActiveSync passant par un serveur ForeFront TMG), cela génère une répartition de charge complètement inéquitable et totalement indépendante de l'application Web utilisée.

La bonne idée est donc de terminer le flux au niveau du répartiteur de charge, et donc de vraiment se positionner au niveau 7. Il existe alors plusieurs modes de persistance communs utilisables:

Adresse IP source (similaire à la persistance de niveau 4)
Cookie applicatif (fourni par le serveur)
Cookie inséré par le répartiteur de charge
SSL ID
En-tête HTTP (au choix)
Selon le répartiteur, des algorithmes avancés, voire "programmables" (tels que les iRules chez F5)

A mon sens, effectuer la terminaison SSL au niveau du répartiteur de charge est quelque chose de nécessaire et permet de choisir pour Exchange (entre autres) le bon mode de persistence en fonction du service utilisé (ex: cookies pour OWA/ECP, en-tête "Authorization" pour ActiveSync, etc). Outre ces aspects, cela permet surtout de garantir une équité sur la répartition de charge, quelque soit le mode d'accès utilisé (interne, via NAT, via Reverse Proxy, via Proxy interne, etc).

Comment activer la terminaison SSL avec Exchange 2010 ?

Je ne vais pas rentrer dans les détails, surtout que cela varie entre Exchange 2010 RTM et Exchange 2010 SP1. Je vais simplement m'attarder sur E2010 SP1, car il s'agit de la version actuelle (que vous devriez donc installer en production :)) et surtout la plus facile à configurer pour la terminaison SSL. Aussi je serai bref dans la façon de procéder:

Pour OWA/ECP: il faut positioner une clef de registre particulière sur chaque CAS: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA ==> SSLOffloaded (REG_DWORD) à 1 (0x00000001) - il faut aussi configurer les répertoires virtuels comme expliqué ci-dessous pour les Web Services
Pour Outlook Anywhere (RPC/HTTP): utiliser -SSLOffloaded:$true sur les Cmdlet Enable-OutlookAnywhere ou Set-OutlookAnywhere afin d'activer la terminaison SSL externe; à faire bien sûr pour chaque CAS où le Rpc/Http sera activé;
Pour les Web Services en général: toujours sur chaque CAS, aller dans la console IIS et configurer leur répertoire en décochant "Require SSL" dans les propriétés SSL du répertoire (/owa, /ecp, /ews, /microsoft-server-activesync, /autodiscover, /oab, /rpc) -- ne pas le faire sur /rpcwithcert

Il va de soit qu'au niveau de la configuration des répertoires virtuels, vous devez tout de même spécifier des URL faisant référence au protocole HTTPS (ex: https://monnomvirtuel.domaine.local/Autodiscover/Autodiscover.xml pour l'accès au Web Service Autodiscover).

Comme d'habitude, toutes ces opérations sont "scriptable" facilement en PowerShell... ;)
Pour plus de détails, je vous invite à lire un bon article de Henrik Walther ici (en anglais). Cependant il ne parle pas du problème qui nous interesse ici.

Revenons à nos moutons, et parlons du Web Service Messagerie Unifiée pour clients Oulook 2007

Ceux qui ont utilisé (ou testé) la Messagerie Unifiée avec Exchange Server 2007 se rappelleront sûrement qu'il existait un répertoire virtuel particulier contenant un Web Service déstiné à servir les clients Outlook 2007. Tout bêtement, ce Web Service permettait à un client Outlook 2007 (dès lors que le compte utilisateur était "UM-enabled") d'accéder à quelques fonctionnalités et informations de Messagerie Unifiée via le menu Outils ==> Options et l'onglet "Messagerie Unifiée".

Dans Exchange 2010, ce Web Service a été conservé mais n'est plus utilisé par les clients Outlook 2010, il a donc été restructuré et déplacé d'un répertoire dédié (/UnifiedMessaging) au même endroit que les autres Web Services "utilitaires" (/EWS) et s'appelle désormais "UM2007Legacy.asmx".

Mais quel est donc le problème ?

Lorsque l'on fait de la terminaison SSL au niveau du répartiteur de charge, on effectue donc un accès HTTP au Web Service, et non plus SSL. Si cela fonctionne avec tous les Web Services (dès lors que la configuration des serveurs est faite correctement), je me suis rendu compte que cela n'était pas le cas avec le Web Service UM2007Legacy destiné aux clients Outlook 2007... Lorsque j'ai effectué mes tests avec un client Outlook 2007, je me suis rendu compte que l'accès au Web Service ne fonctionnait pas. J'ai eu beau chercher et tenter de trouver une faille dans ma configuration, il s'est avéré que le code erreur ne correspondait pas (le serveur me retournait un "404 Not found" au lieu de tout au code erreur frôlant une logique de mauvaise configuration). C'est après quelques minutes de déboggage intensif que je me suis rendu compte que l'erreur ne venait pas de moi, mais bel et bien d'un "oubli" dans Exchange 2010 SP1...

La raison est simple: depuis Exchange 2010 SP1, les Web Services ont légèrement été modifiés afin d'accepter des access HTTP _et_ HTTPS, indépendament de la manière dont leur répertoire virtuel IIS est configuré. Cela est définit dans les fichiers "Web.config" présents dans les répertoires virtuels des Web Services Exchange. Le plus drôle est que cela n'affecte que Exchange 2010 SP1, pas la RTM puisque dans la RTM, tout était HTTP ou HTTPS, mais pas les deux.

Prenons par exemple les Web Services dans /EWS, donc définis dans $exinstall\ClientAccess\exchweb\EWS\Web.config:

Au travers de ces quelques balises XML, nous pouvons voir que le service Microsoft.Exchange.Services.Wcf.EWSService définit plusieurs terminaisons ("endpoints"), dont deux en HTTPS et deux en HTTP. Il suffit donc de regarder comment sont définis les mécanismes d'écoute (bindings) de ces terminaisons et nous trouvons donc ceci (capture d'image tronquée pour une meilleure lisibilité):

En résumé, cela signifie que le Web Service mentionné plus haut accepte le protocole HTTPS et le protocole HTTP, définis respectivement par les balises httpTransport et httpTransport dans deux noeuds XML différents (donc avec des noms différents).

Lorsque l'on s'intéresse maintenant au service Web UM pour clients Outlook 2007, on trouve ceci:

et ceci:

Il n'y a donc aucune terminaison sur le protocole HTTP de prévue !!! Il s'agit clairement d'un oubli du SP1, qui applique un nouveau fichier Web.Config sur tous les Web Services (cela ne concerne que le Web.Config du répertoire EWS).

Comment corriger cet oubli ?

C'est assez simple. Il suffit d'ajouter un "endpoint" et un "binding" pour le Web Service en question. Pour ceci, utiliser un éditeur de type Notepad, Notepad++ ou tout autre de votre choix afin d'effectuer les modifications suivantes (pensez à effectuer une sauvegarde de votre fichier Web.config auparavant):

Editez le fichier Web.Config ($exinstall\ClientAccess\exchweb\EWS\Web.Config)
Localisez la balise "service" correspondant au Web Service "Microsoft.Exchange.UM.ClientAccess.UMWebService"
Ajoutez un "endpoint" faisant référence à un "binding" en Http (personnellement, j'ai utilisé "UMLegacyHttpBinding") et copié depuis le "UMLegacyHttpsBinding"
Aller dans le noeud "customBinding" et ajoutez un "binding" nommé "UMLegacyHttpBinding" recopié à partir de "UMLegacyHttpsBinding", copiez-le puis remplacez la balise "httpsTransport" en "httpTransport"
Enregistrez le fichier et redémarrez IIS (IISreset /noforce) ou recyclez l'application "MSExchangeServicesAppPool"
Réitérez l'opérations sur tous les CAS

Voici ce que cela doit donner pour la définition du Web Service:

Et dans la définition des bindings:

Voilà, ceci clos mon premier article depuis quelque temps... :p

Il ne me reste plus qu'à vous souhaitez de joyeuses fêtes de fin d'année !!! Et de vous dire à l'année prochaine peut-être pour de nouvelles aventures (si j'ai un peu plus de temps libre pour blogger ;))

INFO: La mise à jour OCS 2007 R2 Cumulative Update 6 est à nouveau disponible

2010-09-25T10:00:00.000+02:00

Dans un article précédent, je vous notifiais que la mise à jour cumulative #6 d'Office Communications Server 2007 R2 avait été retirée du centre de téléchargement Microsoft.

Hier, l'équipe produit a republié cette mise à jour, toujours numérotée CU6 mais de Semptembre 2010.

Article: http://support.microsoft.com/kb/968802
Lien de téléchargements: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=b3b02475-150c-41fa-844a-c10a517040f4

Bonne mises à jour !

INFO: Microsoft a retiré l'Update Rollup 6 d'OCS 2007 R2 des espaces de téléchargement

2010-09-07T21:27:00.002+02:00

MISE A JOUR: le CU#6 a été republié, merci de consulter l'article du 25 Septembre 2010.

------------------------------------------------

Suite à un problème découvert lié au Rollup 6 (Juillet 2010) dans le Response Group Service, Microsoft a décidé de retirer cette mise à jour du site de téléchargement.

Le problème survient lorsqu'un nouveau contact est créé dans la configuration du Response Group. Quelque soit le type de Pool (Standard ou Enterprise), il est nécessaire de redémarrer les services liés afin que les modifications soient prises en compte.

Une mise à jour visant à corriger le problème sera mise en ligne avant fin Septembre 2010, et portera logiquement le numero 7.

Pour de plus amples informations, veuillez consulter l'article officiel de la base de connaissances du Support Microsoft: http://support.microsoft.com/?kbid=2401878

Si vous utilisez le Response Group Service et que vous aviez déjà téléchargé le CU#6 et prévoyiez de l'installer, il est fortement recommandé de patienter quelques semaines... Si vous n'utilisez pas le Response Group Service, il n'y a à priori aucun point bloquant à déployer le CU#6.

[INFO]: Exchange Server 2010 SP1 est RTM...

2010-08-25T18:53:00.001+02:00

...et disponible au téléchargement =°)

http://www.microsoft.com/downloads/details.aspx?FamilyID=50b32685-4356-49cc-8b37-d9c9d4ea3f5b&displaylang=en

Bon download ;) !!!

FIX: Forefront TMG 2010 et Windows Server 2008 R2 = Lenteur abominable et plantage au Boot

2010-07-17T02:50:00.002+02:00

Dans mes pérégrinations nocturnes, me voilà que me prend l'envie migrer mon ISA 2006 SP1 vers Forefront TMG 2010 (SP1 aussi). Comme a mon habitude avec les dernières générations de produits Microsoft, je prépare ma VM en Windows Server 2008 R2 (image sysprep).

Ta-da, l'exporte toute ma configuration ISA 2006 SP1 ainsi que la dizaine de certificats puis je l'éteins, pensant l'envoyer sans peine à la retraite !

Et bien, ce fut douloureux ! Outre l'installation de Forefront TMG 2010 qui a échoué m'expliquant gentillemment qu'ADAM n'a pu être installé alors qu'il venait de le faire 2 minutes avant :P), mon plus gros problème se retrouva dans l'incapacité de mon serveur TMG à rebooter sans pêter un câble.

Pour le 1er problème (ADAM), rien de bien dramatique. Il suffit de préparer les pré-requis (composants Windows installés par le Wizard d'installation TMG) puis de redémarrer le serveur. Après redémarrage, TMG s'installe sans soucis.

Le 2nd problème est plus délicat. Le serveur met plus de 16 minutes à démarrer (à atteindre donc le "Press Ctrl+Alt+Suppr to logon" :)) et encore, il démarre mais les 3/4 des services Forefront TMG sont plantés, prétextant qu'ils n'ont pu démarrer dans les délais impartis (non, sans blague... :)).

Bref, après moultes recherches, je me suis rendu compte que Ô Miracle, mon cas n'étais pas isolé. La plupart des gens ayant tenté divers installations de Forefront TMG ont recontré des problèmes similaires avec Windows Server 2008 R2 seulement. De plus, la plupart d'entre eux utilisent TMG + ForeFront for Exchange + Exchange 2010 Edge Transport sur la même machine, ce qui est supporté mais littéralement (dans mon petit esprit puriste) du suicide.

Bien que mon cas ne soit pas aussi dramatique que le leur, j'ai tenté diverses solutions en me basant sur les périgrinations d'autres malheureux qui, comme moi, pensaient que TMG 2010 n'était plus en BETA (cf blog ici: http://projectdream.org/wordpress/2010/04/27/tmg-2010-seems-to-be-still-in-beta/)

La solution qui a fonctionné dans mon lab consiste à modifier les dépendances sur les services HTTP (driver système) et ISACTRL (Forefront TM Control Service), ainsi que de passer ce dernier en "Automatic (Delayed)".

Une fois ces modifications effectuées, le démarrage du serveur montre en main (jusqu'à la mire de connexion) est inférieur à 3 minutes mais surtout tous les services Forefront TMG ont pu démarrer (ce qui n'est pas du luxe!!!).

Voici donc un petit script pour configurer les services:

fixTMG.cmd
@echo off

sc config HTTP depend= CRYPTSVC
sc config isactrl depend= RasMan/SSTPSVC/FwEng/ISASTG/bfe/mpssvc/HTTP
sc config isactrl start= delayed-auto

Le plus drôle (ou pas...) dans l'histoire est que Forefront TMG 2010 en est déjà à son Service Pack 1. Malgré cela, et malgré une interface correcte, le produit n'a toujours pas l'air fini.

Aller, histoire de rigoler, admirez la typo lorsque vous effectuer un Click-Droit sur la racine de la console puis "Finalize Enterprise".

En plus de ne servir à rien (?) si ce n'est faire "OK" (on aime le risque :)) - personne dans l'équipe de test/beta/RTM n'a remarqué cette faute de frappe grotesque... Honte à vous messieurs/dames de la DevTeam Forefront TMG !!!

Vive ISA 2006 SP1 !!!!! (et ses hotfixes salvateurs)

(et malgré ses défauts liés à son architecture vieillissante :P)

Je vais tout de même conserver TMG, histoire de 1) ne pas avoir galèré pour rien et 2) afin de voir ce qu'il a dans le ventre.

TUTORIEL: Exchange 2010 SP1 (Beta) - Activer Keberos pour un pool de serveurs CAS (Client Access Array)

2010-07-15T23:23:00.012+02:00

Si vous avez implémenté Exchange Server 2010 en production avec un pool de serveurs d'Accès Client (CAS) mis en haute-disponibilité derrière un mécanisme de répartition de charge (HLB ou NLB), vous avez peut-être remarqué que l'accès à votre pool de CAS au travers du MAPI/RPC ou aux Web Services ne s'effectuait pas en Kerberos (pour observer cela, il suffit d'utiliser KerbTray, petit outil disponible dans le Resource Kit Windows Server 2003).

En effet, lorsque vous mettez des serveurs CAS en tolérance, vous créez un Client Access Arrary (CASArray). Ce CASArray devient le point de connexion de vos clients, et un nom d'hôte complet (FQDN) associé. Lorsque Outlook démarre, il ne se connecte donc pas sur le FQDN d'un CAS mais du CASArray (par exemple: CASArray.domaine.local), ce qui a pour effet de tenter de récupérer un jeton Kerberos pour les services suivants:

exchangeMDB/CASArray.domaine.local
exchangeRFR/CASArray.domaine.local
exchangeAB/CASArray.domaine.local

La négociation Kerberos ne fonctionne donc pas et Outlook se rabat donc sur le protocole NTLM, ce qui n'a pas d'effet négatif dans la grande majorité des cas, mais peut causer des ralentissements d'authentification en environnement multi-domaines, en particulier dans de grandes arborescences AD. Cela permet aussi une authentification plus efficace dans le cadre d'une relation bidirectionnelle de forêts s'exécutant en mode fonctionnel 2003 natif ou ultérieur (cas typique d'une Forêt de Ressources).

En mode 'Mono-Forêt/Multi-Domaines', une technique pour palier à l'inefficacité du NTLM est de créer des 'Shortcust Trusts' entre le(s) domaine(s) où se situent les serveurs Exchange et celui(ceux) où se situent les utilisateurs.

Mais le mieux et le plus performant (et le plus sexy) reste l'activation du Kerberos sur le Client Access Array :)~

ÉTAPE 1: Créer un compte d'abstraction Kerberos

Méthode 1:

Il suffit de créer un compte utilisateur activé et n'ayant aucun privilège. Cependant il est plus que conseillé de définir un mot de passe très complexe (ex: de 15 caractères ou +), voire même de restreindre l'ouverture de session sur les serveurs CAS seulement (non testé). Le plus simple à gérer est de définir ce mot de passe comme n'expirant jamais.

Pour l'exemple, ce compte s'appelle 'svcCASArray' dans mon lab, ce qui donne comme nom complet 'CORP\svcCASArrary' ('CORP' étant le nom Netbios de mon domaine).

Méthode 2:

L'alternative est d'utiliser un compte d'ordinateur créé à la main dans Active Directory. Il s'agit en fait de la méthode recommandée mais requiert un peu plus de travail pour sa mise en oeuvre et sa maintenance.

Par exemple, votre CAS Array a normalement un non défini, vous pouvez utilisez celui-ci, ou simplement la première partie de son FQDN ou son nom d'objet (pour l'exemple, le mien s'appelle 'MAPI-MAIN'). Le principe est similaire au principe d'avoir un compte d'ordinateur créé pour un serveur virtuel d'un cluster (tel que votre DAG par exemple).

Cela donnerait dans mon lab:

Création d'un objet 'Computer' dans l'Active Directory (ex: création de l'ordinateur 'MAPI-MAIN')
Définition d'un mot de passe pour l'objet 'CORP\MAPI-MAIN$'
Changement périodique du mot de passe pour l'objet 'CORP\MAPI-MAIN$'

Pour la configuration, le compte a utiliser ne sera donc plus 'CORP\svcCASArrary' mais 'CORP\MAPI-MAIN$'. Le hic dans ce mode est qu'il est préférable de changer régulièrement le mot de passe du compte d'ordinateur. A chaque changement, il faudra mettre à jour les 'credentials' mémorisés sur chaque CAS. Cela requiert 'us peu de scripting...' :)

Le gros avantage cependant est la sécurité. En effet, même si le mot de passe du compte d'ordinateur est 'piraté', il ne sera pas possible d'ouvrir une session interactive, et serait dans l'absolu moins facile à exploiter.

ÉTAPE 2: Attribuer les Service Principal Names (SPN) au compte de service pour le MAPI/RPC

Il s'agit ici d'associer au compte de service (ou compte d'ordinateur) les identifiants de service du CASArray.
Cela s'effectue sans peine avec la commande SetSPN.exe (disponible dans l'OS depuis Windows Server 2008):

setspn.exe -F -S "exchangeMDB/CASArray.domaine.local" "CORP\svcCASArray" (ou "CORP\MAPI-MAIN$")
setspn.exe -F -S "exchangeRFR/CASArray.domaine.local" "CORP\svcCASArray" (ou "CORP\MAPI-MAIN$")
setspn.exe -F -S "exchangeAB/CASArray.domaine.local" "CORP\svcCASArray" (ou "CORP\MAPI-MAIN$")

Bien sûr, il faut remplacer 'CASArray.domaine.local' par le FQDN de votre Client Access Array.

Notes:

SetSPN.exe -S permet d'ajouter un Service Principal Name (SPN) en vérifiant préalablement les doublons (avec le switch -F cherche les doubloins dans toute la forêt). Important car si un doublon existe, Kerberos échouera purement et simplement.
SetSPN.exe -C permet de vérfier si le SPN est déjà défini sur un objet 'User' ou 'Computer'. Avec l'option -F cela permet de rechercher dans toute la forêt et avec -P dans un ou plusieurs domaines (le switch -P peut être specifié plusieurs fois).

ÉTAPE 3: Attribuer les Service Principal Names (SPN) au compte de service pour les WebServices

L'idée est la même que ci-dessus, cependant ces SPNs seront de la forme "HTTP/WebService.domaine.local", où 'WebService' pourra être le même, ou différent pour chaque service Web. Dans un premier temps, ajoutez les noms d'hôte correspondant aux "Internal URL" de vos répertoires virtuels Exchange (Get-XXXXXVirtualDirectory). Il est inutile de tenter d'ajouter deux fois le même FQDN, donc si comme dans ma config vous n'avez qu'un FQDN pour tous les services Web, cela donnera quelque chose comme:

setspn.exe -F -S "HTTP/WebService.domaine.local" "CORP\svcCASArray" (ou "CORP\MAPI-MAIN$")

Note: il est tout à fait possible d'utiliser le même FQDN pour le MAPI/RPC et les Services Web.

ÉTAPE 4: Configurer le compte de service

Toute l'astuce est là. Il suffit de récupérer un objet de type 'PSCredential' en PowerShell et de l'assigner aux serveurs CAS participant au pool. Les commandes suivantes doivent être exécutées sur chaque serveur CAS, localement (NDLR: je n'ai pas essayé en PS Remoting, j'ai fait 'autrement' pour l'automatisation :)).

$cred = Get-Credential "CORP\svcCASArray" ==> vous serez invité à entrer le mot de passe du compte de service

Puis ensuite pour l'assigner:
Set-ClientAccessServer -Identity ServeurCAS -AlternateServiceAccountCredential $cred

Patientez une trentaines de secondes, puis vérifiez que la configuration ait été prise en compte avec:
Get-ClientAccessServer -Identity ServeurCAS -IncludeAlternateServiceAccountCredentialStatus et d'observer la propriété 'AlternateServiceAccountConfiguration'.

Petite astuce: Vous pouvez aussi utiliser le switch -IncludeAlternateServiceAccountCredentialPassword afin de récupérer aussi l'objet PSCredentials du compte d'abstraction. Ensuite, avec un peu d'astuce, il est possible de 'copier' ce compte avec son mot de passe sur d'autres serveurs CAS.

Enfin, effectuez un IISReset afin d'être sûr que les Web Applications soient complètement recyclées. Enfin, redémarrez les services suivants à l'aide de la cmdlet Restart-Service:

MSExchangeAB
MSExchangeRPC

ÉTAPE 5: Tester l'authentification Kerberos

Depuis un poste 'de base' avec KerbTray, purgez le tickets en cache. Puis lancez Outlook. Après le lancement d'Outlook, la première visualisation avec KerbTray donne les tickets exchangeMDB, exchangeRFR et exchangeAB récupérés et en cache.

Attendez quelques minutes ou effectuez toute opération faisant appel aux Web Services (tel qu'un Ctrl+Click droit sur l'icône Outlook dans le SysTray ==> Test E-mail Autoconfiguration). Le second visualisation montre qu'un ticket a été ajouté pour le(s) service(s) HTTP/WebService.domaine.local.

Vous pouvez aussi utiliser depuis un serveur Exchange (ou autre ordinateur ayant les outils d'administration installé) en Exchange Management Shell la commande Test-OutlookConnectivity:

$cred = Get-Credential 'DOMAIN\username'
Test-OutlookConnectivity -Identity MailboxIdentity -MailboxCredential $cred

Puis de vérifier avec KerbTray ou KList que le ticket existe.

Si cela ne fonctionne pas, vérifiez les points suivants:

Réplication AD (les SPNs sur le compte de service doivent avoir été répliqués)
Attribut 'servicePrincipalName' sur le compte d'abstraction Kerberos (ex: CORP\svcCASArrary)
Vérifiez qu'il n'existe aucun doublon de SPN dans l'AD (utilisez SetSPN.exe -F -Q Service/FQDN)
Assurez vous aussi que - pour les Web Services - le(s) FQDN(s) soient présents dans la zone "Local Intranet" dans les paramètres de configuration de sécurité dans Internet Explorer

CONFIGURATION 'DE MASSE'

L'activation du Kerberos peut-être fastidieuse, je vous laisse réfléchir au(x) moyen(s) d'effectuer en masse la configuration des serveurs CAS d'un même pool. Pour ma part, c'est déjà fait - j'ai utilisé une technique permettant de mettre en cache les credentials du compte de service afin de le rendre disponible sur tous mes serveurs d'un même CAS Arrary. La seule exception est lors de la 1ere configuration où je suis bien évidemment obligé de spécifier le mot de passe.

Au passage, si cela ne fonctionne pas et que vous voulez revenir en NTLM, utiliser la commande Set-ClientAccessServer -Identity ServeurCAS -RemoveAlternateServiceAccountCredentials puis supprimez le compte de service, ou moins drastiquement les SPNs qui y étaient associés (via SetSPN.exe ou en 'nettoyant' l'attribut servicePrincipalName du compte utilisateur).

POUR FINIR

Cette procédure n'est pas officiellement documentée par Microsoft et la rumeur dit que l'activation du Kerberos avec Exchange Server 2010 RTM ne serait pas supportée, mais le sera pleinement (ainsi que documentée) avec le SP1. Après vérification, la possibilité de configurer le compte d'abstraction a été implémentée dans l'Update Rollup 2 d'Exchange Server 2010 RTM mais ne sera pleinement supportée seulement dans le SP1. Elle ne sera d'ailleurs pleinement documentée (dans le principe et son implémentation) qu'au moment du SP1.

En parlant du SP1 justement, il apportera aussi de nouvelles possibilité avec l'authentification Kerberos puisqu'il supportera la configuration des mécanismes d'Extended Protection documentés ici: http://www.microsoft.com/technet/security/advisory/973811.mspx et là http://www.iis.net/ConfigReference/system.webServer/security/authentication/windowsAuthentication mais aussi ici:
http://support.microsoft.com/kb/973917

Ce mode permet entre autres de traverser des Proxy plus facilement, et globalement de durcir la securité lors de l'accès aux services en se protégeant un maximum des attaques du type "man in the middle" (ex: spoofing DNS, usurpation d'identité).

Note: l'Extended Protection est native dans Windows Server 2008 R2/Windows 7 mais requiert l'installation d'un correctif pour Windows Server 2008/Windows Vista. A l'heure actuelle, l'installation d'Exchange Server 2010 SP1 ne vérifie pas la présence de ce correctif puisqu'il n'est utile que pour activer ce mode (non obligatoire).

INFO: Exchange Server 2010 SP1 - Mais où sont passés les paramètres des fichiers 'config' ?

2010-07-15T23:09:00.004+02:00

Dans Exchange Server 2010 RTM, il était possible de configurer la plupart des services Exchange au travers des fichiers '.config' situés au même endroit que l'exécutable. C'est une grande tradition .NET car facile à implémenter et à utiliser.

Cependant, depuis Exchange Server 2010 SP1 (Beta) un certain nombre de paramètres ont été déplacés à d'autres endroits. Nous l'avons vu précédemment, la configuration de l'intégration Outlook Web App et OCS a été sortie du fichier Web.config (qui pour le coup a été vampirisé complètement :)) au bénéfice de la configuration via la CmdLet Set-OWAVirtualDirectory.

Pour d'autres, cela est moins simple à trouver, ou somme toute plus inattendu.

Par exemple, afin d'utiliser mon "HLB fait maison" dans mon lab, j'ai du configurer l'accès RPC et l'accès à l'annuaire à l'aide de ports statiques.

Si la configuration du port pour l'accès RPC n'a pas changé (valeur dans le registre), la configuration du port TCP pour l'annuaire a été déplacé... dans la base de registre (à l'ancienne quoi =°). Un petit coup de ProcMon m'a permis de vite retrouver où...

HKLM:\SYSTEM\CurrentControlSet\Services\MSExchangeAB\Parameters

NspiHttpPort et RfrHttpPort ==> utilisés pour le RPC/HTTP et inutile de les changer
RpcTcpPort ==> ports du carnet d'adresses

Ces valeurs sont des REG_SZ (et oui, je m'attendait à des REG_DWORD) - en tout cas dans la Beta d'Exchange Server 2010 SP1. J'ose espérer que cela pourrait changer, non pas parce que ça m'amuse, mais utiliser un chaîne de caractère pour y stocker un n° de port TCP me semble juste une hérésie... :)

N'oubliez pas que lorsque vous mettrez à jour vos serveurs Exchange 2010 en SP1, il y a de forte chances que vous y perdiez quelques 'tweaks' au passage. Assurez-vous d'avoir testé au préalable toute mise à jour en condition réelle dans un lab ou une vraie préproduction (avec les mêmes 'tweaks'). Cela est d'autant plus vrai si vous utilisez Blackberry Enterprise Server et que vous avez configuré le MaxUserPerSession tel que recommandé par Research-In-Motion. Je n'ai pas encore trouvé (pas trop cherché) où celui-là a été déplacé, mais je sais qu'il est quelque part dans le Throttling Framework (donc plutôt côté des Throttling Policies :)).

Voici d'autres paramètres du registre en vrac, certains sont hérités des versions antérieures d'Exchange, d'autres méritent investigation:

MSExchangeIS\ParametersSystem

Rpc Compression Minimum Size
Rpc Compression Enabled
Rpc Packing Enabled
Rpc Context Pool Size
RPC Requests Threshold
Async Rpc Notify Enabled
OAB Bandwidth Threshold (kBps)
Log on Ptag set
Allow Order By Delivery Time On Sync
Force Order By Delivery Time On Sync
Force Batch Mode
Maximum Messages To Preread
Reread Logon Quotas Interval
Suppress Event Logs
Flush Call Traces
Flush Call Traces Periodically
ClientStatsIntervalMinutes
ClientStatsMinimumRpcAttempt
ClientStatsSuccessPercentageWarning
ClientStatsLatencySeconds
ClientStatsMaxWarning
ClientStatsMaxWarningIntervalSeconds
ClientMonitoringcMinAgeLimitMinutes
ClientMonitoringMaxLowBandwidth
ClientMonitoringEnableFlags
ClientMonitoringReportLevel
RemoteITP
Synch Mailbox/Check OOF Interval
Max FXGetBuffer Users
FXGetBuffer BackOff Constant
FXGetBuffer Retry Count

MSExchangeIS\ParametersSystem\Private-<GUID>

Maximum RPC Threads Per MDB
Mailbox LCID

MSExchangeRPC\ParametersSystem

ADUserDataCacheTimeout
ExecutionFlags
LoEveryConfigurationUpdate
TCP/IP Port
IdleConnectionCheckPeriod
ShareConnections
EnableExMonTestMode
Maximum Polling Frequency
RPC Retry Count
RPC Retry Delay
EnableWebServicesEndpoint
Max FXGetBuffer Users
FXGetBuffer BackOff Constant
FXGetBuffer Retry Count

INFO: Exchange Server 2010 Update Rollup 4

2010-06-18T16:49:00.000+02:00

Microsoft a mis à disposition, dans le cadre de son cycle de mise à jour bimestriel, l'Update Rollup 4 pour Exchange Server 2010.

Informations ici: http://support.microsoft.com/?kbid=982639
Téléchargement ici: http://www.microsoft.com/downloads/details.aspx?FamilyID=09b4973e-3a80-4fb9-9f60-5c6e2b7a2727&displaylang=en

Bonnes mises à jour!

TUTORIEL: Exchange 2010 SP1 - Intégration OCS dans OWA

2010-06-08T08:37:00.009+02:00

Maintenant que le Service Pack 1 d'Exchange Server 2010 est en Beta Publique, nous allons voir apparaître quelques nouveaux articles... Car oui, en effet, le SP1 d'Exchange Server 2010 va être légèrement "perturbant". Outre l'usuelle correction de bugs et l'ajout des fonctionnalités manquantes dans la RTM, le SP1 "finalise" quelque peu certains aspects, ce qui a pour effet de revoir les artciles publiés, prodcédures d'installation, d'exploitation, docs d'architecture, etc... :)

Note: avant de tenter d'installer le SP1 Beta, pensez à récupérer et installer la mise à jour KB981002 décrite et disponible ici - http://code.msdn.microsoft.com/KB981002 - cette mise à jour s'applique à tous les rôles (certains rôles, tel que l'UM par exemple requièrent encore d'autres composants...).

Rappelez-vous dans Exchange 2010 RTM, on pouvait effectuer l'intégration d'OCS dans OWA en modifiant le fichier Web.Config sur chaque serveur Client Access concerné. Dans le SP1 d'Exchange Server 2010 cette procédure est devenue obsolète. En effet, la DevTeam a étendu la CmdLet Set-OwaVirtualDirectory afin d'ajouter deux paramètres pour la configuration de l'intégration OWA et l'Instant Messaging:

InstantMessagingCertificateThumbprint: "Empreinte digitale" identifiant le Certificat à utiliser pour les connexions SIP/TLS entre le Client Access Server et OCS. L'entrée 'CN' (Canonical Name) de l'attribut Subject Name du certificat sera utilisé pour identifier le Fqdn entrant sur OCS (le Fqdn à spécifier dans les Host Authorizations)
InstantMessagingServerName: nom du Pool OCS auquel se connecter. Il peut s'agir d'un Pool Director, un Pool Standard ou bien évidemment un Pool Enterprise

L'ajout de ces paramètres a deux intérêts. Le premier est évident: facilier la configuration de l'intégration, en particulier offrir la possibilité de l'automatiser. Le second est d'ordre support: la configuration de l'intégration OWA/OCS par le biais d'un fichier de configuration n'était pas optimum et quelque peu 'risqué' puisque un fichier Web.config a toujours été 'sensible'.

Si vous mettez à jour vos serveurs Client Access dans votre environnement de test, l'intégration OWA/OCS cessera de fonctionner. Si vous tentez de configurer une nouvelle installation d'Exchange Server 2010 SP1, vous ne trouverez pas les entrées dans le fichier Web.config.

Aller, un petit exemple pour la route:

N'oubliez pas de vous assurer que l'intégration OCS soit bien activée sur tous les répertoires virtuels OWA des serveurs CAS d'une même ferme avec: Set-OwaVirtualDirectoy -Identity OwaVDirIdentity -InstantMessagingEnabled:$true

Bonnes mises à jour !

INFO: OCS 2007 R2 Group Chat - Cumulative Update 5

2010-04-23T00:03:00.008+02:00

Modification du 8/5/2010: Attention, l'équipe produit vient de prévenir que suite l'installation des correctifs CU #5 pour les clients Group Chat (Client & Admin) provoque un problème empêchant la désinstallation des dits patchs. Microsoft va publier ce week-end une nouvelle version des correctifs - il s'agit des mêmes correctifs, seule la partie installation/désinstallation des correctifs sera corrigée.

Si vous avez déjà déployé le correctif précédent: le seul moyen de supprimer le CU #5 est de désinstaller le client lui-même (Client et/ou Admin) - puis de réinstaller avec un niveau de CU différent (ou la version réactualisée du CU #5);
Si vous n'avez pas déja déployé le CU #5 pour vos clients Group Chat: attendez que la nouvelle version des mises à jour aient été postées (cf lien ci-dessous) et au besoin, téléchargez à nouveau celles-ci.

L'équipe UC a publié aujourd'hui la mise à jour cumulative #5 pour les composants Group Chat d'Office Communications Server 2007 R2.

Ils sont disponibles ici (Server/Client/Admin):

http://www.microsoft.com/downloads/details.aspx?FamilyID=e5924bf9-b042-4c53-b4a6-79c7e5c9749b&displaylang=en

Voici les articles liés:

KB980042 (Server): http://support.microsoft.com/kb/980042
KB980043 (Client): http://support.microsoft.com/kb/980043
KB982128 (Admin): http://support.microsoft.com/kb/982128
KB981449 (SDK): http://support.microsoft.com/kb/981449

N'oubliez pas suivre pas à pas le processus de mise à jour décrit dans l'article Server (certes un peu "complexe"), au risque sinon de corrompre votre installation (base).

Mise à jour du 5/5/2010:

Confirmation que le CU #5 permet de supporter le Group Chat dans un environnement AD 2008 R2
Confirmation que le CU #5 permet de supporter le Group Chat sur un serveur membre Windows Server 2008 R2
Les articles suivants sont en cours de mise à jour:
http://support.microsoft.com/kb/982020
http://support.microsoft.com/kb/982129
http://technet.microsoft.com/en-us/library/ee692314(office.13).aspx
http://support.microsoft.com/kb/982021

Voilà qui devrait satisfaire les entreprises désireuses de mettre à jour leurs contrôleurs de domaine en W08R2 :)
Je rappelle qu'Exchange Server 2003 SP2 supporte un AD 2008 R2 (même natif, sisi!) depuis Janvier 2010. Par conséquent, aucun point de blocage ou nécessiter de terminer une mise à niveau Exchange Server 2010 afin de moderniser l'AD.

INFO: Office 2010 et SharePoint Server 2010 sont RTM !!!

2010-04-22T22:51:00.008+02:00

Enfin, on l'attendait tous avec impatience: Microsoft Office 2010 est enfin RTM et disponible au téléchargement sur MSDN.

Sont donc disponibles:

Microsoft Office 2010 Professional Plus (Word, Excel, PowerPoint, Outlook, Access, SharePoint Workspace, OneNote, InfoPath, Publisher)
Microsoft Office Visio 2010 (Standard/Professional/Premium)
Microsoft Office Project 2010 (Standard/Professional)

Bien qu'il ne fasse plus partie de la suite Office, adhérences obligent, SharePoint Server 2010 est aussi disponible au téléchargement.

Puisqu'une bonne nouvelle ne vient jamais seule, le très attendu Microsoft SQL Server 2008 R2 est aussi RTM, mais sa disponibilité en téléchargement se faire attendre.

Avec Visual Studio 2010 et le Framework 4.0 disponibles eux aussi depuis la semaine dernière en RTM, nul doute que les choses bougent en ce Printemps 2010 du côté de Redmond !

CRITIQUE: Une mise à jour McAfee VirusScan créé un blackout sur Windows XP SP3

2010-04-21T23:17:00.002+02:00

Journée noire pour McAfee, mais surtout pour les malheureux utilisateurs ou malheureuses sociétés ayant une politique de mise à jour antivirale "efficace".

En effet, ce Mercredi 21 Avril 2010, la charmante mise à jour estampillée 5958 pour McAfee VirusScan a causé la détection sur processus "svchost.exe" comme la variante du virus w32/wecorl.a. Il s'agit bien sûr d'un faux-positif, ce processus étant un des processus les plus critiques du système d'exploitation, puisqu'il sert de "berceau" à la plupart des services système. Il semblerait que seul Windows XP SP3 soit touché.

En tant que tel, il est protégé par le service de protection des fichiers systèmes implémenté depuis Windows 2000. Mais surtout, "tuer" ce processus cause un arrêt immédiat du système, par un fameux "Blue Screen of Death" ou un redémarrage pour cause de défaillance d'un service critique.

Là où le bât blesse, c'est que le système de protection intégré a Windows tente désespérément de restaurer le fichier depuis le répertoire DLLCACHE, et l'antivirus détruit systématiquement le fichier...

Notez l'aplomb de McAfee tout de même:

McAfee is aware that a number of customers have incurred a false positive error due to incorrect malware alerts on Wednesday, April 21. The problem occurs with the 5958 virus definition file (DAT) that was released on April 21 at 2.00 PM GMT+1 (6am Pacific Time).
Our initial investigation indicates that the error can result in moderate to significant performance issues on systems running Windows XP Service Pack 3.
The faulty update has been removed from McAfee download servers for corporate users, preventing any further impact on those customers. We are not aware of significant impact on consumer customers and believe we have effectively limited such occurrence.
McAfee teams are working with the highest priority to support impacted customers and plan to provide an update virus definition file shortly. McAfee apologizes for any inconvenience to our customers.

Non seulement, le problème ne s'arrête pas à un problème de performance sur la machine, et le "moderate" est à mourir de rire. D'un point de vue plus personnel, je trouve inadmissible qu'une société, parmi les leaders de la protection des environnements d'Enterprise et qui se vante de disposer d'une des meilleures suites de protection contre les virus de surcroit, ne dispose pas d'un plan de recette digne de ce nom.

De plus, il est d'ores déjà trop tard pour certaines compagnies utilisant VirusScan et ayant encore quelques dizaines de milliers, voire centaines de milliers de postes Windows XP SP3. La rumeur dit qu'un certain fondeur de processeur, leader dans son domaine et dont le nom commence par un "I" serait déjà bien affecté...

J'ai hâte de lire la petit gazette du Web de demain matin... :)

PS: j'ai toujours détesté VirusScan. Travaillant en général sur des technologies récentes, je n'ai jamais vu VirusScan ne pas causer de problèmes de performances ou effets de bords indésirables sur les serveurs de mes clients.

INFO: OCS 2007 R2 Cumulative Update 5 - Une mise à jour conséquente...

2010-04-16T22:32:00.009+02:00

Microsoft a publié la mise à jour cumulative #5 pour OCS 2007 R2 (hors Group Chat, j'y reviendrai plus tard).
Page de référence: http://technet.microsoft.com/en-us/office/ocs/ee695846.aspx (non encore répliquée/à jour)

Au menu ce mois d'Avril 2010, les améliorations les plus marquantes sont:

Une grosse mise à jour de l'API UCMA 2.0: avec beaucoup d'éléments "backportés" de Communications Server Wave 14, le successeur d'OCS. Ici, on trouvera essentiellement beaucoup de nouvelles fonctionnalités très intéressantes pour les développeurs, des améliorations liées à l'interoperabilité, l'introduction de l'"Enhanced Recorder" (j'adore :)), du support du SIP DNS load-balancing (ça fleure bon CS Wave 14 !!!) et surtout un meilleur support des applications "UC" sur Windows Vista SP1 et +, Windows 7 et Windows 2008 R2.
Une grosse mise à jour du Mediation Server: chapeau bas à l'équipe produit, et en particulier à FrançoisD, pour avoir eu le courage d'introduire dans OCS 2007 R2 un fix lié à un mauvais respect des protocoles de voix sur IP par la concurrence (Cisco, pour ne pas les citer =°)). Les environnements souffrant du symptôme des appels coupés après 30 seconds (typiquement, lors d'une mise en attente par le partenaire) tireront bénéfice de ce fix. Ici, le fix va tout simplement permettre de configurer le Mediation Server afin d'ignorer les "faux timeouts" lorsque la passrelle ou l'IP-PBX ne parle pas correctement en RTCP. Il s'agit d'un configuration manuelle (détails dans l'article).
Une mise à jour de performance (Pool Standard ou Enterprise): en particulier lorsque beaucoup de clients Group Chat sont déployés. Requiert aussi une mise à jour du schéma de la base SQL.
Correction du fameux bug des PINs dans CWA/Dial-in Conferencing: celui-là m'a toujours amusé, enfin corrigé !
N'oublions pas le client principal: une nouvelle mise à jour du processus de téléchargement du carnet d'adresses pour MOC 2007 R2 en plus de la correction de quelques bugs mineurs. Cette mise à jour corrige aussi un bug non référencé: celui de la "Blue Window" qui n'affecte que Windows XP sous certaines conditions (les personnes affectées savent de quoi je parle :)).

Les liens directs:

Office Communcations Server 2007 R2:

Office Communicator 2007 R2:

Office Communications Server Attendant Console R2:

Office Communicator Phone Edition R2:

Au sujet du Group Chat, une mise à jour majeure va sortir prochainement. Elle permettra entres autres de supporter un Active Directory Windows Server 2008 R2.

Pour l'instant, il n'est nulle part fait mention d'une mise à jour de CoMo 2007 R2, il n'y en aura probablement pas.

Surtout, n'oubliez pas d'appliquer le patch de la base SQL.

Par sécurité, n'oubliez pas d'arrêter les services OCS sur les frontaux du Pool dont vous mettez à jour la base. Si vous avez un Pool vide (type Disaster Recovery par exemple), n'oubliez pas de le mettre à jour aussi. Si vous avez un (ou plusieurs - ça peut arriver) Pool de Directors, mettez le(s) aussi à jour, même si cela n'est pas fondamental.
Edition Standard: msiexec /i OCS2009-DBUpgrade.msi
Edition Enterprise: msiexec /i OCS2009-DBUpgrade.msi POOLNAME=nomdupool - il est en général conseillé de mettre à jour la base depuis le serveur SQL car les outils SQL y sont normalement déjà installés. Das ce cas, il sera préalablement nécessaire d'installer les composants de base OCS 2007 R2 (idéalement mis à jour aussi immédiatement après): OCSCore, UCMA et le SQL 2005 Backward Compatibility si nécessaire.
Une fois la mise à jour de la base effectuée, n'hésitez pas à effectuer une sauvegarde complète de celle-ci par votre méthode habituelle et préférée.

Le MSI de patch de la base n'est pas désinstallable (comprendre, ne peut pas faire un roll-back de la mise à jour dans la base), mais une fois la mise à jour effectuée, vous pouvez retirer les binaires/scripts de mise à jour en réexecutant la commande msiexec en specifiant /x au lien de /i.

Il ne me reste qu'à vous souhaiter de bonnes mises à jour ! :)

INFO: Mises à jour de securité pour Exchange (toutes versions ou presque...)

2010-04-14T09:49:00.003+02:00

L'équipe Exchange vient de publier un ensemble de mises à jour cumulative afin de corriger une faille de securité affectant toutes les versions d'Exchange. Notez que la mise n'est disponible que pour les versions encore supportées.

Security Update for Exchange 2000 Server (KB976703)
Security Update for Exchange Server 2003 Service Pack 2 (KB976702)
Update Rollup 10 for Exchange Server 2007 Service Pack 1 (KB981407)
Update Rollup 4 for Exchange Server 2007 Service Pack 2 (KB981383)
Update Rollup 3 for Exchange Server 2010 (KB981401)

Plus d'informations sont disponibles dans le bulletin de securité MS10-024 Microsoft Exchange and Windows SMTP Service Could Allow Denial of Service (981832).

INFO: Support de Windows 2008 R2 enfin officiellement annoncé pour OCS 2007 R2

2010-03-30T22:19:00.002+02:00

Certain l'attendaient avec impatience, c'est enfin officiel ! Microsoft a publier hier les articles de la base de connaissance annonçant le support de Windows Server 2008 R2 avec Office Communications Server 2007 et 2007 R2.

Sachez tout d'abord que seul OCS 2007 R2 est supporté pour exécution sur un serveur membre, un certain nombre d'actions sont requises pour préparer le système d'exploitation. Méfiez vous en particulier des points suivants:

Le Framework 3.5.1 doit être installé par l'assistant d'ajout/suppresion de fonctionnalités Windows (ou en ligne de command via ServerManagerCmd.exe ou mieux, avec l'aide du module système "ServerManager" pour PowerShell v2) - méfiez vous car en installant le composant "Web-Server", vous installez aussi le service FTP Microsoft, installez à la place "Web-WebServer"
La version minimale supportée est le build 56, à savoir la mise à jour cumulative #3 d'Octobre 2009. Sachez aussi que la mise à jour cumulative #5 (Avril 2010) va sortir d'ici moins de deux semaines.
Il faudra baisser le niveau de sécurité par defaut de Windows Server 2008 R2 et appliquer un correctif spécifique pour le TLS/SSL (sans quoi l'installation ne sera pas supportée et risque de mal fonctionner)

En ce qui concerne l'Active Directory les versions d'OCS 2007 R2, OCS 2007 et LCS 2005 SP1 sont aussi supportées, mais si l'AD a été mis à niveau depuis une version antiérieure, il faudra ré-executer l'étape "ForestPrep", ce qui n'a aucune conséquence majeure, ni néfaste. En cas d'environnement multi-produit (ex: une forêt mixte avec LCS 2005 SP1 et OCS 2007 R2, il faudra refaire le ForestPrep dans l'ordre "d'ancienneté" des produits... et exactement de la même manière que la première fois !)

Lien vers les articles:

Support de Windows 2008 R2: http://support.microsoft.com/kb/982021
Support de l'AD 2008 R2: http://support.microsoft.com/kb/982020/

INFO: Exchange Server 2010 Update Rollup 2

2010-03-06T08:06:00.002+01:00

Microsoft a mis à disposition, dans le cadre de son cycle de mise à jour bimestriel, l'Update Rollup 2 pour Exchange Server 2010.

Informations ici:http://support.microsoft.com/kb/979611
Téléchargement ici:http://www.microsoft.com/downloads/details.aspx?FamilyID=6d3ae3e0-3982-46d6-9e9c-7d7d63fae565&displaylang=en

Bonnes mises à jour!

INFO: Poster OCS 2007 R2 !!!

2010-01-27T22:36:00.004+01:00

Rui Maximo, de l' "Office Communications Server Team" a enfin terminé son poster résumant les flux OCS 2007 R2, en fonction du type de communication. Travail somme toute titanesque, certains flux ont été restreints dans leur représentation pour une question de lisibilité.

Le poster est téléchargeable ici:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=af2c17cb-207c-4c52-8811-0aca6dfadc94

A vos imprimantes A0 :) !!!

INFO: Mise à jour de la passerelle XMPP pour OCS 2007 R2

2010-01-26T15:27:00.000+01:00

(Pour plus d'informations sur la passerelle XMPP, consultez mes articles précédents ici et là)

Microsoft a publié hier une mise à jour s'applicant au composant XMPP Gateway d'OCS 2007 R2.

Au menu:

Résout des problèmes de communication avec Nokia e-Jabber
Résout des problèmes de communication avec certains domaines Google

Plus d'informations et lien de téléchargement sur l'article de la base de connaissance lié.

INFO: Mise à jour cumlative #10 pour les clients Live Meeting pour Windows et Add-in Outlook 64-bit

2010-01-15T15:01:00.002+01:00

Microsoft vient de publier une mise à jour des clients LiveMeeting 2007 pour Windows.

Liens de téléchargement:

Console LiveMeeting 2007: http://office.microsoft.com/en-us/help/HA101733831033.aspx
Add-in LiveMeeting 2007 pour Outlook (versions 32-bit et 64-bit !!!): http://office.microsoft.com/en-us/help/HA102368901033.aspx

Articles de la base de connaissance, pour le détail des correctifs et nouveautés:

Console (KB976128): http://support.microsoft.com/kb/976128/
Add-in (KB976129): http://support.microsoft.com/kb/976129/

INFO: Mise à jour cumulative #4 pour OCS 2007 R2

2010-01-10T10:38:00.004+01:00

Microsoft a publié cette semaine le lot habituel (plus ou moins trimestriel) de mises à jour des divers composants d'Office Communications Server 2007 R2:

Mises à jour Office Communications Server 2007 R2

Lien de téléchargement: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4

Mises à jour Office Communications Server 2007 R2, Group Chat (Server/Admin/Client):

Lien de téléchargement: http://www.microsoft.com/downloads/details.aspx?FamilyID=e5924bf9-b042-4c53-b4a6-79c7e5c9749b&displaylang=en

Mise à jour Office Communicator 2007 R2 (build 83)

Lien de téléchargement: http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=515d6dba-4c6a-48bb-a06a-d99c5742676d

Mise à jour Office Communicator R2 Phone Edition (build 82)

Lien de téléchargement: http://www.microsoft.com/downloads/details.aspx?familyid=565595BE-6CF3-4A61-A1E4-12555749CA64&displaylang=en

Ce pack de mises à jour rassemble surtout des corrections de bug (et le coup des requêtes de certificat en mode hors connection est un retour d'expérience client =°)), mais ne propose pas de nouvelles fonctionnalités (ou évolution de fonctionnalités comme apportées dans le CU#2). Pas de mise à jour de la console Communicator Attendant 2007 R2 pour l'instant...

De même, il n'y a pas de mises à jour des composants Live Meeting (console et add-in Outlook), qui sont développés dans un cycle "à part".

N'oubliez pas de que CU#4 comporte une mise à jour des procédures stockées SQL et doit être appliquée une fois par Pool OCS afin que la base utilisée par celui-ci soient mises à jour correctement. La mise à jour n'est pas critique pour les environnements mis à niveau depuis OCS 2007, mais très importante pour les environnements en cours de migration depuis LCS 2005 SP1 (activation de la présence enrichie post-migration).

Bonnes mises à niveau =°)

INFO: Démystifier le carnet d'adresses OCS 2007 R2 et son utilisation avec MOC 2007 R2

2009-12-23T12:29:00.003+01:00

Le carnet d'adresses d'Office Communications Server 2007 (et R2) a toujours été le *gros* défaut du produit...

A titre d'exemple aux débuts d'OCS 2007: nous avons connu des problématiques chez un client, où la génération entrait en erreur (deux frontaux généraient les carnet d'adresses en même temps) et badaboom, les clients s'amusaient à télécharger une carnet d'adresses complet à chaque démarrage. A 15 Mo le carnet d'adresses et 20 000 clients en pilote dit "étendu" dans un Active Directory qui comportait plus de 75 000 utilisateurs "actifs", je vous laisse imaginer les dégâts sur la consommation réseau... Ce bug avait été remonté à Microsoft à l'époque et un correctif "privé" fourni en retour, pour enfin être intégré dans un hotfix "officiel".

Heureusement depuis, le service de carnet d'adresses a évolué. Le but de cert article est de résumer les améliorations apportées dans OCS 2007 R2 visant à réduire les impacts sur la consommation réseau des téléchargements du carnet d'adresses, et surtout comment les configurer afin qu'elles soient 100% fonctionnelles.

Compact Deltas

Dans la mise à jour cumlative #2 (Juillet 2009) d'OCS 2007 R2, Microsoft a introduit un nouveau procédé de génération des deltas, appellé "Compact Deltas". Ces compacts deltas sont les fameux fichiers "C-xxx-yyy.labs" dont vous avez peut-être noté la présence dans votre répertoire (ou partage) où sont stockés les fichiers générés par le processus "ABServer.exe" (s'exécutant (par défaut à 1:30 du matin) sur un serveur frontal, une instance unique tournant à un instant T par Pool...).

Cela va de soit, vous devez avoir un client Communicator 2007 R2 à jour (mise à jour cumulative #2 (build 37) ou ultérieure) pour tirer parti des nouveaux compacts deltas. Mais il ne s'agit pas de la seule amélioration visant à réduire les effets (négatifs) du téléchargement du carnet d'adresses OCS 2007 R2...

Utilisation du service de transfert intelligent en tâche de fond (BITS - Background Intelligent Transfer Service)

Cette modification a été aussi introduite dans la mise à jour cumulative de Juillet 2009, et permet à MOC 2007 R2 (build 37 ou plus donc) d'utiliser BITS afin de 1) ne pas faire échouer le téléchargement lorsque les conditions réseau sont "difficiles" et 2) de s'auto-restreindre en cas de saturation du lien réseau.

L'utilisation de BITS ne s'applique (pour l'instant) qu'aux téléchargements du carnet d'adresses complet (fichiers F-xxxx.lsabs) et requiert d'être activé sur les clients (cf configuration des clients ci-après dans cet article).

Configuration des serveurs frontaux - Web Components dans IIS

Afin que les téléchargements BITS fonctionnent, il est nécessaire de forcer les Web Components IIS (le fameux "Handler") de l'Address Book afin d'envoyer un verbe HTTP "Redirect" (302) au client. Ce processus permet au client d'être directement réferré vers le chemin du fichier à télécharger, et autoriser le client BITS d'y accéder directement.

Pour configurer l'emission du Redirect au travers des Web Components IIS, il est nécessaire de modifier les fichiers "Web.Config" de chaque "Handler" (interne et externe) sur chaque serveur frontal OCS 2007 R2. Cette action n'est pas nécessaire sur les frontaux servant un Pool Directeur puisque ceux-ci ont (normalement) les services d'Address Book et IIS désactivés.

Utiliser Notepad pour éditer %OCSInstallDir%\Web Components\Address Book Files\Int\Handler\Web.Config
Changer la valeur dans la clef "redirect" de "false" à "true" (défaut: false);
Enregistrer et fermer le fichier, et répéter l'opération avec %OCSInstallDir%\Web Components\Address Book Files\Ext\Handler\Web.Config
Redémarrer les services IIS (iisreset /noforce) ou recycler l'application IIS associée.

Remplacez %OCSInstallDir% par le chemin d'installation des binaires OCS 2007 R2 (par défaut: %ProgramFiles%\Microsoft Office Communications Server 2007 R2).

Voici donc quelques captures:

Comportement avant changement du Handler (pas de REDIRECT)

Configuration du Handler

Comportement après configuration du Handler (avec REDIRECT)

Configuration des serveurs frontaux - Générateur de carnet d'adresses

Le générateur de carnet d'adresses (ABServer.exe) étant une application .NET, vous aurez probablement remarqué qu'il existe un fichier "ABServer.exe.config" au même emplacement que l'exécutable. Ce dernier permet en particulier de configurer la génération des "Compact Deltas":

Clef "CompactDeltaOnly" (défaut: "false") - Passer à "true" afin d'éviter la génération des "anciens Deltas" (D-xxx-yyy.lsabs). Particulièrement utile pour libérer un espace disque non négligeable à condition de n'avoir que des clients MOC 2007 R2 build 37 ou plus;
Clef "CompactDelta_ExcludedIfSipURI" (défaut: "title,physicalDeliveryOfficeName") - Permet d'exclure les attributs "title" (Titre) et "physicalDeliveryOfficeName" (Office) des entrées dans les compact deltas pour les contacts étant activés pour OCS. Les clients exécuteront des requêtes LDAP pour récupérer ces attributs s'ils n'ont jamais été récupérés auparavant;
Clef "CompactDelta_AlwaysExclude" (défaut: "otherHomePhone,otherMobile,manager") - Permet purement et simplement d'ignorer ces attributs dans les compacts deltas.

Il est important que vous vérifiez que ces clefs sont bien présentes dans le fichier "ABServer.exe.config" de chaque serveur frontal participant à un Pool, et qu'elles soient bien sûr toutes en corrélation. Dans le cas contraire, vos Compact Deltas ne seront plus cohérents en fonction du serveur frontal qui sera en charge de la génération et vous risquez de compromettre leur intégrité, forçant ainsi les clients à ré-effectuer un téléchagement complet du carnet d'adresses.

Configuration du carnet d'adresses via ABSConfig.exe

ABSConfig.exe est un outil du Resource Kit permettant (comme son nom l'indique :)) de configurer la génération du carnet d'adresses sur les serveurs frontaux d'un Pool donné (il n'est donc utile de ne le faire qu'une fois par Pool, et non par serveur frontal).

Je passe la partie (certes importante mais hors sujet ici) sur la normalisation des numéros de téléphone... Le but est de s'intéresser ici aux optimisations qu'il est possible d'apporter lors de la génération du carnet d'adresses afin de réduire la taille de celui-ci.

La génération du carnet d'adresses considère qu'un objet Active Directory (et certains de ses attributs) doivent être transposés dans le carnet d'adresses OCS 2007 (R2) sous certaines conditions. Une de ces conditions, la plus fondamentale est la colonne "Is this Attribute Required?" qui peut être positionné à "Yes" (coché) ou "No" (décoché). Il s'agit donc d'une logique déterministique, à savoir que si l'un de ces attributs est présent (non vide) dans l'objet Active Directory, alors ce dernier est transposé dans la carnet d'adresses.

Par défaut, les attributs requis sont donc l'adresse SIP, et les champs de type téléphone. Ce filtre, très inclusif, a pour but d'autoriser les clients activés pour la téléphonie de "voir" et donc "appeler" les numéros de téléphones d'utilisateurs non activés pour OCS (qu'il s'agisse de fonctionnalités pures "Enterprise Voice" ou juste de type "PBX Integration" (comme le Remote Call Control par exemple)).

Cependant, un certain nombre de sociétés, donc certains de mes clients, n'intègrent pas (et n'intègreront malheureusement peut-être jamais) OCS avec de la téléphonie, et désirent donc n'inclure dans le carnet d'adresses OCS *que* les utilisateurs activés pour OCS.

Ainsi, les paramètres par défaut sont les suivants:

Et les paramètres permettant d'inclure *seulement* les utilisateurs activés pour OCS, ainsi que les groupes de distribution Exchange sont les suivants (en laissant les autres attributs configurés par défaut):

Afin d'alléger encore le carnet d'adresses, il est aussi possible de supprimer certains attributs en sélectionnant la ligne correspondant ceux-ci et en pressant la touche "Suppr" (ou "Del"). Evidemment, vous devez conserver l'attribut msRTCSIP-PrimaryUserAddress

Une fois les paramètres changés, effectuez une regénération complète des ressources utilisateurs (ABServer.exe -RegenUR), ce qui a pour effet de supprimer tous les carnet d'adresse jusqu'alors générés, et de repartir sur une nouvelle base. Le nouveau carnet d'adresses sera alors généré en prenant en compte la nouvelle configuration.

Cette configuration est à faire au plus tôt car elle va forcer les clients à télécharger un carnet d'adresses complet. D'ici là, la récupération des deltas échouera.

Configuration des clients

Réglage des téléchargements

Il existe essentiellement deux paremètres qui sont susceptibles de vous intéresser afin de régler les clients:

Le premier permet de régler le délai initial de téléchargement du carnet d'adresses après démarrage du client. Par défaut, et depuis la mise à jour cumulative #2 (Juillet 2009, build 37), le client introduit un délai aléatoire avant de vérifier/télécharger les mises à jour du carnet d'adresses (cela peut aller jusqu'à 60 minutes).

Ce changement permet de réduire les chances qu'un nombre exceptionnellement grand de clients téléchargent au même moment le carnet d'adresses (ce qui est fréquent le matin lors des pics de connexion...)
Ce délai peut donc être soit désactivé (mis à 0) ou forcé à une valeur (exemple: 5) en *minutes*
En toute objectivité, je recommande de conserver la configuration par défaut, sauf lors des phases de troubleshooting (avec Fiddler par exemple) et/ou pilote -- les seuls cas où l'on est "pressé" de recevoir les mises à jour rapidement.

Le second a été introduit dans la mise à jour cumulative #3 (Octobre 2009, build 56) permet de régler le mode de téléchargement des Compact Deltas:

Désactiver le téléchargement des Compact Deltas
Activer le téléchargement des Compact Deltas (mode par défaut)
Activer le téléchargement des Compact Deltas mais ne pas utiliser de requêtes LDAP

Activation de BITS

Une fois satisfaits avec le comportement du générateur d'Address Book et de votre client, il ne vous reste plus qu'à activer le téléchargement au travers du service BITS (Background Intelligent Transfert Service). N'oubliez pas que BITS est natif dans Windows et que BITS 2.0 est requis (Windows XP ou ultérieur il me semble).

Pour activer BITS, il suffit de mettre la stratégie HKCU\Software\Policies\Microsoft\EnableBitsForGalDownload (REG_DWORD) a 1 (un). Pour désactiver, mettre 0 (zéro) ou supprimer la valeur.

Template ADM pour stratégie de groupe (GPO)

Afin de faciliter la configuration de vos clients, votre serviteur (moi =°)) a donc mis à votre disposition un fichier Communicator.adm modifié (et donc non officiel) ici:

http://cid-21ad54fd70600673.skydrive.live.com/self.aspx/.Public/Communicator.zip

Pour conclure

Depuis les mises à jour cumulative #2 d'OCS 2007 R2 et de MOC 2007 R2 il est possible de réellement et considérablement réduire les impacts liés au téléchagement du carnet d'adresses.

Pour que ces améliorations soient optimales, il est nécessaire que les étapes suivantes soient effectuées:

Maintenir une excellente corrélation entre les versions "serveur" et "client": Je dirai que les mises à jour cumulatives #2 sont un "must have", et je ne saurai que trop conseiller à minima les mises à jour cumulatives #3 [EDIT 16/04/2010 - le CU #5 est disponbile, cf mon article à ce sujet]
Configurer les serveurs frontaux OCS 2007 R2 afin de configurer les "Handlers" internes et externes pour que BITS fonctionne - configurez ensuite les clients manuellement, ou par stratégie.
Optionnellement, optimiser la taille de votre carnet d'adresses en n'incluant que les utilisateurs et/ou attributs donc vous avez besoin.

Un dernier petit conseil pour la route... TESTEZ toute modification dans un environnement de pré-production (avec un annuaire Active Directory peuplé et idéalement représentatif de la production). Cela permettra d'OBSERVER tout changement comportemental du serveur ou des clients, et de valider que ceux-ci réagissent comme attendu.

RIGOLO: Boulette sur le site Technet français =)

2009-12-18T16:44:00.001+01:00

Un collègue m'a pointé vers ce lien, que je voulais partager avec vous en cette période de fêtes de fin d'année emplies de bonne humeur... Heureusement que l'on est pas le 1er Avril ! :)

INFO: Sortie de l'Update Rollup 1 pour Exchange Server 2010 - Ajout du support de Blackberry 5.0.1

2009-12-10T09:10:00.002+01:00

Certains l'attendaient avec impatience, la DevTeam Exchange a officiellement annoncé sur son Blog la mise à disposition de l'Update Rollup 1 d'Exchange Server 2010.

Pourquoi un Rollup si tôt ? Essentiellement pour une question de support de ces petits boitiers démoniaques que sont les Blackberries :) - Microsoft et RIM ont travaillé ensemble pour rendre leurs produits phares compatibles dans des délais somme toute très acceptables au regard de la date de sortie de la RTM d'Exchange Server 2010.

Au menu, trois pré-requis permettent l'interopérabilité:

Requiert l'installation de l'Update Rollup 1 sur le(s) serveur(s) Exchange 2010
Requiert l'installation du package MAPI/CDO version 6.5.8147 sur le(s) serveur(s) BES
Requiert l'installation du Maintenance Rollup 1 pour BES 5.0 sur le(s) serveur(s) BES

L'occasion est prise aussi d'incorporer un certain nombre de "bugfixes" comme décrit dans cet article (anglais).

Lire l'article du Blog de la DevTeam. Notre ami Scott Schnoll a aussi posté un excellent article sur la déploiement du Rollup 1 (généralisable aux futurs prochains) sur son Blog (en anglais).

Bon(s) déploiement(s) !

INFO: Microsoft et Cisco annoncent un support conjoint du Direct SIP entre OCS 2007 (R2) et Call Manager

2009-12-07T23:27:00.005+01:00

Microsoft et Cisco ont annoncé le support de l'interconnexion directe via le protocole SIP (Direct SIP).

Chez Microsoft: Cisco-MSFT Support Statements.docx
Chez Cisco: Page Web (annonce)

En gros, les deux géants ont testé diverses versions (plus facile pour Cisco, étant donné que seuls OCS 2007 et OCS 2007 R2 sont pour l'instant disponibles :) alors que Microsoft a testé les versions 4.x, 5.x, 6.x)

La page UCOIP de Microsoft résume très bien la situation: les versions 4.2, 5.1 et 6.1 (les versions d'IOS varient) sont pleinement supportées pour Direct SIP. C'était bien plus compliqué avant, lorsqu'il fallait passer par une passerelle, ou un GETS... :p -- Attention toutefois, il convient que l'intégration soit supportée aussi bien par Microsoft que Cisco. Le plus "direct" est la mise en oeuvre de l'intégration OCS 2007 R2 avec CCM 6.1.

TUTORIEL: Intégration Exchange 2007/2010, SIPnPBX et SIP Trunk Freephonie!

2009-11-30T02:15:00.010+01:00

Hier, j'expliquais comment intégrer Exchange UM avec Asterisk/Trixbox et Freephonie. Aujourd'hui nous allons voir comment en quelques minutes nous pouvons réitérer cette intégration avec un petit bijou de simplicité nommé PBXnSIP. Merci à Benoit Q de m'en avoir parlé, car je ne connaissais pas!

Étant parfois un peu fainéant, je ne vais pas réécrire la totalité des étapes de configuration Exchange, vous les trouverez dans la première et la seconde partie des articles consacrés à Asterisk/Trixbox.

Installation de PBXnSIP

PBXnSIP est un IP-PBX bien ficelé, qui tourne sur Windows, Linux ou Mac OS ! Contrairement à Asterisk, il n'est ni gratuit ni Open Source mais reste abordable pour des TPE/PME.

Téléchargement: http://www.pbxnsip.com/download-software/software.php
Licence de démo: http://www.pbxnsip.com/sales/trial.php

Pour mes tests, j'utilise une licence de démo permanente mais dont la durée des appels est limitée. Aucune chance donc que je ne l'utilise pour une "vraie" démo. Cependant, il est possible d'utiliser une licence de démo parfaitement fonctionnelle, mais limitée dans le temps (14 jours) -- cela est peut-être une meilleure option pour vous...

Pour mon lab, j'utilise une machine virtuelle Windows Server 2003 SP2 32-bit avec 256 Mo de mémoire. L'installation de PBXnSIP se fait sans accroc en quelques secondes. Lisez le guide d'installation et les instructions sur le site PBXnSIP (configuration du support du TOS et configuration du redémarrage du service en cas de crash... peu important dans un lab, mais à considérer en production).

Dans le même esprit que ma Trixbox, j'ai deux interfaces, dont celle connectée en interne a une route statique par mon interface privée afin de joindre mon serveur UM qui est dans un sous-réseau spécifique.

L'autre interface est bien évidemment connectée à mon réseau "maison", directement NATé à Internet via ma Freebox. Cette interface n'a aucun service type "Client Microsoft" ou "Partage de fichiers/imprimantes" et ne s'enregistre pas dans le DNS. Netbios/TCP est aussi désactivé.

Bref, comme d'habitude, adaptez votre serveur à vos besoin. L'essentiel est que vous puissiez joindre votre serveur UM d'un côté et Internet de l'autre.

Si vous avez joué avec une Trixbox, n'oubliez pas de l'éteindre, en particulier pour tester les appels entrants lorsque la configuration PBXnSIP sera terminée !

Configuration de PBXnSIP

L'interface d'administration de PBXnSIP est accessible au travers d'un navigateur. Par défaut elle s'exécute sur le port 80. Il suffit donc d'aller sur http://localhost et vous de vous authentifier avec le compte 'admin' (mot de passe = vide). Vous pourrez le changer ultérieurement.

La première étape consiste a enregistrer votre n° de licence. Pour cela allez dans "Settings" ==> "Licence". Copiez-collez le n° reçu et faites "Save".

Aller ensuite dans la configuration des domaines en cliquant sur "Domains". Vous y trouverez des domaines pré-configuré. Personnellement je les ai détruits afin de comprendre ce que je recréais au fur et à mesure. A vous de voir...

Il importe de configurer ces paramètres dans votre domaine:

Default Dial Plan: vous n'en avez pas pour l'instant, nous le positionnerons plus tard...
Calling own extension number goes to mailbox: No ==> Si vous laissez à "Yes", vous aurez des problèmes plus tard en utilisant le Play-on-Phone depuis Outlook Web App (Exchange appellera PBXnSIP qui appellera votre boîte vocale Exchange)
External Voice Mail System: 1000 ==> cela correspond au "Pilot Number" Exchange UM qui sera associé à votre UM IP Gateway correspondant à votre serveur PBXnSIP. J'ai volontairement utilisé le même numéro pilote que pour mon Asterisk, cela n'est pas gênant puisqu'ils ne sont pas associés à la même UM IP Gateway.

Sauvegardez ("Save") puis allez faire un tour du côté de l'onglet "Trunks".

Configuration du SIP Trunk Exchange

Ajouter un SIP Trunk de type "SIP Gateway" avec les paramètres suivants:

Name: ExchangeUM
Type: SIP Gateway
Direction: Inbound and Outbound
Domain: 192.168.101.20
Account:
Username: Anonymous
Password/Password (repeat):
Outbound Proxy: sip:192.168.101.20:5060;transport=tcp
Accept Redirect: Yes ==> requis pour le support des 302/Redirect
Trunk requires out of band-DTMF tones: Yes ==> requis pour que le DTMF fonctionne au travers du SIP Trunk Freephonie
Remote Party/Privacy Indication: RFC3325 (P-Asserted-Identity)
Assume that calls come from: 2000 ==> fausse extension qui sera créée pour rediriger vers notre UM Auto Attendant mais qui nous servira aussi à appeler depuis Exchange vers l'extérieur

Sauvegardez avec "Save" puis créer le SIP Trunk Freephonie.

Configuration du SIP Trunk Freephonie

Ajouter un SIP Trunk de type "SIP Registration" avec les paramètres suivants:

Name: Freephonie
Type: SIP Registration
Direction: Inbound and Outbound
Domain: freephonie.net
Account: 09XXXXXXXX
Username: 09XXXXXXXX
Password/Password (repeat):
Outbound Proxy: sip:freephonie.net:5060;transport=udp
Remote Party/Privacy Indication: Remote Party-Id ==> Car Freephonie utilise Asterik !!!
Send call to extension: 2000 ==> la pseudo-extension qui sera dirigée vers l'Attendant UM de notre choix

Sauvegardez avec "Save" puis allez faire un tour du côté de l'onglet "Accounts". Au final vos SIP Trunks existants ressembleront à ceci:

Configuration des extensions

Ajoutez les extensions 2001, 2002, ... dont les noms doivent correspondre aux extensions UM déclarées dans Exchange.

Ajoutez une extension 2000 avec un PIN/mot de passe top secret... Nommez la comme vous le souhaitez (peu importe, ce qui compte c'est qu'elle existe...). Une fois celle-ci créée, éditez les propriétés de cette extension afin d'ajouter un transfert inconditionnel vers le numéro pilote de votre standard automatique (j'utilise 1000 pour le Subscriber Access et 1900 pour l'Auto Attendant).

Au final, vos extensions ressembleront à ceci:

Nous y sommes presque, il nous reste à configurer les règles de routage. Allez pour cela dans l'onglet "Dial-Plans".

Configuration du Dial Plan

Ajouter un Dial Plan, nommez le comme vous le souhaitez cela n'a que peu d'importance, si ce n'est de s'y retrouver dans un environnement du "monde réel" :)

Ajoutez les règles pour les numéros pilotes 1000 et 1900 vers le SIP Trunk ExchangeUM. La règle 0* permet de composer n'importe quel numéro préfixé par 0 et de passer le reste au SIP Trunk. Par exemple, composer 00112345678 passera 0112345678 au SIP Trunk Freephonie.

Note: OCS-MS est un SIP Trunk vers mon Mediation Server OCS 2007 R2 (oui ça marche aussi très bien!). Je compose 5xxxx pour appeler l'extension xxxx déclarée dans OCS (les règles de normalisation faisant le reste).

Maintenant à vous de jouer !!!

N'oubliez pas de créer votre UM IP Gateway dans la configuration UM d'Exchange, le Hunt Group qui va bien, et de l'associer avec le bon numéro pilote au bon UM Dial Plan.

Voilà, si je n'ai rien oublié (ce que je ne garanti pas vu que j'ai tapé cet article très très vite), votre environnement est prêt. Vous devriez vous retrouver dans un environnement fonctionnellement similaire à ce que nous avions avec Asterisk/Trixbox.

Post-mortem

Grâce à notre extension fictive, nous pouvons effectuer des appels depuis Exchange (Play-on-Phone, contacter un n° externe depuis l'annuaire...) sans devoir utiliser une "ruse" comme avec Asterisk. Bon point pour PBXnSIP.

Le MWI d'Exchange 2010 ne fonctionne cependant pas mieux. Tout comme avec Asterisk, PBXnSIP refuse les messages NOTIFY en dehors d'un dialogue SIP établi. Rigolo, quand on sait que Cisco Call Manager sait très bien le faire !

TUTORIEL: Intégration Exchange 2007/2010, Trixbox/Asterisk et SIP Trunk Freephonie! (Seconde partie)

2009-11-28T21:49:00.293+01:00

Dans la première partie, j'expliquais comment intégrer Exchange UM et Asterisk (sur base d'une Trixbox) avec un SIP Trunk.

L'état des lieux suite à cette première partie est celui-ci:

Asterisk est configuré et sait router vers Exchange UM
Exchange UM sait router vers Asterisk, mais cela n'est pas encore configuré
L'appel vers une extension non disponible sera redirigé vers Exchange UM
Tout utilisateur Asterisk peut appeler le "nombre pilote" de la messagerie vocale ou du standard automatique.

Nous allons dans un premier temps nous intéresser à la partie permettant de configurer la reception d'un appel avec un SIP Trunk Freephonie et de le rediriger directement vers le standard automatique Exchange.

Configuration d'une route entrante

Dans la première partie, je disais réserver l'extension 2000 pour un usage particulier. C'est ici que celle-ci intervient.

Avant de créer une route entrante, nous allons créer deux "Custom Destinations". Pour ceci, nous allons dans le menu "PBX" ==> "PBX Settings". Dans le panneau de gauche, aller dans l'onglet "Tools" puis cliquez sur "Custom Destinations".

Ajouter les destinations suivantes:

Outlook Voice Access

Custom Destination: app-eum,ova,1
Description: Outlook Voice Access

Exchange Auto Attendant

Custom Destination: app-eum,aa,1
Description: Exchange Auto Attendant

Explications:

Une "Custom Destination" permet de déclencher un contexte personnel tel qu'une application
Ici nous exécutons les sous-routines "ova" et "aa" de notre application "app-eum" que nous avons installé dans l'article précédent - La syntaxe correspond au macro language d'Asterisk

Nous pouvons maintenant créer une route entrante. Pour ceci il suffit d'aller dans l'onglet principal "Setup" puis dans la section "Inbound Call Control" et de cliquer sur "Inbound Routes".

De là, ajouter une route entrante:

DID Number: 2000
Set Destination

Sélectionner "Custom Destinations" ==> sélectionner "Exchange Auto Attendant"

Validez et appliquez les changements.

Configuration du SIP Trunk avec Freephonie

Créez un nouveau SIP Trunk avec les paramètres suivants:

Trunk name: Freephonie

PEER Details:
type=peer
context=from-pstn
username=09XXXXXXXX
secret=motdepassetopsecret
host=freephonie.net
fromuser=09XXXXXXXX
fromdomain=freephonie.net
insecure=port,invite
nat=yes
qualify=yes
disallow=all
allow=alaw&ulaw
dtmfmode=auto

USER Context: 09XXXXXXXX

Incoming Settings:
type=user
host=freephonie.net
disallow=all
allow=alaw&ulaw
dtmfmode=auto

Register String: 09XXXXXXXX:motdepassetopsecret@freephonie.net/2000

Validez la création de la route puis rechargez la configuration d'Asterisk.

Explications:

La section "PEER Details" permet d'appeler au travers du SIP Trunk Freephonie et contrôle ce contexte
La section "User Details" permet de contrôler le contexte des appels entrants
La valeur de "Register String" permet de s'authentifier auprès de Freephonie. Petite subtilité ici, le "/2000" permet de dirgier tous les appels entrants vers la route que nous avons créé précédemment, et qui porte donc le "faux DID" 2000.

Afin que les appels entrants soient bien dirigés vers votre Trixbox, assurez-vous que vous avez configuré votre compte Free en conséquence ("Rediriger les appels entrants vers le compte SIP").

Une fois cette modification effectuée, vous pouvez tester la configuration en appelant votre n°Freephonie.

Configuration de la route sortante via le SIP Trunk Freephonie

Pour créer la route sortante, allez dans l'onglet principal "Setup" puis dans la section "Basic" et de cliquer sur "Outbound Routes".

Modifier la route sortante par défaut afin qu'elle utilise le SIP Trunk Freephonie au lieu du Zaptel. Au passage, changez les règles de numérotation afin qu'elles correspondent à vos souhaits.

Ci-dessous un exemple:

Validez la création de votre route, puis appliquer les changements de configuration.

Une fois la route créée, vous devriez être capable d'appeler un numéro extérieur depuis votre SIP phone et une extension définie dans Asterisk/Trixbox (ex 2001, 2002, ...)

Configuration d'Exchange pour le "Play on Phone" et les appels sortants

Exchange UM a une fonctionnalité nommée "Play on Phone", qui permet, via Outlook Web Access/Outlook Web App de demander à Exchange de vous appeler sur un numéro que vous lui spécifiez.

Il est aussi possible d'activer les appels sortants au travers des standards automatiques, pour appeler des numéros présents dans les listes d'adresses Exchange ou dans les contacts personnels.

Pour que les fonctionnalités d'appels sortants fonctionnent, vous devrez configurer plusieurs éléments:

Dial Codes: au niveau de l'UM Dial Plan, permettant de reformer un numéro en fonction de lu pays/région du Dial Plan et permettant de déterminer le type de destination ("In Region" ou "International");
Dial Rule Groups: au niveau de l'UM Dial Plan, permettant de transposer un numéro en fonction de sa destination en un numéro formaté tel que l'UM IP Gateway (une passerelle ou un IP-PBX) l'attend.

Voici des exemples de Dial Codes et Dial Rule Groups:

Ensuite, il suffit d'autoriser (ou pas) les appels vers ces Dial Rules. Pour le "Play on Phone", cela se configure au niveau des UM Policies (stratégies UM).

Dans mon lab, j'ai par exemple une stratégie UM me permettant d'appeler des téléphones mobiles, tandis que la stratégie par défaut n'autorise que les 0[1-59]xxxxxxxx !

A partir de là, vous avez la capacité de vous faire appeler par Exchange sur un numéro français, il suffit d'aller dans Outlook Web App puis Options ==> Téléphone ==> Appelez le numéro...

Et là me direz vous "Non ça ne marche pas!!!". En effet, il faut savoir que dans notre cas Exchange UM appelle depuis l'extension "2xxx" telles que nous l'avions défini dans notre première partie.

Or, Asterisk n'est pas un Proxy SIP, c'est un Back-to-Back User Agent (B2BUA) -- si vous activez le debug sip sur Asterisk vous verrez clairement le problème:

Le serveur Exchange envoie une INVITE au numéro externe
Le serveur Asterisk répond avec un erreur 401 (non autorisé)

Le fait est que l'appelant dans notre scénario est, par exemple, 2001. Or cette extension est connue dans Asterisk et doit être authentifiée (avec un REGISTER) avant de pouvoir émettre un appel. Ceci malgré le fait que nous ayons un contexte "from-internal" et configuré un niveau bas de sécurité "insecure=invite,port" pour notre serveur Exchange. Asterisk refuse donc le "spoofing" d'identité, ce qui ne nous arrange pas dans notre cas...

J'ai trouvé deux parades:

Ne pas mettre de "secret" sur l'extension qui doit pouvoir appeler via Exchange... L'extension n'ayant pas de mot de passe, un appel sans REGISTER préalable fonctionne!
Utiliser le fameux UMOUTDIALPREFIX (par exemple, 5)

Créer un UM Dial Plan à 5 chiffres au lieu de 4
Lors de l'activation UM des utilisateurs, préfixez l'extension UM du chiffre choisi (par exemple, 2001 devient 52001)
Ajouter un Hunt Group dont le Pilot Number est 51000 et pointe vers le nouveau Dial Plan
Ajouter un Auto Attendant dont le Pilot Number est 51900
De là, il faut tout reconfigurer côté UM :(

Ensuite, il suffit de spécifier dans le fichier /etc/asterisk/global_custom.conf:

UMOUTDIALPREFIX = 5
UMVMPILOTNUMBER = 51000
UMAAPILOTNUMBER = 51900

Il ne sera plus possible d'appeler "facilement" des extensions Asterisk depuis Exchange (ex: au travers de l'Auto Attendant). Cela requerra une petite manipulation que je ne détaillerai que succinctement ici:

Créer un contexte "from-internal-Exchange" qui inclue le contexte "from-internal" - Définir ce contexte au niveau du SIP Trunk Exchange UM
Ajouter du code Asterisk dans ce contexte qui permet de tronquer le préfixe de l'extension UM lorsque le numéro appelé correspond à 52xxx

Voici ce qui conclue donc notre seconde partie, où nous avons intégré Exchange UM derrière Asterisk/Trixbox mais aussi et surtout notre SIP Trunk Freephonie.

Il va de soit qu'il est possible d'utiliser virtuellement n'importe quel SIP Trunk, voire même plusieurs numéros si votre fournisseur le supporte.

Dans ce dernier cas, il suffira de faire une route entrante par numéro, ce que j'aurai pu faire sans extension "2000" (l'intérêt de mon extension étant de pouvoir la retirer rapidement au niveau de mon SIP Trunk sans modifier la route entrante).

Post-mortem

Ce qui fonctionne bien:

Redirections vers la messagerie vocale
Accès aux standards automatiques Exchange UM

Ce qui fonctionne, mais au prix de quelques bidouilles:

Appels sortants, à cause de la façon dont Asterisk fonctionne - je conserve dans mon lab l'astuce de ne pas avoir de secret sur mes extensions, mais cela rend l'intégration non viable dans un environnement de production, à moins que cette fonctionnalité ne soit pas utilisée.
Il serait possible de mettre en oeuvre un Proxy SIP tel que SipX (qui sait aussi faire SIP Registar) et l'utiliser pour les appels sortants. Cela ajoute un serveur dans l'environnement et complifie légèrement notre environnement de tests, mais pourquoi pas...

Ce qui ne fonctionne pas du tout:

Indicateur de messages (MWI - Message Waiting Indicator) - Une fois encore Asterisk n'autorise pas la réception de messages de type NOTIFY en dehors d'un dialogue SIP (ayant donc commençé par un INVITE) ce qui a pour conséquence un retour avec une erreur 489 (Bad request).
Un patch est censé exister, il me semblait même qu'il était incorporé dans la 1.6.0. Si tel est le cas, j'ai dû rater quelque chose :p -- Il sera vraisemblablement incorporé dans la v1.6.2.

TUTORIEL: Intégration Exchange 2007/2010, Trixbox/Asterisk et SIP Trunk Freephonie! (Première partie)

2009-11-28T17:26:00.026+01:00

Dans cette première partie nous allons aborder la configuration d'une Trixbox avec la messagerie unifiée d'Exchange 2007 ou Exchange 2010 (mon lab utilisant Exchange 2010).

Je passe les détails d'installation des deux parties, vous devez bien sûr avoir un environnement Exchange qui fonctionne parfaitement, donc avec tous les rôles requis installés (CAS, MBX, HTS, UM). Je prends donc l'hypothèse que tout fonctionne bien de ce côté là...

Votre Trixbox (http://www.trixbox.org/) doit utiliser Asterisk 1.6.x (qui supporte nativement le SIP/TCP (enfin!!!)) et disposer d'au moins une interface réseau routé vers le serveur Exchange UM. Pour la seconde partie, nous aurons besoin d'une interface réseau routée vers Internet (au travers de votre *Box) -- bien sûr ce n'est pas requis pour l'intégration Exchange UM.

Dans ma configuration j'ai donc:

eth0: interface "publique" - 192.168.1.7 ==> passerelle par défaut 192.168.1.1
eth1: interface "privée" - 192.168.100.7 ==> aucune passerelle mais une route statique car j'ai plusieurs sous réseaux vrituels (pour ajouter une route statique, lisez la documentation CentOS ici: http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-networkscripts-static-routes.html)
Assurez vous que votre Trixbox a bien accès aux deux réseaux, qu'elle peut résoudre les noms internes et externes et qu'elle a bien accès à Internet.
N'hésitez pas à passer du temps pour vérifier tous ces points
Effectuez ensuite une mise à jour complète de votre Trixbox avec la commande "yum -y update" puis redémarrez avec "reboot".

Pour administrer votre Trixbox vous devrez définir un mot de passe au compte "maint". Vous devez effectuer ceci puis un shell après installation et configuration avec la commande "passwd-maint".

L'interface d'administration de votre Trixbox est accessible par un navigateur (ex: http://192.168.1.7 depuis mon réseau "maison"). N'utilisez pas IE8 car celle-ci fonctionne mal sous le navigateur de Microsoft. Personnellement j'utilise Firefox... :°)

Définition des numéros/noms de la configuration Asterisk

Nom de mon SIP Trunk: Exchange UM
Numéro Pilote pour la messagerie vocale (Pilot Number): 1000
Numéro Pilote pour le standard automatique (Auto Attendant): 1900

Ces valeurs seront celles reprises ultérieurement dans la configuration personnalisée d'Asterisk. Si vous souhaitez utiliser d'autres valeurs, n'hésitez pas, mais n'oubliez pas de les changer où cela est nécessaire (en général elles apparaitront en rouge dans les explications/valeurs mentionnées dans l'article).

Configuration de l'environnement Asterisk

Avant toute chose, nous allons configurer certains fichiers permettant:

De définir des variables globales dans la configuration d'Asterisk, et donc d'être "propre" au regard de la logique de l'IP-PBX;
D'ajouter une macro permettant de prendre en charge la diversion vers Exchange sans traffiquer les fichiers natifs d'Asterisk/Trixbox.
D'ajouter une application permettant de prendre en charge les appels entrants depuis l'extérieur (nous verrons cela dans la configuration du SIP Trunk Freephonie).

Le but de ces manœuvres, vous l'aurez peut-être compris, est de minimiser l'impact sur la configuration initiale d'Asterisk, mais aussi d'éviter en cas de mise à jour de la Trixbox un écrasement "sauvage" de nos modifications. Nous aurons aussi la capacité de gérer les appels entrants de plusieurs manières !

Vous pouvez utiliser un shell directement sur votre serveur Trixbox, ou utiliser un client SSH pour y accéder à distance. Utilisez l'éditeur de texte de votre choix pour créer ou modifier les fichiers. Sachez qu'il est possible de modifier les fichiers existants dans la configuration Trixbox (PBX => Config file editor), mais "l'éditeur" est particulièrement simpliste et désagréable à l'usage...

/etc/asterisk/sip_general_custom.conf

Ce fichier nous permet d'ajouter le support du SIP/TCP pour Asterisk 1.6.x et autoriser les messages SIP de type redirection (302) hors d'Asterisk. Ceci est requis car Exchange UM gère la signalisation des appels entrants sur les ports 5060 (TCP) et 5061 (TLS) au travers du service Exchange UM mais redirige ceux-ci vers le service Speech Engine qui écoute sur d'autres ports (en fonction du "recyclage"), à savoir 5065/5067 en SIP/TCP et 5066/5077 en SIP/TLS.

La partie 'RTP' de la configuration n'est pas requise pour Exchange UM, mais me sert à l'intégration Asterisk/OCS 2007 R2 via mon Mediation Server. Pour information, certains IP-PBX ou certaines passerelles IP ne gèrent pas bien les appels en attente (On Hold) et ont tendance à ne plus envoyer de paquets RTP/RTCP dans ce cas. Par conséquent, le Mediation Server (qui respecte les RFC de ce point de vue) considère son partenaire HS (Hors Service) et donc clos l'appel.

; Enables SIP/TCP support for Asterisk (default post is 5060)
;
tcpenable=yes

; Enables 302/Redirect messages outside of Asterisk
; Required for Exchange UM to redirect from port 5060 (UM listening port) to 5065/5067 (Speech Engine)
;
promiscredir=yes

; Raises RTP timeouts
; This is required to predvent dropping a call when it has been put on hold
; As per RFCs, OCS 2007 R2 Mediation Server expects RTCP packets to still being sent
; while on hold and uncertified IPPBXes and IP Gateways typically don't follow this RFC rule
; All values below are in seconds.
;
rtptimeout=30 ; A value of 0 means 'infinite'
rtpholdtimeout=300 ; A value of 0 means 'infinite'
rtpkeepalive=20 ; A value if 0 means 'no keepalive'

/etc/asterisk/globals_custom.conf

; Exchange UM Configuration
UMSIPTRUNK = ExchangeUM
UMOUTDIALPREFIX =
UMVMPILOTNUMBER = 1000
UMAAPILOTNUMBER = 1900

La variable UMOUTDIALPREFIX permet d'avoir un espace d'extensions séparé entre Asterisk et Exchange. Par exemple, si les extensions Asterisk sont sous forme XXXX, alors la diversion sera faite pour l'extension Exchange XXXX. Ainsi si le prefixe est 5, l'extension UM pour l'extension Asterisk 2001 sera 52001 Dans ce cas, le Dial Plan Exchange sera configuré pour une longueur d'extension de 5.

Je reviendrai plus tard sur le pourquoi-du-comment et l'interêt du préfixe... Pour l'instant faisons sans... :)

/etc/asterisk/extensions_custom.conf

Le fichier extensions_custom.conf est inclus par le fichier extensions.conf et permet de définir des macros ou applications développées pour un besoin spécifique. C'est ce que nous allons faire ici.

Dans ce fichier, nous allons donc créer:

Une macro nommée "eum-vm" (en-tête [macro-eum-vm]) qui permet de gérer la diversion vers Exchange si l'extension est activé pour Exchange UM (nous reviendrons sur le "comment" lors de la configuration de nos extensions/utilisateurs Asterisk)
Une application nommée "app-eum" (en-tête [app-eum]) qui va permette de définir des destinations personnalisées ("Custom Destinations") que nous utiliserons plus tard. Nous distinguons deux procédures stockées dans cette application: ova et aa. "ova" pour Outlook Voice Access et "aa" pour "Auto Attendant".

[macro-eum-vm]
exten => s,1,NoOp(Entering Exchange UM Voicemail)

exten => s,n,Set(EXTTOCALL=${ARG1})
exten => s,n,Set(VMBOX=${UMDIALPREFIX}${EXTTOCALL})
exten => s,n,Set(DIALSTATUS=${ARG2})
exten => s,n,Set(REASON=unavailable)

exten => s,n,Macro(get-vmcontext,${EXTTOCALL})
exten => s,n,GotoIf($["${VMCONTEXT}"="eum"}]?eum,1)
exten => s,n,NoOp(Leaving Exchange UM Voicemail because user is not EUM-enabled)

exten => eum,1,GoSub(diversion-${DIALSTATUS},1)
exten => eum,n,SIPAddHeader(Diversion: <tel:${vmbox}>\;reason=${REASON}\;screen=no\;privacy=off)
exten => eum,n,Dial(SIP/${UMSIPTRUNK}/${UMVMPILOTNUMBER})
exten => eum,n,NoOp(Extension is reporting ${DIALSTATUS} but is not passing to Exchange UM!)

exten => diversion-BUSY,1,Set(REASON=user-busy)
exten => diversion-BUSY,n,Return

exten => diversion-NOANSWER,1,Set(REASON=no-answer)
exten => diversion-NOANSWER,n,Return

exten => diversion-CHANUNAVAIL,1,Set(REASON=unavailable)
exten => diversion-CHANUNAVAIL,n,Return

exten => _diversion-.,1,Set(REASON=unavailable)
exten => _diversion-.,n,Return

[app-eum]
exten => ova,1,NoOp("Incoming call to Exchange UM Outlook Voice Access")
exten => ova,n,Dial(SIP/${UMSIPTRUNK}/${UMVMPILOTNUMBER})
exten => ova,n,NoOp("Call is not passing to Exchange UM!")
exten => ova,n,Playback(sorry-youre-having-problems&goodbye)
exten => ova,n,Macro(hangupcall,)

exten => aa,1,NoOp("Incoming call to Exchange UM Auto Attendant")
exten => aa,n,Dial(SIP/${UMSIPTRUNK}/${UMAAPILOTNUMBER})
exten => aa,n,NoOp("Call is not passing to Exchange UM!")
exten => aa,n,Playback(sorry-youre-having-problems&goodbye)
exten => aa,n,Macro(hangupcall,)

Explications:

La macro "eum-vm" recupère le contexte de messagerie vocale de l'extension (VMCONTEXT). Si celui-ci est positionné à "eum", alors Asterisk effectuera un appel vers le numéro pilote défini (que nous configurerons dans Exchange)
L'application "app-eum" contient les procédures stockées définies par le mot-clef "exten" et les valeurs "<nom>,<ligne>,<commande>", ce qui permet d'effectuer des sauts directs depuis d'autres contextes/macros/applications.

/etc/asterisk/extensions_override_freepbx.conf

Le problème majeur d'Asterisk et de la Trixbox est le manque de souplesse dans la configuration par l'interface (Trixbox). Aussi, il n'est pas prévu de prendre en compte un autre système de messagerie vocale que celui inclus dans l'application (au contraire de SipX, qui est prévu pour...).

L'idée est donc d'utiliser le fichier extensions_override_freepbx.conf, qui permet d'écraser une macro existante par une macro "personnelle". Nous allons donc écraser la macro "exten-vm" qui gère l'appel aux extensions/groupes et redirige vers la messagerie vocale si l'extension est activée pour, ou gère l'échec de l'appel sinon...

En utilisant cette méthode, nous conservons la logique initiale d'Asterisk/Trixbox, tout en rajoutant la gestion de la messagerie vocale d'Exchange avant celle de la messagerie vocale native.

Il suffit donc de copier-coller la macro "exten-vm" depuis le fichier extensions.conf dans le fichier extensions_override_freepbx.conf et d'ajouter les lignes en rouge. L'appel a la macro "eum-vm" est donc effectué avant la vérification de la messagerie vocale intégrée. On passe les arguments EXTTOCALL et DIALSTATUS qui correspondent au numéro d'extension appelé et à la raison d'échec de l'appel.

Voici ce que ça donne:

; Ring an extension, if the extension is busy or there is no answer send it
; to voicemail
; ARGS: $VMBOX, $EXT
[macro-exten-vm]
exten => s,1,Macro(user-callerid)
exten => s,n,Set(RingGroupMethod=none)
exten => s,n,Set(VMBOX=${ARG1})
exten => s,n,Set(EXTTOCALL=${ARG2})
exten => s,n,Set(CFUEXT=${DB(CFU/${EXTTOCALL})})
exten => s,n,Set(CFBEXT=${DB(CFB/${EXTTOCALL})})
exten => s,n,Set(RT=${IF($[$["${VMBOX}"!="novm"] | $["foo${CFUEXT}"!="foo"]]?${RINGTIMER}:"")})
exten => s,n,Macro(record-enable,${EXTTOCALL},IN)
exten => s,n,Macro(dial,${RT},${DIAL_OPTIONS},${EXTTOCALL})
;
exten => s,n,Macro(eum-vm,${EXTTOCALL},${DIALSTATUS})
;exten => s,n,GotoIf($[ $["${VMBOX}" != "novm"] & $["${SCREEN}" != ""] & $["${DIALSTATUS}" = "NOANSWER"] ]?exit,return)
exten => s,n,Set(SV_DIALSTATUS=${DIALSTATUS})
exten => s,n,GosubIf($[$["${SV_DIALSTATUS}"="NOANSWER"] & $["${CFUEXT}"!=""] & $["${SCREEN}" = ""]]?docfu,1) ; check for CFU in use
on no answer
exten => s,n,GosubIf($[$["${SV_DIALSTATUS}"="BUSY"] & $["${CFBEXT}"!=""]]?docfb,1) ; check for CFB in use on busy
exten => s,n,Set(DIALSTATUS=${SV_DIALSTATUS})
exten => s,n,NoOp(Voicemail is '${VMBOX}')
exten => s,n,GotoIf($["${VMBOX}" = "novm"]?s-${DIALSTATUS},1) ; no voicemail in use for this extension
exten => s,n,NoOp(Sending to Voicemail box ${EXTTOCALL})
exten => s,n,Macro(vm,${VMBOX},${DIALSTATUS},${IVR_RETVM})

; Try the Call Forward on No Answer / Unavailable number
exten => docfu,1,Set(RTCFU=${IF($["${VMBOX}"!="novm"]?${RINGTIMER}:"")})
exten => docfu,n,Dial(Local/${CFUEXT}@from-internal/n,${RTCFU},${DIAL_OPTIONS})
exten => docfu,n,Return

; Try the Call Forward on Busy number
exten => docfb,1,Set(RTCFB=${IF($["${VMBOX}"!="novm"]?${RINGTIMER}:"")})
exten => docfb,n,Dial(Local/${CFBEXT}@from-internal/n,${RTCFB},${DIAL_OPTIONS})
exten => docfb,n,Return

exten => s-BUSY,1,NoOp(Extension is reporting BUSY and not passing to Voicemail)
exten => s-BUSY,n,GotoIf($["${IVR_RETVM}" = "RETURN" & "${IVR_CONTEXT}" != ""]?exit,1)
exten => s-BUSY,n,Playtones(busy)
exten => s-BUSY,n,Busy(20)

exten => s-NOANSWER,1,NoOp(Extension is reporting NOANSWER and not passing to Voicemail)
exten => s-NOANSWER,n,GotoIf($["${IVR_RETVM}" = "RETURN" & "${IVR_CONTEXT}" != ""]?exit,1)
exten => s-NOANSWER,n,Return

; Anything else comes here
exten => _s-.,1,Noop(IVR_RETVM: ${IVR_RETVM} IVR_CONTEXT: ${IVR_CONTEXT})
exten => _s-.,n,GotoIf($["${IVR_RETVM}" = "RETURN" & "${IVR_CONTEXT}" != ""]?exit,1)
exten => _s-.,n,Playtones(congestion)
exten => _s-.,n,Congestion(10)

; Short burst of tones then return
exten => exit,1,Playback(beep&line-busy-transfer-menu&silence/1)
exten => exit,n(return),MacroExit()

Rechargement de la configuration Asterisk

Maintenant que nous avons configuré nos personnalisations, il est nécessaire qu'elles soient prises en compte :)
Le plus simple est de se connecter au shell et de taper asterisk.reload ou alors asterisk -r -x reload.

Création du SIP Trunk et de la route vers Exchange

Maintenant que la configuration est prise en compte, nous allons créer notre SIP Trunk vers Exchange.

Dans la console Trixbox, allez dans le menu PBX ==> PBX Settings ==> (Basic) ==> Trunks. Ajoutez alors un SIP Trunk ("Add SIP Trunk") avec les paramètres suivants:

Si vous voulez faire un copier-coller:

type=friend
host=192.168.101.20
context=from-internal
transport=tcp
insecure=invite,port
qualify=yes
canreinvite=no
disallow=all
allow=alaw&ulaw
dtmfmode=auto

Bien sûr, vous devez modifier l'attribut "host" en spécifiant l'adresse IP ou le nom d'hôte complet de votre serveur Exchange UM (ex: exum.domaine.local). J'utilise l'adresse IP pour m'affranchir de problèmes éventuels de résolution de nom, et par fainéantise aussi... :)

Explications:

context ==> Le contexte "from-internal" permet à Exchange d'appeler au travers d'Asterisk. L'utilisation d'un autre contexte est possible, mais Exchange ne sera pas autorisé à appeler vers l'extérieur à moins de personnaliser le contexte pour y inclure des routes.
insecure ==> permet d'effectuer des dialogues SIP depuis Exchange UM (pour les appels sortants) en mode "anonyme" -- ici, nous restreignons sur le verbe "INVITE" (qui initie un dialogue SIP) et sur le port. Certains utilisent "insecure=very" qui fonctionne aussi mais qui pour le coup est vraiment non sécurisé !
transport ==> permet de dire à Asterisk que ce SIP Trunk utilise le SIP/TCP, car sinon le transport par défaut est UDP.
disallow/allow ==> permet de retirer tous les codecs supportés puis de n'autoriser que G.711 a-Law et u-Law dans la négociation média (protocole SDP encapsulé dans le dialogue SIP)
dtmfmode ==> permet de négocier le meilleur mode pour la prise en charge du Dial Tone Multi-Frequencing au travers du codec utilisé. J'ai mis cette valeur car j'avais des soucis depuis des appels effectués par mon GSM. Il est important aussi que cela soit géré au niveau du SIP Trunk depuis Freephonie (ou tout autre SIP Trunk depuis lequel on accepte de router vers Exchange)

Voici notre SIP Trunk créé, il suffit maintenant de créer une route vers Exchange. Dans la console Trixbox, allez dans le menu PBX ==> PBX Settings ==> (Basic) ==> Outbound Routes.

Ajoutez alors une route ("Add Route") avec les paramètres suivants:

Explications:

Route Name: ExchangeRoute ==> mettez le nom que vous voulez :)
Dial Patterns: 1XXX ==> Permet de router tous les numéros à 4 chiffres commençant par 1. Mes numéros "pilote" étant 1000 et 1900, ceci explique cela...
Trunk Sequence ==> choissez le SIP Trunk ExchangeUM créé précédemment.

Assurez-vous que la route est prioritaire par rapport aux routes existantes, dont en particulier la route "Outbound". Une fois toutes ces modifications appliquées, cliquez sur "Apply configuration changes" en haut de la console de gestion du PBX.

Configuration des extensions/utilisateurs Asterisk

Maintenant que nous sommes prêts à nous connecter avec Exchange, nous allons créer des extensions/utilisateurs Asterisk. Dans mon environnement les extensions sont dans la plage 2001-2999, j'ai donc créé les extensions 2001, 2002, 2003... Je réserve 2000 pour un usage ultérieur (gestion des appels entrants).

Dans la console Trixbox, allez dans le menu PBX ==> PBX Settings ==> (Basic) ==> Extensions. Ajoutez alors aux moins deux extensions avec les paramètres suivants:

Device Type: Generic SIP Device
Extension: 2XXX (où XXX est compris entre 001 et 999)
Display Name: Ce que vous voulez
Voicemail & Directory:

Status: Enabled
VM Context: eum

Voici ce que ça donne:

Explications:

Activation de la prise en charge de la messagerie vocale pour cette extension
Le VM Context permet de mettre le mot clef "eum" permettant à notre macro d'effectuer la diversion vers le numéro pilote Exchange UM. Ainsi, il est possible de basculer simplement du système de messagerie vocale intégré à celui d'Exchange... Pratique ;)

Notes:

Trixbox va vous avertir de deux choses:

Si vous n'avez pas défini de "secret" (en général il s'agit d'un PIN), l'extension pourra émettre des appels sans être authentifiée. Bien sûr dans le monde réel, mettre un mot de passe est une bonne idée, mais nous verrons plus tard pourquoi cela vas nous poser un problème...
Vous n'avez pas mis de "secret" sur la messagerie vocale... Pour cause, le PIN est géré par Exchange. Vous pouvez en mettre un ici, mais il ne servirait à rien.

N'oubliez pas de valider vos changements à coups de "Apply configuration changes" en haut de la console de gestion du PBX.

Configuration d'Exchange

Dans Exchange, nous devons configurer:

Un UM Dial Plan

Le mien est nommé FR-0001 et configuré ainsi:

Type: TelephoneExtension
Voip Security: Unsecured
Number of digits in extensions: 4
Sur Exchange 2010, un "Country/Region Code" est requis, utilisez 33 pour la France.

Une UM IP Gateway

Name: Trixbox
IP address: 192.168.x.y (l'IP interne de votre Trixbox)
Ne pas associer un UM Dial Plan par défaut (autant faire propre et l'associer au travers du Hunt Group)

Un UM Hunt Group

Name: HG-0001
Pilot Number: 1000
Associated Dial Plan: FR-0001

Un UM Auto Attendant

Name: FR-0001_AA
Pilot Number: 1900

Notes:

Ajoutez les packs de langue de votre choix sur votre serveur Exchange UM
N'oubliez pas d'associer votre serveur Exchange UM à l'UM Dial Plan nouvellement créé !!!
Choisissez la langue par défaut de votre Dial Plan et de votre Auto Attendant une fois le serveur associé car la liste des langues disponibles est générée en fonction des langues disponibles sur le (ou les) serveur(s) associé(s)
N'oubliez pas de configurer la stratégie créée par défaut (FR-0001 Default Policy) afin de simplifier la securité des codes PIN (par exemple: 4 digits, empêcher l'expiration, autoriser les PIN non complexes (cocher "Allow common patterns in PIN")

Attendez quelques minutes que la configuration soit prise en compte sur le serveur UM.

Activez alors la Messagerie Unifiée sur vos utilisateurs dont l'extension téléphonique correspond avec celle d'Asterisk/Tribox. Assurez vous que l'utilisateur A correspond à l'extension A, utilisateur B à l'extension B, etc etc...

Premiers tests, commençons (enfin) à "jouer" !

Voici les actions permettant de valider que votre intégration est un succès:

Connectez un SIP Phone type X-Lite, eyeBeam (payant!) ou autre... à votre Asterisk. Utilisez par exemple l'extension 2002.
Appelez l'extension 2001. Celle-ci étant indisponible, la diversion va s'effectuer vers Exchange UM. Magique, vous pouvez laisser un message !
Composez maintenant l'extension 1000, vous tombez sur Outlook Voice Access

Entrez un numéro d'extension, par exemple 2001 puis le PIN Exchange UM correspondant
Pilotez votre BàL avec la voix !

Composez maintenant l'extension 1900, vous tombez sur votre Auto Attendant

Prononcez le nom de quelqu'un pour être mis en relation!
Selon la configuration de votre Auto Attendant, il faudra recourir à quelques modifications...

Avant de conclure cette première partie, voici un aperçu de ma configuration:

Vous l'autrez compris, les élements ci-dessous vont permettre d'introduire la configuration des appels sortants d'Exchange UM vers le reste du monde.

Nous verrons donc ces points dans la prochaine partie:

Configuration du SIP Trunk vers Freephonie
Configuration du routage Sortant/Entrant au travers du SIP Trunk Freephonie
Configuration des appels sortants depuis Exchange
Configuration des appels entrants vers Exchange

D'ici là, amusez vous bien !!!!

Quelques astuces si cela ne fonctionne pas:

Depuis un shell Linux, utilisez asterisk -r pour vous connecter à la console Asterisk
De là, vous verrez "sans rien faire" les commandes liées aux macros et contextes s'exécuter lors d'un appel. Assurez vous que les macros que nous avons définies au début de cet article soient bien prises en compte.
Si vous voulez diagnostiquer les messages SIP, utilisez sip set debug ip 192.168.x.x (où bien sûr 192.168.x.x correspond à l'adresse IP de votre serveur Astrisk/Trixbox)

INFO: Exchange Server 2010 disponible sur MSDN!

2009-11-10T09:28:00.002+01:00

Ayet, Exchange Server 2010 RTM est "officiellement" disponible:

Microsoft a publié hier l'ISO d'Exchange Server 2010 sur MSDN.
Et la version d'évaluation est disponible sur Technet.

Le Père Noël est en avance cette année... :)

INFO: Exchange Server 2007 sera supporté sur Windows 2008 R2

2009-11-04T22:38:00.008+01:00

Retournement de situation alors qu'Exchange Server 2010 est tout juste lancé officiellement!

Contrairement à ce qui avait été annoncé il y a quelques semaines, l'équipe produit Exchange Server a décidé de supporter Exchange Server 2007 sur Windows Server 2008 R2, l'annonce vient d'être effectuée sur le site de la DevTeam Exchange. Le support se fera au travers d'une mise à jour, qui sera disponible dans le courant de l'année 2010 (aucune date, ne serait-ce qu'estimée pour l'instant).

Drôle de paradoxe: d'un côté Windows Server 2008 R2 étant un système moderne et performant, ne pourra apporter que des performances accrues à Exchange Server 2007... De l'autre, le support de ce système pour la version "n-1" d'Exchange Server risque de freiner l'adoption d'Exchange Server 2010 (l'argument Windows Server 2008 R2 était tout de même un excellent argument :p). De plus, il existait de réelles questions techniques pour lesquelles le support de Windows Server 2008 R2 n'était pas souhaité (en particulier sur les changements DCOM).

Non, Exchange Server 2007 n'est pas mort :) !!! Mais la DevTeam et le support Microsoft vont sans doute difficilement apprécier de maintenir/supporter un produit sur trois systèmes d'exploitation différents [NDLR: je ne compte pas Windows Server 2003 R2] (ce qui sera une première pour Exchange Server !).

Côté OCS 2007 R2, rien de neuf pour l'instant. Pour avoir moi-même testé certains rôles, tout ne fonctionne pas avec Windows Server 2008 R2. Concernant les services de Pool, je n'ai rien remarqué de spécial (mais je n'ai pas tout testé). Pour CWA R2 c'est une autre histoire: bien qu'arrivant à s'installer et à s'activer, il est impossible de créer un site Web... question de Metabase (IIS 7.0 VS IIS 7.5). Bref, ce n'est pas gagné... :)

Affaire à suivre...

INFO: Mise à jour cumulative #3 pour OCS 2007 R2 et MOC 2007 R2

2009-11-01T21:38:00.009+01:00

MAJ: Microsoft a publié ce Mardi 3 Novembre un gros executable contenant toutes les mises à jour du QFE3. L'executable s'appelle ServerUpdateInstaller.exe et est téléchargeable sur la page résumant les liens de téléchargement du QFE3.

ATTENTION toutefois: l'utilitaire de mise à niveau n'effectue pas la mise à jour de la base, vous devez récupérer le MSI OCS2009-DBUpgrade.msi - Celui-ci ne s'applique qu'à un Pool, puisqu'il patche la base de données SQL afin de modifier le schéma. Dans le cadre d'un Pool Enterprise, inutile donc de l'appliquer sur chaque serveur frontale. N'oubliez pas que cette màj de la base est requise depuis le QFE2 afin que les correctifs s'appliquent effectivement (sinon certains bugs ne sont pas corrigés).

Microsoft a publié le QFE3 pour OCS 2007 R2, dont le Build passe donc en 56. Cette mise à jour permet d'intégrer le client IM présent dans Outlook Web App d'Exchange Server 2010 avec OCS 2007 R2. Afin de faire fonctionner les deux produits ensemble, la mise à jour de l'UCMA API 2.0 doit être déployée partout (sur les serveurs d'Accès Client Exchange 2010 _et_ sur les serveurs OCS 2007 R2).

Au menu, quatre mises à jour datées d'Octobre 2009, qui viennent en sus des mises à jour de Juillet et Avril.

L'intégralité des articles liés est ici. Les liens de téléchargement des mises à jour sont quant à eux ici.

Côté client:

Une mise à jour Communicator 2007 R2
Et une mise à jour de Communicator 2007 R2 Phone Edition (build 55)
La console Live Meeting 2007 et l'Add-in Outlook étaient déjà en Build 143, et fonctionnent d'orès déjà avec Outlook 2010 (testé sur la Beta 2)

TUTORIEL: Construire un répartiteur de charge pour vos labs!!!

2009-11-01T03:55:00.016+01:00

Bon, cela fait maintenant quelques mois que j'avais commençé à penser à rediger un sujet sur la répartition de charge avec OCS 2007 R2 et Exchange... mais je n'avais pas le temps.

J'avais donc mis en place dans mon lab un répartiteur de charge (aussi appelé HLB pour "Hardware Load Balancer" bien qu'il n'ait rien de matériel :)), au début un peu bancal, mais fonctionnel. Mon souci principal était qu'il ne supportait pas le mode SNAT pour OCS 2007 R2. Il tournait sur une OpenSUSE 11.1 élaguée de ses fonctions principales. La distro étant un peu vieillotte, j'ai du mettre tout un tas de mise à jour, et recompiler pas mal de packages afin d'arriver à un resultat satisfaisant... mais trop long à documenter.

N'arrivant pas à dormir ce soir, je me suis mis devant Kamelott Live VI et commençé à tout refaire, pour cela j'ai cherché une distribution Linux récente et légère. Mon choix s'est porté sur une Ubuntu Server 9.10 (basé sur Debian je crois).

Mon HLB tourne donc sur mon serveur Hyper-V R2, avec 128 Mo de mémoire, en pleine charge, je suis à 70 Mo de mémoire consommée... dur dur =°)

Le principe:

Une machine virtuelle Linux, basée sur un noyau 2.6.18 ou + car ce noyau support le "Transparent Proxy" de manière stable depuis cette version;
Pour activer les fonctionnalités de type SNAT, il faut "mangler" le protocole TCP et le manipuler de manière à arriver à devenir "transparent", cela est fait avec iptables (version 1.4.5);
Deux réseaux: une réseau frontal (où l'adresse virtuelle est déclarée) et un réseau dorsal (où se situent les serveurs mis en répartition de charge) -- le HLB joue à la fois un rôle de routeur, répartiteur et "translateur";
Pour le service de répartition de charge, je me suis basé sur l'excellent HAProxy (http://haproxy.1wt.eu/) qui est d'ailleurs utilisé dans l'appliance "Loadbalancer.org" (cette dernière utilise je pense sensiblement mêmes techniques que j'ai utilisées, mais eux sont des "pros" du réseau donc j'imagine que leur appliance fonctionne mieux ;))

Le reste est de la configuration. Dans l'exemple fourni ci-dessous, je ne respecte probablement pas toutes les "Best Practices", mais ça fonctionne plutôt pas mal !

Petite surprise, j'ai rajouté la répartition de charge Exchange 2010, avec le RPC ClientAccessArray (perso, j'adore!!!).

Voici donc les instructions, elles sont en anglais car j'en ai d'abord fait profité mes collègues Avanade et mes pairs MCM. Nul besoin de mentionner qu'il faut un minimum de connaissances Linux, et quand même quelques bonnes connaissances OCS et Exchange 2007/2010 car je n'ai presque rien détaillé de ce côté (désolé, j'essayerai de me ratrapper plus tard =)).

Cliquez sur le lien ci-dessous pour accéder aux fichiers de configuration et aux instructions (que j'essayerai de maintenir à jour au fur et à mesure de mes périgrinations =°)).

INFO: OCS/LCS/MOC et la mise à jour KB974571... suite et fin !

2009-10-28T21:47:00.004+01:00

Microsoft a mis a disposition un fix permettant d'installer la mise à jour de sécurité KB974571 sur des serveurs LCS 2005/OCS 2007/OCS 2007 R2.

Il est recommandé d'appliquer le fix (il s'agit d'un petit utilitaire appelle 'ocsasnfix.exe') avant l'installation du correctif KB974571.

L'article de la base de connaissance a été mis à jour en conséquence.

LCS/OCS/OCS R2 -- ATTENTION, ne pas installer la MàJ Windows KB974571

2009-10-14T11:54:00.013+02:00

(mise à jour: la DevTeam a publié l'information sur son blog officiel -http://communicationsserverteam.com/archive/2009/10/14/632.aspx)

Microsoft a publié dans son "Patch Tuesday" du 13/10 un ensemble de correctifs de securité de niveaux "Important" ou "Critique".

Cependant, suite à l'installation de ces correctif sur mon lab, mon service Front-End ne démarrait plus avec une erreur "Evaluation period has expired, etc etc".

Bref, il va sans dire que je n'ai pas de version d'évaluation, donc j'ai supprimé toutes les mises à jour installées, et cela a résolu le problème.

J'ai donc réinstallé toutes les MàJ une par une, pour finalement arriver à la KB974571 (http://support.microsoft.com/kb/974571) qui consititue une mise à jour de la CryptoAPI de Windows. Cette même API est utilisée afin de générer/valider la clef qui gère la licence sur le service Front-End. Cela ressemble donc fort à un problème de rétrocompatibilité des algorithmes de chiffrement.

Apparement, je ne suis pas tout seul: certains collègues bloggeurs reportent exactement le même problème, et nos IT l'ont rencontré aussi sur notre environnement de pré-production/qualification.

Il faut savoir aussi que le problème peut toucher les environnements LCS 2005 et OCS 2007.

Comme quoi, avoir un environnement de test est, et restera toujours une excellente idée :)

Les équipes produit Windows et OCS sont en cours d'analyse de la cause du problème. La seule méthode de résolution pour l'instant est de désinstaller la mise à jour.

TUTORIEL: Exchange 2010 - Intégration OCS dans OWA

2009-10-12T00:00:00.075+02:00

Depuis la RC1, je me suis mis un peu plus à Exchange 2010 et ses nouvelles fonctionnalités, sauf une: l'intégration E2010/OCS 2007R2. En effet, tant qu'E2010 n'était pas RTM, nos chers IT admins à Seattle ne voulaient pas nous donner les composants d'intégration, alors je me suis dit "wait'n'see"...

Nous allons donc voir comment intégrer l'Outlook Web App d'Exchange 2010 avec OCS 2007 R2. Et comme Microsoft fait bien les choses, c'est très simple! :)

Pré-requis

Vous devez d'abord avoir:

Un rôle de serveur d'accès client (CAS: Client Access Server) pleinement fonctionnel et disposant d'un certificat WebServer ou équivalent, et dont le sujet (attribut Subject Name) est un nom d'hôte valide - Il ne s'agit pas nécessairement du certificat utilisé par OWA. Ce qui importe, c'est de bien noter le nom complet qualifié dans cet attribut, car c'est avec ce nom que le serveur Exchange se présentera au serveur OCS.
Vous devez avoir au moins un pool OCS 2007 R2 déployé et lui-même parfaîtement fonctionnel (NDLR: l'intégration n'est pas supportée avec OCS 2007).
Cela peut paraîtré évident, mais le(s) compte(s) utilisé(s) pour se connecter doit être activé pour Exchange et OCS. Assurez-vous que vous pouvez vous connecter avec Communicator 2007/R2 avec vos comptes de test.

Installation des binaires

Le composant est livré sous la forme d'un MSI, qui contient les binaires suivants:

.NET Framework 3.5.1 x64
Visual C++ 2008 x64 redist
Unified Communications Managed API 2.0 (UCMA 2.0)
CWAOWASPP.msi (le composant OCS pour OWA, il s'agit simplement d'une DLL qui s'enregistrera) disponible ici: http://www.microsoft.com/downloads/details.aspx?familyid=CA107AB1-63C8-4C6A-816D-17961393D2B8&displaylang=en

Tout cela est très famillier n'est-ce pas :) - Oui, à l'exception du dernier, les binaires à installer correspondent aux binaires d'OCS 2007 R2. Après installation, une mise à jour UCMA 2.0 sera nécessaire (j'ai un build 3.5.6907.45 qui n'est pas encore disponible, j'essayerai avec le build 37 tout de même par curiosité).

MAJ: Je confirme que l'UCMA 2.0 build 45 est un minimum requis pour que le chat fonctionne entre un client OWA et un client MOC, sinon seule la présence est fonctionnelle.

Tous ces composants doivent être installés dans l'ordre ci-dessus, sur chaque serveur ayant le rôle Client Access, et sur lesquels la fonctionnalité devra être activée. Bien évidemment, il est nécessaire de déployer le composant sur chaque serveur d'une même ferme. Je passe ici leur installation: sur Windows 2008 R2, le Framework 3.5.1 est déjà installé puisque c'est un pré-requis Exchange 2010.

Configuration du composant

Une fois tout ce petit monde installé, il suffit d'aller modifier le fichier Web.Config de l'application OWA. Pour cela, ouvrez un Exchange Management Shell, et tapez ceci:
notepad "$exinstall\ClientAccess\OWA\Web.Config"
Et cherchez la balise XML nommée: "IMPoolName". Il y a trois valeurs à spécifier:

IMPoolName: le nom complet qualifié (FQDN) du Pool sur lequel se connecter - Personnellement j'utilise un Pool Director afin de rediriger la connection auprès du Home Pool légitime auquel appartient l'utilisateur. C'est presque essentiel dans un environnement à Pools multiples et simplifie énormément la configuration;
IMCertificateIssuer: le nom distingué (Distinguished Name) de l'autorité de certification ayant émis le certificat à utiliser pour la connection MTLS sortante;
IMCertificateSerialNumber: le numéro de série du certificat à utiliser.

Attention: les valeurs IMCertificateIssuer et IMCertificateSerialNumber sont très capricieuses!

IMCertificateIssuer doit correspondre exactement à la valeur de la propriété "Issuer" du certificat;
IMCertificateSerialNumber doit être au format "XX XX XX ... XX XX" c'est à dire, avec un espace entre chaque octet du noméro de série.

Vous avez deux techniques pour récupérer les bonnes valeurs:

Les copier à partir d'une MMC "Certificates" qu'il vous faudra créér à la main au préalable (se référer à mes posts précédents);
Utiliser la cmdlet Get-ExchangeCertificate -- Bien sûr c'est ma méthode préférée =°)

Voici une capture:

N'oubliez pas de répéter l'opération sur tous les CAS sur lesquel activer l'intégration...

Configuration d'OCS 2007 R2

Maintenant qu'Exchange est configuré, passons à OCS 2007 R2. Encore une fois c'est très simple, et dans l'absolu, complètement automatisable via le WMI.

Il suffit d'ajouter le nom complet qualifié du certificat configuré dans le Web.Config d'OWA, car je le rappelle, c'est avec ce nom que le serveur Exchange se présentera.

Note: le serveur OCS 2007 R2 doit faire confiance au certificat utilisé par le serveur Exchange, et vice-versa. Il est recommandé d'utiliser des certificats émis par la même autorité de certification, ou du moins, par une autorité de certification faisant partie de la même chaîne de certification (la racine étant bien évidemment une racine de confiance). Dans l'absolu, il serait techniquement possible d'utiliser le certificat auto-signé du serveur Exchange, mais cela ne serait pas viable dans la durée, et probablement non supporté par Microsoft.
Pour configurer l'autorisation, effectuez les manoeuvres suivantes:

Ouvrez la MMC OCS 2007 R2;
Selectionnez le Pool référencé dans le fichier Web.Config, effectuez un clic-droit puis selectionnez Properties ==> Front-End Properties;
Dans l'onglet "Authorized Hosts", ajoutez une entrée correspondante au nom complet qualifié du certificat du serveur CAS Exchange, et assurez vous que "Treat as Authenticated" et "Throttle as Server" sont cochées;
Validez et fermez la MMC OCS 2007 R2.

Il est normalement inutile de redémarrer les services "Front-End" du(des) serveur(s) du Pool, attendez simplement quelques minutes que la configuration soit appliquée (5 minutes max après une réplication AD).

Activation de la fonctionnalité

La fonctionnalité s'active ou se désactive de deux manières:

Activation par application Web OWA
Activation par segmentation dans une stratégie OWA (OwaPolicy)

Il va de soit que l'activation sur le serveur doit être faite avant, la stratégie OWA par défaut autorisant l'intégration IM dans OWA.

L'activation se fait par la commande Set-OWAVirtualDirectory avec les arguments "InstantMessagingType" et "InstantMessagingEnabled"

InstantMessagingType peut être "None", "OCS" ou "MSN";
InstantMessagingEnabled est un Booléen ($true ou $false).

La commande sera donc simplement celle-ci:

Set-OwaVirtualDirectory SERVEUR\WebApp -InstantMessagingType OCS -InstantMessagingEnabled $true

Une fois la WebApp configurée, il est nécessaire de la recycler (par la console IIS) ou plus simplement de redémarrer les services IIS sur le serveur CAS, à l'aide un désormais classique "iisreset /noforce" (si votre lab peine un peu, faites un iireset /stop puis un iisreset /start).

Testez l'intégration

Observez les eventlogs "Application" sur votre CAS ==> assurez vous qu'il n'y a aucune erreur de configuration, que l'application trouve bien la DLL d'intégration, etc etc... en cas de pépin, vous le verrez tout de suite.

Utilisez deux clients, ou connectez vous depuis un serveur quelconque à OWA, avec deux comptes, bien évidemment. Vous pouvez aussi utiliser deux navigateurs depuis le même poste... =°)

La première connection est toujours un peu longue, surtout dans un lab où la mémoire fait défaut. Après quelques secondes, vous retrouverez vos contacts, votre indicateur de présence ainsi que celui des autres utilisateurs. C'est simple mais tellement efficace :)

Voici une petite capture:

Et une autre avec un client MOC:

Voilà, Exchange 2010 sera disponible dans une dizaine de jours, j'aurais aimé pouvoir allez au TechEd, mais comme l'on dit chez nous "Business FIRST !!!" -- en effet, nous allons délivrer un projet Exchange 2010 chez un gros client et je ne tiens pas à rater ça! ;)

Mettre à jour votre organisation Exchange 2010 RC1 vers la RTM

2009-10-10T11:22:00.008+02:00

En tant que privilégiés du programme TAP, nous avons reçu les binaires Exchange 2010 RTM (build 21) !!!

Pour ceux qui mettrons leur lab à jour prochainement, voici les actions à exécuter, vous aller voir, c'est très simple:

Préparez à nouveau votre Active Directory: le plus simple est de faire un setup.com /preparead - ou en plusieurs étapes selon votre habitude/topologie;
Effectuez une mise à jour de vos serveurs/rôles selon le principe d'une mise à jour classique (ex: Service Pack) avec la commande setup.com /mode:upgrade

Client Access Servers
Hub Transport Servers et Edge Transport Servers
Mailbox Servers
Unified Messaging Servers

Sur mon lab, sous dimensionné, la mise à niveau a pris moins de 5 minutes (depuis un partage réseau de surcroit !!!). C'est hallucinant de voir la performance de Windows Server 2008 R2 en action, grâce aux pré-requis intégrés, tels que le .NET Framework, PowerShell v2, WinRM, etc...

Et voilà ce que ça donne :)

Exchange 2010 est RTM !!!

2009-10-08T21:53:00.006+02:00

Alors que les MSDays viennent de se terminer en France, et que le TechEdh va bientôt avoir lieu (début Novembre à Berlin), l'équipe produit Exchange vient d'annoncer la finalisation du code d'Exchange 2010 RTM (Release To Manufacturing).

Une grande nouvelle donc, que nous attendions tous avec impatience ;)

Plus d'informations sur le blog de la DevTeam:
http://msexchangeteam.com/archive/2009/10/08/452775.aspx

Parmi les nouveautés, nous noterons en particulier:

Performances et capacité de haute disponibilité accrues, en combinant les couches "cluster" Windows, à la réplication continue améliorée depuis Exchange Server 2007 en introduisant le concept du Groupe de Disponibilité de Bases de Données (ou DAG, pour "Database Availability Group" en anglais).
Outlook Web Access, pardon, Outlook WebApp, qui s'enrichit d'une myriade de nouvelles fonctionnalités "out of the box" et très similaires à Outlook 2010 - Et qui introduit l'"Exchange Control Panel", une application Web permettant de gérer de manière simple des listes de distributions, boîtes aux lettres, etc... pour les administrateurs ou des administrateurs délégués.
Accès OWA Premium depuis IE, Firefox et Safari, grande démonstration d'ouverture de la part de la firme de Redmond.
Utilisation de PowerShell v2 et du PowerShell Remoting, mise en oeuvre des RBAC (Role-Based Access Control) qui permet de déléguer plus finement l'administration et de limiter (ou étendre) les outils/cmdlets.
Amélioration du rôle Unified Messaging, pour une reconnaissance vocale en français (entre autres), la possibilité d'utiliser un assistant personnel automatique, l'indicateur de message natif avec des IPPBX autres qu'OCS 2007/R2.
Les fameux MailTips, les surdoués de la bonne pratique de l'usage d'une messagerie :)
La vue sous forme de dissussions (Threading), dans OWA et Outlook 2010, tout le monde adore !
La recherche instantanée, et encore plein d'autres...

A dans quelques semaines, préparez vous à faire chauffer vos connexions Internet, préparez vos machines virtuelles, ça sent bon le lab "nouvelle génération" ;)

Pour notre part chez Avanade, nous étions sur le code de la RTM mais sans les corrections liées à l'internationalisation. Nous allons donc mettre à niveau dès que Microsoft nous aura fourni les binaires complémentaires (avant même la mise à disposition sur MSDN ou consors ;)) et donc pouvoir démarrer notre pilote "Enterprise Voice" avec la messagerie unifiée Exchange 2010 dans la foulée. Que du bonheur =°)

Configurer la passerelle XMPP pour interconnexion avec Jabber et GMail/GTalk

2009-10-04T13:27:00.005+02:00

Preuve de la volonté de l'équipe produit Office Communications Server/Unified Communications de favoriser l'interconnexion avec les IM alternatifs (utilisant le XMPP au lieu du très standard SIP... :P), celle-ci a publié sur sont blog deux articles décrivant de manière simpe la configuration de la passerelle XMPP pour OCS. La méthode décrite est bonne, mais un peu simpliste et avec quelques erreurs, méfiez vous des nom d'hôtes/enregistrements DNS décrits.

Voici les liens:

GMail: http://communicationsserverteam.com/archive/2009/10/01/599.aspx
Jabber: http://communicationsserverteam.com/archive/2009/10/02/620.aspx

De mon côté, ma passerelle de lab est configurée et la connexion à Jabber et GMail fonctionne. Cependant, vu que mon lab n'a pas de domaine public, c'est unilatéral (donc ça ne sert à rien :)).

Je suis donc en train de m'installer un serveur XMPP Jabber Open Source... Jabber2. Le hic, c'est que je n'ai aucune idée de s'il sera compatible avec la passerelle ou non. Cisco ayant acquis Jabber, l'ouverture de ce dernier va devenir compliquée... ( au passage: RIP Tandberg :( )

Bref, je vous tiens au courant dès que j'ai pu avancer un peu!

Changement dans les licences "PIC" pour OCS et passerelle XMPP

2009-10-01T19:52:00.008+02:00

Comme vous le savez certainement déjà, la fédération avec la messagerie instantanée publique Windows Live est gratuite (dès lors que vous disposer des serveurs nécessaires à l'interconnexion) depuis Juin dernier.

Microsoft a annoncé la gratuité de la fédération avec AOL (à partir d'une CAL Standard ou via la Software Assurance).

En outre, le prix de l'abonnement pour fédération avec Yahoo! a été réduit de 50%, conséquence de la gratuité avec les autres fournisseurs.

Enfin, Microsoft a aussi publié la passerelle XMPP tant attendue permettant la fédération avec Jabber (à partir de la version 5.4) et Google Talk. Cette passerelle est un composant d'OCS 2007 R2 et fait donc partie de la suite: cela signifie que si vous avez déjà des licences OCS 2007 R2, vous n'avez aucune licence supplémentaire à acheter pour déployer ce composant, de même aucune licence cliente additionnelle n'est nécessaire, et ce composant est pleinement supporté par Microsoft.

Cependant, il sera nécessaire de déployer cette passerelle sur un serveur à part, et devra s'interconnecter avec un ou plusieurs serveurs "Edge" dans le réseau de périmètre (fédération avec Jabber externe/public) ou dans une "zone neutre" (fédération avec Jabber interne).

Pour ceux qui ne savent pas ce qu'est le XMPP, il s'agit simplement d'un protocole (eXtensible Messaging and Presence Protocol) alternatif à notre bon vieux SIP (et le XML intégré dedans entre autres) utilisé par OCS.

Passerelle XMPP pour OCS 2007 R2:
http://www.microsoft.com/downloads/details.aspx?FamilyID=aa560bfe-9960-473a-bfb8-53bff678cec4&displaylang=en

Que des bonnes nouvelles donc! :)

Le communiqué de presse complet d'Eric Swift est disponible ici (en anglais) :
http://www.microsoft.com/presspass/features/2009/oct09/10-01ucinterop.mspx

(Informations issues des release notes)

Limitations de la passerelle XMPP:

Messagerie instantanée et présence de base, mode texte (les autres modalités ne sont pas supportés) en peer-to-peer seulement (pas de conférence, même IM);
Les notes depuis les clients Communicator 2007 ne sont pas supportées;
Fonctionne seulement avec OCS 2007 R2 et OCS 2007, pas de support pour LCS 2005;
Les messages émis depuis OCS/R2 vers la passerelle n'aboutissent que sur le 1er point de présence du contact;
La souscription à la présence d'un utilisateurs OCS/R2 via la passerelle (ex: depuis Jabber ou Google) ne fonctionne que lorsque la présence de l'utilisateur OCS/R2 est modifiée.

Résoudre les erreurs 0-1-492 dans Communicator Web Access 2007 R2 sur Windows 2008

2009-09-03T23:33:00.011+02:00

Si vous avez des erreurs 0-1-492 (Erreur: l'horloge interne de votre client n'est pas synchronisée avec celle du serveur) au moment de l'authenticiation intégrée sur un site CWA Interne, il faut vérifier le nom de service Kerberos du compte CWA doit comporter "http/fqdn.dusite.ext".

Par exemple, si votre site CWA interne est publié au niveau DNS avec le nom "cwa.societe.com", le nom de service principal sera "http/cwa.societe.com". Il n'est pas utile d'ajouter "as.cwa.societe.com" ni "download.cwa.societe.com" car ce sont des enregistrements CNAME (pointant vers "cwa.societe.com"). Le plus simple pour ajouter le nom principal Kerberos au compte CWA est d'utiliser SetSPN, par exemple:

setspn -A DOMAINE\CWAService http/cwa.societe.com

... Et de redémarrer le(s) serveur(s) (le Kerberos étant résident, un IISRESET ne résoudra probablement pas immédiatement le souci).
Malgré tout, cela peut ne pas suffire. Ce problème est récurrent dans les implémentations où le site CWA interne est mis derrière un répartiteur de charge. Il semble accentué dans une topologie multi-forêts (en particulier en mode forêt de ressource lorsque l'authentification NTLM est utilisée au niveau de la relation d'approbation (approbation de domaine, et non de forêt)).
Pour (définitivement :)) résoudre le problème, la solution de contournement est d'autoriser les accès anonymes sur la page /cwa/AuthMainCommandHandler.ashx du site CWA interne.
Microsoft n'a pas prévu de correctif car cela reviendrait à modifier le programme d'installation d'OCS 2007 R2, mais un article de la KB est en cours de rédaction, et sera probablement ensuite intégré dans la documentation.
Au lieu d'un long discours, voici un script pour le faire:
'
' $File:
' Fix-CWAUthentication.vbs
'
' $Description:
' Configures AuthMainCommandHandler.ashx on CWA Internal Web Sites to allow
' Anonymous authentication and fix CWA Authentication issues that
' may arise when deploying load-balanced CWA Web Sites.
'
' $Author:
' Benoit Boudeville
'
' $Date:
' September 3rd, 2009
'
Option Explicit
Const C_SERVER_TYPE = "Internal"

FixCWAAuthentication

Function FixCWAAuthentication
On Error Resume Next
Dim objShell, objWMIService, objItem, colItems
Dim strComputer, strSystemRoot, strCmd

FixCWAAuthentication = False
strComputer = "."

Err.Clear
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\default\rtccwa_repository")
Set colItems = objWMIService.ExecQuery("Select * from MSFT_CWASiteSetting where ServerType = '" & C_SERVER_TYPE & "'")
If Err <> 0 Then
WScript.Echo "[ERROR]: Unable to query CWA WMI Settings!"
Exit Function
End If

Set objShell = CreateObject("WScript.Shell")
strSystemRoot = objShell.ExpandEnvironmentStrings("%SystemRoot%")
For Each objItem In colItems
objShell.Run """%SystemRoot%\System32\inetsrv\appcmd.exe"" set config """ & objItem.Description & "/cwa/AuthMainCommandHandler.ashx"" -section:system.webServer/security/authentication/anonymousAuthentication /enabled:""True"" /commit:apphost", 2, True
Next
FixCWAAuthentication = True

Set objShell = Nothing
Set objItem = Nothing
Set colItems = Nothing
Set objWMIService = Nothing
End Function

Exchange Server 2007 SP2

2009-08-25T12:01:00.002+02:00

En attendant qu'Exchange Server 2010 soit RTM (une quarantaine de jours), Microsoft a enfin publié le Service Pack 2 d'Exchange Server 2007.

Page de téléchargement:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4c4bd2a3-5e50-42b0-8bbb-2cc9afe3216a

Outils d'Administration à Distance pour Windows 7

2009-08-13T10:37:00.004+02:00

Maintenant que Windows 7 et Windows 2008 R2 sont RTM, et que Windows Server 2008 R2 RTM sera disponible dès demain, Microsoft a dorès déjà mis à disposition les outils d'administration à distance pour Win7. Il sont disponibles ici:

http://www.microsoft.com/downloads/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en#filelist

Pas légers, mais tellement complets... :)

OCS 2007 R2 - Précisions sur le QFE2 et l'Address Book

2009-08-02T14:27:00.005+02:00

Dans mon message précédent, je mentionnais un ensemble de correctifs pour OCS 2007 R2.
Cet ensemble de correctifs s'appelle le "QFE2" (le QFE1 étant l'ensemble des correctifs sortis fin Avril 2009).

Outre les diverses corrections traditionnelles de bogues bien spécifiques, cet ensemble de mise à jours introduit une certain nombre d'améliorations au niveau du carnet d'adresses OCS 2007 R2 / MOC 2007 R2:

Le carnet d'adresses est maintenant généré avec des deltas beaucoup plus petits. En effet, ceux ci n'incluent maintenant que les attributs modifiés des objets modifiés VS tous les attributs des objets modifiés précédemment. Les nouveaus deltas sont jusqu'à 5 fois plus petits qu'avant, et sont générés avec un nom commençant par C-xxxx-yyyy.lsabs (pas de .dsabs, donc les Phone Editions ne sont pas concernés). Plus il y a d'objets dans l'AD, plus les impacts de cette optimisation sont importants...
C'est surtout côté client que l'on trouve un paquet d'amélorations:
D'orénavant, lorsqu'un téléchargement complet du carnet d'adresses est nécessaire, MOC 2007 R2 utilisera BITS (Background Intelligent Transfer Service), ce qui a pour effet de limiter la bande passante utilisée et de s'adapter au WAN;
Les deltas seront récupérés à partir du nouveau format disponible si le serveur a le QFE2 (ou ultérieur) d'installé.

Bien évidemment, le QFE2 (build 37) doit être installé sur les serveurs ET sur les clients pour bénéficier de ces (importantes) améliorations.

Parmi les autres améliorations on notera aussi:

Synchronisation des délégués entre Outlook et MOC 2007 R2, avant cette fonctionnalité n'était réservée qu'aux utilisateurs activés pour la ToIP (Enterprise Voice);
Possibilité pour les administrateurs de gérer l'intégration à Outlook sans vérouiller d'autres paramètres;
Changement fonctionnel sur les serveurs de Médiation (possibilité d'ajouter le Display Name);

Comme me disait un Product Manager Microsoft "exporté" ;) à Dallas, ce QFE peut être considéré comme l'équivalent d'un Service Pack pour OCS 2007 R2. A installer de toute urgence donc !

Bon courage!

Nouvelles mises à jour OCS 2007 R2 / MOC 2007 R2 [...]

2009-07-29T16:22:00.019+02:00

Microsoft a publié récemment un ensemble de mises à jour pour OCS 2007 R2 et MOC 2007 R2. Côté serveur, l'ensemble des mises à jour reprend quelques mises à jour précédentes et mettent à niveau certaines au build ".37".

Un package MSI est aussi fourni permettant la mise à jour de la base de données des Pools OCS 2007 R2 afin de corriger un problème avec la fonctionnalité "My meeting" (bien que ce problème soit rare, il peut vite devenir embêtant). Bien évidemment, cette mise à jour de la base est recommandée bien qu'elle ne soit pas requise pour l'application des correctifs.

Communicator 2007 R2 passe aussi en version ".37". Des mises à jours Live Meeting 2007 et Add-in Outlook sont en route.

Au passage, il est à noter une mise à jour des documentations OCS 2007 R2 (en particulier l'excellente documentation au format CHM, qui passe de 9 Mo à environ 12 Mo :)).

Liste maîtresse des correctifs OCS 2007 R2 (en cours de mise à jour): http://support.microsoft.com/?kbid=968802
Mise à jour OCS 2007 R2: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4
Mise à jour Communicator 2007 R2: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=515d6dba-4c6a-48bb-a06a-d99c5742676d
Ensemble de documentations OCS 2007 R2: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e9f86f96-aa09-4dca-9088-f64b4f01c703#filelist

N'oubliez pas de toujours tester l'application des mises à jour dans un environnement d'intégration et de revalider que l'intégralité des fonctionnalités utilisées fonctionne toujours après application.

Bonnes mises à jour :)

OCS 2007 R2 et le pare-feu intégré à Windows Server 2008

2009-07-25T15:51:00.006+02:00

De mon avis personnel, et d'un point de vue général, c'est une erreur de désactiver le pare-feu intégré à Windows Server 2008...

Au sujet d'OCS 2007 R2 et Windows Server 2008, il est inutile de désactiver le pare-feu Windows pour l'installation d'un serveur OCS 2007 R2, quelque soit le rôle, car les exceptions seront positionnées automatiquement lors de l'installation. Fait intéressant d'ailleurs, puisqu'une personne de mon entourage avait désactivé le pare-feu en pensant bien faire... Grosse erreur, car si le pare-feu est désactivé, les exceptions ne sont pas positionnées (pourtant c'est écrit dans la docs OCS 2007 R2 ^^). Lorsqu'il a réactivé le pare-feu, badaboum, plus rien ne fonctionnait.

Sur le serveur dorsal SQL, il faudra positionner les exceptions manuellement pour le service SQL Browser et le service correspondant à l'instance SQL du Pool, cela est requit pour créer les bases du Pool à distance (depuis un frontal pour les bases d'un Pool Enterprise, ou depuis les serveurs d'Archivage ou de Monitoring lors de leur installation, c'est beaucoup plus simple...)

Jusque là tout va bien, et tout fonctionne... Jusqu'au moment où un administrateur vous remonte qu'il n'arrive pas à utiliser la console d'administration OCS 2007 R2 pour arrêter/démarrer un service depuis sa station, ou configurer l'archivage ou le monitoring...

En fait, il suffit de simplement autoriser quelques exceptions, et le problème est résolu:

1. Activer le "ping" -- permet d'éviter des lenteurs lors de la connexion au serveur depuis la console

netsh advfirewall firewall set rule name="File and Printer Sharing (Echo Request - ICMPv4-In)" new enable=yes
netsh advfirewall firewall set rule name="File and Printer Sharing (Echo Request - ICMPv6-In)" new enable=yes

2. Activer l'administration distante -- permet d'accéder aux fonctions d'administration à distance et à la gestion des services

netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
netsh advfirewall firewall set rule group="Remote Service Management" new enable=yes

Voilà, le tour est joué, vous pouvez désormais pleinement administrer vos serveurs OCS 2007 R2 tournant sur Windows Server 2008 sans déscendre complètement le pare-feu Windows!

OCS (R2) et le DNS... (partie 2: la pratique)

2009-07-09T12:11:00.030+02:00

Voici la seconde partie de l'article "OCS (R2) et le DNS" (et vous... :))

Rappel: Dans la première partie, j'expliquais pourquoi l'utilisation d'un domaine SIP correspondant à un domaine public pouvait poser problème, en particulier lorsque celui-ci correspond à une zone DNS publique contenant des enregistrements qui doivent idéalement être résolus depuis les réseaux internes d'une société, et bien sûr depuis l'extérieur.

Une méthode classique est l'utilisation d'un "split DNS", à savoir la présence d'une zone DNS correspondant au domaine SIP sur les serveurs internes et externes, chacune étant finalement maintenue indépendament l'une de l'autre. Or, cette solution, bien que parfaitement gérable dans de petits environnements, peut s'avérer très complexe lorsque beaucoup de domaines et d'enregistrement DNS sont concernés.

Afin de simplifier tout ça, je proposais donc d'utiliser un split DNS afin de créer des zones correspondantes au premier sous-niveau du domaine SIP, et non au niveau du domaine SIP lui-même.

Par exemple, une zone "sip.domaine.com" et une zone "_tcp.domaine.com", chacune contenant respectivement un enregistrement "A" racine, et un enregistrement "SRV" relatif nommé "_sipinternaltls".

Aujourd'hui, nous allons voir deux méthodes afin de créer ces enregistrements. Imaginons que je souhaite ajouter un domaine SIP nommé "unifiees.fr" et supporter la découverte automatique par mes clients en utilisant cette technique.

Méthode 1: Interface de gestion DNS Windows

Je passe les détails de la création de zone... Pour ce type de besoin en interne, mon choix s'oriente en général vers une zone intégrée à l'AD (mais sans enregistrement dynamique) et se répliquant sur tous les serveurs DNS de la forêt. Bien sûr, rien n'empêche d'utiliser un fédérateur DNS interne... plutôt qu'un DNS intégré AD.

Commençons par l'enregistrement SRV: premier point sautant au yeux, lorsque l'on veut créer un enregistrement SRV dans la zone "_tcp.unifiees.fr", l'interface nous propose de renseigner ceci:

Service
Protocole
Priorité
Poids
Hôte cible

Et là, le premier reflexe est de se dire: "Mais si j'entre Service="_sipinternaltls et Protocole="_tcp", mon enregistrement SRV résultant sera... "_sipinternaltls._tcp._tcp.unifiees.fr" !!!

Et oui... mais non... Par un quelconque miracle, l'outil de gestion DNS établit que "_tcp" fait déjà partie du nom complet qualifié de l'enregistrement à créer, et zappe le double "_tcp". S'agit-il d'un bug ou d'un fait-exprès des équipes Microsoft ? Difficile à dire...

Quoiqu'il en soit, l'enregistrement créé est bien "_sipinternaltls._tcp.unifiees.fr". Qu'il s'agisse du DNS Windows 2003 ou Windows 2008, le comportement est identique.

Voici donc un moyen ultra-simple de créer l'enregistrement SRV, pratique et rapide dès lors que l'on a fait absraction du côté intattendu de la chose.

Reste ensuite à créer l'enregistrement "A" correspondant au nom d'hôte mentionné dans le SRV. Je rappelle qu'avec OCS R2, la vérification stricte du nom d'hôte s'applique par défaut, il est donc recommandé d'utiliser un nom d'hôte se terminant par ".nomdedomaine.ext" (ici: .unifiees.fr). Bien sûr, ce nom d'hôte doit être présent dans les noms alternatifs du certificat utilisé par votre Pool (qu'il s'agit d'un Pool classique ou d'un Pool utilisé comme Director).

Méthode 2: Utilisation de la commande DNSCMD.EXE

Cette méthode est moins triviale, mais beaucoup plus pratique afin d'éviter une hypothétique confusion de la part de vos administrateurs, ou tout simplement cette question récurrente: "Euh... t'es sûr que ta procédure est correcte parce que là c'est bizarre ça va faire un double '_tcp' ?" :)

Elle permet surtout d'industrialiser la création de zones et des enregistrements DNS lorsqu'une implémentation d'OCS 2007 (R2) dessert beaucoup de domaines. En bonus, elle permet de gérer la durée de vie en cache des enregistrements (TTL), ce qui peut s'avérer utile lors d'un plan de recouvrement de désastre (DRP).

Création de la zone (ici: intégrée à l'AD et se répliquant sur tous les DNS de la forêt)
dnscmd.exe serveurdns /ZoneAdd zonedns /DsPrimary /DP /forest/domain/legacy

Ce qui nous donne:

dnscmd.exe sv-dc01 /ZoneAdd _tcp.unifiees.fr /DsPrimary /DP /forest
puis dnscmd.exe sv-dc01 /ZoneAdd sip.unifiees.fr /DsPrimary /DP /forest

Création des enregistrements DNS
dnscmd.exe serveurdns /RecordAdd zonedns nomrelatif type donnes

Note: Dans le cas particulier d'un nom d'hôte racine à la zone, le nom relatif devra être ".".

Ce qui nous donne:

dnscmd.exe sv-dc01 /RecordAdd "_tcp.unifiees.fr" "_sipinternaltls" SRV 0 0 5061 "sip.unifiees.fr."
puis dnscmd.exe sv-dc01 /RecordAdd "sip.unifiees.fr" "." A "192.168.100.30"

Conclusion

Vous avez maintenant les clefs pour gérer votre DNS au mieux avec OCS 2007/R2. Bien sûr, il faudra généraliser le concept aux cas suivants:

Enregistrement SRV pour les clients OCS Phone Edition (aka CPE) (_ntp._udp.domaine.com)
Enregistrement SRV sur un DNS externe, pour les clients externes (_sip._tls.domaine.com)
Enregistrement SRV sur un DNS externe, pour la fédération (_sipfederationtls._tcp.domaine.com)
Enregistrements CWA (A pour cwa.domaine.com, CNAME pour as.cwa.domaine.com et download.cwa.domaine.com)
Et les autres... comme ceux utilisés par Exchange par exemple (SRV et/ou A pour l'Autodiscover) ou pour les mises à jours CPE (updates.domaine.com, updates-r2.domaine.com)

Quelle que soit la méthode que vous préférez, n'oubliez jamais de vérifier que vos zones et enregistrements sont créés correctement...

Dans votre console de gestion DNS
Avec la commande nslookup, idéalement depuis un poste client
Et lorsque vos serveurs sont opérationnels, avec un client Communicator tout simplement

Amusez-vous bien =°)

OCS (R2) et le DNS... (partie 1: la théorie)

2009-06-30T14:48:00.014+02:00

Introduction

Comme vous le savez tous, OCS 2007 et OCS 2007 R2 capitalisent sur un système DNS bien provisionné afin de permettre aux clients de pouvoir se connecter automatiquement, en fonction de l'adresse SIP de l'utilisateur.

C'est particulièrement pratique pour plusieurs raisons:

Effort d'administration réduit
Perception de l'utilisateur, qui apprécie de ne rien avoir à faire (ou presque :))
Maniabilité de l'infrastructure

Certes, il est possible de configurer les clients par stratégie de groupe (GPO) afin de reproduire quelque chose de similaire, mais lorsque des changements doivent s'appliquer, cela se complique car les stratégies ne s'appliquent pas immédiatement (utilisateurs connectés en attente de rafraîchissement, utilisateurs mobiles), voire pas du tout (clients hors du domaine, ou externes).

Alors, quels sont les enregistrements DNS qu'un client OC va rechercher lors de son démarrage ?

Il s'agit de ceux-ci:

_sipinternaltls._tcp.domaine.com
_sipinternal._tcp.domaine.com
_sip._tls.domaine.com
_sip._tcp.domaine.com
sip.domaine.com

Les quatre premiers enregistrements doivent être de type "SRV" (Service Locator), sauf si vous avez changé les ports part défaut, les versions "TLS" doivent pointer vers le port 5061 et les autres vers le port 5060. Le dernier est un enregistrement de type "A" (hôte IPv4).

Je rappelle qu'OCS 2007 et OCS 2007 R2 sont configurés par défaut pour utiliser le port 5061 (SIP sur TLS), il n'est donc pas nécessaire de créer les enregistrements "_sipinternal._tcp" et "_sip._tcp" si vous n'avez pas configuré OCS pour écouter sur ce port. Je reviendrai plus tard sur l'accès distant au travers d'un serveur Edge.

Le problème

Le DNS c'est bien, mais voilà... c'est parfois un casse-tête car tout le monde n'a pas le moyen d'utiliser ce que l'on appelle communément un "split DNS".

En effet, imaginez que votre domaine SIP soit "uc-lab.com": la configuration idéale qu'il corresponde au domaine SMTP utilisé par la messagerie, mais aussi à tout ce qui est visible de l'extérieur... Par exemple www.uc-lab.com.

Dans ce cas, que se passe-t-il ? Afin que la découverte auomatique fonctionne, vous configurez au moins ceci:

Sur vos serveurs DNS interne, vous créez une zone DNS nommée "uc-lab.com"
Un enregistrement A nommé "sip.uc-lab.com" (notez qu'il est possible d'utiliser autre chose que "sip.domaine.com", l'avantage de cet enregistrement est cependant d'autoriser la configuration automatique si le client ne sait pas faire de requête SRV ou simplement si vous n'avez pas de serveur DNS capable de gérer les SRV -- Ok ok, de nos jours c'est très marginal =°))
Un enregistrement SRV "_sipinternaltls._tcp.uc-lab.com" pointant vers "sip.uc-lab.com"

Un fois tout ce petit monde en place, vous confirmez que vous arrivez à vous connecter à OCS, mais se pose alors un autre problème... Lorsque vous voulez accéder au site www.uc-lab.com depuis votre réseau interne, vous vous faites insulter par votre navigateur Web préféré... Aïe... normal puisque votre DNS interne gère désormais la zone "uc-lab.com", si vous utilisiez un redirecteur DNS ou les DNS racines les requêtes vers ceux-ci cessent et donc c'est à votre ou vos serveur(s) interne(s) de répondre. Vu qu'aucun enregistrement nommé "www" n'existe, normal que la recherche de www.uc-lab.com échoue.

Il vous reste alors deux options qui semble "triviales":

Créer un enregistrement A pour www.uc-lab.com - Ok, pourquoi pas, mais cela oblige à une double gestion, ce qui n'est pas toujours une synécure. Imaginez la catastrophe si vous avez des centaines d'enregistrements à gérer sur vos DNS externes !!!
Ne pas utiliser de split DNS, ce qui revient donc à créer ces enregistrements sur une zone DNS externe (sur un DNS public) et de la mettre à disposition en interne (par réplication ou redirection) - Ce n'est pas toujours faisable, et cela pose un autre problème: cela oblige à publier une adresse IP interne sur une zone DNS publique... Ce n'est pas élégant, et pire, un client externe essayera de s'y connecter puisqu'il pourra la résoudre, puis passera à l'enregistrement suivant qui, si tout va bien, sera celui d'un serveur Edge et donc lui permettra de se connecter. Cependant, cela ralentit le processus de connexion.

Ces solutions sont donc à éviter, autant que faire-ce-peut, car voici _LA_ solution.

La (meilleure?) solution

Il suffit de rappeller comment fonctionne le DNS. Basiquement le caractère "." est le séparateur de labels dans le nom complet qualifié de l'enregistrement recherché. Par exemple, dans "sip.uc-lab.com" "sip" est le nom d'hôte (aussi appellé nom relatif), "uc-lab" et "com" sont des labels arbitraires, même si "com" est aussi une zone racine sur Internet (on appelle aussi ce label "extension").

Aussi, peut importe la façon dont ces enregistrements sont stockés par le serveur DNS, ce qui importe, c'est qu'ils puissent être résolus.

Petit exemple, imaginez un nom complet qualifié "serveur.dom1.aa.domaine.com", disons qu'il est de type "A". Quelles sont alors les façons possibles de déclarer cet enregistrements auprès d'un DNS. Il en existe en fait au moins cinq:

Créer une zone "com" puis un enregistrement relatif "serveur.dom1.aa.domaine"
Créer une zone "domaine.com" puis un enregistrement relatif "serveur.dom1.aa"
Créer une zone "aa.domaine.com" puis un enregistrement relatif "serveur.dom1"
Créer une zone "dom1.aa.domaine.com" puis un enregistrement relatif "serveur"
Créer une zone "serveur.dom1.aa.domaine.com" puis en enregistrement relatif "" (nom vide)

L'option #1 est à éviter (à moins de vouloir bloquer *.com :)), les options #2/3/4 sont des classiques, et l'option #5 semble "juste bizarre". C'est pourtant cette façon de déclarer les enregistrements DNS qui va changer la donne et résoudre tous les problèmes... ! :)

Typiquement sur un DNS de type "bind" (ex: sur Unix), cela revient à jouer avec le mot-clef "$ORIGIN" (qui est exposé dans un DNS Windows si vous n'utilisez pas Active Directory pour stocker les informations DNS, mais plutôt un fichier "nomdezone.dns").

Aussi, en reprenant mon exemple avec le domaine "uc-lab.com", il suffit de créer les zones et enregistrements suivants:

Zone: "_tcp.uc-lab.com" ==> Enregistrement SRV relatif nommé "_sipinternaltls" pointant vers "sip.uc-lab.com"
Zone: "sip.uc-lab.com" ==> Enregistrement A relatif non nommé (chaine vide)

Et voilà, un client DNS n'y verra que du feu et cela permettra de conserver des redirecteurs ou l'utilisation de serveurs DNS racines pour résoudre

Autres applications

Pour OCS, n'oubliez pas si votre déploiement comporte des clients de type Communicator Phone Edition (CPE), ou si vous utilisez Communicator Web Access (CWA), vous devrez créer des enregistrements supplémentaires (les zones sont en gras):

Pour CPE:

ucupdates.domaine.com (A)
ucupdates-r2.domaine.com (A)
_ntp._udp.domaine.com (SRV relatif "_ntp" vers un sevrveur NTP interne)

Pour CWA (optionnel/pas toujours applicable, mais personnellement j'aime avoir le même nom de serveur CWA en interne et en externe):

cwa.domaine.com (A)
as.cwa.domaine.com (CNAME relatif "as" vers l'enregistrement A racine dans cwa.domaine.com)
download.cwa.domaine.com (CNAME relatif "download" vers l'enregistrement A racine dans cwa.domaine.com)

En bonus, si vous avez Exchange 2007 + Outlook 2007 et que vous souhaitez utiliser Outlook Anywhere en interne (ex: clients hors de la forêt AD, mais se connectant depuis les réseaux internes):

autodiscover.domaine.com (A représentant l'IP de votre serveur CAS principal ou du load-balancer si vous avez plusieurs CAS)
et/ou _autodiscover._tcp.domaine.com (SRV pointant vers le port 443 et le nom d'hôte de votre CAS ou du load-balancer)

Et en externe... ?

Le même principe peut s'appliquer, même si cela ne devrait pas être nécessaire puisque tout peut être géré au sein de la même zone. La différence majeure se situe au niveau des enregistrements SRV, en effet, on préfèrera déclarer les enregistrements suivants:

sip.domaine.com (A représentant l'IP du rôle Access Edge du serveur Edge (ou du load-balancer dans le cas d'un pool de serveurs Edge))
_sip._tls.domaine.com (SRV pointant vers "sip.domaine.com" sur le port 443 (port par défaut pour l'accès distant des clients OCS au travers du Edge)
Et si la fédération est utilisée: _sipfederationtls._tcp.domaine.com (SRV vers "sip.domaine.com" sur le port 5061 si le même serveur Edge est utilisé pour la fédération)

Conclusion

Malgré la longueur ce cet article, le principe est somme toute assez simple, nous verrons dans le prochain article comment mettre tout ceci en oeuvre sur un DNS Windows, avec la console d'administration DNS et l'utilitaire dnscmd.exe...

OCS 2007 R2 / Communicator 2007 R2 - Correctif pour les versions d'évaluation

2009-06-16T10:39:00.003+02:00

Décidément, nos amis de Microsoft ont un souci avec le 13 Juin (rappellez-vous le problème de l'outil ABSConfig...)

Suite à un petit bogue, les personnes ayant installé une version d'évaluation d'OCS 2007 R2 et/ou de MOC 2007 R2 se retrouvent en carafe depuis avant-hier.

Pour corriger le problème, il suffit d'installer ces deux correctifs:

Sur le serveur (si le serveur est en Eval): http://www.microsoft.com/downloads/details.aspx?FamilyID=b3b02475-150c-41fa-844a-c10a517040f4&displaylang=en
Sur les clients (si les clients sont en Eval): http://www.microsoft.com/downloads/details.aspx?FamilyID=515d6dba-4c6a-48bb-a06a-d99c5742676d&displaylang=en

Ces correctifs n'apportent rien de plus part rapport aux mises à jour d'Avril (OCS R2 build .9) et de Mai (MOC 2007 R2 build .22). Il faudra encore attendre quelques semaines pour le QFE2... :)

OCS R2, SQL 2008 et WMI

2009-06-07T13:42:00.006+02:00

Durant mes expériementations sur mon "environnement de jeu", j'ai voulu aller trifouiller la configuration de mon nouveau Pool OCS R2 tout fraîchement installé avec un serveur SQL 2008 en tant que serveur dorsal, et s'exécutant sur Win20008 x64 (mes frontaux étant aussi installés sur Win2008 x64).

Bref... le moyen le plus simple étant d'utiliser wbemtest pour aller bidouiller la configuration, je décide de faire "comme d'habitude":

Se connecter à root\cimv2 (pratique, sur Win2008 c'est le contexte de connexion par défaut)
Aller dans "Query" et entrer la requête en langage WQL (WMI Query Language), comme par exemple "select * from msft_sipaddressbooksetting where backend = 'sv-sql'"
Et là, le drame... Au lieu de fonctionner et de me retourner l'instance de la classe correspondante, je me fais insulter avec une erreur inconnue... Késako ?

Je vérifie alors quelques éléments:

Mon pool est configuré pour se connecter à "sv-sql\OCSR2"
Mes frontaux fonctionnent parfaitement bien
Mon serveur SQL a les exceptions correctes sur le pare-feux Windows: les services SQL et le service SQLBrowser sont tous mis en exclusion
Mon service SQL pour l'instance OCSR2 est bien configuré pour TCP/IP et là... Je me rappelle/réalise que SQL 2008 est joueur... Pour une instance nommée, un port aléatoire est choisi, contrairement à l'instance par défaut qui s'exécute sur le port TCP 1433 !

Je prends alors mon Netmon, et lance une trace réseau en réessayant un Wbemtest, afin de voir ce qui se trame (admirez le jeu de mots =°)) derrière...

Je découvre alors que la requête WMI déclence une connexion SQL sur le port... 1433 ! Damned...

J'arrête donc proprement les services sur mes frontaux, change le port d'écoute de mon instance SQL en 1433 et redémarre mon instance. Une validation avec un 'netstat -an find /I 1433' confirme que le port est ouvert en écoute...

Après un redémarrage de mes services frontaux, je tente à nouveau ma requête WQL, et elle fonctionne !

Une autre technique, beaucoup plus simple et d'utiliser le nom complet de l'instance SQL, par exemple select * from msft_sipaddressbooksetting where backend = 'sv-sql\\OCSR2' (notez le double backslash, un grand classique :))

Moralité: Normalement, vous n'avez pas besoin de trifouiller la base SQL avec WMI (je rappelle tout de même que c'est l'interface qui est supportée par Microsoft pour configurer OCS/OCS R2, et que modifier directement la base SQL n'est pas supporté). Dans certains cas, cela nécessaire, comme par exemple activer la QoS, changer les URLs de publication des services Web, ou juste parce qu'il faut changer une valeur bien particulière (en général pour une raison tout autant particulière =)).

MCM: Office Communications Server 2007/R2

2009-05-20T18:51:00.006+02:00

Et bien voilà, c'est chose faite. Après 3 semaines de dur labeur à Redmond, dans le campus Microsoft, je viens de recevoir aujourd'hui la confirmation que j'ai réussi mon examen MCM Office Communications Server 2007/R2 !!!

Il s'agissait de la seconde rotation de l'histoire d'OCS 2007 (R2 inclus) !!! Nul besoin de dire que c'était éprouvant, intense et très enrichissant... Du pur bonheur quoi ! :)

Pour ceux qui ne connaissent pas le programme MCM (Microsoft Certified Masters), voici un lien décrivant ce dont il s'agit: http://www.microsoft.com/learning/mcp/master/default.mspx, et plus précisement pour OCS: http://www.microsoft.com/learning/mcp/master/OCS/default.mspx