Posté par Frédéric Laubel le novembre 5, 2009
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é 
Publié dans Architecture, Exploitation | 3 Commentaires »
Posté par Frédéric Laubel le octobre 28, 2009
Exchange 2010 est disponible en deux éditions et en deux types de licence d’accès client (CAL).
Plusieurs éléments sont à noter :
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 ! 
Publié dans Exchange 2010 | Laisser un commentaire »
Posté par Frédéric Laubel le octobre 24, 2009
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 !
Publié dans TechEd | Laisser un commentaire »
Posté par Frédéric Laubel le septembre 27, 2009
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 !
Publié dans Exchange 2010 | 1 commentaire »
Posté par Frédéric Laubel le septembre 25, 2009
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 :
Publié dans Exchange 2010 | Laisser un commentaire »
Posté par Frédéric Laubel le août 26, 2009
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 :
Le Service Pack 2 pour Exchange 2007 est indispensable pour pouvoir migrer les boites aux lettres d’un serveur Exchange 2007 vers Exchange 2010 .
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.
Exchange 2007 SP2 intègre l’équivalent l’outil Diagnostic Logging Tool directement dans la console, à l’image de Exchange 2010.
Il est possible d’auditer très finement les modifications apportées à l’environnement de messagerie, voir l’excellent White Paper à ce sujet.
Cependant :
Publié dans Exploitation, Rollups et Bugs | Laisser un commentaire »
Posté par Frédéric Laubel le août 25, 2009
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.
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 :
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.
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.
Publié dans Exchange 2010 | Laisser un commentaire »
Posté par Frédéric Laubel le août 24, 2009
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.
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 :
Pour une installation du rôle CAS uniquement :
Pour une installation du rôle HUB uniquement :
Pour une installation du rôle Mailbox uniquement :
Pour une installation du rôle UM uniquement :
Pour une installation du rôle Edge uniquement :
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.
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 :
Pour une installation du rôle CAS uniquement :
Pour une installation du rôle HUB ou Mailbox :
Pour une installation du rôle UM :
Pour une installation du rôle Edge :
6. Reboot et le serveur est prêt pour recevoir Exchange 2010.
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
Les serveurs Exchange 2003 et Exchange 2007 doivent possèder le Service Pack 2 :
Publié dans Exchange 2010 | Laisser un commentaire »
Posté par Frédéric Laubel le juillet 19, 2009
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
Publié dans Architecture | Laisser un commentaire »
Posté par Frédéric Laubel le juillet 17, 2009
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“.
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 !
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 :
Publié dans Exchange 2010 | Laisser un commentaire »
