Exchange your Mind

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

Archive for décembre 2009

Points de Performance Exchange 2007/2010

Posted by Teruin laurent le décembre 24, 2009


 

Le but de ce document est de présenter les quelques points de contrôle de performance que vous devriez vérifier manuellement si vous n’avez pas la change d’avoir un outil de monitoring spécifique a l’environnement Microsoft Exchange 2007/2010. Ce document ne prétend pas documenter l’ensemble des compteurs fort nombreux d’ailleurs, mais mettre l’accent sur des compteurs spécifiques majeurs au sein d’exchange 2007/2010

 

Surveillance des serveurs Cas Exchange 2007 /2010

Les serveurs client Access supportent la charge de plusieurs services comme les services ActiveSync RpcOverHttp, Owa etc. Mesurer leurs charges est important, surtout en cas de lenteurs constatées, mais également lorsque vous allez, petit à petit migrer les utilisateurs vers la nouvelle plateforme. L’utilitaire de Performance propose une vaste gamme de compteurs et choisir le bon n’est pas forcement chose aisée.Le but de cette section est donc de présenter quelques indicateurs clefs qui vous permettront en un clin d’œil de visualiser la charge de vos processus.

 

Mesure de la performance OWA

 

La première étape est de vérifier dans un premier temps le nombre d’utilisateur connectés. Cette possibilité vous est offerte par le compteur :

MSExchange OWA\Utilisateurs uniques actuels.(
MSExchange OWA\Current Unique Users ) Exchange 2007/2010.
Ce compteur indique le nombre d’utilisateurs uniques actuellement connectés à OWA. Il reprend le nombre d’utilisateur connectés actuel tant que ceux ci ne ce sont pas déconnectés. Si vous avez des serveurs Cas multiples en répartition de charge IP, il est intéressant de créer plusieurs instances de ce compteur depuis un même serveur CAS de façon à mesurer effectivement si votre répartition de charge pour le processus OWA fonctionne. Une fois que vous avez pris en compte le nombre d’utilisateur connectés sur vos serveurs, il est important je pense, de mesurer si les temps d’accès aux ressources OWA sont correctes.

Pour cela Microsoft fourni un compteur intéressant :

 

MSExchange OWA\Temps moyen de réponse : Ce dernier indique le temps moyen en milliseconde qui s’est écoulé entre le début d’une demande et la fin de cette dernière. Ce compteur permet donc d’estimer la latence moyenne des requêtes clients et vous permettra d’estimer le ressenti utilisateur. Pour que cela soit correct, il faut que cette valeur soit inférieure à 100 ms de façon continue. Si cela n’est pas le cas, Examiner le nombre de connexion et la charge processeur.

 

 

Mesure de la performance ActiveSync

 

Un peu moins critique, le service ActiveSync peut également faire l’objet de mesure mais ne possède que peu de compteur en environnement 2007.

 

MSExchange ActiveSync\Durée moyenne de demande indique le temps moyen d’une demande faite au serveur via ActiveSync. Microsoft ne donne pas de valeur critique quand a ce dernier compteur. Dans le cas de plusieurs Cas, je vous conseillerais de les comparer pour vérifier d’une part la répartition de charge et d’autre part pour éventuellement détecter que ces derniers soient homogène.

 

 

Mesure de la performance disques

Les latences disques ont un effet assez direct sur la charge d’un serveur. Plus impactant sur un serveur Mailbox que sur un serveur Cas, le mauvais dimensionnement de IO disques sur un serveur Cas risque de provoquer des ralentissements généraux de l’environnement server. Moins évolué que sur les serveurs de boites aux lettres, deux compteurs existent qui permettent de mesurer la latence disques des serveurs CAS. Le premier est un compteur en lecture uniquement :

 

(LogicalDisk(_Total)\Lectures disque/s), le second en écriture (LogicalDisk(_Total)\Écritures disque/s). Dans les deux cas les valeurs observées cumulées doivent être inférieures à 50

 

Mesures de la performance du service de disponibilité.

 

Le service de disponibilité est typiquement un processus client dont une latence trop importante sera rapidement constatée par les clients Outlook. La vérification de la relative bonne santé de ce service est importante. Concernant cette mesure Microsoft fourni le compteur suivant :

 

MSExchange Availability Service\Délai de traitement moyen d’une requête de disponibilité (MSExchange Availability Service\Average Time to Process a Free Busy Request) qui indique le temps moyen de traitement d’une requête de disponibilité. Le temps est donné en seconde et doit toujours être inférieur à 5.

 

Mesure de la performance du processus ASP.NET

Les processus ASP net jouent un rôle important en tant que processus sous jacent dans l’environnement Exchange. Pour mesurer leurs exécutions correctes utiliser le compteur suivant :

ASP.NET\Durée d’attente de la requête (ASP.NET\Request Wait Time). En environnement Exchange 2007 celle-ci doit inférieure à 1000 ms. En environnement 2010 celle-ci doit être égale à 0.

Indique le nombre de millisecondes attendu par la demande la plus récente dans la file d’attente.

 

 

 

Performance de la couche transport

 

La couche transport est importante car le délai important peut se faire ressentir très rapidement par les clients de messagerie qui ont désormais come habitude de voir les messages délivrés très rapidement. A la différence d’y il a quelques années, nos chers utilisateurs s’inquiètent désormais lorsqu’il constate que les mails n’arrivent pas dans les quelques minutes qui suivent leurs envois. D’autre part, laisser « trainer » des mails en attente n’est pas bon signe car compte tenu de la volumétrie échangée, la saturation d’espace disque n’est souvent pas loin.

 

Une donnée importante à mesurer est donc la longueur des files d’attentes. Quelles files d’attentes me direz-vous. La réponse est : toute. Microsoft fourni un paramètre magique qui permet en un clin d’œil de visualiser l’état des files d’attente. Ce dernier est :

 

\Files d’attentes de MSExchangeTransport(_total)\Longueur globale des files d’attente de remise (toutes les files d’attente) (\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)). Cette dernière comme sont nom l’indique précise la longueur cumulée de toutes les files d’attente sur le serveur en question. La valeur doit être inférieure à 3000 et ne pas dépasser 5000 (Exchange 2003/2010). J’ajouterai que plus cette valeur est petite plus vos serveurs de transport sont en mesure de délivrer rapidement les messages et que aucun point de destination n’est injoignable.

 

Il existe ensuite pas mal de compteur pour toutes les files d’attentes qui en fonction de ce que vous aurez observé dans le premier compteur ci-dessus méritent d’être vérifiées. C’est le cas des files d’attentes suivantes :

 

  • Longueur des files d’attente de remise distante actives
  • Longueur des files d’attente de remise des boîtes aux lettres actives
  • Longueur de la file d’attente de soumission
  • Longueur des files d’attente de remise Non-SMTP actives
  • Longueur des files d’attente de remise des boîtes aux lettres de nouvelle tentative
  • Longueur des files d’attente de remise non-SMTP de nouvelle tentative
  • Longueur des files d’attente de remise distante de nouvelle tentative
  • Longueur des files d’attente inaccessibles
  • Longueur de la file d’attente de remise la plus grande
  • Longueur de la file d’attente de messages incohérents

 

Un compteur cependant doit attirer plus particulièrement votre attention qui est la Longueur de la file d’attente de soumission. Dans le cas ou celle-ci dépasserait 100 allez vérifier vos serveurs de boites aux lettres ainsi que la disponibilité de votre environnement Active Directory.

 

Comme pour l’ensemble des serveurs, les temps de latence disques sont importants. La surveillance des compteurs suivant en lecture écriture demeure donc nécessaire :

 

  • Disque logique/physique(*)\Moyenne disque s/lecture (Logical/Physical Disk(*)\Avg. Disk sec/Read)

 

  • Disque logique/physique(*)\Moyenne disque s/écriture (Logical/Physical Disk(*)\Avg. Disk sec/Write)

 

 

La valeur à ne pas dépasser en environnement de production est de 50 en moyenne (Exchange 2007/2010)

 

 

PERFORMANCE DES SERVEURS DE BOITES AUX LETTRES

 

La performance des serveurs de boites aux lettres est importante car la plupart des clients Outlook sont connectés dessus. Ceci est encore plus vrai si vous avez d’ancien client Outlook qui ne sont pas positionnés en mode cache. Le moindre ralentissement de l’activité de votre serveur de boites aux lettres Exchange aura pour conséquence un ressenti utilisateur.

Dans un environnement de serveur de base de données plusieurs compteurs doivent être inspectés on notera que les aspects disque, latence RPC jouent un rôle important dans le ressenti utilisateurs.

La première chose à vérifier sur un serveur de boites aux lettre en production est le nombre de client Outlook que nous avons de connectés (MSExchangeIS\Nombre d’utilisateurs). C’est important pour la suite car si peu d’utilisateur sont connecté set que vos latences RPC sont trop longues alors … il faut s’inquiéter.

 

Concernant les ressources disques et leurs surveillance, il faut séparer les disques de données contenant les bases et ceux concernant les journaux.

 

CONCERNANT LES DISQUES DE BASES DE DONNEES : vous devrez vérifier les compteurs suivants :

 

Disque logique(*)\Moyenne disque s/lecture &Disque physique(*)\Moyenne disque s/lecture

La valeur moyenne à ne pas dépasser est de 20 Ms. C’est ce seuil que vérifie notamment le produit Jetstress que vous avez ou auriez du passer sur vos volumes pour contrôler la capacité de votre matériel à supporter la charge. Le second compteur est celui en écriture

 

Disque logique(*)\Moyenne disque s/écriture & Disque physique(*)\Moyenne disque s/écriture

Dans ce cas vérifiez qu’il ne dépasse pas 100.

Dans le cas ou les valeurs constatées sont supérieures il faudra vérifier l’ensemble de la chaine de liaison de votre sous systèmes disques. A savoir les pilotes de disque (drivers HBA par exemple) , l’organisation des modules raid etc..

 

CONCERNANT LES DISQUES DE JOURNAUX vous devrez vérifier les compteurs suivants :

 

Disque logique(*)\Moyenne disque s/lecture La valeur moyenne a ne pas dépasser est de 20 Ms. C’est ce seuil que vérifie notamment le produit Jetstress que vous avez ou auriez du passer sur vos volumes pour contrôler la capacité de votre matériel à supporter la charge.

 

Disque logique(*)\Moyenne disque s/écriture

Dans ce cas vérifier qu’il ne dépasse pas 10.

 

Le second compteur clef que vous devez vérifier concerne la latence RPC de votre serveur de boites aux lettres. Ce dernier est le suivant :

 

MSExchangeIS\Latence RPC moyenne (MSExchangeIS\RPC Averaged Latency).


Il indique la latence RPC moyenne, exprimée en millisecondes, de toutes les opérations des 1 024 derniers paquets. Cette valeur doit être inférieure à 25 ms en moyenne en Exchange 2007 et 10 ms en Exchange 2010 (En moyenne)

 

Autre point de contrôle

 

Vérifier si votre serveur Exchange a assez de mémoire.

Exchange 2007 est pourvu d’un cache de base de données sans limitations connues. La consommation de la mémoire par le processus store est supérieure à l’environnement Exchange 2003. L’allocation de mémoire concernant le cache est dynamique et le moteur jet va utiliser toute la mémoire disponible du système et en redonner si besoins. Dans le cas d’un environnement serveur de 20 Go le cache de base de données va utiliser environ 18 Go et laisser environ 2Go pour le système. L’allocation dynamique de buffer va en fait faire grandir le cache en comparant les Entrées Sorties des bases de données avec les totalités des entrées sortie du système qui génère des défauts de pages matériel (voir rappel) . En gros, si le serveur Exchange génère plus d’E/S et surtout plus de défaut de pages, le cache va s’agrandir, ce qui est logique. Dans le cas contraire le cache va diminuer. Lors des opérations de maintenance, il faut également prendre en compte que lors des opérations de maintenance la mémoire nécessaire supplémentaire peut avoisiner les 4GB. Sur des serveurs en production équipés de 32 Go de mémoire vive et Windows 2008 SP2, abritant environ 4500 boites aux lettres nous avons observé ce phénomène. Entre 30 et 28 Go de mémoire allouées sur les serveurs actifs.

 

Rappel : Défaut de page (Technet): Si un processus demande une page en mémoire et ne peut pas la trouver à l’emplacement requis, un défaut de page se produit. C’est ce qu’on appelle un défaut de page matériel (ou disque). Si une page est trouvée ailleurs dans la mémoire, le défaut est appelé défaut de page logiciel (mémoire)

 


 

Pour savoir si votre serveur dispose de suffisamment de mémoire, vérifier la valeur du compteur suivant :

Mémoire\Pages de lecture/s (Memory\Page Reads/sec) : Indique que les données doivent être lues à partir du disque plutôt que de la mémoire. Indique que la mémoire est insuffisante et que la pagination commence. Une valeur supérieure à 30 par seconde signifie que le serveur ne peut plus supporter la charge. (Exchange 2007/2010)

 

Vérifier la disponibilité de votre environnement AD

Le serveur Exchange 2007/2010 va effectuer des requêtes LDAP sur les serveurs contrôleur de domaine. Si ces derniers sont trop sollicités des ralentissements ce feront ressentir.

Microsoft fourni certains compteur qui vont vous permettre de mesurer les temps de réponses de vos serveurs Active Directory vis-à-vis des demandes Exchange. Pour cela utiliser les compteurs suivants :

 

Contrôleurs de domaine MSExchange ADAccess(*)\Durée de lecture LDAP : Indique le temps, exprimé en millisecondes (ms), pour envoyer une demande de lecture LDAP au contrôleur de domaine spécifié et recevoir une réponse.

 

Contrôleurs de domaine MSExchange ADAccess(*)\Durée de recherche LDAP

Indique le temps (en ms) pour envoyer une demande de recherche LDAP et recevoir une réponse.

 

Ces valeurs doivent être inférieures à 50 ms en moyenne. Les pics (valeurs maximales) de doivent pas être supérieurs à 100 ms.

 

Bien sur il existe bon nombre de compteur à commencer par ceux de la carte réseau, mais l’objectif de l’article était d’en dégager quelque uns qui convient de surveiller plus particulièrement surtout si vous ne disposez pas d’outils de supervision tels que Scom.

 

Pour information les valeurs données pour Exchange 2010 ne sont pas encore totalement figée dans le marbre car non publiées pour l’instant mais ne devraient pas évoluer énormément.

 

Bonne fêtes
Laurent Teruin

 


 

Posted in Performance-2007, Performance-2010 | Leave a Comment »

WebCast: Sauvegarde et Archivage des messages en Exchange 2007

Posted by Teruin laurent le décembre 23, 2009


La gestion des données de la messagerie d’entreprise est devenu au cours du temps un véritable casse tête ! La complexité s’est accrue d’autant plus avec les lois concernant la rétention des messages électroniques.Dans cette session, nous aborderons comment Microsoft permet aux administrateurs Exchange de sauvegarder leurs systèmes de messagerie avec Microsoft Data Protection Manager 2007, les nouveautés du SP1 de DPM et le positionnement de cette approche avec les solution de secours native à Exchange 2007. Nous aborderons aussi comment Exchange 2007 SP1 permet d’adresser les problématiques légales (SOX, BALE2, EuroSox) ou non de rétention des messages.

 A suivre : http://www.microsoft.com/france/vision/mstechdays09/Webcast.aspx?EID=f98be21f-a8f7-46d0-89ca-f95b98fc02a2

Posted in Sauvegarde-2007 | Leave a Comment »

GESTION DU MAIL APPLICATIF

Posted by Teruin laurent le décembre 23, 2009


L’on conviendra tous que les flux de messagerie sont devenus tout autant critiques que le fonctionnement de certaines bases de données métier au sein des entreprises. Arrêter les services de messagerie est devenu parfois tout simplement impossible compte tenu du nombre d’information transitant par ce média. Au fur et mesure des projets en tout genre qu’il m’à été donné d’entreprendre, j’ai pu constater que les flux applicatifs de messagerie, flux utilisés par les applications métiers, ne sont généralement pas contrôlés. L’idée n’est évidement pas de systématiquement dans un environnement partiellement sécurisé que constitue le réseau local de l’entreprise, de « fliquer » les communications mais simplement recenser, voir normaliser les protocoles de communications de l’outil de messagerie.

Les flux applicatifs de messagerie sont généralement initiés par des applications diverses, développées par différentes équipes, utilisant à leurs tours différentes plateformes de développement. Dans la plupart des cas, les connaissances en matières de sécurisation des protocoles Smtp, Pop3, Imap4 (Authentification, Cryptage, signature etc..) sont quasi inconnu des développeurs ou chef de projet. Ils se contentent simplement de l’utilisation des telles ou telles fonctions fournie par l’interface de développement.

La conséquence de cette situation conduit généralement à la mise en place quelque peu précipitée d’un service d’envoi et de réception totalement ouvert , sans authentification préalable permettant au flux métier de pouvoir envoyer et recevoir sans véritable contrôle des messages depuis , ou vers le réseau Internet. L’open relai est une faille de sécurité importante car il permet facilement l’usurpation d’identité sans pouvoir en déterminer la source (Absence d’authentification). De plus, l’absence de contrôle des méthodes de connexions complexifie l’évolution des infrastructures de messagerie. Le déplacement des services d’envoi et de réception de message est alors hasardeux compte tenu de la non-connaissance par les équipes technique de l’utilisation faite par les progiciels métiers. L’outil ou du moins l’utilisation qui en est faite échappe alors à son gestionnaire. Or je pense que cela n’est pas souhaitable à terme, la normalisation des protocoles d’échange doit nécessairement être établie car elle est souvent beaucoup plus critique pour l’entreprise que la communication interpersonnelle dont l’importance de certain sujet reste encore à démontrer…

 

Vers une normalisation des échanges

Comme précisé en introduction l’Entreprise doit pouvoir contrôler l’usage qui est fait de son principal outil de communication à savoir son outil de messagerie. Il convient donc de proposer à l’ensemble des acteurs concernés une normalisation des échanges. Cette proposition de normalisation devrait inclure plusieurs niveaux de sécurité pour permettre à certaines applications aux fonctionnements basiques de pouvoir malgré tout continuer à envoyer ou recevoir des messages. Je propose donc une normalisation à plusieurs niveaux avec la suppression progressive de ces relais ouverts permettant à quiconque d’envoyer au nom d’une personne interne un message à destination de l’interne ou de l’externe.

Le premier niveau à prendre en compte est l’authentification des serveurs ou stations de travail devant initier une connexion vers les services de messagerie. Par la même, les administrateurs de plateformes de messagerie pourront restreindre l’utilisation des services SMTP à ces dernières, évitant que tout utilisateurs depuis son poste puisse envoyer en dehors de son traditionnel client de messagerie des messages au nom d’autre personne. La restriction s’effectuera la plupart du temps par une interdiction du relai ouvert exception faite des machines concernées. Dans la plupart des cas ces restrictions se feront soit par adresse IP soit par le nom pleinement qualifié (nomdelastation.nomdudomaineinterne.extension). Cette protection constitue le premier niveau de sécurisation. La problématique dans sa mise en place réside dans l’authentification des machines. Pour ce faire, les journaux de connexion des actuels serveurs SMTP/POP/IMAP seront d’une grande utilité.

Le deuxième niveau concerne le premier aspect de normalisation à mettre en place. En effet, les applications émettrices peuvent adresser les services SMTP de plusieurs façons. La première méthode est l’adressage direct via l’adresse IP. La seconde est l’utilisation d’un nom pleinement qualifié dont la résolution peut être assurée par les services DNS de l’entreprise ou localement par le biais d’un fichier host. Dans tout les cas, ces méthodes ralentissent considérablement les déplacements de services SMTP lors des opérations de migration d’infrastructure. Elle complexifie également les tests de plan de reprise d’activité. IL faut donc mettre en place un adressage commun relatif comme le nom DNS le permet, et imposer ce dernier à tous les environnements de développement. Une fois réalisé, il sera très simple de basculer un service SMTP vers un autre serveur sans véritable conséquence pour les flux applicatifs. On pensera également à baisser la durée de vie des ces enregistrements afin de faciliter la convergence en cas de basculement de service.

Le troisième niveau de concerne l’authentification des connexions applicatives. Ici plusieurs techniques sont possibles. Dans la plupart des cas il faudra composer avec ce que sont capable de faire les applications métiers. Certaines seront capables d’utiliser plusieurs méthodes d’authentification plus ou moins sécurisées, d’autre ne proposeront qu’un seul type d’authentification de type plaintext. (Passage du mot de passe en clair sur le réseau cf : http://tools.ietf.org/html/rfc4616). La rfc4954 (http://tools.ietf.org/html/rfc4954) définie par l’IETF précise la façon dont une application peut négocier son authentification. Il existe à ce jour plusieurs protocoles d’authentification (GSSAPI, DIGEST-MD5,PLAIN,CRAM-MD5,NTLM) qui seront supportées ou pas, selon votre solution de messagerie. On précisera ici qu’il s’agit d’authentification simple. Ces mécanismes d’authentification sont intégralement décrit dans la Rfc 4422 (http://tools.ietf.org/html/rfc4422) .

A ce stade plusieurs organisations sont possibles. La première est d’utiliser un seul et même compte utilisateur pour l’ensemble des applications métiers. Solution que je ne conseillerai pas en raison de l’impact que pourrai avoir la suppression de ce compte ou le changement de son mot de passe. La seconde est d’utiliser un compte générique par applications métier. De cette façon vous contrôlerez beaucoup mieux le modèle de permissions et minimiserez l’impact d’un changement de mot de passe.

Le quatrième niveau consiste à mettre en place une solution sécurisée basée sur le cryptage systématique des flux internes. Elle demandera l’utilisation de certificat permettant de mettre en place la couche SSL. Elle sera nécessaire si vous désirez sécuriser les flux de réception utilisés par vos applications métiers (POPs/Imaps). Par défaut Exchange 2007 est d’ailleurs paramétré pour n’utiliser que la couche sécurisée des deux protocoles précités.

Une évolution alternative consiste à utilisez pour les applications ayant la nécessitée d’interagir fortement avec la messagerie (Messagerie, Calendrier etc..) , le protocole propriétaire utilisé par les clients de messagerie (Ex : Mapi pour Microsoft Exchange). Certains d’entre eux sont également accessibles par le biais de protocole plus standardisés comme cela est le cas dans l’environnement Microsoft Exchange 2007 via les Webservices. (http://msdn.microsoft.com/en-us/library/bb204119.aspx)

Conclusion

Sans céder aux tentations de la sécurisation à outrance, la sécurisation des flux de messagerie engendrés par les applications métiers est nécessaire pour éviter la perte de contrôle de l’utilisation de l’outil. Du simple référencement à la mise en place d’authentification basée sur une couche de transport cryptée, plusieurs niveaux sont possibles. Nul doute que la mise en place sera longue et progressive car elle demandera des modifications des développement existants. Malgré cela l’entreprise gagnera en souplesse facilitant la reprise d’activité et les opérations de modification d’infrastructure, tels que les migrations et les montées de version. En tout état de cause elle renforcera son niveau de sécurité.

 

 

 

Posted in 7-Gouvernance | Leave a Comment »

Procédure de migration Blackberry pour Exchange 2007

Posted by Teruin laurent le décembre 23, 2009


Certains d’entre vous aurons dans le cadre de leurs projets de migrer les serveurs Blackeberry vers EXchange 2007. Voici donc la procédure a suivre :

Environment

  • BlackBerry® Enterprise Server for Microsoft® Exchange

Microsoft® Exchange Server 2000 to 2007

Overview

To migrate the BlackBerry Enterprise Server from Microsoft Exchange Server 2000 or 2003 to Microsoft Exchange Server 2007, complete the following steps:

  1. Stop all BlackBerry Enterprise Server services.
  2. Important: Restarting certain BlackBerry Enterprise Server services will delay email message delivery to BlackBerry smartphones. For more information, see article KB04789.
  3. Move the BlackBerry Enterprise Server service account mailbox to the new Microsoft Exchange Server. The default name for this account is BESAdmin.
  4. After migrating Microsoft Exchange Server 2000 or 2003, verify the Microsoft Exchange Server 2007 permissions for the BlackBerry Enterprise Server.
  5. Set the required permissions for the BlackBerry Enterprise Server in Microsoft Exchange 2007. For more information, see article KB12483.
  6. If Microsoft Exchange System Manager 2003 Service Pack 2 (SP2) Version 6.5.7638 or higher is installed on the BlackBerry Enterprise Server skip to step 10. If it is lower, continue with step 6.
  7. Remove Microsoft Exchange System Manager. (A Microsoft Exchange Server installation CD is required to complete this step.)
  8. Perform a search for MAPI32.dll and cdo.dll.
  9. Rename any cdo.dll and MAPI32.dll files from the system32 folder and the program files\exchsrvr\bin folder to a .bak file extension.
  10. Download and install the latest Messaging Application Programming Interface (MAPI) and Collaboration Data Object (CDO) clients. For more information, see article KB12697.
  11. Stop all BlackBerry Enterprise Server Services.
  12. Resolve the MAPI profile for the BlackBerry Enterprise Server by going to Start > Programs > BlackBerry Enterprise Server > Edit MAPI Profile.
  13. Start the BlackBerry Enterprise services. Be sure to start the services in this order:

    BlackBerry Router     BlackBerry Dispatcher     BlackBerry Controller .    The rest in any order

     

Resolve the MAPI profile for the BlackBerry Enterprise Server service account mailbox on the Microsoft Exchange Server 2007 by going to Start > Programs > BlackBerry Enterprise Server > Edit MAPI Profile.

Important: Restarting the BlackBerry Enterprise Server will delay email message delivery to BlackBerry smartphones. For more information, see article KB04789.

Posted in Mobilité-2007 | Leave a Comment »

Testez Microsoft Forefront Management Gateway

Posted by Teruin laurent le décembre 23, 2009


   

 Microsoft vient de mettre à disposition la Release To Manufacturing (RTM) du successeur d’ISA Server : Forefront Threat Management Gateway (TMG). Basé sur Windows Server 2008, Forefront TMG est conçu pour offrir une administration simplifiée, une connectivité sécurisée, et une protection contre des menaces multiples. C’est une passerelle web sécurisée (incluant une protection anti-malware) qui permet de protéger les employés des menaces lorsqu’ils surfent sur Internet. De plus, Forefront TMG protège le réseau des attaques zero-day et inspecte le trafic sortant HTTP et HTTPS.

 

 Les nouveautés présentes dans Forefront TMG sont :

  • Contrôle de l’accès réseau au niveau du Firewall
  • Protection des utilisateurs contre les menaces qu’ils peuvent rencontrer lorsqu’ils surfent. (Web Client Protection)
  • Protection des utilisateurs des menaces liées aux E-mail (Email Protection)
  • Protection des postes de travail et des serveurs contre les tentatives d’intrusion. (NIS)
  • Possibilité pour les utilisateurs d’avoir un accès distant aux ressources de l’entreprise. (VPN, Secure Web Publishing)
  • Management simplifié

  Pour télécharger la version : http://www.microsoft.com/downloads/details.aspx?FamilyID=E05AECBC-D0EB-4E0F-A5DB-8F236995BCCD&displaylang=en


 

Posted in Non classé | Leave a Comment »

Publication de Exchange 2010 a travers un serveur ISA 2006 SP1

Posted by Teruin laurent le décembre 23, 2009


Comme vous le savez peut-être, la publication d’un environnement Exchange 2010 est possible à travers un serveur ISA 2006 SP1. Cependant, ISA 2006 entretien des relations étroites avec l’environnement Exchange notamment en ce qui concerne l’environnement de publication OWA et l’authentification par Formulaire.. De plus, les serveurs Exchange 2010 CAS n’utilisent plus certains répertoires comme /exchweb et /unifiedmessaging. Les serveurs CAS utilisent également d’autres répertoires comme Exchange Control Panel. Les serveurs Exchange 2010 ne fournissent pas l’accès à l’environnement de boites aux lettres des plateformes anciennes et vont utiliser la technique de redirection.

Comme on peut donc le prévoir certaines disposition de publication… devront être réalisées pour permettre une publication correcte de l’environnement Exchange 2010 à travers un serveur ISA 2006 SP1.

Ross Smith vient de publier un article très complet à ce sujet. Un document complet et indispensable pour assurer la migration exchange 200x vers Exchange 2010 sans encombre.

A lire donc : http://msexchangeteam.com/archive/2009/12/17/453625.aspx

Cordialement

Posted in Publication-2010 | Leave a Comment »

Procédures d’installation d’un serveur Exchange 2010 RU1 en Windows 2008 R2

Posted by Teruin laurent le décembre 23, 2009


INTRODUCTION

 

Le but de ce document est de présenter l’ensemble des actions que vous devrez entreprendre pour installer un serveur Exchange 2010 RU1 sur un environnement Windows 2008 R2. Dans cet article nous supposons que votre serveur Windows 2008 devant héberger l’environnement Microsoft Exchange 2010 est « fraichement » installé et ne comporte pas de logiciel autre que ceux fourni par une installation de base.

ETAPES PREPARATOIRES

 

Pour installer les pré-requis Windows 2008 R2 de Microsoft Exchange 2010 vous devez procéder de la façon suivante :

  • Etape 1 Installation du composant Microsoft Filter Pack

Sur chaque server qui vont héberger les rôles de transport ou de boites aux lettres vous devez procéder a l’installation du module Microsoft Filter Pack. Ce composant peut être récupérer sur le lien suivant :

http://www.microsoft.com/downloads/details.aspx?FamilyId=60C92A37-719C-4077-B5C6-CAC34F4227CC&displaylang=en

  • Etape 2 : Importation du module Serveur Manager

les étapes suivantes vont necessiter l’ajout du module ServerManager. pour ce faire :

Cliquer sur StartMenu/All programs/Accesories/Windows Powershell, ouvrer une console powershell en administrateur et executer la commande suivante

  • Import-Module ServerManager
  • Etape 3 : Installation des modules complémentaires

Nous allons maintenant procéder à l’installation des compléments Windows nécessaire a l’installation de Microsoft Exchange 2010.

Composant Windows requis pour un serveur MB/CAS/HUB

Si vous envisager d’installer un serveur de boites aux lettres, hébergeant en plus les rôles Client Access et Transport exécuter la commande suivante :

  • Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

Composant Windows réquis pour un serveur MB/CAS/HUB/UM

Si vous envisager d’installer un serveur de boites aux lettres, hébergeant en plus les rôles Client Access et Transport et messagerie unifié exécuter la commande suivante

  • Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy,Desktop-Experience -Restart

Composant Windows requis pour un serveur CAS/HUB

Si vous envisager d’installer un serveur ayant les rôles Client Access et Transport éxecuter la commande suivante :

  • Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

Composant Windows requis pour un serveur CAS :

Si vous envisager d’installer un serveur uniquement le rôle Client Access exécuter la commande suivante :

  • Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

Composant Windows requis pour un serveur HUB/MB :

Si vous envisager d’installer un serveur uniquement le rôle Hub Transport ou Serveur de boites aux lettres exécuter la commande suivante :

  • Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server -Restart

Composant Windows requis pour un serveur de messagerie unifiée :

Si vous envisager d’installer un serveur uniquement possédant le rôle UM exécuter la commande suivante :

  • Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Desktop-Experience -Restart

Composant Windows requis pour un serveur Edge :

Si vous envisager d’installer un serveur uniquement possédant le rôle Edge exécuter la commande suivante :

  • Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS -Restart
  • Etape 4 : Paramétrage du port TCP

Une fois que le serveur a redemarrer connectez-vous sur le serveur dans le domaine avec un compte administrateur et configurer le service de partage de port TCP. Net (Net.Tcp Port Sharing Service) pour qu’il démarre automatiquement. pour cela tapez la commande suivante :

  • Set-Service NetTcpPortSharing -StartupType Automatic

 

  • Etape 5 : Mise à jour du système d’exploitation

Avant de procéder à l’installation de Microsoft Exchange 2010 effectuer une mise a jour dus système d’exploitation via Microsoft Update pour récupérer et installer les dernières mises à jour.

 

INSTALLATION DE EXCHANGE 2010

Conditions préalables

Vous devez vous assurer que chaque rôle serveur répond aux conditions préalables et à la configuration système requises avant de commencer l’installation.

Installer Exchange ServeUr 2010

(Extrait technet)

Pour exécuter la procédure suivante, vous devez utiliser un compte auquel l’appartenance au groupe Administrateurs de schéma a été déléguée si vous n’avez pas déjà préparé le schéma Active Directory. Si vous installez le premier serveur Exchange 2010 de l’organisation, vous devez utiliser un compte appartenant au groupe Administrateurs d’entreprise. Si vous avez déjà préparé le schéma mais que vous n’installez pas le premier serveur Exchange 2010 de l’organisation, vous devez utiliser un compte appartenant au groupe Rôle installation déléguée.

Dans la page Démarrer, vérifiez que vous avez effectué les étapes 1 à 3. Si vous n’avez pas encore installé les composants dont il est question dans ces étapes, le programme d’installation affichera un lien vers les sites correspondants pour vous permettre de télécharger ces composants. La page Introduction lance l’installation d’Exchange dans votre organisation. Elle vous guidera au cours de l’installation. Cliquez sur Suivant pour continuer.

  1. Dans la page Contrat de licence, acceptez les termes du contrat et cliquez sur Suivant.
  2. Dans la page Rapport d’erreurs, indiquez si vous souhaitez activer ou désactiver la fonctionnalité de rapport d’erreurs Exchange, puis cliquez sur Suivant.
  3. Dans la page Type d’installation, indiquez si vous voulez réaliser une installation par défaut d’Exchange ou une installation personnalisée d’Exchange Server, puis cliquez sur Suivant. Si vous choisissez Installation par défaut d’Exchange Server, vous ne pourrez pas installer le rôle serveur de messagerie unifiée ou le rôle serveur de transport Edge. Vous pourrez ajouter des rôles serveur supplémentaires ultérieurement si vous décidez de ne pas les installer au cours de cette installation.
  4. Dans la page Sélection des rôles serveur, sélectionnez les rôles serveur Exchange à installer et cliquez sur Suivant. Vous pourrez ajouter des rôles serveur supplémentaires ultérieurement si vous décidez de ne pas les installer au cours de cette installation. Le rôle serveur de transport Edge ne peut pas coexister sur le même ordinateur qu’un autre rôle serveur. Vous devez déployer le rôle serveur de transport Edge dans le réseau de périmètre et à l’extérieur de la forêt Active Directory. Par ailleurs, les outils de gestion Exchange ne sont pas installés par défaut. Par conséquent, vous devez sélectionner Outils de gestion pour installer la console de gestion Exchange et les cmdlets Exchange pour l’environnement de ligne de commande Exchange Management Shell. Les outils de gestion sont installés automatiquement si vous installez un autre rôle serveur.
  5. S’il s’agit du premier serveur Exchange de votre organisation, dans la page Organisation Exchange, entrez le nom de votre organisation Exchange. Un nom d’organisation Exchange ne peut contenir que les caractères suivants :A à Z,a à z,0 à 9,Espace (pas au début ni à la fin),Trait d’union ou tiret
  6. S’il s’agit du premier serveur Exchange de votre organisation, dans la page Paramètres du client, cliquez sur l’option qui décrit les ordinateurs clients de votre organisation exécutant Microsoft Office Outlook.

Remarque : Si vous n’avez pas d’ordinateur client exécutant Outlook 2003 ou une version antérieure et que vous sélectionnez Oui, Exchange 2010 crée une base de données de dossiers publics sur le serveur de boîtes aux lettres. Si tous les ordinateurs clients exécutent Outlook 2010, les dossiers publics sont facultatifs dans Exchange 2010. Si vous sélectionnez Non, Exchange 2010 ne crée pas de base de données de dossiers publics sur le serveur de boîtes aux lettres. Vous pourrez ajouter une base de données de dossiers publics ultérieurement. Par exemple, si vous ajoutez des ordinateurs clients exécutant Outlook 2003 et avez besoin d’une base de données de dossiers publics, vous pouvez en créer une sur le serveur de boîtes aux lettres Exchange 2010. Vous devez ensuite configurer le carnet d’adresses en mode hors connexion pour la distribution des dossiers publics, puis redémarrer le service Banque d’informations d’Exchange avant que des ordinateurs clients exécutant Outlook 2003 ou des versions antérieures soient en mesure de se connecter au serveur.

8 – Dans la page Configurez le domaine externe du serveur d’accès au client, saisissez le nom de domaine à utiliser pour configurer les serveurs d’accès au client. Pour plus d’informations sur la configuration des serveurs d’accès au client, voir Managing External Client Access. Cliquez sur Suivant.

9- Dans la page Programme d’amélioration de la satisfaction client, choisissez les sélections appropriées à votre organisation, puis cliquez sur Suivant.

10- Dans la page Tests de préparation, affichez l’état pour déterminer si les contrôles préalables de l’organisation et du rôle serveur ont été accomplis avec succès. Si c’est le cas, cliquez sur Installer pour installer Exchange 2010.

11- Dans la page Achèvement, cliquez sur Terminer.

 

INSTALLATION DU CORRECTIF RU1

 

Une fois que votre installation Exchange 2010 est terminée, vous devez installer le dernier correctif Exchange 2010 RU1. Certaines précautions sont à prendre.

IMPORTANT :

Si votre serveur Exchange 2010 n’est pas connecté à l’internet nous vous conseillons d’effectuer la procédure suivante, qui vous évitera d’attendre un certain temps lors de l’application du correctif

  • Dans Internet Explorer, sélectionnez l’onglet Avancé/Outils, Internet Options.
  • Dans la section sécurité, cliquez pour décocher la case à cocher Vérification de révocation de certificats de l’éditeur.
  • Cliquez sur OK pour fermer la boîte de dialogue Internet Options.

Si vous avez modifié les pages OWA dans Exchange 2010, le paragraphe suivant vous concerne :

Lorsque vous appliquez un package de correctifs cumulatifs, le processus de mise à jour écrase les fichiers OWA (Outlook Web App) s’il est nécessaire. Si vous avez modifié le fichier Logon.aspx ou d’autres fichiers OWA, les personnalisations sont remplacées pour vous assurer que OWA est correctement mis à jour. Après avoir appliqué le package de correctifs de mise à jour, vous devez recréer personnalisation OWA dans Logon.aspx.

Nous vous recommandons de toujours effectuer une copie de sauvegarde de tous les fichiers OWA personnalisées avant d’appliquer le correctif cumulatif.

Si vous avez installé des mises à jour intermédiaires ; il faut impérativement les supprimer. (Interim Updates)

Pour récupérer le correctif, cliquez sur le lien suivant :

http://www.microsoft.com/downloads/details.aspx?FamilyID=371add31-d7a0-4c8b-8325-a6fced2d05e6&displaylang=en

 

Positionnement des sources

Afin de faciliter la maintenance nous vous conseillons de copier les sources sur une partition du serveur en organisant les répertoires suivants


 

VERIFICATION DE L’INSTALLATION

 

Une fois terminé, vous devez vérifier l’installation de l’environnement Microsoft Exchange. Pour cela exécuter la commande Powershell

  • Get-Exchangeserver

Et examiner le journal d’installation. En cas de souci ce dernier vous informera sur les problèmes d’installation.


Vérifications de base

  1. Après avoir redémarrer, vérifier que tout les services Exchange 2010 positionnés en démarrage automatique sont correctement lancés
  2. Vérifier l’accès à la console Exchange 2010
  3. Créer une boite aux lettres de test
  4. Vérifier l’accès à Outlook Web APP via le navigateur IE sur le serveur Exchange en tapant le nom du serveur pleinement qualifié suivi de /owa comme suit : http://nomduserveurfqdn/owa
  5. Vérifier l’envoi et la réception de message depuis OWA depuis et vers le compte de test.

 

ANNEXES

 

Liste des services installés par Microsoft Exchange 2010

 

SERVICE NAME

SERVICE SHORT NAME

SECURITY CONTEXT

DESCRIPTION AND DEPENDENCIES

DEFAULT STARTUP TYPE

SERVER ROLES

REQUIRED (R) OR OPTIONAL (O)

Microsoft Exchange Active Directory Topology

MSExchangeADTopology

Local System

Provides Active Directory topology information to Exchange services. If this service is stopped, most Exchange services are unable to start. This service has no dependencies.

Automatic

Mailbox, Hub Transport, Client Access, Unified Messaging

R

Microsoft Exchange ADAM

ADAM_MSExchange

Network Service

Stores configuration data and recipient data on the Edge Transport server. This service represents the named instance of Active Directory Lightweight Directory Service (AD LDS) that’s automatically created by Setup during Edge Transport server installation. This service is dependent upon the COM+ Event System service.

Automatic

Edge Transport

R

Microsoft Exchange Address Book

MSExchangeAB

Local System

Manages client address book connections. This service is dependent upon the Microsoft Exchange Active Directory Topology service.

Automatic

Client Access

R

Microsoft Exchange Anti-spam Update

MSExchangeAntispamUpdate

Local System

Provides the Microsoft Forefront Protection 2010 for Exchange Server anti-spam update service. On Hub Transport servers, this service is dependent upon the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service is dependent upon the Microsoft Exchange ADAM service.

Automatic

Hub Transport, Edge Transport

O

Microsoft Exchange Credential Service

MSExchangeEdgeCredential

Local System

Monitors credential changes in AD LDS and installs the changes on the Edge Transport server. This service is dependent upon the Microsoft Exchange ADAM service.

Automatic

Edge Transport

R

Microsoft Exchange EdgeSync

MSExchangeEdgeSync

Local System

Connects to an AD LDS instance on subscribed Edge Transport servers over a secure LDAP channel to synchronize data between a Hub Transport server and an Edge Transport server. This service is dependent upon the Microsoft Exchange Active Directory Topology service. If Edge Subscription isn’t configured, this service can be disabled.

Automatic

Hub Transport

O

Microsoft Exchange File Distribution

MSExchangeFDS

Local System

Distributes offline address book (OAB) and custom Unified Messaging prompts. This service is dependent upon the Microsoft Exchange Active Directory Topology and Workstation services.

Automatic

Client Access, Unified Messaging

R

Microsoft Exchange Forms-Based Authentication

MSExchangeFBA

Local System

Provides forms-based authentication to Microsoft Office Outlook Web App and the Exchange Control Panel. If this service is stopped, Outlook Web App and the Exchange Control Panel won’t authenticate users. This service has no dependencies.

Automatic

Client Access

R

Microsoft Exchange IMAP4

MSExchangeIMAP4

Network Service

Provides IMAP4 service to clients. If this service is stopped, clients won’t be able to connect to this computer using the IMAP4 protocol. This service is dependent upon the Microsoft Exchange Active Directory Topology service.

Manual

Client Access

O

Microsoft Exchange Information Store

MSExchangeIS

Local System

Manages the Exchange Information Store. This includes mailbox databases and public folder databases. If this service is stopped, mailbox databases and public folder databases on this computer are unavailable. If this service is disabled, any services that explicitly depend on it will fail to start. This service is dependent on the RPC, Server, Windows Event Log, and Workstation services.

Automatic

Mailbox

R

Microsoft Exchange Mail Submission Service

MSExchangeMailSubmission

Local System

Submits messages from the Mailbox server to Exchange 2010 Hub Transport servers. This service is dependent upon the Microsoft Exchange Active Directory Topology service.

Automatic

Mailbox

R

Microsoft Exchange Mailbox Assistants

MSExchangeMailboxAssistants

Local System

Performs background processing of mailboxes in the Exchange store. This service is dependent upon the Microsoft Exchange Active Directory Topology service.

Automatic

Mailbox

R

Microsoft Exchange Mailbox Replication Service

MSExchangeMailboxReplication

Local System

Processes mailbox moves and move requests. This service is dependent upon the Microsoft Exchange Active Directory Topology and Net.Tcp Port Sharing service.

Automatic

Client Access

O

Microsoft Exchange Monitoring

MSExchangeMonitoring

Local System

Allows applications to call the Exchange diagnostic cmdlets. This service has no dependencies.

Manual

All

O

Microsoft Exchange POP3

MSExchangePOP3

Network Service

Provides POP3 service to clients. If this service is stopped, clients can’t connect to this computer using the POP3 protocol. This service is dependent upon the Microsoft Exchange Active Directory Topology service.

Manual

Client Access

O

Microsoft Exchange Protected Service Host

MSExchangeProtectedServiceHost

Local System

Provides a host for several Exchange services that must be protected from other services. This service is dependent upon the Microsoft Exchange Active Directory Topology service.

Automatic

Hub Transport, Client Access

R

Microsoft Exchange Replication Service

MSExchangeRepl

Local System

Provides replication functionality for mailbox databases on Mailbox servers in a database availability group (DAG). This service is dependent upon the Microsoft Exchange Active Directory Topology service.

Automatic

Mailbox

O

Microsoft Exchange RPC Client Access

MSExchangeRPC

Network Service

Manages client RPC connections for Exchange. This service is dependent upon the Microsoft Exchange Active Directory Topology service.

Automatic

Mailbox, Client Access

O (Mailbox), R (Client Access)

Microsoft Exchange Search Indexer

MSExchangeSearch

Local System

Drives indexing of mailbox content, which improves the performance of content search. This service is dependent upon the Microsoft Exchange Active Directory Topology and Microsoft Search (Exchange Server) services.

Automatic

Mailbox

O

Microsoft Exchange Server Extension for Windows Server Backup

WSBExchange

Local System

Enables Windows Server Backup users to back up and recover application data for Microsoft Exchange. This service has no dependencies.

Manual

Mailbox

O

Microsoft Exchange Service Host

MSExchangeServiceHost

Local System

Provides a host for several Exchange services. On internal server roles, this service is dependent upon the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service is dependent upon the Microsoft Exchange ADAM service.

Automatic

All

R

Microsoft Exchange Speech Engine

MSSpeechService

Network Service

Provides speech processing services for Unified Messaging. This service is dependent upon the Windows Management Instrumentation (WMI) service.

Automatic

Unified Messaging

R

Microsoft Exchange System Attendant

MSExchangeSA

Local System

Forwards directory lookups to a global catalog server for legacy Outlook clients, generates e-mail addresses and OABs, updates free/busy information for legacy clients, and maintains permissions and group memberships for the server. If this service is disabled, any services that explicitly depend on it will fail to start. This service is dependent on the RPC, Server, Windows Event Log, and Workstation services.

Automatic

Mailbox

R

Microsoft Exchange Throttling

MSExchangeThrottling

Network Service

Limits the rate of user operations. This service is dependent upon the Microsoft Exchange Active Directory Topology service.

Automatic

Mailbox

R

Microsoft Exchange Transport

MSExchangeTransport

Network Service

Provides SMTP server and transport stack. On Hub Transport servers, this service is dependent upon the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service is dependent upon the Microsoft Exchange ADAM service.

Automatic

Hub Transport, Edge Transport

R

Microsoft Exchange Transport Log Search

MSExchangeTransportLogSearch

Local System

Provides remote search capability for Microsoft Exchange Transport log files. On Hub Transport servers, this service is dependent upon the Microsoft Exchange Active Directory Topology service. On Edge Transport servers, this service is dependent upon the Microsoft Exchange ADAM service.

Automatic

Hub Transport, Mailbox, Edge Transport

O

Microsoft Exchange Unified Messaging

MSExchangeUM

Local System

Enables Microsoft Exchange Unified Messaging features. This allows voice and fax messages to be stored in Exchange and gives users telephone access to e-mail, voice mail, calendar, contacts, or an auto attendant. If this service is stopped, Unified Messaging isn’t available. This service is dependent upon the Microsoft Exchange Active Directory Topology and the Microsoft Exchange Speech Engine service.

Automatic

Unified Messaging

R

Microsoft Search (Exchange Server)

msftesql-Exchange

Local System

This is a Microsoft Exchange-customized version of Microsoft Search. This service is dependent on the RPC service.

Manual

Hub Transport, Mailbox

O


 

Posted in Installation-2010 | Leave a Comment »

Support d’Exchange 2010 Par Backup Exec

Posted by Teruin laurent le décembre 23, 2009


Symantec met sur le marché Backup Exec System Recovery 2010, la nouvelle version de sa solution de sauvegarde et de restauration pour petites entreprises. La solution prend en charge les nouveaux systèmes d’exploitation de Microsoft, notamment Windows 7, Microsoft Exchange 2010 et Microsoft Windows Server 2008 R2. Backup Exec System Recovery 2010 inclut désormais en standard la technologie Granular Recovery qui permet de sauvegarder l’intégralité d’un serveur de fichiers, d’un ordinateur de bureau ou portable, d’un serveur virtuel ou d’un serveur d’application stratégique.

De plus, Backup Exec System Recovery introduit la prise en charge des environnements virtuels tels que VMware vSphere 4.0, Microsoft Hyper-V Server 2008 R2 et Citrix XenServer 5.x. Symantec Backup Exec System Recovery 2010 est disponible au prix public indicatif de 684,82 euros par serveur et de 62,57 euros par poste de travail. Symantec Backup Exec System Recovery Linux Edition sera disponible d’ici la fin de l’année au prix public indicatif de 426,4 euros par serveur.

Posted in Sauvegarde-2010 | 2 Comments »

Webcast : Quel Stockage pour Microsoft Exchange 2010

Posted by Teruin laurent le décembre 23, 2009


L’architecture de Exchange 2010 a été profondément modifiée par rapport aux versions précédentes. Dans cette session nous présenterons les évolutions du moteur de la base de données d’Exchange. Nous verrons aussi comment cette évolution modifie les solutions de Cluster et de Haute Disponibilité de la messagerie. Et nous évoquerons comment considérer Exchange Online pour ses déploiements.

Un webcast signé Christophe Vallé / Emmanuel Frick

http://www.microsoft.com/france/vision/msdays09/Webcast.aspx?EID=cbd2c7e2-158b-4ed4-a51a-528f82176f60

Posted in Webcast-2010 | Leave a Comment »

Webcast : Protection et contrôle de l’information sous Exchange 2010

Posted by Teruin laurent le décembre 23, 2009


Combien de messages confidentiels circulent sur Internet sans avoir été chiffrés ? Combien de messages devant être conservés pendant une durée légale ne le sont pas ? Combien de messages indésirables polluent vos boites aux lettres ?

Un séminaire realisé de main de maitre par Damien Caro : http://blogs.technet.com/dcaro/

A voir absolument : http://www.microsoft.com/france/vision/msdays09/Webcast.aspx?EID=6600d3fa-0b30-4af4-86aa-715abe9d7799

 
 


 
 

Posted in Webcast-2010 | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 224 autres abonnés