Coup d'oeil sur les changements dans l'infrastructure d'accès client avec Exchange Server 2013

Comme déjà mentionné il y a des changements dans la façon dont les clients Outlook se connectent à Exchange 2013. En effet le RPC (TCP) n'est plus pris en charge comme un mécanisme d'accès direct pour les clients Outlook. Au lieu de cela, les clients Outlook vont maintenant se connecter en utilisant le protocole HTTPS (Outlook Anywhere).

Dans cet article, nous allons creuser un peu plus profondément dans ce sujet.

RPC over TCP est mort. vive RPC over HTTP 

Exchange 2010 a été en particulier en ce qui concerne les espaces de noms relativement compliqué. Dans une architecture avec différents site, vous pourriez potentiellement vous retrouver avec 8 espaces de noms. La cause: l'accès au client RPC.

Maintenant que vous n'avez plus de service RPC, vous n'avez pas besoin d'un espace de noms (FQDN du serveur).

Néanmoins, afin qu'Outlook se connecter au serveur Exchange Server 2013, celui-ci doit utilise la découverte automatique pour créer le nouveau point de connexion. Ce point de connexion est constitué d'une boîte aux lettres et du GUID d'un suffixe

Comment sont gérer la demande des client Outlook ?

Afin de répondre à cette question, nous allons jeter un œil à la façon dont le serveur d’accès client Exchange 2013 gère les demandes des clients Outlook. (schema de Michael Van Horenbeeck)
L'image suivante montre une connexion à partir d'Outlook pour la boîte aux lettres créé:

Remarque Avant de contacter le CAS pour accéder à la boîte aux lettres, le client Outlook effectue un AutoDiscover au démarrage pour récupérer ses paramètres.

Quels sont les changements de conception que ce nouveau comportement implique?

Parce que dans Exchange 2010, il y avait un lien étroit entre le CAS et la boîte aux lettres, vous deviez avoir au moins un serveur CAS dans le même site AD en tant que serveur de boîte aux lettres. Toutefois, cette exigence ne s'applique plus. Vous pouvez maintenant déployer un serveur de boîtes aux lettres sur un site, tout en ayant vos serveurs CAS dans un autre site. Cela ouvre la possibilité de créer un site qui sert de point d'accès unique pour que vos données de boîtes aux lettres soient éventuellement stockées ailleurs.

Pour mieux comprendre cela, nous allons jeter un coup d’œil sur le comportement du proxy et la redirection des client par un serveur d'accès dans Exchange 2013. L'image suivant décrit trois scénarios différents (chacun indiqué par une couleur différente):

1. Outlook se connecte au CAS
2. Le TAS constate que la boîte aux lettres se trouve sur le même site et transmettra la demande au serveur de boîtes aux lettres.
3. Outlook se connecte au CAS
4. CAS découvre que la boîte aux lettres se trouve dans le site 2.  Le Site 2 contient un CAS. Le CAS sur le site 1 émet une redirection vers le client Outlook.
5. Le client Outlook va maintenant se connecter au TAS dans le Site 2
6. Le CAS dans le site 2, transmet la demande au serveur de boîtes aux lettres approprié
7. Un client Outlook dans le site 2 se connecte au CAS
8. Le TAS découvre que la boîte aux lettres se trouve dans le site 3. Cependant, le site 3 n'a pas de CAS déploy.
9. Le CAS proxyfira la demande au serveur de boîtes aux lettres approprié sur le site 3.

Les serveurs d'accès au client est un proxy ... Ca veut dire que je peux le déployer dans une DMZ?  
Il faut savoir que le CAS est encore un ordinateur joint au domaine. Techniquement parlant, vous pouvez le déployer dans une DMZ. Au moins aussi longtemps que vous vous assurez que tous les ports nécessaires soient ouverts pour joindre votre réseau interne. Ce pendant je ne le conseil pas spécialement sauf si vous voulez que votre pare feu ressemble a un gruyère

Comment puis-je configurer les URL au-quelle un client va se connecter ?
Avec Exchange 2010, vous ne pouviez spécifier le nom d'hôte externe. Échange 2013 ajoute maintenant le "nom d'hôte interne". 
Vous pouvez modifier la valeur avec la commande suivante:

1	Get-OutlookAnywhere -Serveur <nomserveur> | Set-OutlookAnywhere -InternalHostname <CASArray>>

Vous pouvez également définir quel mécanisme d'authentification les clients internes doivent utiliser:

1	Get-OutlookAnywhere -Serveur <nomserveur> | Set-OutlookAnywhere -InternalClientAuthenticationMethode <auth_method>

Remarque après l'exécution de la commande, attendre quelques minutes pour que les paramètres deviennent actifs

Source