[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.