Réunion CUMULOS le 6 avril 2011

A l’occasion du lancement de la beta publique d’Office 365 début avril, CUMULOS, la Communauté des Utilisateurs Microsoft Online Services vous invite à participer à une après-midi spécialement consacrée à cet évènement le 6 avril 2011 de 14h00 à 18h00 sur le Campus de Microsoft France, 41 quai du Président Roosevelt, 92130 Issy-les-Moulineaux.

Au programme : présentation des services Exchange Online, SharePoint Online et Lync Online, nouveautés de la beta, Q&A avec les équipes Microsoft, présentation de produits tiers et d’offres autour de la solution Microsoft Office 365.

La page de l’évènement sur Facebook

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

[Tips Office 365] Se connecter à Exchange Online en Remote PowerShell

Comme avec BPOS, il est possible de faire du remote Remote Powershell avec Office365.
A la différence près qu’il est possible de se connecter au cloud avec la la console powershell de base. Il n’est plus necessaire de télécharger les outils de migration pour executer nos commandes à distance.

Les prérequis

  • PowerShell v2 (De base sous Win7 et Win2008 R2)
  • Windows Remote Management (WinRM) 2.0 (De base sous Win7 et Win2008 R2)

Le tout étant disponible ici si vous êtes encore sous XP

Se connecter

Bref, voilà comment se connecter et même comment récuperer la liste des commandes PS disponible !

Commande de base pour saisir les identifiants (Jusque là, pas de changement)

$cred = Get-Credential

Connecting_PS_1

Chaine de connexion

$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic –AllowRedirection

Connecting_PS_2

Ouverture de la session

$importresults = Import-PSSession $s

Connecting_PS_3

Vous êtes maintenant connectés.

Liste des commandes disponibles

Maintenant, pour avoir la liste des commandes disponibles, il vous suffit de taper la commande ci-dessous.

Get-Command -Module $importresults | Out-Host -Paging

Connecting_PS_4