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

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

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...

...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

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)

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' ?

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

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

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

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 !!!

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

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...

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:
• http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4
• Article: http://support.microsoft.com/?kbid=968802
• Office Communicator 2007 R2:
• http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=515d6dba-4c6a-48bb-a06a-d99c5742676d
• Article: http://support.microsoft.com/?kbid=978564
• Office Communications Server Attendant Console R2:
• http://www.microsoft.com/downloads/details.aspx?FamilyID=36beb56d-072e-4a92-b781-a1e8a548a5ac&displaylang=en&displaylang=en
• Article: http://support.microsoft.com/?kbid=980936
• Office Communicator Phone Edition R2:
• http://www.microsoft.com/downloads/details.aspx?familyid=565595BE-6CF3-4A61-A1E4-12555749CA64&displaylang=en
• Article: http://support.microsoft.com/?kbid=981526

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

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

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

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 !!!

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

 (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

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

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

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.