L’équipe Exchange vient d’annoncer qu’il va être très bientôt possible d’installer Exchange 2007 sur Windows Server 2008  R2 !

En effet jusqu’à présent la seule version d’Exchange qui peut s’installer sur Windows Server 2008 R2 est Exchange 2010. Vivement la sortie du patch !

J’en connais un qui va devoir modifier sa matrice de compatibilité

Exchange 2010 est disponible en deux éditions et en deux types de licence d’accès client (CAL).

Plusieurs éléments sont à noter :

• Exchange 2010 permet de déployer une architecture à haute-disponibilité (DAG) dès la version Standard ! C’est un tournant par rapport aux éditions précédentes d’Exchange qui nécessitent la version Entreprise pour pouvoir bénéficier de la haute-disponibilité. Petite subtilité: si le DAG est accessible dès Exchange 2010 Standard, il est par contre toujours nécessaire d’installer Exchange sur du Windows Server Entreprise. Cela reste un apport important pour les petites sociétés qui feront l’économie d’une licence Exchange Entreprise.
• Exchange 2010 Entreprise supporte jusqu’à 100 bases actives (versus 50 sur Exchange 2007 Entreprise),
• L’archivage nécessite une CAL Entreprise mais fonctionne très bien sur du Exchange Standard.

Notez qu’il n’existe plus de groupe de stockage. On parle ici de bases actives (jusqu’à 15 réplicas par bases). Il est conseillé de ne pas faire “exploser” la taille des bases au delà de 2 Tera.

Bref Exchange Server 2010 offre toujours plus de services et démocratise la haute-dispo !

Cette année le Teched quitte Barcelone pour venir s’installer à Berlin du 9 novembre au 13 novembre. Cette édition va être énorme ! Exchange 2010, Windows 2008 R2, Hyper-V R2, SCVMM R2, Windows 7, DPM, etc…ça va être la folie !!!!

Histoire d’avoir l’eau à la bouche allez jeter un coup d’œil à la liste des sessions : https://www.msteched.com/europe/public/sessionlist.aspx

Concernant Exchange ne surtout pas rater les sessions de Scott Schnoll, Ilse Van Criekinge, Andrew Ehrensing et de notre champion national Damien Caro !! Damien va notamment présenter une session sur l’interconnexion entre Office Communications Server 2007 R2 et Microsoft Exchange 2010. De la folie je vous dis !!

A titre personnel il y a aussi un changement, puisque cette année j’ai l’honneur de faire partie du staff et à ce titre je vais être présent sur les stands pour répondre aux questions autour d’Exchange. Donc pour ceux qui sont inscrits n’hésitez pas à venir me voir

See you in Berlin !

J’ai créé récemment une présentation powerpoint pour expliquer les différences de sizing entre Exchange 2007 et Exchange 2010. Aujourd’hui je partage avec vous quelques slides.

Par rapport à une architecture Exchange 2007, le point à prendre en considération est la partie sizing des serveurs CAS: changement en terme de puissance CPU, et changement en terme de ratio par rapport aux serveurs mailbox. Le deuxième point important est  la partie stockage: avec des IOPS disques réduit de 70% il est possible d’installer Exchange 2010 en production sur des disques SATA.

Par rapport à Exchange 2007, les besoins en RAM et CPU de Exchange 2010 sont plus importants pour les rôles CAS et MBX. Logique puisque maintenant le rôle CAS gère l’ensemble des protocoles d’accès (MAPI compris) et le rôle Mailbox gère le DAG avec une gestion plus poussée des bases Exchange (compression des bases ESE et cryptage du seeding par exemple).

J’ai surligné en bleu ce qui représentera sans doute la majorité de configuration: 4Go de RAM + 6Mo par BAL. Toujours prendre le pré-requis le plus élevé (par exemple 10Mo si la BAL doit être énorme malgré un profil léger).

C’est l’énorme changement de Exchange 2010: les IOPS disques ont fortement diminués, et surtout la typologie des IOPS est différente: les IOPS sont surtout séquentiels et non plus aléatoire. Du coup il est possible d’installer Exchange 2010 dans une configuration à disques SATA avec de grosses boites aux lettres sans soucis de perfs ! J’insiste sur ce point: L’équipe produit à conçu Exchange 2010 pour tourner sur des disques SATA !

La preuve avec ces recommandations pour le stockage : à partir de 3 copies les configurations sans RAID sur des disques SATA sont possibles !

Tout d’abord rappelons qu’il n’est pas obligatoire de migrer vers Outlook 2010 pour pouvoir se connecter à Exchange 2010 …les version de Outlook supportées avec Exchange 2010 sont 2010/2007/2003/2002 ( le support s’arrête bien à Outlook 2003).

En faisant un test de migration de Exchange 2003 vers Exchange 2010, avec des postes en Outlook 2003  je me suis rendu compte que la connexion avec le serveur était impossible.

Inutile de supprimer ou recréer le profil, de mettre à jour Outlook…la solution passe par l’activation du cryptage entre Outlook et Exchange 2010.

En effet par défaut avec Outlook 2003  le cryptage n’est pas activé :

En cochant la case et en redémarrant Outlook il est possible de se connecter à Exchange 2010 sans problème :

Explication :

Exchange 2010, par défaut, n’accepte que les connexions MAPI cryptées. La solution passe donc soit par l’activation du cryptage par GPO sur l’ensemble des postes Outlook antérieurs à Outlook 2007, soit par la modification du comportement par défaut de Exchange 2010.

En vérifiant sur un serveur CAS le paramétrage par défaut :

Nous voyons que le cryptage est requis pour les connexions RPC CAS. Là ceux qui connaissent Exchange 2007 doivent tiquer: en effet avec Exchange 2010, les connexions MAPI se font toutes sur les serveurs CAS et non plus directement sur les serveurs MBX !!

Pour bien comprendre ce changement profond, comparez le schéma d’architecture entre 2007 et 2010 :

En  terme d’architecture cela à de multiples conséquences, j’aurais l’occasion d’y revenir, notamment d’un point de vue sizing et haute disponibilité.

Évidemment,  il est possible, mais vivement déconseillé de désactiver le cryptage au niveau du serveur Exchange 2010, avec la commande Set-RpcClientAccess, puis de vérifier le résultat :

Exchange 2007 SP2 est disponible !

Ce Service Pack 2 est une mise à jour majeur. En effet non seulement le SP2 contient l’ensemble des correctifs (Rollup) sortis depuis Exchange 2007 SP1, mais il apporte aussi des nouveautés, citons entre autres :

• Coexistence avec Exchange 2010

Le Service Pack 2 pour Exchange 2007 est indispensable pour pouvoir migrer les boites aux lettres d’un serveur Exchange 2007 vers Exchange 2010 .

• Sauvegarde avec Windows Server Backup 2008

Un ajout réclamé depuis longtemps, il est enfn possible de sauvegarder Exchange 2007 avec la logiciel de backup intégré dans Windows 2008. Il existe cependant quelques limitations.

• Intégration dans la console Exchange d’une interface de gestion du niveau de logging

Exchange 2007 SP2 intègre l’équivalent l’outil Diagnostic Logging Tool directement dans la console, à l’image de Exchange 2010.

• Améliorations de l’audit

Il est possible d’auditer très finement les modifications apportées à l’environnement de messagerie, voir l’excellent White Paper à ce sujet.

Cependant :

• Exchange 2007 SP2 modifie la schéma Active Directory, donc prenez les précautions d’usage avant de l’installer !
• Exchange 2007 SP2 nécessite Windows Installer 4.5, donc prévoir son installation et un reboot avant l’installation du SP2. Bonne nouvelle Windows Server 2008 SP2 contient déjà Windows Installer 4.5.
• Exchange 2007 SP2 n’apporte pas le support de Windows Server 2008 R2. Le seul Exchange supporté sur Windows Server 2008 R2 est Exchange 2010.
• Lisez le fichier Release Note avant de l’installer.

Introduction

Exchange Server 2010 permet d’auditer les actions des comptes ayant des privilèges Exchange, que ceux-ci utilisent le Shell Exchange, la Console Exchange, ou l’interface d’administration Web Exchange.

L’activation et le paramétrage de l’audit s’effectue à l’aide une nouvelle Cmdlet du Shell Exchange nommée Set-AdminAuditLogConfig.

Activation de l’audit

Par défaut l’audit des tâches d’administration n’est pas activé. La vérification de la configuration initiale se fait  en utilisant la Cmdlet Get-AdminAuditLogConfig.

L’activation de l’audit à lieu en mettant le paramètre AdminAuditLogEnabled à True :

Vérification de l’activation de l’audit :

Configuration de la boite à lettres pour la réception des alertes

Après activation de l’audit il est nécessaire de spécifier la boite aux lettres qui sera utilisée pour recevoir les notifications de l’audit.

Vérification :

A ce stade l’audit est opérationnel et chaque création ou modification d’un objet Exchange entrainera l’envoi d’un email dans la boite aux lettres dédiée à l’audit.

NB : Il est conseillé d’activer l’audit et spécifier la boite aux lettres dans la même Cmdlet :

Ici les deux étapes sont séparées pour mieux comprendre le processus.

Tests et consultation des alertes

Ici un administrateur change les propriétés d’un utilisateur.

Immédiatement une notification est envoyée dans la boite aux lettres de l’audit :

Quelque soit l’outil utilisé, la console Exchange, le Shell Exchange ou l’interface Web Exchange, le sujet de l’email indique l’action effectuée sous forme de Cmdlet Exchange. Dans cet exemple le champ Code Postal est modifié via la console Exchange, mais c’est l’équivalent Cmdlet qui apparait (Set-User).

En prenant d’autres exemples comme la désactivation d’un compte et le déplacement d’une boite aux lettres d’une base à une autre :

NB : L’audit supervise uniquement les modifications donc les commandes de lecture ne sont pas prises en compte (Get-).

Modification du champ d’application de l’audit

L’activation de l’audit sans paramètres supplémentaires permet de superviser l’ensemble de tâches effectuées sur Exchange Server ce qui peut vite générer énormément d’alertes.

Il est possible de limiter l’audit uniquement à certains paramètres ou certaines cmdlet Exchange.

Tableau des paramètres de la cmdlet Set-AdminAuditLogConfig :

Limiter l’audit à certaines cmdlet

Exemple pour limiter l’audit à la seule modification des boites aux lettres :
Set-AdminAuditLogConfig -AdminAuditLogCmdlets Set-Mailbox

Une alerte sera envoyée uniquement en cas de modification d’une boite aux lettres existante, quelque soit le paramètre modifié.

Limiter l’audit à certains paramètres

Example pour limiter l’audit à la seule modification du champ Alias :
Set-AdminAuditLogConfig -AdminAuditLogParameters Alias

Une alerte sera envoyée uniquement en cas de modification du champ Alias.

Application en une seule fois des modifications :

Vérification:

Le changement d’alias d’une boite aux lettres à pour conséquence la génération d’une alerte.

Exchange 2010 Release Candidate est disponible en libre téléchargement. Pour rappel la version finale de Exchange 2010 est prévue d’ici très peu de temps (oui c’est vague mais je n’ai pas le droit de vous en dire plus..)

J’en profite pour souligner le fait que Exchange 2010 ne s’installe que sur Windows Server 2008 SP2 ou sur Windows Server 2008 R2 le tout en 64 bits uniquement.

Pré-requis Windows Server 2008

1.       Installer Windows Server 2008 x64 (Standard ou Enterprise  – Exchange ne s’installe pas sur la version Core ou Web Server) et joindre le serveur dans le domaine

2.       Installer le  Service Pack 2

3.       Installer le .NET Framework 3.5 Service Pack 1

4.       Installer le .NET Framework 3.5 SP1 Update

5.       Installer le package PowerShell V2/Windows Remote

6.       Installer Office Filter Pack pour les rôles HUB et Mailbox

7.       Se positionner dans le sous-dossier\Scripts du dossier d’installation de Exchange afin d’installer les pré-requis propres aux rôles Exchange (exactement comme pour Exchange 2007 sauf que maintenant il n’est plus nécessaire de télécharger les scripts) :

Pour une installation des rôles CAS, Hub, et Mailbox :

• ServerManagerCmd –ip <media>\Scripts\Exchange-Typical.xml

Pour une installation du rôle CAS uniquement :

• ServerManagerCmd –ip <media>\Scripts\Exchange-CAS.xml

Pour une installation du rôle HUB uniquement :

• ServerManagerCmd –ip <media>\Scripts\Exchange-Hub.xml

Pour une installation du rôle Mailbox uniquement :

• ServerManagerCmd –ip <media>\Scripts\Exchange-MBX.xml

Pour une installation du rôle UM uniquement :

• ServerManagerCmd –ip <media>\Scripts\Exchange-UM.xml

Pour une installation du rôle Edge uniquement :

• ServerManagerCmd –ip <media>\Scripts\Exchange-Edge.xml

8.       Pour le rôle CAS exécuter:  “sc config NetTcpPortSharing start= auto”

9.     Reboot et le serveur est prêt pour recevoir Exchange 2010.

Pré-requis Windows Server 2008 R2

1.       Installer Windows Server 2008 R2 (Standard ou Enterprise  – Exchange ne s’installe pas sur la version Core ou Web Server) et joindre le serveur dans le domaine

2.       Installer Office Filter Pack pour les rôles HUB et Mailbox

3.       Ouvrir la console Windows PowerShell

4.       Taper “Import-Module ServerManager”  et valider

5.       Installer les pré-requis selon les rôles à installer (ici la procédure change par rapport à Windows 2008 SP2)

Pour une installation des rôles CAS, Hub, et Mailbox :

• 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
• Set-Service NetTcpPortSharing -StartupType Automatic

Pour une installation du rôle CAS uniquement :

• 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
• Set-Service NetTcpPortSharing -StartupType Automatic

Pour une installation du rôle HUB ou Mailbox :

• 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

Pour une installation du rôle UM :

• 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

Pour une installation du rôle Edge :

• Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS

6.       Reboot et le serveur est prêt pour recevoir Exchange 2010.

Pré-requis Active Directory

a.       Le schéma master doit être au minimum en Windows Server 2003 Service Pack 1 Service Pack 2

b.      La forêt doit être au minimum en mode Windows Server 2003

c.       Les serveurs Exchange 2010 doivent communiquer avec les catalogues globaux qui doivent être au minimum en Windows Server 2003 Service Pack 1 Service Pack 2

d.      Read-only domain controllers (RODC) ne sont pas supportés (comme pour Exchange 2007)

Voir : http://technet.microsoft.com/en-us/library/aa996719%28EXCHG.140%29.aspx

Pré-requis Exchange 2003/2007

Les serveurs Exchange 2003 et Exchange 2007 doivent possèder le Service Pack 2 :

• L’ensemble des serveurs Exchange 2007 d’un site Active Directory concerné par la migration doivent être en SP2. De plus dans une architecture multi-sites il est nécessaire de mettre à jour l’ensemble des serveurs CAS de l’organisation vers Exchange 2007 SP2.

• L’ensemble des serveurs Exchange 2003 de l’organisation doivent posséder le Service Pack 2.

Un excellent article – comme toujours – de Mister Tim qui explique comment dédiée une carte réseau pour la réplication SCR. Il n’y a rien à rajouté de plus, l’article est super : http://blogs.technet.com/timmcmic/archive/2009/07/12/enabling-standby-continuous-replication-to-use-an-alternate-network-interface-in-exchange-2007-sp1.aspx

Parmi les multiples améliorations apportées dans OWA 2010 il en est une particulièrement sympathique : la possibilité d’envoyer des emails “En tant que” et “De la part de” !!!

Dans Exchange 2007 ce type de délégation n’est utilisable qu’avec client lourd Outlook. Avec Exchange 2010 il est devenu possible de s’affranchir du client lourd pour ces types de délégation, chose bien utile pour les scénarii de type patron/secrétaire ou boites de service

Dans les exemples ci-dessous j’ai pris comme exemple le scénario Patron/Secrétaire. Le compte “Secrétaire” se voit déléguer les droits sur la boite aux lettres “Frédéric Laubel”. Tout d’abord le droit “En tant que“, puis le droit “De la part de“.

• Envoi En tant que

La première étape consiste à activer le champ De dans OWA car celui-ci n’est pas activé par défaut. Rien de plus simple il suffit de l’activer directement dans les options de OWA.

Et c’est tout ! Ensuite il suffit de rédiger un nouveau email. Le champ De apparait maintenant sur la gauche. En cliquant dessus nous voyons qu’il est possible de sélectionner un autre compte de messagerie pour l’envoi de l’email :

Ici je sélectionne le compte sur lequel j’ai la délégation à savoir “Frédéric Laubel” :

L’email est envoyé. Je me connecte sur la boite aux lettres du destinataire (Jean Dujardin) pour valider le bon fonctionnement.

L’email envoyé par la secrétaire avec la délégation En tant que apparait bien comme étant envoyé depuis le compte Frédéric Laubel ! Ça marche !

• Envoi De la part de

Je ne reviens pas sur la première étape qui consiste à activer le champ De depuis les options OWA. De nouveau je rédige un email depuis la boite aux lettres Secrétaire en prenant soin de sélectionner le compte Frédéric Laubel dans le champ De.

Je me connecte sur la boite aux lettres du destinataire pour valider le comportement. L’email apparait bien comme étant envoyé de secrétaire de la part de Frédéric Laubel :

En ouvrant l’email nous voyons que le comportement est conforme à ce qui est attendu, il est indiqué clairement que l’email est envoyé De la part de :