Exchange your Mind

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archive for the ‘Cas-2010’ Category

Exchange 2010 / Outlook 2010: Unable to download Address Book: 0x80190194 Through F5 Vip

Posted by Teruin laurent le janvier 25, 2013


Hello

We have experimented an issue with a F5 VIP and Outlook Address Book Download function. Outlook are not able on https to download the Address Book (Error : 0x80190194)

After searching and testing during one day we found the solution who consist to disable cache and compression (in Red in the script)

 

Best regards

Laurent Teruin

 

Exchange version :14.2 Build 247.5

Outlook Version : (version Outlook 14.0.6023.1000 32 Bits)

F5 Version 11.2.0 (build 2557.0)

 

The current script for the F5 is the following

 

## iRule to select pool and persistence method when all Exchange Client

## Access HTTP-based services are accessed through the same BIG-IP virtual

## server. This iRule will use an HTTP header inserted by a BIG-IP Edge

## Gateway for persistence (if that header is present); otherwise it will

## set persistence according to traditional methods.

 

## CHANGE ALL POOL NAMES TO MATCH THOSE IN YOUR ENVIRONMENT.

when HTTP_REQUEST {

## Offline Address Book and Autodiscover do not require persistence.

switch -glob — [string tolower [HTTP::path]] {

"/microsoft-server-activesync" {

## ActiveSync.

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} elseif { [HTTP::header exists "Authorization"] } {

persist uie [HTTP::header "Authorization"] 7200

} else {

persist source_addr

}

pool Pool_EXC_Pub_CAS-Array-Serveurs

COMPRESS::disable

CACHE::disable

return

}

"/owa*" {

## Outlook Web Access

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} else {

persist cookie insert

}

pool Pool_EXC_Pub_CAS-Array-ServeursOWA

return

}

"/ecp*" {

## Exchange Control Panel.

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} else {

persist cookie insert

}

pool Pool_EXC_Pub_CAS-Array-ServeursOWA

return

}

"/ews*" {

## Exchange Web Services.

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} else {

persist source_addr

}

pool Pool_EXC_Pub_CAS-Array-ServeursOA

COMPRESS::disable

CACHE::disable

return

}

"/oab*" {

## Offline Address Book.

pool Pool_EXC_Pub_CAS-Array-ServeursOA


COMPRESS::disable

CACHE::disable

return

}

 

"/rpc/rpcproxy.dll" {

## Outlook Anywhere.

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} elseif { [string tolower [HTTP::header "Authorization"]] starts_with "basic" } {

persist uie [HTTP::header "Authorization"] 7200

} else {

persist source_addr

}

pool Pool_EXC_Pub_CAS-Array-ServeursOA

COMPRESS::disable

CACHE::disable

return

}

 

"/autodiscover*" {

## Autodiscover.

pool Pool_EXC_Pub_CAS-Array-ServeursAD

return

}

 

default {

## This final section takes all traffic that has not otherwise

## been accounted for and sends it to the pool for Outlook Web App

if { [HTTP::header exists "APM_session"] } {

persist uie [HTTP::header "APM_session"] 7200

} else {

persist source_addr

}

pool Pool_EXC_Pub_CAS-Array-ServeursOWA

}

}

}

 

when HTTP_RESPONSE {

if { [string tolower [HTTP::header values "WWW-Authenticate"]] contains "negotiate"} {

ONECONNECT::reuse disable

ONECONNECT::detach disable

## this command disables NTLM conn pool for connections where OneConnect has been disabled

NTLM::disable

}

## this command rechunks encoded responses

if {[HTTP::header exists "Transfer-Encoding"]} {

HTTP::payload rechunk

}

}

 

F5 Version 11.2.0 ( build 2557.0)


 

Posted in 1-EXCHANGE 2010, Cas-2010, Exchange 2010 SP2, Haute disponibilité | Leave a Comment »

Exchange 2010 : Comment forcer Outlook 2010 à se connecter en Outlook Anywhere.

Posted by Teruin laurent le juin 11, 2012


Pour forcer les clients Outlook à se connecter en RPC over Https il existe une méthode simple qui consiste à fixer dans l’environnement Microsoft Exchange son comportement par défaut.

En utilisant la commande Set-OutlookProvider et les paramètres suivants :

  • OutlookProviderFlags : Le paramètre OutlookProviderFlags indique que les clients Outlook 2010 doivent se connecter via RPC sur HTTP (Outlook Anywhere) avant d’essayer RPC via des connexions TCP. Cela augmente la vitesse à laquelle les clients Outlook 2010 se connectent lorsque des clients accèdent principalement à Exchange via Internet. La valeur peut être définie sur ServerExclusiveConnect ou None pour effacer les indicateurs. Pour les clients Outlook 2010 accédant à Exchange sur les intranets d’entreprise et sur Internet, la valeur recommandée est None, qui est également le paramètre par défaut.
  • CertPrincipalName : Le paramètre CertPrincipalName spécifie le nom principal du certificat SSL (Secure Sockets Layer) requis pour la connexion à Exchange à partir d’un emplacement externe. Ce paramètre est utilisé uniquement pour les clients Outlook Anywhere. C’est ce que vous allez indiquer dans le champ suivant :

La seconde méthode est d’utiliser les GPO de façon à modifier le paramétrage de Outlook en téléchargeant un fichier ADM qui contient ces informations. Voir article : http://support.microsoft.com/kb/2426686/fr


 

Une fois installée vous avez la possibilité de configurer les différents paramètres régissant la connexion RpcOverHttps.




 


 


N’oubliez Pas ! Si vous désirez avoir accès au référentiel documentaire envoyez un message à Unifiedit@hotmail.com !

Posted in 1-EXCHANGE 2010, Cas-2010 | Leave a Comment »

Exchange 2010 Cas : Utiliser les fonctionnalités X-Forwarded-For sous Windows 2008 R2

Posted by Teruin laurent le avril 24, 2012


Dans le cas de l’utilisation des fonctions de répartition de charges, et dans le but d’éviter des demi-sessions, on peut être contraint à utiliser des fonctions de Nat source (SNat ou Snat Automap) sur les répartiteurs de charge.

Note : Après l’avoir testeé, la procédure donnée par F5 dans le guide « Deploying the BIG-IP System v10 with Microsoft Internet Information Services 7.0 » ne semble pas correcte.

L’inconvénient de cette technique est que par défaut, les administrateurs Exchange vont perdre l’adresse IP des clients http(s). Une solution de contournement consiste à mettre en place sur les répartiteurs de charge réseau une fonctionnalité qui permet d’insérer dans l’entête http l’adresse Ip de ces derniers. Si cela est possible dans certains répartiteur de charge, les serveurs IIS par défaut, ne logueront pas cette information sauf si vous activez les options de journalisations avancées de IIS et que vous configuriez ces dernières pour prendre en compte cette information.

Pour installer sur vos Cas Server Windows 2008 R2 X64 cette fonctionnalité, il vous faudra récupérer un module complémentaire. Pour récupérer ce module de journalisation avancée cliquez sur le lien suivant :

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7211

Et procédez à son installation sur le serveur Web Windows 2008 R2 Cas Exchange 2010



Une fois installé, ouvrez Internet Information Services (IIS) Manager et dans le panneau de connexion cliquez sur le répertoire sur lequel vous désirez configurer la journalisation avancée.


Activer les fonctions de journalisation avancées en cliquant sur Enable Advanced Logging


Puis modifier les journaux en ajoutant la valeur X-Forwaded-For comme le montre l’exemple suivant :



Ensuite retourner dans Advanced Logging et cliquer sur Edit Log Definition


Dans la fenêtre suivante cliquez sur X-Forwarded-FOR pour activer son suivi


Si la fonction n’est pas activée pensez à l’activer en cliquant sur Enable Advanced Logging



 

Les journaux IIS comprendront désormais les adresses IP de vos chers clients http.

 

Cordialement
Laurent Teruin

 

 

 

Posted in 1-EXCHANGE 2010, Cas-2010, Haute disponibilité | Leave a Comment »

Exchange 2010 SP1 : Répartition de charge 1/2

Posted by Teruin laurent le octobre 30, 2011


Introduction

La venue de Microsoft Exchange 2010 a fortement nécessité l’acquisition ainsi que la mise en place de répartiteur de charge matériel. Bien sûr me direz-vous, la répartition Windows est toujours là, mais est-ce vraiment jouable ? Comment répartir correctement la charge réseau dans un environnement exchange 2010 avec ce type de procédé. C’est ce que je vous propose de regarder.

En premier lieu, et par déontologie, je vous propose un petit retour sur les solutions possibles que vous pourriez mettre en place. A ce jour 3 choix sont envisageables.

  • Répartition de charge NLB
  • Répartition de charge Round Robin
  • Répartition de charge matérielle
  1. Répartition de charge Windows NLB ou WNLB.

Cette répartition de charge est présente dans n’importe quels serveurs Windows, qu’il soit en version standard ou en version Entreprise. Comme dans quasi-totalité des cas, vos serveurs de transport HUB ou vos serveurs d’accès clients s’exécutent sur des serveurs possédant la licence Standard, Cette solution est activable nativement.

Seulement, si elle fait partie de la licence serveur, la couche NLB n’as pas grand rapport avec l’environnement Exchange. Cette couche logicielle ne va pas par exemple, vérifier si les services publiés derrière l’adresse IP NLB sont en ordre de marche. Ainsi, si pour une raison quelconque un serveur IIS s’arrête, le NLB continuera à distribuer ce serveur comme destination aux clients de messagerie. En fait, tant que votre serveur répond via TCPIP alors le service NLB considère qu’il est valide, et ce même si tous les services Exchange sont arrêtés. D’autre part la mise en place de l’environnement NLB s’avère également complexe dans des environnements géographiquement étendus comme le sont de plus en plus les environnements Exchange.

La couche WNLB est également limitée par plusieurs facteurs comme le nombre de nœud quelle peut supporter, 8 au maximum. De plus, elle est incompatible avec des serveurs Exchange qui exécutent la couche Windows Failover clustering. Dans les environnements possédant un nombre de boites aux lettres important, elle va poser problème en raison du nombre de port limité à 65 000 depuis une seule et unique adresse IP. Mais nous allons expliciter cela. Pour finir, l’ajout ou la suppression d’un nœud au sein d’un cluster IP va provoquer la déconnexion des utilisateurs. Ce qui va de facto limiter son usage dans le cas des opérations de maintenance. Voici donc résumé les limitations de cette répartition de charge, qui vous l’aurez compris ne retient que peu mon attention dans la construction d’architecture Exchange redondantes. Son principal avantage ?… il est d’être gratuit.

  1. Répartition de charge Round Robin.

La répartition de charge Round Robin distribue le flux grâce aux fonctionnements DNS. Le principe est simple. Créez deux enregistrements DNS portant le même nom de domaine (nom de votre Client Access Array) et attribuez-lui deux adresses IP différentes. Activez le mode RoundRobin dans le server DNS (Par défaut dans Windows Server) et le tour est joué. Un coup sur deux, le DNS va renvoyer l’adresse 1 ou l’adresse 2. Enfantin, pas cher, simple, sauf que … c’est nettement insuffisant pour l’environnement Exchange 2010.

Comme WNLB, le round Robin n’a aucune idée de l’état des services Windows et même si le serveur est arrêté, il continuera à renvoyer au client l’adresse IP en question. Quant aux chances de connexion du client, sur un serveur hors service…… elles seront faibles.

En réalité ces deux modes de répartition de charge, sont relativement obsolètes et non pas évolués au fur et à mesure de l’évolution de l’environnement Windows. Conçus pour de la répartition de charge TSE ou de simple connexion IP, ils s’avèrent totalement dépassés dans l’environnement Exchange.

Mais est-ce vraiment si compliqué que cela de faire de la répartition de charge Exchange correctement. ? Et bien … cela dépend ! Comme un jour m’a dit un jour une personne de Microsoft, Exchange 2007 vous a fait découvrir les coulisses des certificats, Exchange 2010 vous fera découvrir les sous-sols de la répartition de charge matérielle. Alors c’est parti !

  1. Répartiteur de charge matériel (HLB ou ADC).

En opposition avec les deux protocoles que je vous ai présenté, les répartiteurs de charges matériels offrent beaucoup plus de possibilité et notamment la répartition de charge selon plusieurs critères. Car une des questions à se poser c’est sur quels critères votre répartiteur de charge va se baser pour répartir le flux clients vers les serveurs Exchange

La première possibilité est l’adresse IP du client. Lorsque le répartiteur de charge matériel identifie un client avec son adresse Ip (ex : 192.168.1.1) , il le connecte sur le serveur Exchange Numéro 1. Pour une autre adresse IP (ex : 192.168.1.2) , il le positionnera sur le numéro 2 , etc etc . L’avantage de cette répartition est de garantir que pour une session IP, le client à l’adresse 192.168.1.1, sera toujours affecté au serveur Exchange 1.

Pour quelle raison ? Pour tout simplement garantir par exemple dans OWA que l’utilisateur n’ait pas à se reconnecter lorsqu’il demande à voir le message suivant. C’est effectivement ce qui se passerait si pour une même session IP Owa, le répartiteur de charge acheminait le client vers un autre serveur d’accès client. Tout cela pour maintenir la persistance de session. Deux termes qu’il nous faut définir.

  1. Session et persistance

Les problèmes de persistance de sessions viennent entre du fait que par nature, le protocole HTTP n’a pas été conçu pour à l’origine pour être de type applicatif mais plutôt orienté lecture et récupération de document. De ce fait, le protocole HTTP ne maintient pas de connexion (Stateless) en permanence avec les serveurs Web qu’il consulte. Parallèlement, l’usage de ce protocole à évolué, et il est utilisé aujourd’hui pour comme un frontal applicatif (Exchange OWA par exemple, Site d’achat en ligne etc..) usage qui demande nécessairement la persistance de session (Statefull).

Une des solutions et qui fonctionne correctement pour mettre en place une notion de session entre le client et le serveur est l’usage de Cookie qui, stocké sur le poste client permet à l’applicatif de retrouver les éléments des sessions (SessionID). C’est par ailleurs grâce à ce mécanisme que nous arrivons à maintenir les sessions Outlook Web Access.

L’exemple ci-dessous donne une idée de ce que l’on peut trouver dans un Coolie de session et notamment la notion d’Id de session.

Cookie: JSESSIONID=9879876473431
Cache-Control: no-cache
Host: 127.0.0.1:8080
Connection: Keep-Alive

 Une fois la session créée par le biais de Session ID et de cookie, les répartiteurs de charges ou plutôt les ADC (Application Delivery Controller) vont se charger de récupérer cette session ID de chaque client de façon à orienter les requêtes d’un client toujours sur le même serveur. On parle alors de persistance. Plusieurs solutions sont possibles. La première est de se baser sur L’ID SSL d’une session HTTPS (généré par le serveur dans la phase de négociation) par exemple. La seconde est simplement d’utiliser un cookie de session transféré dans l’entête HTTP et généré par le serveur Web.

Autre solution alternative consiste pour garantir la notion de session, à ce baser sur l’adresse IP du client. Ce baser sur l’adresse IP c’est bien, mais à condition que vos clients en possèdent une toutes différentes ! Je m’explique. Si vos clients viennent d’un sous réseau naté de votre entreprise ou si ils utilisent un serveur proxy d’agence, ils posséderont virtuellement la même adresse IP et votre répartiteur de charge sera bien incapable de répartir la charge. Résultat vous vous retrouverez, avec tous les clients connectés sur le même serveur Exchange.

En réalité tout dépend de la façon dont vous allez implémenter votre répartiteur de charge matériel et comment se dernier agira sur les flux clients vis-à-vis de votre infrastructure Exchange d’accès client.

Snat / Dnat

La mise en place d’un répartiteur de charge ou ADC va en partie conditionner la façon dont ce dernier doit agir avec vos serveurs Exchange. La première possibilité est de placer votre Répartiteur de charge en coupure de vos infrastructures Parefeux


 

La seconde est de le placer sur le réseau de l’entreprise.


Dans le cas où le répartiteur de charge est en coupure, il est évident que le flux entrant et sortant (réponse des serveurs d’accès client) passera par le répartiteur de charge. Dans Le cas contraire, ou le répartiteur de charge est sur le réseau local, il est possible que le flux entrant passe alors par le répartiteur de charge mais que le serveur réponde directement aux clients.

En fait tout dépend d dont la translation d’adresse est faite et dont le réseau est organisé. Un petit tour vers les notions de Snat et Dnat s’impose donc.

  1. SNAT ou Source NAT

Le Source NAT (translation d’adresse source) correspond à la modification de l’adresse source dans un paquet translaté. Dans ce cas, votre répartiteur de charge va changer l’adresse source du paquet client par une adresse IP positionnée sur votre répartiteur que vous aurez désignée. Le but de cette opération est par conséquent de s’assurer que votre serveur CAS, renvoi la réponse de facto à votre répartiteur de charge au lieu de le renvoyer directement au client originel. Vous noterez que dans ce cas précis, le répartiteur de charge n’a même pas besoin d’être en coupure physique. Pour effectuer cette opération vous aurez plusieurs choix et notamment le choix de faire une simple translation d’adresse vers un adresse ip unique ou alors, vers un pool d’adresse IP positionné sur votre répartiteur. Dans le premier cas on parlera de SNAT Standard dans le second de SNAT pool.

 


Ce mode de translation peut être utile car d’un point de vue firewall seul le Répartiteur de charge est concerné. Par contre dans Exchange les choses se compliquent un peu.

 

Explication : Dans le cas du SNAT, et vous l’aurez compris, vous perdez (coté Exchange) la notion d’adresse client, puisque toutes les adresses IP du client sont modifiées par l’adresse ou les adresses sélectionnées (Snat Pool) dans votre répartiteur de charge. De ce fait, et si vous faites cela pour l’environnement SMTP interne par exemple, vous perdez notamment la possibilité dans les connecteurs de réception de limiter le relai par adresses IP.
Pour rappel, voir set-receiveconnector et le paramètre RemoteIprange des connecteurs de réception. (http://technet.microsoft.com/fr-fr/library/bb125140.aspx)

Limitation du SNAT

.

Les fonctionnalités de SNAT sont intéressantes mais limitées, car le nombre de port ouverts maximum pour une seule adresse Ip est de 65,535 par destination. Ce qui peut être très vite atteint (environ 6000 utilisateurs). Dans ce cas il faudra privilégier l’utilisation des fonctions de SNAT pool pour dépasser cette limite.
Par contre, si vous projetez d’utiliser les fonctions de SNAT Pool et que vos serveurs d’accès client doivent recevoir des flux Mapi RPC (Je ne parle pas de Outlook anywhere ici mais de connexion MAPI Outlook) alors, il faudra que le répartiteur de charge adresse vers le serveur CAS toujours la même adresse source par connexion RPC. En gros si un client Mapi se connecte sur un HLB effectuant du SNAT pool, il faut que cette connexion garde toujours la même adresse IP de sortie vers le serveur Cas.

DNAT ou Destination NAT
Le Destination NAT correspond à la modification de l’adresse destination dans un paquet translaté. Il est utilisé pour la NAT statique, lorsqu’on veut accéder à un serveur sur un réseau local. Cette solution consiste à garder l’adresse IP du client mais cacher les adresses IP local du serveur d’accès client Exchange.

Bon vous voilà paré pour la seconde partie plus axée sur l’environnement Exchange 2010

Cordialement
Laurent Teruin

Posted in Cas-2010, Exchange 2010 Service Pack 1, Publication-2010 | 3 Comments »

Exchange 2007/2010 : Certificat étoile une alternative intéressante ?

Posted by Teruin laurent le septembre 28, 2010


L’avènement de Microsoft exchange 2010 est les opérations de migration relance le débats sur l’utilisation des certificats de type étoile. En effet, pour migrer les services d’accès client vous devrez modifier les certificats clients existants pour ajouter un nom de type Legacy.fqdnpublic-des-services-cas. La mise en place de certificats de type *.fdqn est intéressant a ce point de vue car elle permet de garder le même certificat et éviter de couper le lien SSL de production.

D’autre part elle permet de faire porter aux services Cas plein de noms différents comme les noms des serveurs active directory, les autodiscover, webmail etc.. De ce point de vue-là, les certificats de type «  étoile » ont le vent en poupe. Un autre avantage est le prix car dans le cas de certificat SAN, la facturation de certaines sociétés se fera sur le prix du certificat et le nombre d’entrées alternatives. Ce qui risque de faire monter l’addition….
Un autre avantage reste la facilitée de gestion et le fait qu’il n’est pas nécessaire de les changer à chaque ajout de nom supplémentaire. Alors il faut bien quelques inconvénients non ?

Coté inconvénients nous allons trouver leurs incapacité à gérer plusieurs noms de domaine et pour cause. Les certificats étoiles que vous devrez acquérir seront de la sorte *.unifiedit.com. Si votre nom de domaine interne est identique à celui de l’externe pas de souci tout cela fonctionnera. On parle dans ce cas-là, de « SplitDNS ». Ce qui en soit est une configuration conseillée officiellement par Microsoft (voir techdays 2010). Il est vrai que cela est plus simple à tout point de vue. Dans le cas contraire, le certificat étoile (Wildcard) ne pourra rien pour vous. Si vos ressources externes sont joignables par *.unifiedit.com et que en interne, elles le sont par *.unifiedit.local point de salut. Les certificats San sont obligatoires.

Sachez que l’utilisation des certificats Wildcard va demander une modification du paramétrage Outlook pour que le fonctionnement du RPCoverHtpp (Outlook Anywhere reste possible). L’article suivant explique comment paramétrer les services Exchange lors de l’utilisation des certificats étoiles :

http://technet.microsoft.com/en-us/library/cc535023(EXCHG.80).aspx

Un autre inconvénient réside dans la non supportabilité vis-à-vis de Windows Mobile 5 (Cf article technet : http://technet.microsoft.com/en-us/library/cc182301.aspx).


Quand à Windows Mobile 6 cette version le supporte à la condition que le certificat étoile ne soit pas délivré par une PKI Microsoft.


Sachez enfin que l’utilisation des Certificats Wildcard ne fait pas partie des « Best Practice » Microsoft.

Important : A noter également que les certificats SAN via Outlook en accès POP et Imap inférieur à la version 2010 ne sont pas supportés sauf si vos Outlook 2007 possèdent le service pack2 ou supérieur.

Coté OCS ou plutôt Lync je vais aller me renseigner je reviens vers vous rapidement

Cordialement
Laurent Teruin

Posted in Cas-2010, Certificat-2007, Certificat-2010, Windows Mobile | Leave a Comment »

Exchange 2010 : Redirection automatique http vers https://…/owa

Posted by Teruin laurent le septembre 27, 2010


Nous avons tous eu le besoin de faire de la redirection d’URL avec les versions précédentes de Microsoft Exchange. Le but du jeu est de faire en sorte que lorsque vos chers utilisateurs tapent http://webmail.votrenomdesociete.com une redirection se fasse vers https://webmail.votrenomdesociete.com/owa. Pour ce faire, vous en conviendrez, il faut impérativement que votre serveur ou que votre reverse proxy écoute sur le port 80. Sinon point de salut. Dans le cas d’un serveur ISA vous pouvez très facilement faire une redirection des flux http vers Https. Celle-ci se faisant dans la règle de publication. Ce qui n’empêche pas d’ailleurs que votre ISA ou TMG doit écouter sur le 80 en tcp. Si vous essayez les anciennes méthodes celles-ci ne fonctionneront pas. Voici comment il faut procéder :

Pour que cela fonctionne il faut utilisez les fonctions de redirection de IIS et supprimer l’obligation d’utiliser la couches SSL.

Etape 1 : Mise en place de redirection vers Https://……/owa

Positionnez-vous sir le site web par défaut et éditer les redirections HTTP


Le souci de cette configuration c’est qu’elle va s’appliquer sur tous les répertoires situés en dessous. Si si ;-)) c’est vrai et par conséquent il faudra supprimer cette redirection sur l’ensemble des répertoires virtuels situés en dessous.

Etape 2 : Suppression de la redirection pour les sous répertoires virtuels

Vous m’excuserez mais je n’ai pas pris de screenshot pour tous les répertoires virtuels ;-)))

Etape 3 : Suppression de l’obligation d’utiliser SSL
Pour supprimer L’obligation d’utiliser SSL procédez comme le montre la figure suivante :


Vous pensez comme moi ? Vous avez raison ! Cette modification va s’appliquer sur tous les répertoires en dessous. Ce qui en soit… n’est pas correct. Alors .. c’est reparti.
Il faut repositionner le SSL sur les répertoires Exchange suivants : Aspnet_client, Autodiscover, Ecp, EWS, Microsoft-ActiveSync,OAB,Windows Powershell et RPC.
Une fois effectué ouvrez une commande cmd et exécutez un iisreset.
Lancer un navigateur et tapez votre commande http://Webmail.nomdevotresociete.com vous devriez être redirigé vers https://webmail.nomdevotre societe.com/owa

Cordialement
Laurent Teruin
Testé sur Exchange 2010 SP1 Uk version / Windows 2008 R2 Ent Uk X64

Posted in 1-EXCHANGE 2010, Cas-2010, Owa-2010 | 1 Comment »

Tmg, Répartiteur de charges, Exchange 200X : Problématiques de basculement

Posted by Teruin laurent le septembre 23, 2010


Dans un article précédent (http://unifiedit.wordpress.com/2010/08/18/exchange-2010-plaidoyer-pour-les-repartiteurs-de-charges-materiels/), j’avais préconisé l’usage de répartiteur matériel. Je vous rassure je n’ai pas changé d’avis. Mais je me permets de revenir vers vous vis-à-vis d’une problématique que vous allez rencontrer si vous envisager de mettre en place des HLB (Répartiteurs de charge matériels) vers des serveurs reverse proxy TMG, ISA ou autre. Dans le cas où vous envisagez de mettre un site de secours (DRP) comme le précise la figure suivante plusieurs règles seront à établir.


Dans un premier temps, il faudra définir votre site Actif et votre site passif et définir les règles de basculement. Dans la plupart des cas on paramétrera les HLB pour qu’ils vérifient la présence du service de publication Exchange via des ports classiques comme 80/TCP et 443/TCP sur les serveurs Reverse Proxy. Dans le cas où ces ports ne répondent pas, alors le HLB du site primaire devra basculer le flux vers le second serveur ISA/TMG du site distant. Si vous n’allez pas plus loin vous vous apercevrez rapidement que votre HLB ne basculera jamais les flux vers le site de secours pour la bonne et simple raison que même si les services CAS sont arrêtés les serveurs proxy continuent à écouter sur les ports 80/443 et par conséquent votre HLB ne détectera pas la panne. Il vous faudra donc allez plus loin et analyser le type de page retournée pour vérifier que celle-ci correspond bien à celle d’un OWA. Mais pour cela ….. il faudra vous connectez via le HLB avec un compte AD autorisé.
Par contre la bonne question à vous poser c’est quel type d’authentification votre HLB supporte-t-il ? Car comme vous l’aurez deviné l’authentification que va vous proposer votre ISA ou TMG Server est une authentification de type FBA (Authentification par formulaire) .Un beau formulaire de type html dans lequel votre HLB devra rentrer ces coordonnées pour vérifier si votre serveur CAS répond convenablement. Je sais que la crème des Load Balancer savent le faire (Ex : F5 BigIP), mais avant de vous lancer dans l’achat effréné d’une solution bon marché mieux vaut vérifier.
Une autre solution consiste à monitorer directement le serveur CAS via le HLB. Cela impliquera de mettre votre HLB dans plusieurs zones (DMZ/LanInterne) et de conditionner le basculement vers le serveur TMG/ISA/Reverseproxy de secours a la non réponse du serveur CAS du site primaire. Ça aussi il faudra vérifier que cela est possible dans la solution HLB envisagée.
Enfin il existe une troisième solution si votre Load Balancer ne sait pas faire ce genre d’exercices c’est de confier le basculement de vos services CAS à votre reverse proxy ISA/TMG en les déclarant via une ferme.

Conclusion : le choix d’un HLB doit se faire non pas uniquement sur le prix mais également vis-à-vis de ce vous escomptez lui faire faire.
Cordialement
Laurent Teruin
Questions / Réactions : unifiedit@hotmail.fr

Posted in 1-EXCHANGE 2010, Cas-2010, EXCHANGE 2007, Forefront TMG, Publication-2007, Publication-2010 | Leave a Comment »

Exchange 2010 SP1 : Mises à jour requises pour les CAS

Posted by Teruin laurent le août 31, 2010


La mise en place de Microsoft Exchange 2010 SP1 va nécessiter l’installation de quelques mises à jour qui ne sont pas distribuées par Windows Update. Une fois n’est pas coutume.

La présence de ces mises à jour est obligatoire. Dans le cas contraire voici les messages d’erreur qui vous seront remontés

Pour les récupérer il faudra suivre les URL en question . Certain pourront s’étonner que dans la description de ses mises à jours il figure le message suivant  

  • Please be aware this Hotfix has not gone through full Microsoft product regression testing nor has it been tested in combination with > other Hotfixes.

 En fait ceci est tout à fait normal car le code mis à jour ne fait pas l’objet de tests aussi importants que les changements majeurs comme peuvent l’être les services Pack. C’est exactement le même scénario que dans le cas des Rollup package Exchange.

 Lors de la récupération de ses packages logiciel il faudra aller sur le site Msdn et connect pour récupérer ces derniers. Certain s’étonneront que ne figure pas Windows 2008 ou Windows 2008 R2.

Il faudra récupérer les binaires pour Win7 selon votre infrastructure IA64, X64, x86.

 

 L’installation de ses mises à jour nécessitera le redémarrage de votre serveur Exchange 2010.
Cordialement 
Laurent Teruin
Unifiedit@hotmail.fr

Posted in 1-EXCHANGE 2010, Cas-2010, Exchange 2010 Service Pack 1 | Leave a Comment »

Exchange 2010 et les Array CAS (Client Access Servers) – Part 2

Posted by David PEKMEZ le janvier 25, 2010


Introduction

 

Une des nouveautés d’Exchange 2010 est de centraliser les connexions clients vers les serveurs CAS, ce qui était déjà le cas en Exchange Server 2007 pour des services tels que Active Sync, OWA ou encore RPC Over http, les clients lourds Outlook se connectaient eux encore sur les serveurs de boîtes aux lettres en direct.

La grande nouveauté concerne donc la connexion des clients Outlook aux serveurs CAS qui porte définitivement bien son nom dans cette nouvelle version puisqu’il accueille tous les clients Exchange, le rôle de boîte aux lettres est dédié au stockage et à la gestion des banques d’informations.

Voici un schéma représentant les connexions clients vers les serveurs CAS sous Exchange server 2010


Dans la première partie de cet article, nous avons configuré un cluster de type NLB ;

La seconde partie de cet article sera consacrée à la création et la configuration d’un Array de serveur CAS afin d’accueillir les clients Outlook.

Création et configuration de l’Array de servers CAS

 

La création de cet array passe par la commande Powershell suivante : New-ClientAccessArray

New-ClientAccessArray –Name « Enter a Name » -Fqdn « Array Fqdn Name » -Site « Array Site Name »


 

Attention

Su une base de donnée est crée avant l’array de serveurs CAS elle ne prendra pas en compte cette configuration,

Ci-dessous, je peux remarquer que le paramètre RpcClientAccressServer pointe sur un de mes serveurs CAS et pas sur mon Array


Je vais devoir modifier ce paramètre à l’aide de la commande Set-MailboxDatabase afin de modifier la valeur du paramètre RpcClientAccressServer

Si par contre je créé une nouvelle base de données, elle prendra automatiquement ce paramètre en compte



 

Conclusion

La grande nouveauté est la gestion par les serveurs CAS de tous les clients de messagerie, il paraît tout de même important de noter que les connexions aux publics folders sont font en direct sur les serveurs de boîtes aux lettres.

Ceci implique tout de même un travail bien plus important de ces serveurs en comparaison avec Exchange 2007 donc faite bien attention au dimensionnement des serveurs hébergeant ces rôles CAS.

Cette fonctionnalité permet d’améliorer grandement les périodes de non disponibilité durant une perte de connexion, qui est de 30 secondes d’après les équipes produit au lieu de plusieurs minutes avec les versions précédentes.

Posted in Cas-2010, Cluster-2010 | Leave a Comment »

Exchange 2010 et les Array CAS (Client Access Servers) – Part 1

Posted by David PEKMEZ le janvier 7, 2010


Introduction

 

Une des nouveautés d’Exchange 2010 est de centraliser les connexions clients vers les serveurs CAS, ce qui était déjà le cas en Exchange Server 2007 pour des services tels que Active Sync, OWA ou encore RPC Over http, les clients lourds Outlook se connectaient eux encore sur les serveurs de boîtes aux lettres en direct.

La grande nouveauté concerne donc la connexion des clients Outlook aux serveurs CAS qui porte définitivement bien son nom dans cette nouvelle version puisqu’il accueille tous les clients Exchange, le rôle de boîte aux lettres est dédié au stockage et à la gestion des banques d’informations.

Voici un schéma représentant cette différence entre Exchange Server 2007 et Exchange Server 2010.


Afin d’avoir un système de haute disponibilité pour gérer ces connexions Outlook, un unique point de connexion est créé, un serveur CAS ou un Array de serveurs CAS, ce qui permet de basculer les connexions clients vers d’autres serveurs CAS en cas de défaillance.

Il faut noter que ces bascule sont très courtes (moins de 30 secondes) lors d’une bascule entre serveurs CAS.

Dans cet article nous utiliserons le NLB Microsoft afin de mettre en haute disponibilité les serveurs CAS mais il est tout à fait possible de mettre en place des HLB (Hardware Load Balancer).

Cette précision est importante puisqu’il n’est pas possible de combiner sur les mêmes serveurs les technologies de clustering MSCS et NLB,

Si vous désirez donc installer deux serveurs ayant les rôles CAS, HUB et MAILBOX et tout mettre en haute disponibilité, c’est tout à fait faisable mais en créant un DAG (Pour le rôle Mailbox)

Cf Article concernant les DAG et installer un HLB pour la haute disponibilité des rôles CAS et HUB ;

Si vous désirez installer du NLB pour la haute disponibilité de ces rôles il va vous falloir installer les rôles CAS et HUB sur des serveurs différents ou aucun DAG n’est créé.

 

Pour les besoins de cet article, j’ai monté une plateforme avec :

- 1 contrôleur de domaine

- 1 serveur de Boîte aux lettres

- 2 serveurs CAS

 

La configuration d’un Array de Cas se déroule en plusieurs étapes :

1 – Mise en place du NLB Microsoft sur les serveurs Windows

2 – Création et configuration de l’Array

Cette première partie d’article détaille la création du Cluster NLB de Microsoft et la seconde partie traitera de la création et la configuration de l’Array de serveurs CAS.

 

Configuration du NLB

 

Tout d’abord, nous devons disposer de deux cartes réseaux afin d’avoir une carte dédiée au clustering NLB (Pas obligatoire mais recommandé de séparer les deux réseaux).

Paramètres réseaux globaux

 


Cliquer sur « Alt » pour faire apparaître le Menu



Vérifier les priorités des cartes réseaux dans la configuration avançée des cartes.

 

Configuration de la carte dédiée au NLB

 


La carte dédiée au clustering NLB ne doit pas disposer de Gateway ni de serveur DNS,

Dans les propriétés avançées elle ne doit pas non plus s’enregistrer dans le DNS et NETBIOS doit être désactivé.



Par défaut dans Windows 2008, l’IP Forwarding est désactivé, un serveur ayant plusieurs interfaces réseau ne répond pas sans une passerelle par défaut de configuré,

Ce comportement peut être modifié en entrant la commande suivante :

Netsh interface ipv4 set int "[NLB NIC]*" forwarding=enabled

(NLB NIC* = le nom de votre interface dédiée au NLB)

Configuration du NLB

 

Pour installer la fonctionnalité lancer Powershell et taper les commandes suivantes : (sur tous les serveurs intégrant le cluster NLB)

Import-module servermanager

Add-WindowsFeature NLB

Lancer ensuite la console de gestion du clustering NLB pour créer un nouveau cluster



Entrer le nom du premier serveur CAS intégrant le cluster, choisir la carte dédiée au NLB et cliquer sur suivant


Cliquer sur « suivant »


Entrer l’adresse du cluster NLB et cliquer sur « OK »


Entrer le nom que portera le cluster NLB (ici il porte le nom : clients)


La configuration des ports peut être affinée en utilisant ces informations

- RPC MAPI (135 TCP)

- RPC (1024-65535 UDP/TCP)

- HTTP (80/443 TCP) 

Il est possible d’ajouter le port 25 bien entendu pour mettre en haute disponibilité les serveurs HUB pour les connexions entrantes par exemple


Le cluster NLB est configuré et intègre un serveur CAS, nous allons en ajouter un second



Entrer le nom du serveur CAS à ajouter et choisir son adresse IP dédiée au cluster NLB


Cliquer sur « Suivant »


Il récupère ici la configuration faite en installant le premier serveur NLB


Les deux serveurs sont maintenant intégrés au cluster NLB

Nous allons maintenant entrer un enregistrement dans la DNS pointant sur l’adresse IP du NLB afin de le rendre disponible aux clients de messagerie.


Choisir un enregistrement de type A / AAAA


Entrer le nom et l’IP désirés puis cliquer sur « Add Host »


Conclusion

 

Nos deux serveurs CAS sont intégrés au cluster NLB,

La seconde partie de cet article sera consacrée à la création et la configuration de l’Array de serveurs CAS.

Référence Technet concernant le NLB Microsoft : http://technet.microsoft.com/en-us/library/cc732855(WS.10).aspx

 

Posted in Cas-2010 | 1 Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 223 autres abonnés