PI Services

Introduction

Cet article divisé en deux parties est un retour d'expérience sur une migration entre tenant Office 365. Il ne traitera pas de tous les services disponibles sur Office 365 mais seulement de ceux rencontrés lors de la migration (voir Contexte). La première partie traitait de la migration des licences, du SSO (ADFS) et de Dirsync (http://blog.piservices.fr/post/Retour-dexperience-Migration-de28099un-tenant-Office-365-Partie-1.aspx). Cette seconde partie sera consacré aux autres services d'Office 365 (Yammer, Exchange Online, Sharepoint Online).

Contexte

Pour rappel, la société possédait deux tenant et souhaitait migrer les services de l'un des deux (nommé ici myenterprise1) vers le second (nommé ici myenterprise2). Pour chaque service, un listing des étapes à réaliser sera détaillé.

Exchange Online

Il n'existe pas de réel procédure pour la migration de boîtes aux lettres entre tenant. Le processus ci-dessous est manuel. Globalement, il consiste à exporter les boîtes aux lettres au format PST, à migrer le domaine SMTP puis à recréer les boîtes aux lettres sur le nouveau tenant. Cette procédure est entièrement manuelle. Voici un listing chronologique des étapes à appliquer :

• Configuration du domaine SMTP sur le nouveau tenant (myenterprise2). Il ne faut bien évidemment pas faire la vérification mais simplement créé les enregistrements et valider qu'ils sont bien visibles avant de passer à l'étape suivante. Cela permet de réduire la coupure de service à quelques minutes. Si les enregistrements DNS ne sont pas créés en amont, le service peut être coupé le temps de la création de ceux-ci et de la propagation dans les DNS (cela peut durer 24H).
• Création des utilisateurs sur le nouveau tenant (positionnement d'un suffixe UPN en *.onmicrosoft.com). Cela permet de gagner encore un peu de temps sur la coupure de service.
• Sauvegarde des boîtes aux lettres sur l'ancien tenant (myenterprise1) au format PST (via Outlook par exemple).
• Changement de domaine des utilisateurs sur l'ancien tenant (myenterprise1). Il suffit de définir leurs suffixes UPN sur le domaine *.onmicrosoft.com afin qu'il n'interfère pas avec la migration du domaine SMTP.
• Suppression du domaine SMTP de l'ancien tenant (myenterprise1) Office 365.
• Vérification du domaine sur le nouveau tenant et attribution de l'intention de domaine de type Exchange Online.
• Changement du domaine d'appartenance des utilisateurs sur le nouveau tenant (mise en place du nouveau domaine SMTP).
• Activation des boîtes aux lettres pour les utilisateurs sur le nouveau tenant (myenterprise2).
• Import du PST d'export réalisé précédemment pour chaque boîte aux lettres sur le nouveau tenant (myenterprise2).
• Reconfigurer les clients Outlook. Il est nécessaire de supprimer le profil et de le recréer pour que la boîtes aux lettres soit accessible.

Toutes les étapes de changements d'UPN sont automatisables via Powershell avec la commande Set-MsolUserPrincipalName (voir script de la section Modification des utilisateurs de la partie 1).

Cette procédure est donc valable pour un faible nombre de boîtes aux lettres. Si le volume de boîte aux lettres est trop important, il reste deux solutions possibles mais plus lourdes et/ou plus onéreuses :

• Migrer vers une infrastructure On Premise Exchange (scénario prévu par Microsoft) puis rebasculer sur le nouveau tenant Exchange Online.
• Utiliser des outils de migrations payants.

Sharepoint Online

Comme pour d’autres services Office 365, la migration d’un site Sharepoint Online est manuelle. La migration se déroule en cinq étapes :

1. Récupération du contenu
2. Génération d’un modèle
3. Import du modèle
4. Intégration du contenu
5. Paramétrage du nouveau site : il s’agit de reconfigurer les paramètres comme les autorisations utilisateurs.

Nous allons nous intéresser à la migration du contenu, à la génération du modèle de site et à l’import de ce dernier.

Migration du contenu

Afin de migrer le contenu d’un site Sharepoint Online, il faut utiliser OneDrive. Il est nécessaire de se connecter au site web à migrer est de copier tout le contenu du site. Néanmoins si votre site possède moins de 50Mo de contenu, il suffira de l’inclure dans le modèle. En effet, ce dernier peut inclure du contenu si celui-ci ne dépasse pas cette limite de taille.

NB : Il existe aussi des outils de migrations payant.

Génération du modèle de site

La génération du modèle de site se fait via la console d’administration du site (Paramètre du site).

Dans la section Action du site, il faut choisir “Enregistrer le site en tant que modèle”.

Un assistant vous proposera ensuite de donner un nom au modèle et éventuellement d’inclure le contenu du site (cette opération n’est fonctionnelle que si votre contenu pèse moins de 50Mo).

Vous pourrez ensuite accéder à la galerie des solutions et télécharger le modèle au format .wsp.

NB : L’option “Enregistrer le site en tant que modèle” n’est parfois pas disponible. Pour l’activer, il faut utiliser Sharepoint Designer 2013. Il est nécessaire d’ouvrir le site depuis ce logiciel en spécifiant son url et de choisir “Options de site” dans le ruban.

Enfin, il faut changer la valeur du paramètre “SaveSiteAsTemplateEnabled” à “True” et appliquer le changement. Ainsi, l’option d’enregistrement du site en tant que modèle sera disponible dans les paramètres du site Sharepoint.

Import du modèle de site

Pour importer un modèle de site, il suffit de créer un nouveau site en spécifiant un modèle personnalisé (le modèle devra être fourni ultérieurement).

Enfin, il faut ouvrir le nouveau site web et choisir “Galerie Solution” dans lors du choix du modèle. Ce lien vous mènera à une fenêtre permettant de charger le fichier .wsp précédemment créé via le bouton “Télécharger la solution”.

Yammer

Yammer étant un service encore peut intégré avec Office 365, il est plus facile à migrer entre deux tenants. Tout d'abord, il est nécessaire de supprimer le domaine qui correspond au nom du réseau Yammer sur l'ancien tenant(myenterprise1). Il s'agit ensuite de l'ajouter sur le nouveau tenant (myenterprise2).

Si le domaine n'est pas fédéré, il faut que ce dernier soit défini comme domaine par défaut de Yammer. Dans le cas contraire, une erreur est remontée au moment de l'activation du service Yammer. Pour réaliser cette opération, il suffit de se rendre dans le listing des domaines, de sélectionner le bon domaine est de cliquer sur l'option “Définir par défaut”.

Nous pouvons ensuite activer Yammer sur le nouveau tenant (myenterprise2). Dans le panneau d'administration d'Office 365, il faut cliquer sur “Tableau de bord” puis choisir “Service Inclus”. Un nouveau panel apparaît sur la droite permettant d'activer Yammer.

On peut ensuite confirmer l'activation du service.

Le réseau Yammer est rattaché au nouveau tenant dès que le service est activé. Il existe deux types d'administrateurs sur Yammer :

• des administrateurs déclarés directement dans Yammer
• des administrateurs héritant de ces droits car ils possèdent le rôle administrateur général du tenant

Les premiers ne subissent aucune perte de droits pendant la migration. Cependant pour la seconde catégorie, il est nécessaire que les utilisateurs aient un compte avec le rôle administrateur général sur le nouveau tenant sinon ils perdront les droits d'administration de Yammer en plus des droits d'administration du tenant (on peut aussi les déclarés directement dans Yammer si on ne souhaitent plus qu'ils soient administrateurs du tenant).

Concernant Yammer Dirsync, comme ce dernier n'interagit pas avec Office 365 (il s'agit d'un second produit de synchronisation différent d'Office 365 Dirsync), il n'y a aucune manipulation à réaliser. Il en est de même pour la configuration du SSO via ADFS.

OneDrive

Concernant OneDrive, il faut, pour chaque utilisateur :

• Arrêter la synchronisation du dossier
• Désactiver l'utilisateur sur l'ancien tenant (myenterprise1)
• Créer son compte sur le nouveau tenant (provisionning manuel ou via Dirsync)
• Synchroniser le nouveau dossier personnel dans lequel on copiera le contenu qui aura été conservé en local sur la machine.
  

Il existe des outils payant si vous souhaitez automatiser le transfert des données entre les deux tenants. Néanmoins, il restera à reconfigurer le client OneDrive.

Conclusion

Contrairement à la migration du SSO et de la synchronisation Dirsync qui est plus structurée (bien qu'il n'existe pas non plus de procédure officielle), la migration de services Office 365 entre tenant est actuellement totalement manuelle et relève plus d'astuces que de réels procédures.

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

Microsoft est en train d’analyser l’existence d’une vulnérabilité dans SharePoint Services et SharePoint Server qui permet l’exécution de scripts arbitraires permettant d’effectuer une élévation des privilèges au niveau des sites SharePoint.

Les versions affectées par cette vulnérabilité sont :

• Microsoft Office SharePoint Server 2007 SP1 et SP2
• Microsoft Windows SharePoint Services 3.0 SP1 et SP2

Les deux architectures x86 et x64 sont affectées.

Pour plus de détail cliquer ici

L’erreur DCOM est une erreur qui apparait quasi systématiquement après l’installation et la configuration d’une plateforme MOSS 2007. Cette erreur apparait sur tous les serveurs de la ferme et à des intervalles réguliers.

Cette erreur est due au droit « LOCAL Activation » manquant sur certains objets DCOM pour les utilisateurs SharePoint et principalement les comptes utilisés pour les pools d’application qui font partie du groupe IIS_WPG.

Pour remédier à cette erreur procédez comme suit :

Ajoutez l’utilisateur “Service Réseau” (NETWORK Service)  au groupe “Utilisateurs du modèle COM distribué” (Distributed COM Users).

Accordez au groupe IIS_WPG les bons droits sur les composants IIS Admin Service et IIS WAMREG Admin Service

1 - Démarrez la console services de composants en exécutant : C:\Windows\System32\com\comexp.msc

ou

Cliquez sur Démarrer | Outils D’administration | Services de composants

2 - Réinitialisez la configuration de la sécurité des composants IIS Admin Service et IIS WAMREG Admin Service :

Cliquez sur le composant IIS Admin Service avec le bouton droit puis cliquez sur Propriétés.

Sélectionnez l’onglet Sécurité et positionnez toutes les autorisations à Par Défaut (Use Default) puis cliquez sur le bouton OK.

Important : Réalisez la même opération pour le composant IIS WAMREG Admin Service.

Cliquez sur le composant IIS Admin Service avec le bouton droit puis cliquer sur Propriétés.

Sélectionnez l’onglet Sécurité, au niveau de la section Autorisation d’exécution et d’activation ("Launch and Activation Permissions"), côchez Personnaliser ("Customize") puis cliquez sur Modifier ("Edit").

Ajoutez le groupe IIS_WPG et accordez-lui toutes les autorisations.

Au niveau de la section Autorisations d’accès ("Access Permissions"), côchez Personnaliser ("Customize") puis cliquez sur Modifier ("Edit").

Ajoutez le groupe IIS_WPG et accordez-lui toutes les autorisations.

Vérifier les droits de configuration pour le groupe Utilisateurs.

Au niveau de la section Autorisations de configuration ("Configuration Permissions") côchez Personnaliser ("Customize") puis cliquez sur Modifier ("Edit"). 

Vérifiez que le groupe Utilisateurs dispose des autorisations Lecture ("Read") et Autorisations Spéciales ("Special permissions").

Important : Réalisez la même opération pour le composant IIS WAMREG Admin Service.

A l'issue de cette procédure, l'erreur DCOM ne devrait plus ce produire !

Une vulnérabilité dans la sécurité d'Excel Services pour Microsoft Office SharePoint Server 2007 peut permettre à un code arbitraire de s'exécuter lors de l'ouverture sur le serveur d'un fichier qui a été modifié à des fins malintentionnées.

Une mise à jour de sécurité vient d’être publié le 05 mars 2010 afin de remédier à cette vulnérabilité.

La mise à jour est disponible en téléchargement en version 32 Bit et 64 Bit et elle concerne seulement les serveurs SharePoint 2007 sur les quels Excel Services est installé.

Pour de plus amples détail consulter le Bulletin de Sécurité MS10-017.

Symptômes

Après avoir installer MOSS 2007 et créer des applications Web et des sites  vous n’arrivez pas à explorer vos sites avec leurs noms d’hôtes sur le serveur MOSS lui même, par contre ils sont bien accessibles depuis n’importe quel autre serveur ou poste client.

Lorsque vous tapez l’adresse de votre site on vous demande de s’authentifier 3 fois de suite et vous recevez une page vierge au niveau de l’explorateur.

Pas de messages d’erreur enregistrés à l’exception du journal de sécurité qui présente une série d’événements 4625: An Account Failed to Logon

Ce comportement se manifeste sur le serveur Web lui même et ne concerne que les sites ayant des noms d’hôte.

Cause

Depuis le service pack 1 de Windows Server 2003 une fonctionnalité de sécurité a été intégré au système d’exploitation (LoopBack Check) afin d’empêcher les attaques par réflexion sur les serveurs Web.

Cette fonctionnalité provoque un échec d’authentification pour toute demande portant un nom d’hôte qui ne ne correspond pas au nom de la machine.       

Résolution

Pour remédier à ce problème on dispose de deux méthodes:

Méthode 1 : Désactiver la fonctionnalité LoopBack Check

• Ajouter une valeur DWORD nommée DisableLoopBackCheck ayant une valeur 1 à la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

•   Redémarrer le service d’administration d’IIS

Méthode 2 : Spécifier les noms d’hôtes en question

• Ajouter une valeur Multi-String nommée BackConnectionHostNames  à la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 et y tapez les noms d’hôtes de tous les sites dont l’authentification est Windows et qui présentent le problème.       

• Redémarrer le service d’administration d’IIS

Réflexion

Avant de passer à l’action il faut se poser la question si on considère ce comportement problématique ou non puisque les sites sont bien accessibles de n’importe quel serveur ou poste client et seulement inaccessibles depuis le serveur Web lui même.

Il faut bien avoir cette réflexion puisque la résolution de ce “faux” problème consiste à désactiver la fonctionnalité LoopBack Check ce qui constitue en lui même l’exposition du serveur à un risque de sécurité.

Parmi les deux méthodes de résolution la deuxième semble comme même plus adaptée étant données qu’elle nous permet de spécifier les sites pour les quels la fonctionnalité sera désactivée et qui peuvent être les sites les plus sécurisés de point de vue fonctionnalités et utilisation, ce qui nous permettra de minimiser l’exposition du serveur à ce genre de risques de sécurité.

Avant de procéder à la mise à niveau de vos systèmes d’exploitation il faudra vérifier la compatibilité des applications serveur avec Windows 2008 R2.

1. SQL Server
   1. SQL Server 2005 Service Pack 3 et plus
   2. SQL Server 2008 Service Pack 1 et plus
   3. SQL Server 2005 Express Edition Service Pack 2
   4. SQL Server 2008 Express RTM
   5. SQL Server 2008 R2 sera supporté H1 2010

1. Exchange
   1. Exchange 2010 version est supporté depuis Q4 2009

1. Office Servers
   1. Forms Server 2007 Service Pack 2 et plus
   2. Groove Server 2007 Service Pack 2 et plus
   3. PerformancePoint Server 2007 Service Pack 2 et plus sera supporté Q1 2010
   4. Project Server 2007 Service Pack 2 et plus
   5. SharePoint Server 2007 Service Pack 2 et plus
   6. Search Server 2008 Service Pack 2 et plus
   7. Search Server 2008 Express Service Pack 2 et plus

Pour la liste complète des applications voir Microsoft Server Applications Supported on Windows Server 2008 R2

Si vous avez installé récemment le SLD 2.0 et que vous n’êtes pas très familier avec Sharepoint (comme moi), vous allez rapidement vous apercevoir d’une consommation “anormale” de l’espace disque sur le disque système.

Cette consommation est due à la génération un peu trop fréquente de fichiers de logs.

On peut le constater en se rendant dans le dossier c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS:

Je vous conseille donc de réduire la génération des fichiers de logs en allant dans la console centrale d’administration Sharepoint,

puis “Operations” et “Diagnostic Logging”:

Modifier la section “Event Throttling” de manière à restreindre l’enregistrement des événements aux erreurs inattendues uniquement:

Si besoin, aller dans l’emplacement des fichiers de logs pour supprimer manuellement les fichiers obsolètes.

L’emplacement est mentionné sur la même page d’administration (Trace Log). Par défaut, il s’agit de “c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS”