PI Services

Dans certains scénarios nous avons besoin de partager des boîtes aux lettres de service entre plusieurs utilisateurs, et dans ce cas on donne le droit à ces utilisateurs d'envoyer des messages au nom de la boîte partagée.

Afin d'assurer le bon fonctionnement de cette boîte partagée et permettre un suivi de son activité il faut s'assurer que les messages envoyés par les différents utilisateurs au nom de cette boîte soient stockés au niveau du dossier éléments envoyé de celle ci et non au niveau de celui de l'expéditeur réel du message.

Supposons qu'une BAL partagée au nom de HelpDesk existe et que j'ai le droit d'envoyer au nom de cette boîte, tous les messages que j'envoi seront stockés dans le dossier Eléments envoyés de ma boîte et non celui de la BAL partagée.

Pour remédier à ceci il suffit:

- D'installer le Hotfix Outlook 2007 du 30 Juin 2009 téléchargeable ici

- De configurer la clé de registre suivante :

Nom : HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Preferences\DelegateSentItemsStyle

Type : DWORD

Valeur : 1

Certains serveurs SMTP réalisent une vérification de l’entête d’un message électronique

et particulièrement du champ Message-Id généré par le serveur source de l’expéditeur.

Si ce champ est  incorrect ou vide une erreur 553 5.0.0 Bogus “Message-Id:” header

est retournée. Le message est donc rejeté.

L’erreur suivante est reçue par l’expéditeur:

Impossible de contacter le(s) destinataire(s) suivant(s) :

yyy@zzz.com le 05/05/2010 10:43

Le système de messagerie n'a pas pu remettre ce message mais n'a pas signalé de raison particulière. Vérifiez l'adresse du destinataire et réessayez d'envoyer le message. Dans le cas d'un nouvel échec, contactez votre administrateur système.< aaa.bbb.com #5.0.0 SMTP; 553 5.0.0 Bogus "Message-Id:" header>

Dans ce cas, le champ Message-ID à la valeur null qui n’est pas conforme pour certains

serveurs SMTP.

Message-ID: null

Un champ conforme est de ce type:

Message-ID: <BC0DD8437D918340AC4AF8FD8F367240072EE3BB@Fxxx.fyyy.fr>

Quelle est la cause d’une valeur non conforme dans ce champ?

La raison est simplement l’excès de zèle de certains administrateurs de messagerie

sur la sécurité.

Une sécurité excessive peut donc pénaliser les échanges classiques voir pénaliser les 

affaires commerciales.

Après une migration de boites aux lettres depuis une organisation Exchange 2003 vers une organisation Exchange 2007, il peut arriver que l’attribut “Recipient Type Details” ne soit pas défini en tant que “User Mailbox”

Voici différent cas rencontrés :

Legacy Mailbox

Ceci est typiquement le type de boite aux lettres créé avec les outils Exchange 2003. Ce type de boite aux lettres fonctionne sous Exchange 2007 mais afin d’éviter la perte de certaines fonctionnalités d'Exchange 2007, il est préférable de la convertir.

Pour cela, une simple commande Powershell suffit :

Linked Mailbox

Ceci indique que la boite aux lettre disposait d’un compte externe associé (autre que le compte SELF) avant la migration.

Pour résoudre le problème, il faut modifier les attributs de l’utilisateur en question (avec ADSIEdit) et modifier la valeur de l’attribut msExchRecipientTypeDetails de la valeur 2 à la valeur 1.

http://technet.microsoft.com/en-us/library/cc164371.aspx

Shared Mailbox

Ceci indique que le compte SELF est configuré en tant que compte externe associé sur la boite aux lettres.

Après la migration de la boite aux lettres, supprimer l’association du compte SELF en tant que compte externe associé. Ceci modifiera l’attribut msExchMasterAccountSid et lui donnera la valeur <Not Set>. Ensuite, lancer la commande Powershell suivante :

http://technet.microsoft.com/en-us/library/bb201749.aspx

Lors de l’exécution d’un script powershell (.PS1) sur un serveur Exchange 2010, alors que vous possédez des droits Administrateurs, vous rencontrez l’erreur suivante :

Par défaut, et pour des raisons évidentes de sécurité, l’exécution de script “Powershell for Exchange” est bridée. Afin de visualiser ce niveau de sécurité, il suffit de lancer la commande “Get-ExecutionPolicy” :

afin de se rendre compte que les droits sont positionnés à “Restricted” par défaut.

Les différents droits existants pour l’exécution de script sont les suivants :

• Unrestricted
• RemoteSigned
• AllSigned
• Restricted
• Default
• Bypass
• Undefined

Il est alors possible d’autoriser l’exécution de script à l’aide de la commande “Set-ExecutionPolicy” et d’y ajouter la valeur désirée (nommée précédemment).

Mais comme l’indique alors le message lors du passage de la commande, le niveau de sécurité est dans ce cas abaissé. Ce qui peut poser problème. Si on désire autoriser momentanément l’exécution de script sans toucher au niveau de sécurité, il est possible de paramétrer l’environnement d’exécution juste pour ce lancement, avec un VBS par exemple, et qui servira de “lanceur” au script powershell.

1/ Le raccourci de lancement du Powershell for Exchange s’exécute comme suit :

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command            ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"

• Lancement de l’exécutable –Command “appel du script RemoteExchange.ps1 permettant d’alimenter le Powershell avec les commandes pour Exchange 2010”; Connexion au premier serveur Exchange disponible

2/ Il suffit alors de rajouter ce type de commande supplémentaire :

• Set-ExecutionPolicy -ExecutionPolicy Bypass –Force

Ce qui pourrait donner :

• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command            ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"; Set-ExecutionPolicy -ExecutionPolicy Bypass –Force

3/ Une fois inclus dans un script VBS, cela peut donner :

• Return = WshShell.run (“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command            ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"; Set-ExecutionPolicy -ExecutionPolicy Bypass –Force; MonScript.ps1; exit“)

Le script “MonScript.ps1” sera alors exécuté avec les bonnes autorisations sans impacter les paramètres de sécurité du serveur de manière définitive.

N.B.: il est possible de remplacer “-auto” par le nom d’un serveur Exchange spécifique permettant ainsi d’effectuer du “Remote Scripting” sur le serveur désiré.

N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !…

Pourquoi fixer les ports RPC ?

Le fait de fixer les ports RPC de communication des serveurs Exchange permet d’augmenter la sécurité (en réduisant la surface d'attaque ainsi que le nombre de ports à ouvrir dans les pare-feu) mais également de simplifier la configuration des équipements de Load Balancing.

En effet, avec la configuration prédéfinie au sein d'Exchange, l’ensemble de la plage de "ports haut" (1024 à 65535) doit être équilibrée lors de la mise en place d'une ferme de serveurs CAS hautement disponible (que l'on utilise un Load Balancer materiel ou bien le NLB Windows).

Comment fixer les ports RPC sur les serveurs Exchange 2010 ?

Cette procédure s'applique aux serveurs Hub, Cas ou Mailbox.

Pour commencer, connectez-vous sur un serveur et lancez l'éditeur de registre (regedit.exe) puis parcourez l’arborescence pour atteindre la clef: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRpc

Modifiez ensuite la clé ParametersSystem (si elle n’existe pas vous pouvez créer l’entrée puis la valeur DWORD « TCP/IP Port »).

Remarque : Cette opération doit être répétée sur chacun des serveurs HUB/CAS ainsi que les serveurs de boite aux lettres (Mailbox).

Comment fixer les ports RPC utilisés pour interroger les contrôleurs de domaine ?

Exchange communique régulièrement avec les contrôleurs de domaine, notamment dans le processus de génération du Carnet d’adresse hors connexion (OAB) et dans le processus de découverte de la topologie Active directory.

La modification du port se réalise directement sur les serveurs Exchange. Pour réaliser la modification il est nécessaire d’éditer le fichier Microsoft.exchange.addressbook.service.exe.config situé dans le répertoire C:\Program Files\Microsoft\Exchange Server\V14\Bin

Conclusion

Cette opération permet de réduire la surface d’utilisation MAPI d’exchange 2010 et des clients de messagerie.

Cette opération est documentée dans la fiche Technet suivante suivante pour les version Exchange 5.5, 2000 et 2003.

Exchange Server static port mappings

Pourquoi ce billet ?

Microsoft ne fournit pas, à l’heure actuelle, d’outil graphique pour réaliser des migrations de boîtes Inter organisation. Le seul outil mis à disposition des administrateurs reste la commande « PowerShell » Move-Mailbox.

Dans cet article je vais présenter quelques exemples de commandes Power Shell pour réaliser des migrations de boîtes aux lettres depuis une organisation Exchange 2000/2003 vers une organisations Exchange 2007.

Toutes ces commandes sont issues d’un retour d’expérience projet réalisé dans une multinationale française (grand compte).

N.B.: Bien entendu, toutes les références à ce client (nom des environnements, des serveurs…) ont été modifiées dans les exemples ci-dessous.

Environnement utilisé

Les commandes présentées ici utilisent les références suivantes :

Organisation source Exchange 2003

• Contrôleur de domaine et CG: DC.source.net
• Serveur Exchange: SourceServer

Organisation cible Exchange 2007

• Contôleur de domaine et CG: DC.target.net
• Serveur Exchange: EXC2007

Pour information, la migration depuis Exchange 5.5 n'est pas possible.

La commande Move-Mailbox ne communique qu'avec des contrôleurs de domaines exécutant Windows 2003 SP1 ou plus.

Avant d'utiliser la commande move-mailbox, l'identifiant source et cible doivent être saisi :

$s=get-credential

Une fenêtre apparaît et vous devez fournir une authentification

$t=get-credential

Idem.

N.B. : Si vous utilisez un compte qui a les droits nécessaire sur la source et la cible, cette étape n'est pas nécessaire.

Exemple 1

Get-mailbox -resultsize unlimited -DomainController 'DC.source.net' –Credential $s | where { $_.customattribute7 -eq '260110' } | move-mailbox -TargetDatabase 'EXC2007\ST01\ISMB01' -BadItemLimit 10 -MaxThreads 30 -SourceForestGlobalCatalog 'DC.source.net' -GlobalCatalog 'DC.target.net' -DomainController 'DC.target.net' -NtaccountOU 'OU=Migrated,DC=target,DC=net' -SourceMailboxCleanupOptions DeleteSourceMailbox -SourceForestCredential $s -TargetForestCredential $t

Cette commande migre les boîtes en mode clone (spécifié par le paramètre NtaccountOU) dans l'OU « Migrated ». Elle sélectionne les boîtes dont le « custom attribute 7 » est égal à « 260110 ». Ces boîtes peuvent provenir de plusieurs serveurs. Elles sont migrées dans la banque d'information ISMB01 du serveur EXC2007. Après la migration, la boîte source est supprimée (SourceMailboxCleanupOptions DeleteSourceMailbox ).Le processus traitera en parallèle 30 objets (Max Threads).

Exemple 2

Move-Mailbox -TargetDatabase 'EXC2007\ST01\ISMB01' -Identity “JeanV” -GlobalCatalog ‘DC.target.net’ -SourceForestGlobalCatalog ‘DC.source.net’ -NTAccountOU 'OU=Migrated,DC=target,DC=net' -SourceMailboxCleanupOptions DeleteSourceMailbox -SourceForestCredential $s –TargetForestCredential $t

Cette commande migre la boîte « JeanV » en mode clone dans l'OU « Migrated » dans la banque d’information ISMB01 du serveur EXC2007. La boîte source sera supprimée après la migration.

Exemple 3

Get-mailbox -DomainController 'DC.source.net' -Credential $s -database 'SourceServer\ST01\ISMB01' | move-mailbox -TargetDatabase 'EXC2007\ST01\ISMB01' -SourceForestGlobalCatalog 'DC.source.net' -GlobalCatalog 'DC.target.net' -DomainController 'DC.target.net' -NTAccountOU 'OU=Migrated,DC=target,DC=net' -SourceMailboxCleanupOptions DeleteSourceNTAccount -SourceForestCredential $s -TargetForestCredential $t

Cette commande migre en mode clone les boîtes de la banque d'information ISMB01 du serveur source vers la banque d’information ISMB01 du serveur EXC2007 . Les comptes NT seront supprimés (SourceMailboxCleanupOptions DeleteSourceNTAccount).

Exemple 4

Get-user -DomainController 'DC.source.net' -Credential $s | where { $_.Department -ilike "DIRECTION" } | move-mailbox -TargetDatabase 'EXC2007\ST01\ISMB01' -SourceForestGlobalCatalog 'DC.source.net' -GlobalCatalog 'DC.target.net' -DomainController 'DC.target.net' -NTAccountOU 'OU=Migrated,DC=target,DC=net' -SourceMailboxCleanupOptions DeleteSourceNTAccount -SourceForestCredential $s -TargetForestCredential $t

Cette commande migre en mode clone les boîtes dont le champ Departement est « DIRECTION » vers la banque d’information ISMB01 du serveur EXC2007. Les comptes NT seront supprimés.

Pour aller plus loin…

Cette commande possède de multiples options que vous pouvez retrouver en consultant ce lien.

http://technet.microsoft.com/fr-fr/library/aa997599%28EXCHG.80%29.aspx

Nous aborderons prochainement la migration Inter-Organisation avec Exchange 2010.

La problématique

Les utilisateurs ne reçoivent plus de messages sur leurs Blackberry après un « Move-Mailbox »

Après le déplacement de leur boite aux lettres d’une base de données vers une autre au sein du même serveur de messagerie, les Blackberrys des utilisateurs concernés ne peuvent plus synchroniser avec Exchange.

L’explication

Ceci est dû au fonctionnement même de BES (Blackberry Enterprise Server). Celui-ci est capable de faire le lien entre un terminal Blackberry et une boite aux lettres d’un utilisateur en vérifiant dans la GAL (Global Address List) Exchange les modifications concernant le DN (Distinguish Name) du serveur de messagerie. Le serveur de messagerie n’ayant pas changé, il ne tente pas de mettre à jour ses informations concernant l’utilisateur.

La solution

Ainsi, la procédure à suivre dans le cadre d’un move-mailbox est la suivante :

- Lancer le “move-mailbox” tel que vous avez l’habitude de faire

Exchange Mailbox Move Wizard ou bien via les commandes Powershell

- Redémarrer les services BES

- Lancer le Cleanup Utility de BES

RIM recommande le lancement de l’utilitaire de cleanup une fois le move-mailbox effectué.

Executer « C:\Program Files\Research In Motion\Blackberry Enterprise Server\Utility\handheldcleanup –u »

Eh bien, il vous est déjà arrivé, en tant qu’utilisateur Outlook d’avoir un message du type :

Pendant l’apparition de ce message, si vous n’êtes pas en mode cache, Outlook ne répond pas.

Le client interroge le client régulièrement le serveur pour avoir des modifications, comme par exemple l’arrivée d’un nouveau message.

Ce message est généré par une requête du client vers le serveur Exchange. Et si au bout de 5 seconds, la réponse ne parvient pas au client, ce fameux message s’affiche.

Le Wrapper est le process générateur de ce message.

Dans les anciennes versions d’Exchange, il y avait des plantages des clients Outlook de manière intempestive et non expliquée. Les développeurs ont donc ajouté ce message de manière à distinguer un plantage lié au fonctionnement d’Outlook d’un autre plantage.

C’est un moyen de debug.

Les causes d’apparition de ce message peuvent être nombreuses. Il peut s’agit :

· Des problèmes liés à l’accès à Exchange à l’Active Directory (DSAccess)

· Des problèmes réseaux

· Des problèmes d’accès aux dossiers Freebusy pour les versions antérieures à Exchange 2007.

Pour plus d’information, merci de se référer à la Kb suivante :

http://support.microsoft.com/kb/892764/fr

Durant les phases de POC ou de pilote il peut s'avérer intéressant de générer des messages reconnus comme étant des SPAM par Brightmail.

Cela permet notamment de valider le bon fonctionnement des règles antispam et/ou des règles de conformité positionnées dans l'environnement du client.

Pour cela il est tout à fait possible d'envoyer un email contenant dans l'objet ou dans le corps du message quelques mots ou expressions savamment choisies.

Il est également possible d'utiliser un en-tête SMTP prévu à cet effet dans le moteur antispam des Appliances SBG !

L'astuce consiste à ajouter l'expression X-Advertisement:spam lorsque vous envoyez un email de test sur une invite de commande en telnet (NB : Cette expression doit être saisie après la commande DATA).

Dans l'exemple ci-dessus, l'email est bel et bien reconnu comme SPAM et l'action prise consiste à modifier l'objet du message, puis à envoyer le message dans la quarantaine.

Ce tips est tiré de la note technique suivante :

Testing mail flow and spam detection in Symantec Brightmail products and Symantec Mail Security appliances.

Introduction

Les boitiers Symantec Brightmail Gateway (anciennement SMS 8300) sont des Appliances antispam et antivirus commercialisées par Symantec. Ces Appliances sont également capables d'appliquer des règles de conformité voir de s'intégrer à des solutions DLP.

On distingue plusieurs types de mises à jour sur les boitiers SBG :

• Les mises à jour des définitions antispam sont appliquées automatiquement par le service Conduit (les mises à jour ont lieu toutes les 10 minutes environ)
• Les mises à jour des définitions antivirus sont appliquées automatiquement par le service LiveUpdate en fonction de la planification définie par l'administrateur
• Les mises à jour du logiciel (software) qui sont appliquées manuellement à l'initiative de l'administrateur

C'est bien entendu la troisième catégorie qui nous intéresse ici ! Symantec ne fournit par de roadmap publique précise en ce qui concerne les mises à jour du logiciel. Néanmoins on peut considérer que des mises à jour mineures sont disponibles de manière trimestrielle et que des mises à jour majeures sont effectuées tous les 1 à 2 ans.

A titre informatif, voici la liste des mises à jour du software de ces deux dernières années en ordre chronologique :

• Août 2007 - 7.5
• Mars 2008 - 7.6.1-7
• Août 2008 - 7.6.1-14
• Septembre 2008 - 7.7.0-17
• Janvier 2009 - 8.0.0-24
• Mars 2009 - 8.0.1
• Mai 2009 - 8.0.2
• Octobre 2009 - 8.0.3  

Pour être averti instantanément lors de la disponibilité d'une nouvelle version du logiciel, le plus simple reste d'utiliser les alertes par emails intégrées au sein du produit (cf. capture d'écran ci-dessous).

Les Best Practices

Voici les best practices en ce qui concerne les mises à jour du logiciel d'une Appliance Symantec Brightmail Gateway :

• Effectuer une sauvegarde de la configuration du "control center"
• Vérifier que le "control center" n'est pas en train d'effectuer une synchronisation avec un serveur d'annuaire
• Vérifier que les "scanner" ne sont pas en train d'effectuer une réplication des données LDAP à partir du "control center"
• Configurer la pile MTA des boitiers "scanner" sur "Do not accept incoming messages"
• Mettre à jour les boitiers "scanner" avec le "control center"

Procédure

Pour lancer la mise à jour d'une Appliance via l'interface Web, il faut suivre la procédure suivante :

1. Cliquer sur Version dans l'onglet Administration
2. Aller dans l'onglet Updates

Il faut ensuite sélectionner la mise à jour, afficher la description (les "release notes"), puis cliquer sur le bouton Update.

L'interface Web affiche ensuite la barre de progression ci-dessous :

Aucune précision supplémentaire n'est ensuite affichée dans l'interface Web. Pour suivre de manière plus précise les différentes étapes de l'installation (téléchargement des différents modules, installation...), il faut se connecter en SSH sur l'Appliance avec un client tel que putty et utiliser la commande watch update.log (cf. capture d'écran ci-dessous).

A l'issue de l'installation, il est possible de vérifier la version installée sur le boitier à l'aide de la commande version.