Forefront TMG 2010 Fin de Vie

Le 12 Septembre, Microsoft a annoncé la fin pour Forefront TMG 2010. Microsoft continuera à fournir le support sur TMG jusqu'au  14 Avril 2015, et un support étendu jusqu'au 14 Avril 2020. Les Services de protection Web (WPS) de Forefront TMG 2010  seront abandonné le 31 Décembre 2015. À compter du 1 Janvier 2016, les protections Web (filtrage de l'URL, virus,...) continuera à fonctionner, mais ne recevront plus de mises à jour.

La fin de vie pour Forefront TMG 2010 s'inscrit dans le cadre des changements radicaux apportés à la suite de protection complète du produits Forefront. En plus de mettre fin au développement de Forefront TMG 2010, Microsoft a également annoncé que Forefront Protection pour Exchange (FPE), Forefront Protection for SharePoint (FPSP), Forefront Security pour OCS (FSOCS), et Forefront Protection Server Management Console (FPSMC) sont tous arrêté. Forefront Online Protection pour Exchange (FOPE), qui fait partie d'Office 365, est rebaptisée Exchange Online Protection.

Pour l'avenir, Forefront Unified Access Gateway (UAG) 2010 et Forefront Identifier Manager (FIM) 2010 R2 ont tous les deux feuilles de route actuelles et continuera à être développé, mais il est probable qu'ils ne seront plus sous le nom Forefront.

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

MSP

Bonjour à tous,

Désolé de ne pas avoir fait de post depuis plus d'un mois mais vacance oblige mais promis je vais reprendre un rythme un peu plus soutenu en terme de post.

Information importante, cette reprise commence bien pour moi puis que ma candidature Microsoft Student Partner (MSP pour les intimes) a été accepté par Microsoft. Grâce à cela, je vais pouvoir retourner dans les locaux de Microsoft à Paris et rencontrer des autres MSP ainsi que des MVP et les Microsoftees (les employés Microsoft, comme on les appelle ), et voir en détail ce que nous réserve la boite pour les mois à venir!

Je ne manquerai pas de vous faire un retour dès que cette journée sera réalisé. En attendant si vous voulez plus d'information sur le programme Microsoft Student Partner je vous invite a visiter le site http://www.microsoft.com/france/etudiants/student-partners/default.aspx