[Office365] OWA – Créer signature HTML (avec Image)

Parmi les limitation d’Outlook Web Access, on trouvera l’impossibilité d’insérer une image dans sa signature.
En effet, la gestion des signatures dans OWA ne permet pas d’insérer une image (logo d’entreprise par exemple) :

UI_Sign
(Cliquer pour agrandir)

Dans le cas ou un utilisateur doit envoyer un mail via l’interface web, il est plus agréable d’avoir une signature standard plutôt que du texte brut, voir pas de signature du tout…

Il existe une solution pour passer au delà de ce problème.Un script PowerShell peut être utilisé pour appliquer une signature à un utilisateur quand il utilise OWA.
Pour ce faire, il faudra :

  1. Un compte Office 365 sur lequel appliquer la signature;
  2. Un compte Admin pour pouvoir exécuter les commandes.

Dans un premier temps, il faut créer la signature au format HTM/HTML selon la modèle souhaité.
Pour insérer une image, il faut que celle-ci soit hébergée sur internet, et c’est là que c’est important. Il faut que l’image soit accessible sur internet.
Ensuite, dans une console PowerShell connectée à Office 365, saisir les commandes suivantes :

$file = "[URL_SIGN]"

$temp = Get-Content Path $file ReadCount 0
Set-MailboxMessageConfiguration identity [ACCOUNT] SignatureHtml $temp

[URL_SIGN] : Correspond au chemin du fichier HTM sur l’ordinateur
[ACCOUNT] : Correspond au compte sur lequel appliquer la signature

Voilà ce que cela donne

Sign_Final
(cliquer pour agrandir)

Inconvénients :

  • L’utilisateur ne peut pas mettre en place cette procédure seul;
  • Lors de la réception de mails, il est possible que l’image soit bloquée par sécurité. Pour que cette alerte n’apparaisse plus, il faut ajouter le domaine à la liste des expéditeurs approuvés en cliquant sur l’alerte.

Sign_Warning
Sign_Warning2
(cliquer pour agrandir)

En revanche, cela convient parfaitement lors de la création de la messagerie par le service adéquate au sein d’une société. Ainsi, il est possible d’appliquer le même modèle de signature pour tout le monde.

P.S. : Il est aussi possible de passer par le “Presse Papier” pour intégrer une image via OWA directement, mais il n’est pas évident de gérer l’emplacement de celle-ci via cette méthode.

Jimmy.
(Billet d’origine : http://www.overthecloud.fr/?p=93)

[Tips Office 365]–Eléments de réponses dans le cadre d’un POC “Productif”

Dans le cadre d’un POC ou “Proof Of Concept”, il est possible que vous ou vos clients souhaitiez évaluer les services O365 de manière productive sans avoir à tout modifier dans l’infrastructure on-premises.

Quand je dis “de manière productive” je sous-entends ne pas jouer avec quelques utilisateurs uniquement sur un domaine *.onmicrosoft.com pendant deux jours et valider que O365 c’est génial.

Pour commencer, il faut savoir que contrairement à BPOS, Office 365 ne permet pas la coexistence d’une boite mail on-premises et dans le cloud si le compte a été créé via une synchronisation Active Directory… (Je n’ai pas testé avec d’autres systèmes de messagerie que Exchange, à voir pour Lotus Notes, si vous avez des réponses à me donner, je suis preneurJ)

Lors de la synchronisation de l’annuaire, si l’outil de synchronisation détecte que l’utilisateur à une boite mail on-premises, il synchronise le compte et refuse de créer la boite mail sur la plateforme Office 365. La solution supportée par Microsoft ? Migrer l’utilisateur sur la plateforme en bêta et sans garantie de pouvoir faire un RollBack propre en cas de problème.

Plus gênant encore, depuis la semaine dernière (Semaine 10), la plateforme a subi de nombreuses mises à jour (Sujet d’un prochain billet après vérification des NDA), et entre autre il n’est maintenant plus possible de désactiver la synchronisation Active Directory une fois celle-ci active.

Voir la réponse de Microsoft ci-dessous :

Forum

Bref, la mise en place d’un POC n’est pas vraiment facile. Et il y a beaucoup de choses à savoir avant de se lancer, car nous pouvons très très vite rencontrer des surprises…

Validation du domaine

Pour commencer, il vous faudra avoir validé votre nom de domaine sur la plateforme hébergée.
Vous ne pourrez pas mener cette validation du nom de domaine (création des MX et autres entrées DNS nécessaire à la plateforme Office365) à terme puisque vous avez une infrastructure en local. Le faire reviendrait à supprimer les enregistrements qui pointent vers votre infrastructure locale. Ce n’est pas ce que nous souhaitons faire. Limitez-vous donc à valider que vous être le propriétaire du domaine (c’est-à-dire jusqu’à la fin de la création du DNS qui pointe vers ps.microsoftonline.com).

Pour plus d’informations sur la validation de nom de domaine sous Office365, consultez l’article d’eudo Smile

AutoDiscover – Fonctionnement

Dans ce billet, nous allons parler des problèmes liés à l’AutoDiscover dans le cadre d’un POC productif.
En effet, si nous partons d’un serveur Exchange en local, il y a très certainement un AutoDiscover en place sur le domaine. Or, si nous mettons en place des comptes utilisateurs avec la même adresse SMTP dans le cloud, nous serons promptés très régulièrement à travers Outlook pour configurer ce compte avec les paramètres On-premise. Vous me suivez ?

Il faut savoir que puisque votre MX pointe vers votre serveur Exchange, il en est de même pour l’AutoDiscover.

1. Par défaut, Outlook tentera d’utiliser l’AutoDiscover du domaine SMTP donné en accédant au CAS (Client Access Server) à partir de l’adresse https://cumulos.fr/autodiscover/autodiscover.xml (pour le domaine Cumulos.fr).

2. Si cela ne fonctionne pas, il tentera d’accéder à https://autodiscover.cumulos.fr/autodiscover/autodiscover.xml.

3. Si le second essai ne fonctionne toujours pas, il tentera de chercher les informations du CAS d’un un fichier XML en local sur la machine.

4. Ensuite c’est via l’adresse http://cumulos.fr/autodiscover/autodiscover.xml qu’il tentera de se connecter (non sécurisé)

5. Et pour terminer, si rien n’a fonctionné, Outlook tentera de localiser l’enregistrement SRV pour l’adresse : http://autodiscover.cumulos.fr/autodiscover/autodiscover.xml.

scr_3

Lors de la configuration automatique, Outlook récupère la configuration de mon serveur local.. Alors que je souhaite le configurer pour Office365

Bref, ici, rien ne permet de dire à Outlook qu’il ne faut pas se fier à mes enregistrements DNS et que cumulos.fr est un domaine SMTP un peu spécial (Un POC c’est toujours un environnement un peu spécial). Mais que dis-je, notre fichier XML en local est éditable… (Etape 3) Il est donc possible de rediriger mes informations sur la plateforme Office365 !

Outil de simulation de configuration automatique

Pour tester votre configuration automatique (autrement dit savoir ce que fait Outlook lors de la configuration du profil), vous pouvez utiliser un outil fourni avec votre client de messagerie préféré.

Appuyez sur « Ctrl Gauche » et cliquez sur l’icône Outlook dans la zone de notification puis choisissez « Tester la configuration automatique de la messagerie ».

Outlook_conf

Dans la fenêtre qui s’ouvre, entrez vos identifiants et cliquez sur « Tester ».

En dehors d’un POC, vous pouvez aussi utiliser Exc RCA pour vérifier la configuration automatique (j’ai écris un article à ce sujet ).

 

AutoDiscover – Configuration

La configuration n’est pas bien compliquée. Elle consiste en la création de deux valeurs dans la base de registre et la création d’un fichier XML.

Le fichier XML

Il vous faut donc créer un fichier XML afin de donner à Outlook les informations nécessaires pour contacter les serveurs Office365 et ne pas/plus passer le serveur Exchange local le temps du POC.

Voilà le contenu du fichier XML :

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<Account>
<AccountType>email</AccountType>
<Action>redirectUrl</Action>
<RedirectUrl>https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml</RedirectUrl>
</Account>
</Response>
</Autodiscover>

Pour faire rapide, copiez/collez le code ci-dessus dans un bloc note, et enregistrez le (en tant que TestAutoDiscover.xml par exemple) dans un endroit où il ne risque pas d’être supprimé par erreur.

https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml est le chemin du CAS des serveurs Office365. Avec ça, Outlook cherchera à identifier l’utilisateur sur la plateforme dans le cloud et non en local.

Ajout des valeurs dans la base de registre

Les valeurs à ajouter dans la base de registre ne nécessitent pas de droits d’administrateur.
Il faut les créer dans Hkey Current User (HKCU). Cela implique aussi que si l’ordinateur est utilisé par plusieurs utilisateurs, il faudra répéter ces manipulations.

Pour faire rapide, copiez/collez le code ci-dessous dans un bloc note, paramétrez-le (à l’aide des instructions en dessous du code) et enregistrez le en tant que AutodiscoverAddRegistry.reg. Puis exécutez-le.

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover]
"cumulos.fr"="C:\\Documents and Settings\\XcessiV\\Desktop\\TestAutoDiscover.xml"
"PreferLocalXML"=dword:00000001

Les inscriptions en gras sont à modifier

Première valeur :

Celle-ci indique à Outlook que pour le domaine donné (Cumulos.fr ici) il faudra utiliser le Fichier XML indiqué.

    • La valeur "Cumulos.fr" correspond à votre domaine SMTP.
    • La valeur "C:\\Documents and Settings\\XcessiV\\Desktop\\TestAutoDiscover.xml" correspond au chemin ou sera stocké votre fichier XML. N’oubliez pas de doubler les « \ »

Seconde valeur :

"PreferLocalXML" impose à Outlook d’utiliser le fichier XML local en premier. Cette partie n’est pas à modifier

Suppression des valeurs de la base de registre

A toute modification sur les postes/serveurs lors d’un POC, le Roll-Back doit pouvoir se faire facilement.

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover]
"cumulos.fr"=-
"PreferLocalXML"=-

Les inscriptions en gras sont à modifier

Je reviendrais sur cette partie plus tard. Mais créez le fichier AutodiscoverAddRegistry.reg de la même manière que pour l’ajout.

Les « » après les valeurs indiquent que nous souhaitons supprimer ces valeurs.

Vérification

Toujours avec l’outil de configuration automatique, je relance le test sur mon compte dans le cloud…

scr_7Outlook utilise maintenant les paramètres de la plateforme Office365 Smile

Cette fois-ci, tout est ok.
Nos utilisateurs pourront jouer avec Outlook et avoir une réelle coexistence entre leur infrastructure locale et Office 365 (moyennant la mise en place des redirecteurs : Sujet de billet ? J)

Roll-Back

Afin de revenir à un environnement propre, il est nécessaire de réaliser quelques manipulations, que cela soit pour l’administrateur ou l’utilisateur.

Je pars ici du principe que des redirecteurs de mails ont été mis en place en amont afin de ne pas perdre de mail en réception. En effet, si un problème intervient lors du Roll-Back, nous serons certains d’avoir minimisé les pertes.

1. Il faudra donc penser à récupérer :

    • Les éléments envoyés
    • Les contacts
    • Le calendrier

Pour ceci, pas compliqué, vous pouvez utiliser Outlook pour exporter les données du profil. Voilà un lien (en anglais) qui vous explique comment faire.

2. Supprimer les clés de registre à l’aide du second fichier REG (AutodiscoverAddRegistry.reg) Winking smile

3. Supprimer le fichier XML enregistré en local

4. Importer les données dans l’ancien profil Outlook (même lien que pour l’étape 1)

Entre nous, il est peu probable que vous souhaitiez revenir en arrière après avoir testé Office 365 Smile

 

Si vous n’avez pas peur des articles en anglais, je me suis fortement inspiré de celui-ci.
Merci à Julien Peigné (vNext) et
Eudes-Olivier Robert (Néo-Soft Services) pour leur aide et leurs éléments de réponse.

[Tips Office 365] Configurer les options régionales pour tous les utilisateurs

Regional_PS_1

Problématique

Lors de la première connexion à Outlook Web Access, les utilisateurs ont pour obligation de renseigner la langue de l’interface ainsi que leur fuseau horaire.

Selon leur niveau et le nombre de popups qu’ils ont eu à gérer dans la journée, les retours seront les suivants :

  • L’utilisateur prend le temps de tout lire et renseigne correctement les champs. Pas d’incindence.
  • L’utilisateur ne souhaite pas comprendre et appelle le support… Pas d’incidence mais perte de temps.
  • L’utilisateur ne lis pas le message et clique sur Ok sans se rendre compte des problèmes que cela peut lui apporter…

Le problème étant que le serveur fait ce qu’on lui demande de faire, c’est à dire caler l’heure du rendez-vous selon le fuseau horaire. Hors, si l’utilisateur ne se trouve dans le bon fuseau, il aura du mal à se connecter à la réunion.

Exemple :

  • J’ai mon Outlook configuré correctement et une utilisatrice qui n’a pas souhaité configurer le fuseau horaire de son OWA.
  • J’ai créé une réunion pour le 11 Mars de 18 à 19 heures.
  • Lorsque j’ouvre le rendez-vous sur son compte, le rendez-vous s’est calé sur son fuseau horaire et apparait donc de 21H30 à 22H30.

Imaginez ce genre de problème dans toute une société…

Regional_PS_2

Et bien il est possible de pré-enregistrer le fuseau horaire et la langue pour tous les utilisateurs en remote PowerShell !

Edition et vérification

Pour commencer, si vous souhaitez vérifier la configuration régionale d’un compte :

Get-Mailbox –identity <votre compte>| Get-MailboxRegionalConfiguration

Regional_PS_3

Si c’est la configuration globale de tous les comptes activés que vous voulez :

Get-Mailbox | Get-MailboxRegionalConfiguration

Regional_PS_4

 

Nous pouvons voir plusiuers choses intéressantes ici.

  • La première étant que tous les utilisateurs ne se sont pas connectés sur OWA et n’ont donc pas configuré les paramètres régionaux.
  • La seconde étant que trois utilisateurs n’ont pas les bons paramètres (Natalie Protman, Alexis et moi oO)

Pour modifier ces paramètres (sur un seul compte), la commande est la suivante :

Set-MailboxRegionalConfiguration <votre compte> -Language fr-FR –TimeZone "Romance Standard Time" -DateFormat "dd/MM/yyyy"

Voilà ce que cela donne après avoir modifié le profil d’Alexis

Regional_PS_5

 

Ce qui peut être sympa, c’est de pouvoir le faire pour toute la société (si tous les employés sont dans le même fuseau). Voilà comment…

Get-Mailbox -Resultsize unlimited | Set-MailboxRegionalConfiguration -Language fr-FR -TimeZone "Romance Standard Time" -DateFormat "dd/MM/yyyy"

Et voilà le résultat

Regional_PS_6

Et voilà, tout est configuré et ça évite bien des problèmes.
Par contre, si vos utilisateurs ne sont pas tous en France, ou que vous ne souhaitez pas modifier le format de date pour tout le monde, vous pouvez par un fichier CSV…

Configuration Outlook sans le client SSO…

… ou configurer deux comptes Online Services sur le même profil Outlook.

Pour cette première vidéo, on va voir comment bypasser l’utilisation du SSO (Single Sign On).
Outre le fait qu’on se libère du client de connexion (non sans concession), cela permet de configurer plusieurs comptes Online Services même si ceux-ci ne font pas parti de la même organisation.
Bref, passons à la pratique Sourire

 

P.S. : Oui, mon wall n’est pas corporate. La prochaine fois il sera MS Compliant ^^
P.S.2 : C’est ma première vidéo commentée, je suis preneur de tout commentaire
P.S.3 : Si vous avez des idées de vidéos/articles n’hésitez pas à nous le faire savoir !

Microsoft simplifie les interopérabilités futures avec Outlook

Quelques jours après avoir annoncé une nouvelle version du plugin Outlook Hotmail Connector, Microsoft vient de publier deux projets open source visant à permettre aux développeurs de créer des applications capables de lire et d’écrire des données depuis et vers le logiciel Outlook.
Au coeur d’Outlook et de Microsoft Exchange, nous retrouvons le format .pst (Personal Storage Table), c’est-à-dire un répertoire personnel stocké à distance (Exchange) ou en local et au sein duquel figure l’ensemble des informations comme les événements du calendrier, la base de données des contacts, ou encore les notes.
Hier Microsoft a ainsi publié un outil permettant de naviguer les données structurées au sein d’un fichier PST (PST Data Structure View Tool) ainsi qu’un kit de développement pour ce même format de fichier (PST File Format SDK). Ces deux projets sont hébergés sur le site Codeplex.org, le répertoire open source de Microsoft, et distribués sous licence Apache V 2.0.
Reste à savoir de quelle manière les développeurs feront usage de ces outils. L’on imagine un petit plugin capable de rechercher et de filtrer automatiquement les fichiers multimédias insérés en tant que pièces jointes dans les emails mais aussi des outils de migration vers un logiciel concurrent. Le magazine Infoworld rapporte les propos de Paul Lorimer, chargé de l’interopérabilité au sein du groupe Microsoft Office : « je pense que cela satisfait davantage nos utilisateurs de savoir que nous souhaitons offrir une solution transparente et qu’ils ne sont pas bloqués (au sein d’un logiciel donné) ».

Source : clubic.com