PI Services

Le blog des collaborateurs de PI Services

Office 365 – Retour d’expérience d’une migration IMAP

Introduction

L'offre Office 365 inclut un outil de migration. Cet outil permet la migration des boites mails depuis Exchange (2003 / 2007 / 2010 /2013) vers Office 365 ou depuis un autre serveur de messagerie utilisant l'IMAP vers Office 365.
Ce billet portera sur mon retour d'expérience d'une migration IMAP vers Office 365.

Retour d'expérience

Les prérequis


1) Chaque compte migré doit avoir un utilisateur unique associé avec une licence active. Le compte peut être uniquement dans le cloud ou synchronisé avec Active Directory (via DirSync par exemple).
Dans le cadre d'une architecture hybride (c'était le cas dans ce projet), d'autres prérequis utilisateurs sont nécessaires. L'utilisateur doit être "connu" par les serveurs Exchange OnPremise. Pour cela la commande PowerShell suivante est à passer sur les serveurs Exchange OnPremise :

Enable-RemoteMailbox –Identity Utilisateur –RemoteRoutingAddress utilisateur@tenant.mail.onmicosoft.com –PrimarySMTPAddress utilisateur@domaine.fr
Remarque : Attention, si l'utilisateur possède d'autres adresses SMTP que la principale il est nécessaire de les indiquer dans la commande à l'aide du paramètre EmailAddresses
Remarque 2 : Il est également recommandé d'avoir l'UPN (UserPrincipalName) de l'utilisateur qui soit égal à l'adresse email afin de faciliter la connexion aux services Office 365.

2) Un Migration Endpoint avec les éléments suivants :

  • L'URL du serveur IMAP
  • Le type d'authentification (Basic ou NTLM)
  • Le chiffrement (Aucun, SSL, TLS)
  • Le port utilisé pour se connecter en IMAP au serveur
  • Le nombre maximum de migrations simultanées
  • Le nombre maximum de synchronisation incrémentales simultanées

image
3) Un fichier CSV contenant l'adresse email cible, le nom d'utilisateur et le mot de passe du compte IMAP (ou d'un compte administrateur). Le fichier CSV sera construit ainsi :

Les éléments migrés


La migration IMAP n'inclut que la partie mail. En effet les éléments de type contacts, calendrier, tâches… ne sont pas pris en compte.
La migration IMAP prend en compte les mails qui se trouvent dans les différents dossiers (et sous dossiers) personnels ainsi que les dossiers de base (Boite de réception, éléments envoyés, éléments supprimés…).

La migration


La migration se déroule par lot. Chaque lot peut comporter jusqu'à 5000 utilisateurs.
Pour une meilleure gestion des erreurs et de la volumétrie, des lots de 1200 utilisateurs environ ont été fait.
A titre d'exemple, le temps de migration pour un lot de 1200 utilisateurs ayant une volumétrie d'environ 30 Go au total (soit une moyenne de 25Mo/BAL) a mis un peu plus de deux heures.
Cette estimation est bien évidement propre à l'architecture et peut être différente en fonction de la bande passante et des performances du serveur source.

La gestion des erreurs


Il est courant qu'un lot de migration comporte des erreurs. Pour les identifier il est possible d'utiliser la commande PowerShell suivante sur le tenant Office 365 :
Get-MigrationUser -ResultSize Unlimited | ?{$_.Status -ne "Synced"}

image

Les utilisateurs en échec peuvent être sorti du lot de migration et relancés dans un lot séparé.
Remarque : Un utilisateur ne peut pas être inclus dans un nouveau lot s'il appartient déjà à un lot. Microsoft met également à disposition des rapports (au format CSV) sur la plateforme d'administration d'Office 365 – Exchange.

Conclusion

Dans le cadre de cette migration, le pourcentage d'erreur a été de 0.2% (moins d'une vingtaine de boites en erreur sur plus de 6000 boites migrées).
Le seul point négatif est la limite des éléments migrés. Les calendriers, carnets d'adresses… ne sont pas pris en compte et doivent être fait manuellement par l'utilisateur ou via un autre outil de migration.


Pour conclure l'outil de migration fonctionne parfaitement. Même s'il possède peu de fonctionnalités contrairement à d'autres outils de migration (Refresh IT, Quest…) il permet une migration simple à un moindre coût.

Hyper-V et NetApp – Retour d’expérience

Introduction

Dans le cadre d’une migration de stockage, j’ai été amené à utiliser différents outils de NetApp (SnapDrive, SnapManager…).

Dans ce billet je ferai une brève présentation des différents outils utilisés ainsi que mon retour d’expérience quant à l’utilisation de ces derniers.

Environnement

L’environnement source se compose de différents serveurs Hyper-V (sous Windows Server 2008 R2 SP1 et Windows Server 2012). Toutes les machines virtuelles se trouvent sur un stockage en local.

Dans un souci de PRA / PCA, l’environnement cible se composera de différentes baies NetApp réparties sur deux sites différents. Les machines virtuelles sont donc basculées du stockage local au stockage sur la baie.

Les baies NetApp serviront également de sauvegarde.

Outils

Différents outils NetApp sont utilisés dans l’environnement cible.

SnapDrive est l’outil qui permet d’interagir entre le système d’exploitation et la baie de stockage. Il peut ainsi générer des snapshots consistants du point de vue du système d’exploitation en s’appuyant sur des fonctionnalités telles que VSS.

SnapManager for Hyper-V (SMHV) permet de réaliser des snapshots des machines virtuelles hébergées par les hosters.

OnCommand permet de gérer le stockage des baies.

Retour d’expérience

 

Installation et migration

L’installation et la configuration des outils sur les serveurs Hyper-V se font simplement. L’attachement des volumes sur la baie se fait via SnapDrive.

2014-06-20_141253

La migration des machines virtuelles sur la baie se font ensuite grâce à la fonctionnalité Live Migration d’Hyper-V (pour plus d’informations sur la Live Migration suivre ce lien http://technet.microsoft.com/en-us/library/jj134199.aspx).

Mise en place des sauvegardes

La mise en place des sauvegardes se fait en via SMHV. On associe des règles à l’hyperviseur pour les sauvegardes.

2014-06-20_142008

Les sauvegardes via NetApp se font de deux façon différentes : application consistent et le crash consistent.

L’application consistent utilise VSS au niveau de la VM afin d’assurer une consistance au niveau application. A l’inverse le crash consistent utilise VSS au niveau du hoster. Il n’y a donc pas de consistance au niveau applicatif.

N.B : Les sauvegardes de types application consistent ne fonctionnent pas avec des machines virtuelles possédant des bases de données (cela inclut également les contrôleurs de domaine). Pour ces VMs les sauvegardes seront faites qu’en crash consistent, ce qui réduit les possibilités au niveau restauration (restauration à chaud impossible par exemple). Il peut-être alors intéressant de mettre en place système de sauvegarde différents en parallèle afin d’avoir plus de fonctionnalités en cas de restauration.

L’intégration de SnapManager for Hyper-V avec OnCommand se fait uniquement ligne de commande via SnapDrive.

Cette intégration permet par exemple, la gestion automatique des sauvegardes. Dans le cas rencontré, une fois les sauvegardes effectuées une copie des données est envoyée sur la baie du site distant.

 

Conclusion

La mise en place des outils NetApp sur les serveurs Hyper-V est rapide. Les bascules des machines virtuelles du stockage local vers la baie de stockage s’avèrent beaucoup plus longues (cela dépend de la taille de la VM bien entendu). Il faut compter 30 minutes pour l’installation des outils NetApp et 15 minutes pour la migration d’une VM faisant une centaine giga-octets.

N.B : Ces estimations peuvent variées en fonction de l’environnement (vitesse des disques, temps de redémarrage des serveurs…).

La migration des VMs peut se faire à chaud via la Live Migration, ainsi la production n’est pas impactée.

Les sauvegardes des VMs sont faites assez rapidement (les sauvegardes sont uniquement basées sur le delta entre la dernière sauvegarde et l’état actuel de la VM). Une sauvegarde d’une dizaine de machines prend une dizaine de minutes en application consistent et prend quelques minutes (1-2 minutes) en crash consistent.

La réplication de la baie principale à la seconde baie prend du temps lors de la première réplication (cette initialisation doit être faite en ligne de commande sur le contrôleur de la seconde baie).

N.B : Dans le cadre du projet, cette étape s’est faite avec les baies sur le même site pour augmenter la vitesse de copie (environ 20 minutes pour 100 Go de données). Une fois les baies sur les différents sites la vitesse sera plus lente (le lien réseau entre les sites n’étant pas du gigabyte) mais les données à transférer seront moindre (delta uniquement).

Les restaurations peuvent se faire à chaud (sauvegarde de type application consistent uniquement) sur le même hoster ou en récupérant les fichiers (sur le même hoster ou un hoster différent).

Powershell : Définir la liste d'adresse par défaut d'Outlook

Problème rencontré

Lors d'une migration Exchange inter organisation visant à la consolidation des infrastructure de messagerie des filiales d'une entreprise, il s'est présenté la problématique suivante. Il fallait que les utilisateurs aient accès dans leur client Outlook à une liste d'adresse correspondant à leur filiale. Cette dernière devait être la liste visible par défaut.

Solution proposée

Pour se faire, il est nécessaire de modifier une clé de registre sur les postes clients.
Dans la ruche : "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\", sont listés les profiles du client Outlook. Une ruche est présente dans chacun de ceux-ci : "9207f3e0a3b11019908b08002b2a56c2". Celle-ci contient la clé "01023d06" qui définit la liste d'adresse qui sera affiché par défaut à l'ouverture du carnet d'adresse. Attention la valeur est encodé au format Bytes HEX. Nous verrons comment la définir.

S'agissant d'appliquer une modification du registre à l'ensemble des postes clients d'une filiale, la solution la plus simple était d'implémenter cela dans le login script. Cela sera fait en Powershell. Il est bien entendu aussi possible de réaliser cette opération en VBS.
 
Il est à savoir que la vue par défaut du carnet d'adresse est la "Global Address List". De plus, si une valeur erronée est inscrite dans la clé de registre (ne correspondant à aucune liste d'adresse) alors Outlook repositionnera automatiquement le carnet d'adresse sur la liste d'adresse globale.

Récupération des paramètres

Afin de connaitre la valeur que nous devons positionner sur la clé "01023d06", il faut paramétrer manuellement Outlook afin de récupérer la valeur que l’on devra positionner. Pour cela, on définit la liste d’adresse sur laquelle on souhaite que nos utilisateurs se trouvent par défaut.

3

Ensuite, on peut ouvrir la clé de registre qui nous intéresse et observer sa valeur.

1

Si l'on modifie plusieurs fois cette valeur, on remarque le phénomène suivant. Elle se découpe en 3 parties :
- Une première qui est généré dynamiquement par utilisateur (avant le trait rouge)
- Une seconde qui est fixe qui va nous être utile pour récupérer la partie dynamique (entre le trait rouge et vert).
- Une troisième partie fixe (après le trait vert).

Ces trois éléments ont toujours une longueur fixe.

Il faut ensuite reformater les deux dernières parties sous forme de tableau de bytes. Il suffit devant chaque valeur en byte d’ajouter “0x” et de mettre une virgule entre toutes les bytes (syntaxe d'un tableau en Powershell).
Exemple :

01 00 00 00 00 01 00 00 2F devient 0x01,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x2F. Dans le script cette valeur sera définit par la variable $GALSuffix.

67 75 69 64 3D 38 42 34 39 43 31 36 34 45 44 35 41 36 34 30 39 34 42 30 42 4236 35 43 34 45 38 46 39 42 39 00 devient 0x67,0x75,0x69,0x64,0x3D,0x34,0x38,0x42,0x34,0x39,0x43, 0x31,0x36,0x34,0x45,0x44,0x35,0x41,0x36,0x34,0x30,0x39,0x34,0x42,0x30,0x42,0x42, 0x36,0x35,0x43,0x34,0x45,0x38,0x46,0x39,0x42,0x39,0x00.

Dans le script cette valeur sera définit par la variable $GALDefaultValue.

Script

Ci-dessous, le script commenté, où l'on va appliquer les paramètres que l'on a récupéré précédemment. Ceux-ci seront comparés avec ceux que l'on retrouve dans la clé de registre "11023d05" qui contient une configuration de sauvegarde. Cela permet de récupérer la première partie qui est dynamique.

2

Entre la ligne 37 et 47 on compare un à un les bytes rencontrés dans la clé de registre "11023d05" afin de retrouver l’index ou se trouve le tableau de bytes contenu dans $GALSuffix. Une fois cette valeur obtenue, on sait que la partie dynamique à rechercher est définie dans les 20 bytes précédentes.

Contrôle à distance de Sharepoint via Powershell

Introduction

L'une des forces de Powershell est de pouvoir administrer des produits directement depuis un poste client sans avoir à installer des outils d'administration. Hormis dans certains cas particuliers comme Exchange Online, il n'est pas non plus nécessaire d'ajouter des modules ou snapin Powershell sur notre ordinateur. Ceux-ci sont déjà présents sur le serveur distant, il est donc possible de les réutiliser. Dans cet article nous verrons le cas de Sharepoint pour lequel j'ai rencontré une petite subtilité.

Connexion à distance

Tout d'abord nous allons initier une nouvelle PSSession. Pour rappel, ce sont elles qui nous permettent d'interagir avec un serveur à distance. Elles ont été introduites à partir de Powershell v2.0.

On commence par stocker les paramètres d'authentification dans une variable.

$Credential = Get-Credential

On crée une variable avec le serveur sur lequel on souhaite se connecter

$Server =  "XXXXXXXXXX"

On génère une nouvelle PSSession en spécifiant les deux paramètres précédents. Celle-ci est stocké dans une variable car nous allons la réutiliser.

$Session = New-PSSession –ComputerName $Server -Credential $Credential

Ensuite, nous allons utiliser, la Cmdlet Invoke-Command afin d'exécuter une commande dans la session distante que nous venons de créer.

Invoke-Command -ScriptBlock {$ver = $host | select version; if ($ver.Version.Major -gt 1) {$Host.Runspace.ThreadOptions = "ReuseThread"}; Add-PSSnapin Microsoft.SharePoint.PowerShell;} -Session $Session

Il est nécessaire de préciser la session sur lequel va être réalisé le bloc de commandes. Un scriptblock est exécuté. Si la version de Powershell est supérieur à 1 alors on positionne l'interpréteur pour réutilisé constamment le même thread. Ceci est une configuration obligatoire si l'on souhaite ajouter le snapin Sharepoint. Nous pouvons le retrouver dans le fichier “sharepoint.ps1” qui est lancé par le Sharepoint Management Shell.

Enfin nous pouvons importer la session. Avec cette méthode l'intégralité des commandes sera utilisable directement depuis le poste client.

Import-PSSession $Session -AllowClobber

Erreur rencontrée

Lorsque l'on effectue une connexion a distance il se peut que l'on obtienne l'erreur suivante :

Import-PSSession : L’exécution de la commande Get-Command dans la session à distance a signalé l’erreur suivante: Le traitement de données pour une commande distante
a échoué avec le message d'erreur suivant: <f:WSManFault xmlns:f="
http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="3762507597"
Machine="XXXXXXXXXXXXXXXXXXX"><f:Message><f:ProviderFault provider="microsoft.powershell"
path="C:\Windows\system32\pwrshplugin.dll"></f:ProviderFault></f:Message></f:WSManFault> Pour plus d'informations, voir la rubrique d'aide
about_Remote_Troubleshooting...

Cette dernière signifie qu'il n'y a pas assez de mémoire disponible pour charger les commandes. En effet, les commandes Sharepoint sont très consommatrice en mémoire. Bien entendu, il existe un paramétrage pour pallier à ce problème.

Paramétrage serveur

Afin de corriger cette erreur, il faut augmenter la quantité de mémoire maximum allouée pour un shell distant. Il est recommandé pour Sharepoint de définir cette valeur à 1000 MB.

Pour réaliser cette étape il suffit de modifier la valeur MaxMemoryPerShellMB via le provider WSMan permetant d'accéder à la configuration des connexions distantes. Par défaut la valeur est à 100 MB.

Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000

Lync2010 - Déploiement de Lync Server 2010 dans une forêt distante (retour d’expérience)

Introduction

Dans le cadre d’un POC (proof of concept) ou bien tout simplement dans le cadre d’un rapprochement entre deux sociétés (fusion / acquisition), il peut être nécessaire de déployer Lync Server 2010 dans une forêt distante.

S’il s’agit d’un POC, l’intérêt de monter une forêt dédiée à Lync 2010 est généralement de ne pas impacter l’environnement de production (Lync nécessitant une extension du schéma Active Directory) et donc de permettre un retrait / une désinstallation facile de Lync dans l’hypothèse où le produit ne serait pas retenu à l’issue de la phase de test.

S’il s’agit d’une fusion entre deux sociétés ou tout simplement d’une société disposant de plusieurs forêts (reliées entre elles par le biais de relations d’approbation) on déploie généralement Lync dans une seule forêt (la forêt “principale” ou bien la forêt de ressources le cas échéant) pour éviter de multiplier les serveurs.

Quel que soit le cas de figure, à un moment donné l’administrateur se retrouve contraint de donner un accès à des serveurs Lync dans une forêt B sur ses utilisateurs de la forêt A.

Ce billet a pour but de lister l’ensemble des contraintes et actions à prendre en compte dans un tel scénario.

Points à prendre en compte

Les points à prendre en considération (par rapport à un déploiement de Lync en environnement mono-forêt et mono-domaine) sont les suivants :

  • Une relation d’approbation (de type inter forêt) doit exister entre les deux forêts
  • Les comptes utilisateurs de la forêt A doivent être provisionnés dans la forêt B par le biais d’un outil tél qu’ADMT (si la population est réduite) ou bien via un outil de synchronisation de compte tel que FIM (si l’environnement est de plus grande taille)
  • L’outil de provisionnement des comptes doit migrer l'attribut SID du compte source dans l’attribut SIDHistory des comptes cible. Il est conseillé de désactiver les comptes présents dans la forêt cible pour des raisons de sécurité (de la même manière que pour une boîte aux lettres Exchange 2010 de type “linked”)
  • Un script doit ensuite être développé pour copier le SID source dans l’attribut msRTCSIP-OriginatorSid du compte utilisateur
  • Les certificats utilisés sur les serveurs frontaux et Edge Lync 2010 devront être émis par une infrastructure PKI reconnue comme de confiance par les clients des deux forêts

L’intégration du composant Lync au Webmail Exchange 2010 est possible quelle que soit la forêt dans laquelle est déployée Exchange. Si la messagerie Exchange 2010 est déployée dans une forêt distincte de celle de Lync alors les adresses SIP devront être ajoutées manuellement (ou pas script) sur les boîtes aux lettres.

N.B. : Le déploiement de Lync 2010 dans une forêt distante n’a pas d’impact particulier sur le déploiement des services de Mobilité Lync 2010.