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

Coup d'oeil sur les «nouveaux» dossiers publics dans Exchange Server 2013

Dans ce poste vous trouverez une explication des «nouveaux» dossiers publics dans Exchange Server 2013, un peu plus en détail. (Idée de Michael VanHorenbeeck)

Historique
Depuis Exchange Server 2007 Microsoft a proclamé que les dossiers publics finiraient par disparaître. A cette époque, il a été dit que les dossiers publics cesseraient d'exister dans les futures versions et les consultants ont reçu les conseils d'évangéliser SharePoint comme étant le remplacement pour les dossiers publics. Il semble, toutefois, que ces déclarations ont provoqué pas mal de commentaires sur le terrain: les entreprises du monde entier utiliserait encore les dossiers publics et ne sont pas décidé à les oublier si facilement. De plus lorsque l’on voit le coût d’une migration vers SharePoint, c'est tout à fait compréhensible que certaines entreprises étaient plutôt réticentes à sauter immédiatement sur ​​le SharePoint-train.

En fait, je ne peux pas les blâmer. Même jusqu'à aujourd'hui, il n'y a pas de véritable solution qui offre la même fonctionnalité et la facilité d'utilisation que les dossiers publics.
Au fil du temps, Microsoft semble avoir reconnu que tuer des dossiers publics n’était pas une si bonne idée après tout, et a changé son attitude. Néanmoins, ils ont toujours déconseillé l'utilisation des dossiers publics
....du moins jusqu'à maintenant.

Pour mieux comprendre les changements dans Exchange Server 2013, nous allons d'abord jeter un œil à la façon dont les choses étaient dans Exchange Server 2010.

Dossiers publics dans Exchange 2010 ( et avant)
Dans Exchange Server 2010 (et avant), les dossiers publics ont été stockés dans leur propre base de données.
Fondamentalement parlant, les dossiers publics se composent de deux: 

• hiérarchie qui contient les propriétés des dossiers publics et inclut également l'arborescence dans lequel les dossiers publics sont organisés. 
• Contenu qui contient les données réelles (par exemple des messages) dans un dossier public

Chaque base de données de dossiers publics contient une copie de la hiérarchie, mais ne contenait pas le même contenu:  

   

Point de vue graphique simplifiée d'une base de données de dossiers publics

 

C'était à l'administrateur de définir le contenu qui serait répliqué sur un (ou plusieurs) serveurs. Quand un dossier public a été installé pour avoir des copies multiples, un processus appelé « Public Folder replication » veille à ce que les données soient répliquées.

Cette réplication n'est en aucune façon comparable à la façon dont un DAG réplique les données

  

Vue d'ensemble simplifiée du modèle de réplication des dossier publics

Bien que les données de dossiers publics hautement disponibles: il ne l’était pas réellement. Du moins pas quand il s'agit de l'expérience de l'utilisateur final lors d'un basculement. En effet chaque base de données de boîtes aux lettres est configurée avec une base de données de dossiers publics par défaut ("preferred").

• Si  Pour une raison quelconque - le serveur hébergeant la base de données de dossiers publics ne serait pas disponible entièrement (déconnecté, par exemple), un délai d'attente (+ / - 60 secondes) serait réalisé avant que les clients soit réorientées vers une autre base de dossiers publics.

• Si, toutefois, le serveur serait encore en ligne, mais la base de données serait par exemple démonté, il n'y aurait pas de redirection et les clients se retrouverait avec aucun des dossiers publics.

Comme vous pouvez l'imaginer, pas vraiment une expérience utilisateur agréable

Changements dans Exchange Server 2013
Exchange Server 2013 modifie entièrement la façon dont les dossiers publics fonctionnent. Du point de vue d’un utilisateur final, tout reste comme avant.
Les principaux changements architecturaux qui sont introduits sont :

·         Les dossiers publics sont maintenant stockés dans un fichier de base de données de boîtes aux lettres

·         Les dossiers publics peuvent désormais exploiter un DAG et bénéficier d’une haute disponibilité

Des boîtes aux lettres de dossiers publics
Les dossiers publics sont désormais également boîtes aux lettres, mais leur type est "Public Folder" (tout comme une boîte aux lettres de Salle est une boîte aux lettres de type "Room").

Remarque parce que les dossiers publics sont maintenant stockés dans les boîtes aux lettres, le quota de boîte aux lettres leur sont applicables.

Comment fonctionne ces «nouveaux» Dossiers publics ?
Le processus de connexion sur un dossier public peut être résumé cela :

1.       Un utilisateur se connecte à un dossier public (boîte aux lettres).

2.       Toute opération dans le dossier public est enregistrée dans la boîte aux lettres

3.       Si les données se trouvent dans un autre dossier public de boîtes aux lettres, l'opération est redirigée vers la boîte aux lettres de dossier public approprié

4.       Les changements hiérarchie (par exemple ajouter ou supprimer des dossiers) sont redirigés vers la boîte aux lettres PF Hiérarchie Maître où ils sont à leur tour répliqué sur tous les boîtes aux lettres PF (5).

Haute disponibilité.
Comme les dossiers publics sont maintenant dans des bases de données de boîtes aux lettres, ils peuvent bénéficier de la haute disponibilité qu'un Database Availability Group. Comme vous pouvez stocker les boîtes aux lettres de dossiers publics dans une base de données, il n'y a aucune différence quant à la façon dont ils sont traités dans le cas d'un basculement.

Les implications de ces changements
Grace à ces changements, la façon dont nous mettrons en œuvre des dossiers publics va changer. Tout d'abord, il faudra planifier un peu plus à partir de maintenant le placement pour les dossiers publics. En effet il ne peut y avoir qu'un seul exemplaire actif d’une base de données de boîtes aux lettres à un moment donné.
Cela signifie que vous devez de préférence placer vos boîtes aux lettres de dossiers publics au plus près à vos utilisateurs. Si, toutefois, différents groupes ont besoin de travailler sur le même ensemble de dossiers, mais sur des sites opposés du globe, vous pourriez être devant un choix difficile ... Bien sûr, on pourrait commencer à se demander si les dossiers publics serait le bon choix dans un telle scénario, après tout il ne s'agit pas seulement de bonnes nouvelles

Malheureusement, tous avantage a aussi un inconvénient: en raison de tous ces changements qui ont été introduites, il semble que Microsoft n'est pas en mesure de finaliser dans les temps. Ainsi au RTM, nous n'aurons pas les dossiers publics dans OWA. C'est peut-être quelque chose que nous allons voir ajoutée dans SP1 (tout comme avec Exchange 2010) ...

Vous voudrez jeter un oeil sur le blog de Busbar et MichaelVan Horenbeeck pour avoir plus d’information  au sujet des nouveaux dossiers public

Source