Exchange your Mind

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

Archive for the ‘Doc-de-Ref-2010’ Category

Datacenter Activation Coordination Protocol : Ou comment éviter que vos serveurs Exchange ne deviennent schizophrènes

Posted by Teruin laurent le novembre 7, 2010


Les serveurs Exchange 2010 pourraient-il devenir schizophrènes. En quelque sorte…. La réponse est Oui. Mais rassurez-vous le DACP veille ;-)
J’ai donc traduit pour une meilleure compréhension l’article du TechNet suivant (http://technet.microsoft.com/en-us/library/dd979790.aspx). Ce dernier me parait très important spécialement si vous envisager de mettre en place une même architecture Exchange répartie dans deux centres de données.

Bonne lecture !

Le mode de coordination d’activation de centre de données (Datacenter Activation Coordination Mode) est une propriété mise en place sur un Groupe de Disponibilité de Bases de données (DAG). Le mode Dac est désactivé par défaut et doit être activé pour tous les Groupes de Disponibilité de Bases de données (DAG) qui utilisent la réplication continue. Le mode DAC ne doit pas être activé pour les Groupes de bases de données qui utilisent la réplication tierce partie sauf sur recommandations par l’éditeur en question.
Si un panne importante provient et qui affecte le Groupe de bases de données (Par exemple une panne générale d’un des centres de bases de données), le mode DAC est utilisé pour contrôler le comportement de l’activation au sein du DAG. Lorsque le mode DAC n’est pas activé et qu’une panne survient affectant plusieurs serveurs dans le groupe de base de données, ce comportement peut engendrer un split Brain Syndrome, une condition qui provient lorsque tous les réseaux ne sont plus disponibles, et que les membres du DAG ne peuvent pas recevoir des signaux de vie (HeartBeat) des autres membres. Le Split Brain Syndrome, peut également se produire lorsque la connectivité réseau n’est plus disponible entres les centres de données.

Le phénomène de Split Brain Syndrome peut toujours être évité en requérant la disponibilité de la majorité des membres du groupe de disponibilité (Et dans le cas de Dag qui ont un nombre pair de membre, avec l’utilisation de témoin de partage de fichier) et en interagissant, afin que le groupe de base de données soit opérationnel. Lorsque la majorité des membres communiquent, on dit alors que le groupe de disponibilité possède le quorum.
Par exemple, considérons un scénario ou le premier centre de données contenant deux membres d’un groupe de disponibilité de bases de données et un témoin de partage de fichier , et un second centre de données contenant deux autres serveurs membres du groupes de disponibilités de base de données. Si le premier centre de données est remis en route sans connectivité réseaux vers le second centre de donnés, le groupe de disponibilité peut entrer en mode splitbrain syndrome.
Comment fonctionne le mode DAC (coordination d’activation de centre de données)
Le mode DAC a été conçu pour éviter qu’un syndrome SplitBrain ne puisse survenir, en incluant le protocole DACP (Datacenter Activation Coordination Protocol). Après une panne majeure lorsque le groupe de disponibilité de base de donnés remonte, il ne va pas remonter automatiquement les bases de données sauf dans le cas où le Dag possède le quorum. Dans le cas contraire, le protocole DACP est utilisé pour déterminer l’état en cours du groupe de disponibilité de bases de données et si le processus Active Manager doit tenter de monter les bases de données.
On pourrait penser que le mode DAC se rapproche d’un niveau applicatif lié au quorum dans le but de monter les bases de données. . Afin de bien comprendre le but du DACP et comment ce dernier fonctionne, il est important de prendre en compte le premier scenario décrit ci-dessus.
Considérant deux centre de données, en supposant qu’un panne complète de courant se produise dans le premier centre de données, dans ce cas de figure tous les serveurs et l’interconnexion réseau seront arrêtés. L’organisation va donc décider d’activer le second centre de données considéré comme "de secours". Dans la plupart des cas, lors des opérations de remise en route, lorsque l’électricité va revenir dans le premier centre de données, les liens d’interconnexion réseau risquent de ne pas être opérationnels. Cela implique donc que les membres du groupe de disponibilités dans le centre de données primaire vont démarrer mais ne seront pas capable de communiquer avec les autres membres du Groupe de Disponibilité de base de données s’exécutant dans le centre de secours. Or les membres du Groupe de disponibilité de bases de données du premier centre posséderont la majorité et par conséquent le quorum. Ceci pose donc un problème car ces serveurs vont tenter de monter les bases de données, ce qui va provoquer une divergence vis à vis des bases de données déjà actives sur le site de secours.

Le protocole DACP a donc été créé dans ce but. Active Manager va stocker un Bit en mémoire (0 ou 1) qui va informer le DAG, lui permettant de savoir s’il est dans la position de monter ou pas les bases de données locales assignées comme « active » sur ce server. Lorsque le groupe de disponibilité de base de données s’exécute en mode DAC (Ce qui peut être n’importe quel groupe de disponibilité de base de données comprenant 3 membres ou plus), alors, chaque fois que le processus Active Manager démarre, il positionne le bit à zéro, précisant qu’il n’est pas autorisé à monter les bases de données. Parce ce que l’on est en mode Dac, le serveur doit essayer de communiquer avec les autres membres du groupe de disponibilité de base de données qu’il connait de façon à obtenir une réponse lui permettant de savoir si il peut ou non monter les bases de données qui lui sont assignée comme actives.
La réponse viendra par conséquent de la valeur assignée au bit en question par les processus Active manager des autres serveurs du DAG. Si les autres serveurs répondent que la valeur du Bit est à 1, cela précise qu’il est possible de monter les bases de données, le serveur démarrant, va positionner le bit à 1 et monter ces bases de données.
Lorsque l’on remet en route un centre de données après un dommage électrique et lorsque les serveurs remontent sans interconnexion possible sur le réseau étendu, tous les membres du groupe de disponibilité de base de données du centre de données primaire vont avoir comme Bit liés au protocole DACP la valeur 0. Ainsi, aucun des serveurs du centre de données primaire ne va tenter de monter les bases de données en question, car aucun d’entre eux n’est capable de communiquer avec des membres du groupe de disponibilité de base de données ayant une valeur égale à 1.
Le Mode Dac avec un groupe de disponibilité de base de données comprenant uniquement deux membres.
Les groupes de disponibilité comprenant uniquement deux membres ont des limitations intrinsèques qui permettent au protocole DACP d’être totalement protégé vis à vis du syndrome de type splitbrain. Pour les Groupes de disponibilité de base de données ne comprenant que deux membres, le mode Dac utilise également les informations de temps liés au démarrage du serveur témoin de partage de fichier afin de déterminer s’il est dans la mesure de monter ou non les bases de données. L’heure de démarrage du serveur de témoin du partage de fichier est alors comparée à l’heure ou le bit de DACP a été positionné à 1.
  • Si le moment ou le bit DACP précède le moment de démarrage du serveur témoin, le système va estimer que le serveur du dag en question et que le serveur témoin de partage de fichier ont été redémarré au même moment (Vraisemblablement dans le cas d’un problème d’alimentation électrique du premier centre de données), et dans ce cas les serveurs membre du dag ne seront pas autorisés à monter les bases de données.
  • Dans le cas contraire, ou le moment ou le bit du DACP succède le moment de démarrage du serveur témoin, le système va estimer que le membre du groupe de disponibilité de bases de données a été redémarrer pour d’autre raisons (Eventuellement un arrêt programmé dans le cas d’un maintenance, un crash server ou une panne de courant local a ce dernier) et le membre du groupe sera donc autorisé a monté les bases de données
IMPORTANT
En raison du fait que l’heure de démarrage du serveur témoin de partage de fichier est prise en compte pour déterminer si un membre du DAG est en mesure de monter ses bases Actives on démarrage, vous ne devez jamais redémarrer le serveur témoin de partage de fichier et le membre du DAG au même moment. Si cela se produisait, le membre du Dag serait dans un état ou il ne pourrait pas monter les bases. Dans ce cas précis vous devez utiliser la commande PowerShell Restore-DatabaseAvailabilityGroup
sur le DAG en question. Cette commande aura pour effet de paramétrer le Bit du DACP et permettre au membre du DAG de monter ses bases de données.
La prochaine fois on essayera d’illustrer cela dans le cadre d’un exemple concret
Cordialement
Laurent Teruin

Posted in Administration-2010, Doc-de-Ref-2010, Exchange 2010 Service Pack 1 | Leave a Comment »

Exchange 2010 : Tableaux de flux

Posted by Teruin laurent le octobre 4, 2010


Vous trouverez ci-dessous le tableau des principaux flux de communication entre les serveurs Exchange (rôle de transport et serveurs de boites aux lettres).
Cordialement
Laurent Teruin

 

SERVEURS HUB & EDGE

Haut du formulaire

CheminBas du formulaire

Ports requis

Authentification par défaut

Authentification supportée

Support du cryptage

Crypté par défaut

ROLE

Serveur de transport(Hub) vers Serveur de transport(Hub)

25/TCP (SMTP)

Kerberos

Kerberos

Oui, via Transport Layer Security (TLS)

Oui

HUB

Serveur de transport(Hub) vers Serveur de Transport (Edge)

25/TCP (SMTP)

Direct trust

Direct trust

Oui via TLS

Oui

HUB

Serveur de Transport (Edge) vers Serveur de transport(Hub)

25/TCP (SMTP)

Direct trust

Direct trust

Oui via TLS

Oui

HUB

Serveur de Transport (Edge) vers Serveur de Transport (Edge)

25/TCP SMTP

Anonymes, Certificate

Anonymes, Certificate

Oui via TLS

Oui

HUB

Serveur de boites aux lettres
vers Serveur de transport(Hub) via the Microsoft Exchange Mail Submission Service

135/TCP (RPC)

NTLM. si le serveur Hub et le serveur de boites aux lettres sont sur la même machine alors Kerberos est utilisé.

NTLM/Kerberos

Oui via Encryption RPC

Oui

HUB

Hub Transport vers Serveur de boites aux lettres
via MAPI

135/TCP (RPC)

NTLM. si le serveur Hub et le serveur de boites aux lettres sont sur la même machine alors Kerberos est utilisé.

NTLM/Kerberos

Oui via Encryption RPC

Oui

HUB

Serveur de messagerie Unifiée vers Serveur de transport(Hub)

25/TCP (SMTP)

Kerberos

Kerberos

Oui via TLS

Oui

HUB

Service Microsoft Exchange EdgeSync depuis Serveur de transport(Hub) vers Serveur de Transport (Edge)

50636/TCP (SSL)

Basic

Basic

Oui, via LDAP over SSL (LDAPS)

Oui

HUB

Accès AD depuis Serveur de transport(Hub)

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Oui, via Kerberos encryption

Oui

HUB

Active DirectoryRights Management Services (AD RMS) vers depuis Serveur de transport(Hub)

443/TCP (HTTPS)

NTLM/Kerberos

NTLM/Kerberos

Oui, via SSL

Oui*

HUB

SMTP clients vers Serveur de transport(Hub) (Utilisateur Outlook express par exemple)

587 (SMTP)

NTLM/Kerberos

NTLM/Kerberos

Oui via TLS

Oui

Bas du formulaire

HUB

25/TCP (SMTP)

  

             

SERVEUR DE BOITES AUX LETTRES

             

Haut du formulaire

Chemin

Bas du formulaire

Ports requis

Authentification par défault

Authentification supportée

Support du cryptage

Crypté par défault

ROLE

Accès Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Oui, via Kerberos encryption

Oui

MB

Accès Admin remote (Remote Registry)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via IPsec

Non

MB

Accès Admin remote (SMB/File)

445/TCP (SMB)

NTLM/Kerberos

NTLM/Kerberos

Oui, via IPsec

Non

MB

Availability Web service (Client vers Mailbox)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Clustering

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via IPsec

Non

MB

Indexation de contenus

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Log shipping

64327 (personalisable)

NTLM/Kerberos

NTLM/Kerberos

Oui

Non

MB

Seeding

64327 (personalisable)

NTLM/Kerberos

NTLM/Kerberos

Oui

Non

MB

Sauvegarde via Volume shadow copy service (VSS)

Local Message Block (SMB)

NTLM/Kerberos

NTLM/Kerberos

Non

Non

MB

Assistants de boites aux lettres

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Non

Non

MB

Accès MAPI

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Accès Microsoft Exchange Active Directory Topology service

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Accès Microsoft Exchange System Attendant service legacy (Ecoute de requêtes)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Non

Non

MB

Microsoft Exchange System Attendant service legacy vers Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Oui, via Kerberos encryption

Oui

MB

Microsoft Exchange System Attendant service legacy vers (Comme un client MAPI )

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Offline address book (OAB) versing Active Directory

135/TCP (RPC)

Kerberos

Kerberos

Oui, via RPC encryption

Oui

MB

Outlook versing OAB

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM/Kerberos

Oui, via HTTPS

Non

MB

Accès Recipient Update Service RPC

135/TCP (RPC)

Kerberos

Kerberos

Oui, via RPC encryption

Oui

MB

Recipient update vers Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Oui, via Kerberos encryption

Oui

Bas du formulaire

MB

Posted in 1-EXCHANGE 2010, Doc-de-Ref-2010, Transport-2010 | Leave a Comment »

Liste des ports utilisés par Exchange Server 2010

Posted by David PEKMEZ le novembre 10, 2009


Cette liste peut s’avérer bien pratique lors de déploiements d’Exchange Server, ports utilisés, authentification supportée et cryptage supporté ou non.

Voici la liste suivant les rôles

Les serveurs de transport :

Data path

Required ports

Default authentication

Supported authentication

Encryption supported?

Encrypted by default?

Hub Transport server to Hub Transport server

25/TCP (Transport Layer Security [TLS])

Kerberos

Kerberos

Yes (TLS)

Yes

Hub Transport server to Edge Transport server

25/TCP (TLS)

Direct trust

Direct trust

Yes (TLS)

Yes

Edge Transport server to Hub Transport server

25/TCP (TLS)

Direct trust

Direct trust

Yes (TLS)

Yes

Edge Transport server to Edge Transport server

25/TCP (SSL)

Anonymous, Certificate

Anonymous, Certificate

Yes (TLS)

Yes

Mailbox server to Hub Transport server via the Microsoft Exchange Mail Submission Service

135/TCP (RPC)

NTLM. If the Hub Tranpsort and the Mailbox server roles are on the same server, Kerberos is used.

NTLM/Kerberos

Yes (RPC encryption)

Yes

Hub Transport to Mailbox server via MAPI

135/TCP (RPC)

NTLM. If the Hub Tranpsort and the Mailbox server roles are on the same server, Kerberos is used..

NTLM/Kerberos

Yes (RPC encryption)

Yes

Unified Messaging server to Hub Transport server

25/TCP (TLS)

Kerberos

Kerberos

Yes (TLS)

Yes

Microsoft Exchange EdgeSync service from Hub Transport server to Edge Transport server

50636/TCP (SSL)

Basic

Basic

Yes (LDAPS)

Yes

Active Directory directory service access from Hub Transport server

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

Active Directory Rights Management Services (AD RMS) access from Hub Transport server

443/TCP (HTTPS)

NTLM/Kerberos

NTLM/Kerberos

Yes (SSL)

Yes*

SMTP clients to Hub Transport server (for example, end-users using Outlook Express)

587 (TLS)

25/TCP (TLS)

NTLM/Kerberos

NTLM/Kerberos

Yes (TLS)

Yes

 

Serveur de boîte aux lettres :

Data path

Required ports

Default authentication

Supported authentication

Encryption supported?

Encrypted by default?

Active Directory access

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

Admin remote access (Remote Registry)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (IPsec)

No

Admin remote access (SMB/File)

445/TCP (SMB)

NTLM/Kerberos

NTLM/Kerberos

Yes (IPsec)

No

Availability Web service (Client Access to Mailbox)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Clustering

135/TCP (RPC) See "Notes on Mailbox Servers" after this table.

NTLM/Kerberos

NTLM/Kerberos

Yes (IPsec)

No

Content indexing

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

DSAccess to Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

Log shipping

64327 (customizable)

NTLM/Kerberos

NTLM/Kerberos

Yes

No

Seeding

64327 (customizable)

NTLM/Kerberos

NTLM/Kerberos

Yes

No

Volume shadow copy service (VSS) backup

Local Message Block (SMB)l

NTLM/Kerberos

NTLM/Kerberos

No

No

Mailbox Assistants

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

No

No

MAPI access

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Microsoft Exchange Active Directory Topology service access

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Microsoft Exchange System Attendant service legacy access (Listen to requests)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

No

No

Microsoft Exchange System Attendant service legacy access to Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

Microsoft Exchange System Attendant service legacy access (As MAPI client)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Offline Address Book (OAB) accessing Active Directory

135/TCP (RPC)

Kerberos

Kerberos

Yes (RPC encryption)

Yes

Outlook accessing Offline Address Book (OAB)

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM/Kerberos

Yes (HTTPS)

No

Recipient Update Service RPC access

135/TCP (RPC)

Kerberos

Kerberos

Yes (RPC encryption)

Yes

Recipient update to Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Yes (Kerberos encryption)

Yes

WebDav

80/TCP, 443/TCP (SSL)

Basic, NTLM, Negotiate

Basic, NTLM, Negotiate

Yes (HTTPS)

Yes

 

Le client Access Servers :

Data path

Required ports

Default authentication

Supported authentication

Encryption supported?

Encrypted by default?

Autodiscover service

80/TCP, 443/TCP (SSL)

Basic/Integrated Windows authentication (Negotiate)

Basic, Digest, NTLM, Negotiate (Kerberos)

Yes (HTTPS)

Yes

Availability service

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM, Kerberos

Yes (HTTPS)

Yes

Outlook Web Access

80/TCP, 443/TCP (SSL)

Forms Based Authentication

Basic, Digest, Forms Based Authentication, NTLM (v2 only), Kerberos, Certificate

Yes (HTTPS)

Yes using self-signed certificate

POP3

110/TCP (TLS), 995/TCP (SSL)

Basic, NTLM, Kerberos

Basic, NTLM, Kerberos

Yes (SSL, TLS)

Yes

IMAP4

143/TCP (TLS), 993/TCP (SSL)

Basic, NTLM, Kerberos

Basic, NTLM, Kerberos

Yes (SSL, TLS)

Yes

Outlook Anywhere (formerly known as RPC over HTTP )

80/TCP, 443/TCP (SSL)

Basic

Basic or NTLM

Yes (HTTPS)

Yes

Exchange ActiveSync application

80/TCP, 443/TCP (SSL)

Basic

Basic, Certificate

Yes (HTTPS)

Yes

Client Access server to Unified Messaging server

5060/TCP, 5061/TCP, 5062/TCP, a dynamic port

By IP address

By IP address

Yes (Session Initiation Protocol [SIP] over TLS)

Yes

Client Access server to a Mailbox server that is running an earlier version of Exchange Server

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

Negotiate (Kerberos with fallback to NTLM or optionally Basic,) POP/IMAP plain text

Yes (IPsec)

No

Client Access server to Exchange 2010 Mailbox server

RPC. See "Notes on Client Access Servers" after this table.

Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

Client Access server to Client Access server (Exchange ActiveSync)

80/TCP, 443/TCP (SSL)

Kerberos

Kerberos, Certificate

Yes (HTTPS)

Yes using self-signed certificate

Client Access server to Client Access server (Outlook Web Access)

80/TCP, 443/TCP (SSL)

Kerberos

Kerberos

Yes (HTTPS)

Yes

WebDAV

80/TCP, 443/TCP (SSL)

HTTP Basic or Outlook Web Access forms-based authentication

Basic, Outlook Web Access forms-based authentication

Yes (HTTPS)

Yes

 

Le serveur de messagerie unifiée :

Data path

Required ports

Default authentication

Supported authentication

Encryption supported?

Encrypted by default?

Unified Messaging Phone interaction (PBX)

5060/TCP, 5061/TCP, 5062/TCP, a dynamic port

By IP address

By IP address

SIP over TLS, but Media is not encrypted

Yes for SIP

Unified Messaging Web Service

80/TCP, 443/TCP (SSL)

Integrated Windows authentication (Negotiate)

Basic, Digest, NTLM, Negotiate (Kerberos)

Yes (SSL)

Yes

Unified Messaging server to Client Access server

5075, 5076, 5075 (TCP)

Integrated Windows authentication (Negotiate)

Basic, Digest, NTLM, Negotiate (Kerberos)

Yes (SSL)

Yes

Unified Messaging to Hub Transport

25/TCP (TLS)

Kerberos

Kerberos

Yes (TLS)

Yes

Unified Messaging server to Mailbox server

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Yes (RPC encryption)

Yes

 

Vous trouverez des informations supplémentaires sur le TechNet Microsoft !

http://technet.microsoft.com/en-us/library/bb331973(EXCHG.140).aspx

Bonne lecture !

Posted in Doc-de-Ref-2010 | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 224 autres abonnés