Pour Office, ça se passe par là
Pour Sharepoint, Exchange, Lync, Office Web Apps, Project et Visio, c’est par ici.

Bon test !

Cela vient de la façon dont Exchange traite les emails pour les domaines distants. Si vous avez Exchange 2007 ou 2010, il est possible d’éviter ce comportement. Les destinataires de vos emails pourront les lire correctement, sans faire perdre de temps à leur service IT ou encore mieux, sans vous faire perdre de temps (après tout, le problème est du côté Exchange).

Il vous suffit alors de désactiver l’envoi de Rich-Text au niveau Exchange. Cela se passe en powershell avec la commande suivante (veillez à changer le nom du domaine si nécessaire) :
Set-RemoteDomain -CharacterSet '' -NonMimeCharacterSet '' -TNEFEnabled $false -Identity 'Default'.

L’application est immédiate.

Cette clé est à créer dans HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover (remplacer 12.0 par 14.0 si vous êtes en Outlook 2010). Elle devra se nommer ZeroConfigExchange, être de type DWORD et avoir pour valeur 1.

Encore une simplification côté utilisateur

Depuis Exchange 2010, il est possible de d’ajouter des signatures HTML au niveau de l’organisation Exchange en se basant sur les attributs Active Directory. Pour cela, nous allons utiliser les règles de transport.
On va commencer par composer la signature au format HTML. Il est possible d’utiliser des attributs AD particuliers. Ces attributs sont en fait des prédicats de règle de transport. Il faudra que les attributs AD soient correctement remplis. Ici, j’utilise le nom complet de la personne (displayName), sa fonction (title), son entreprise (company), etc. J’utilise également un attribut personnalisé d’Exchange (customAttribute1).

Cette règle va s’appliquer à tous les messages transitant dans l’organisation Exchange quelque soit leur destination (interne ou externe). Comme toute règle de transport, il est possible de limiter l’application de la signature aux seuls mails sortants ou à un certain groupe de personnes. Il est également possible de placer des exceptions.

Attention cependant à l’utilisation de cette règle de transport. Vous devrez vous assurer que les attributs AD utilisés ne soient pas confidentiels (comme les numéros de ligne directe). vous devrez aussi vous assurer qu’ils ne deviennent pas confidentiels. Pour cela, vous pourrez créer une autre règle de transport (avec les mêmes critères d’application ou non) pour rendre conformes les emails sortants. On voit souvent le terme anglais compliance pour désigner ce processus.

Pour avoir plus d’informations sur les disclaimers HTML, je vous conseille ceci : Présentation des dédits de responsabilité.

Pour le télécharger, c’est par ici : http://www.microsoft.com/downloads/en/details.aspx?familyid=cea0cf7e-d824-49bb-8924-39d66a5fb88e

Comme d’habitude, il est conseillé de l’imprimer sur une grande feuille et de l’afficher dans votre bureau

Vous pouvez les télécharger par ici : http://download.microsoft.com/download/8/9/6/8963C321-0CC1-4859-B8B0-FC7F2CEBF92C/Exchange2010.vss

La première solution serait d’utiliser le port 587 (SMTPS) pour contacter les serveurs. Le problème est que tous les SMTP ne disposent pas forcément d’un port sécurisé. On pourra donc facilement tomber sur un SMTP non sécurisé et donc être dans une impasse.

La seconde solution est d’utiliser un serveur SMTP sécurisé (authentifiant) qui fasse relai. Les serveurs GMail proposent ce genre de service depuis longtemps mais ils ont l’inconvénient majeur de réécrire le champ Sender des emails pour y mettre l’adresse du compte GMail utilisé pour s’authentifier sur le serveur. Cela veut dire que vous ne pourrez pas envoyer d’emails provenant de votre domaine email.

Des registrar DNS fournissent des comptes email associés à votre domaine. C’est le cas de Gandi par exemple. Il vous suffit de créer un compte email sur l’interface d’administration pour avoir accès à leur SMTP sécurisé. On peut donc contourner la limitation de l’opérateur.
Une fois que vous avez votre compte, testez l’envoi d’email par ce SMTP avec votre client email. Cela permet d’être sûr que le compte fonctionne.

Maintenant, je vais vous expliquer comment configurer Exchange pour qu’il utilise un SMTP externe pour envoyer les emails. On va configurer le rôle transport hub pour router les messages vers un hôte actif grâce aux connecteurs d’envoi. On peut créer ce connecteur en mode graphique mais on ne peut pas sélectionner le port SMTP distant : cette opération ne peut s’effectuer qu’en Powershell. Vous devrez donc ouvrir Exchange Management Shell.

Une petite explication :
-Name : nom du connecteur dans Exchange
-AddressSpaces : l’espace de nommage pour déterminer si Exchange doit utiliser ce connecteur ou pas. Ici le connecteur va prendre en charge toutes les adresses SMTP avec un coût de 1. Attention au deux-points et point-virgule
-Usage : ça parle tout seul
-SmartHosts : serveur actif qui va prendre en charge les emails sortants d’Exchange. J’utilise le serveur gandi, à adapter pour coller à ta config.
-SmartHostAuthMechanism : permet de préciser la méthode d’authentification. Ici, il faut utiliser une authentification basique en forçant l’utilisation de TLS.
-RequireTLS : permet de forcer l’utilisation de TLS
-Port : c’est le paramètre qui n’est pas modifiable en mode graphique. On précise le port sécurisé standard (différent de 25 donc on contourne les restrictions orange)
-AuthenticationCredential : donne au connecteur les identifiants pour se connecter au serveur distant
-Enabled : active le connecteur

Si votre serveur ne supporte pas StartTLS, vous devrez indiquer à Exchange de ne pas utiliser StartTLS en utilisant cette commande en remplacement de la précédente :

Il ne vous reste plus qu’à tester. Si les emails ne sortent pas, consultez la queue des messages dans la boîte à outils Exchange pour savoir ce qu’il se passe.

Voilà comment contourner une limitation (vraiment) stupide

L’avantage le plus important est que vous n’avez plus à gérer les serveurs (maintenance, debug, mise à jour, sauvegarde, etc): ces derniers sont dans les datacenters Microsoft. Ces derniers sont répartis sur les différents continents. Comme avec Azure, vous irez interroger le datacenter de votre continent. Vous aurez accès à une interface d’administration pour gérer les comptes de votre entreprise et différents paramètres de la plateforme.

Niveau modularité et donc tarif, vous pouvez choisir parmi les produits qui vous intéressent.

Sur le papier, cette offre est bonne. Dans la pratique, comment cela se passe ? Developpez et Microsoft vous proposent de tester MOS gratuitement avec l’offre BPOS (Exchange, Sharepoint, Live meeting et OCS). Vous pourrez donc vous rendre compte si MOS correspond à vos attentes et surtout poser vos questions à l’équipe MOS de Microsoft lors d’un Live Meeting en avril.
Ce sera également l’occasion de faire un retour de votre expérience sur MOS pour améliorer la plateforme.

Je vous invite à continuer sur ce topic et faire vos remarques directement dessus

Notez également que Microsoft a mis à disposition un outil pour tester votre connectivité à l’offre BPOS. Très pratique et très simple !

Bon test !

Un script powershell a été créé pour répondre à cela. Celui ci est géré au niveau de l’entreprise mais intervient au niveau de chaque client. Vous pourrez générer les signatures de vos collaborateurs automatiquement à partir des informations stockées dans votre Active Directory comme le nom, prénom et fonction.

Le lien vers le script Set-OutlookSignature.ps1​