Translate

lundi 27 décembre 2010

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

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):
  1. Editez le fichier Web.Config ($exinstall\ClientAccess\exchweb\EWS\Web.Config)
  2. Localisez la balise "service" correspondant au Web Service "Microsoft.Exchange.UM.ClientAccess.UMWebService"
  3. Ajoutez un "endpoint" faisant référence à un "binding" en Http (personnellement, j'ai utilisé "UMLegacyHttpBinding") et copié depuis le "UMLegacyHttpsBinding"
  4. Aller dans le noeud "customBinding" et ajoutez un "binding" nommé "UMLegacyHttpBinding" recopié à partir de "UMLegacyHttpsBinding", copiez-le puis remplacez la balise "httpsTransport" en "httpTransport"
  5. Enregistrez le fichier et redémarrez IIS (IISreset /noforce) ou recyclez l'application "MSExchangeServicesAppPool"
  6. 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 ;))

samedi 25 septembre 2010

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 !

mardi 7 septembre 2010

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.

mercredi 25 août 2010

samedi 17 juillet 2010

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.

jeudi 15 juillet 2010

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

vendredi 18 juin 2010

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.
Bonnes mises à jour!

mardi 8 juin 2010

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 !

vendredi 23 avril 2010

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

    jeudi 22 avril 2010

    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 !

    mercredi 21 avril 2010

    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.

    vendredi 16 avril 2010

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

    mercredi 14 avril 2010

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

    mardi 30 mars 2010

    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:

    samedi 6 mars 2010

    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.
    Bonnes mises à jour!

    mercredi 27 janvier 2010

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