PI Services

Pour créer notre package d’application virtualisée, vous devez installer une machine qui servira de référence.

Cette machine doit se rapprocher le plus possible en terme de configuration (registre, ..) de l’environnement sur lequel sera déployé votre application virtualisée.

Connectez-vous sur cette machine et installer le séquenceur App-V.

Les binaires sont disponibles dans la librairie VMM (Application Framework)

L’application permettant la capture est désormais installée.

Lancer l’application et cliquer sur Create a New Virtual Application Package

Cliquer sur Next

Sélectionner l’application à virtualiser. Dans notre exemple, nous allons installer Filezilla.

Cliquer sur Next

Donner un nom à votre Package et cliquer sur Next

L’installation démarre. Procéder à l’exécution de votre application avec les paramètres tel que vous désirez que ceux-ci soient capturés.

Une fois l’application installée, vous pouvez procéder à d’autres modifications sur la machine. Ceux-ci seront capturés.

Cliquer maintenant sur I am finished installing et cliquer sur Next

Cliquer sur Next

Cliquer sur Close

Vous avez maintenant fini de capturer votre application. Il faut maintenant sauvegarder votre projet.

Cliquer sur File et Save as

Le package est désormais créé. Il ne vous reste plus qu’à déplacer votre package dans la librairie VMM.

Dans ce blog, vous pourrez trouver un exemple d’une installation d’application virtualisée à travers un Update de service  de type In-Place dans VMM 2012

http://blog.piservices.fr/post/Mise-a-jour-de28099un-service-dans-SCVMM-2012.aspx

Il peut arriver que des scripts soient incapable d’appeler les cmdlet SCOM.

Dans mon cas, ce problème a été remarqué à cause du Management Pack Service Bus v1.1 et plus précisément à cause de la définition de son moniteur (UnitMonitorType) nommé Related Objects Health State, mais il aurait pu s’agir de n’importe quel script exécuté par un Management Pack ou non.

Il se traduisait ici par des évènements Error avec l’ID 4101 dans le journal d’évènements Operations Manager :

Managegement Group: xxx. Script: RelatedObjectsHealthStateMonitorScript\Main : Error occured during Related Objects Health State monitoring.

Computer:yyy

Reason: The term 'Get-SCOMRelationship' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Voyons comment fonctionne ce Monitor Type. Il est basé sur un script powershell qui commence par les commandes suivantes :

param($objectId, $relationshipId, $relatedObjectClassId, $relatedObjectMonitorId, $ignoreUnavailable, $ignoreInMaintenanceMode)
#TODO: Discuss event id
$SCRIPT_EVENT_ID = 4101 
#Event Severity values
$INFORMATION_EVENT_TYPE = 0
$ERROR_EVENT_TYPE = 1 
function GetRelatedObjectsHealthState7Version
{
param
(
$objectId,
$relationshipId,
$relatedObjectClassId,
$relatedObjectMonitorId,
[bool]$ignoreUnavailable,
[bool]$ignoreInMaintenanceMode
)
Import-Module -Name "OperationsManager"
$constUnintializedHealthState = "Uninitialized"
$constSuccessHealthState = "Success"
$constWarningHealthState = "Warning"
$constErrorHealthState = "Error"
#
# Get Relationship
#
$relationship = Get-SCOMRelationship -Id $relationshipId
if($relationship -eq $null)
{
$exceptionMsg = "Relationship with Id {0} not found." -f $relationshipId
$argumentException = New-Object System.ArgumentException -ArgumentList $exceptionMsg 
throw $argumentException
}

Les premières cmdlet SCOM réellement exécutées sont celles surlignées en jaune , les autres lignes ne sont que des définitions de variables ou des appels indépendants de SCOM.

Or, l’évènement indique un échec dès l’appel du cmdlet Get-SCOMRelationship : Reason: The term 'Get-SCOMRelationship' is not recognized as the name of a cmdlet, function, script file, or operable program.

On peut donc supposer qu’en réalité, le script n’a pas été en mesure de charger le module OperationsManager et qu’il ne reconnait donc pas le cmdlet.

On constate également que l’import manuel du module OperationsManager dans un shell PowerShell échoue.

Vérifions donc qu’il est bien présent sur le serveur où remonte l’alerte. Il doit se trouver dans le dossier d’installation de SCOM, sous-dossier Powershell > OperationsManager :

Le module existe bien.

Vérifions maintenant qu’il est bien enregistré dans la variable d’environnement $env:PSModulePath :

Manifestement, il est bien enregistré… Mais pas au bon endroit !

En effet, la variable d’environnement pointe vers C:\Program Files\System Center 2012\Operations Manager\Powershell\ alors que le module se trouve en réalité dans C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager !

La solution est alors toute trouvée : rajouter le bon chemin à la variable d’environnement à l’aide des commandes suivantes :

$originalpaths = (Get-ItemProperty -Path ‘Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment’ -Name PSModulePath).PSModulePath

$newPath=$originalpaths+’;C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\’

Set-ItemProperty –Path ‘Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment’ -Name PSModulePath –Value $newPath

Il ne reste plus qu’à redémarrer le serveur pour que la modification soit prise en compte et le problème résolu !

Lors de l’envoi d’un email dans Orchestrator à l’aide de l’activité Send Email, il est possible de choisir entre de choisir entre le format texte brut et le format HTML pour le corps du mail, dans l’onglet Advanced :

Il devient alors tout naturel de vouloir y intégrer des images à l’aide de la balise HTML <img> , afin d’enrichir encore la mise en page.

Il est alors possible d’avoir recours à plusieurs méthodes : la plus classique consiste à stocker ces images à un endroit accessible par tous les destinataires du mail (site web, partage réseau…) ; mais cette technique présente différents inconvénients : les images sont inaccessibles si l’accès à la source n’est pas disponible au moment de la lecture du mail, la plupart des clients mail bloquent leur chargement par défaut…

Une autre solution consiste à intégrer directement ces images dans les pièces jointes, et à les appeler à l’aide d’un Content ID (CID) au lieu d’un lien réseau ou http, à l’aide de la syntaxe suivante : <img src=’’cid:nomdelimage.jpg’’ />

Et c’est tout, les images seront désormais visibles dans le corps du mail. Encore mieux : selon le client mail utilisé, elles n’apparaitront même pas dans les pièces jointes !

Assurez-vous toutefois bien que le serveur Orchestrator soit lui toujours en mesure d’accéder aux images, il les recharge à chaque appel de l’activité Send Email.

Introduction

Exchange bénéficie d'un grand nombre de cmdlet Powershell très abouties et permettant de configurer et d'administrer l'intégralité d'une infrastructure de messagerie. Aussi, celles-ci sont très utiles dans le cas de scripts de provisionning. J'ai rencontré une erreur lorsque je cherchais à créer et à configurer un grand nombre de boites aux lettres de ressources.

Contexte

L'environnement dans lequel j'ai découvert ce problème est une forêt mono domaine Active Directory avec une infrastructure Exchange 2010 SP3 dans laquelle il y avait plusieurs contrôleurs de domaine dans le même site Active Directory que la totalité des serveurs de messagerie.

Plus globalement, cette erreur pourra être rencontrée dès qu'un serveur Exchange pourra être amené à interroger plus d'un contrôleur de domaine.

Erreur rencontrée

Dans un script de provisionning de boîtes aux lettres, on cherche à les créer mais aussi à les configurer. Si l'on souhaite configurer une boite aux lettres tout de suite après sa création alors on obtient une erreur similaire à celle ci-dessous (“ObjectNotFoundException”) :

Cela peut se retrouver en exécutant l'exemple suivant :

Une ou plusieurs opérations de modification (de type Set-…) vont échouer avec le message d'erreur cité précédemment.

Explication

Suite à cette erreur, il est logique de penser que cela est dû à l'interrogation de différents contrôleurs de domaine qui n'ont pas encore répliqué entre eux (Une réplication intra site peut prendre quelques secondes).

Aussi, on peut se dire qu'il suffit alors de spécifier le paramètre DomainController pour corriger le problème en l'indiquant sur toutes les commandes et en définissant un contrôleur de domaine unique qui traitera toutes les opérations.

Cependant, cela ne corrigera pas le problème. Microsoft en donne l'explication dans les fiches Technet des cmdlets :http://technet.microsoft.com/en-us/library/dd335046.aspx.

Le paramètre DomainController ne concerne que le contrôleur de domaine qui va écrire les modifications dans Active Directory. Cependant, un autre contrôleur de domaine  peut être utilisé pour lire l'objet avant d'écrire les changements sur celui spécifié en paramètre.

Aussi, pour une cmdlet de type Get-… (lecture), le paramètre DomainController sera bien le contrôleur de domaine sur lequel l'objet sera lu (cela sera utile pour mettre en place l'une des solutions proposées).

Solution

Pour résoudre ce problème,  il faut donc attendre que la réplication ait eu lieu sur la totalité des contrôleurs de domaine du site Active Directory de l'infrastructure Exchange. Pour cela, nous avons trois solutions.

Solution 1 :

Il est possible de séparer la création des boîtes aux lettres et leurs configurations. Cette solution oblige donc a réaliser le provisioning en plusieurs phases.

Solution 2 :

On peut définir un délai entre l'opération de la cmdlet de création et la cmdlet de configuration via un Start-Sleep par exemple. Cependant, cette solution ne garantit pas que les opérations vont toutes se dérouler correctement. Il faudra sans doute que le délai soit important pour que le provisioning ait un taux de réussite élevé et donc augmenter considérablement le temps d'exécution du script.

Solution 3 :

La dernière solution est une combinaison des deux précédentes puisqu'elle permet de n'avoir qu'une seule phase de provisioning tout en ayant un temps d'exécution relativement rapide.

Cette solution consiste à implémenter une boucle de test de l'opération à réaliser sur le même contrôleur de domaine via la cmdlet de lecture (Get-…).

Exemple :

Il est possible d'ajouter une courte pause entre chaque test afin de ne pas surcharger le processus sans pour autant trop pénaliser le temps d'exécution du script. Le paramètre ErrorAction permet d'alléger l'affichage car on connait déjà l'erreur que l'on va rencontrer.

Il ne vous reste plus qu'à choisir la solution que vous préférez.

Contexte

Sur un serveur Exchange 2013 (CU8), le service Microsoft Exchange Search Host Controller ne démarre pas et dans le journal d’évènements l’erreur suivante est présente :

Source : Application Error
Evènement : 1000
Nom de l’application défaillante hostcontrollerservice.exe 

Solution

Le problème semble provenir d’une corruption des fichiers du dossier <X:>\Program Files\Microsoft\Exchange Server \V15\Bin\Search\Ceres\HostController\Data.

Il existe un script Exchange qui reconstruit ce dossier. Pour ce faire, renommez l’ancien dossier Data en DataOld.

Puis lancez les commandes suivantes dans une console PowerShell Exchange :

• cd X:\Program Files\Microsoft\Exchange Server \V15\Bin\Search\Ceres\Installer
• .\installconfig.ps1 –action –i –dataFolder X:\Program Files\Microsoft\Exchange Server \V15\Bin\Search\Ceres\HostController\Data

La commande renvoi un Successfully configured Search Foundation for Exchange.

Le service a normalement démarré automatiquement.

Contexte

Sur un serveur Exchange 2013 CU6, le service Microsoft Exchange Replication ne démarre pas et dans le journal d’évènements l’erreur suivante est présente :

Source : MSExchangeRepl
Event ID : 4401
Microsoft Exchange Server Locator Service failed to find active server for database <MailboxDatabase GUID>. Error: An Active Manager operation failed. Error: Invalid Active Manager configuration. Error: Active Manager hasn't completed configuration initialization.

De plus la commande Get-MailboxDatabaseCopyStatus renvoie toutes les bases en ServiceDown.

Solution

Ce problème provient d’anciennes entrées corrompues dans le journal d’évènements (dans le crimson channel log plus précisément).

L’installation du CU7 d’Exchange 2013 résout ce problème. Cependant si vous souhaitez résoudre le problème sans passer le CU7, suivez la procédure ci-dessous.

Depuis un invite de commande (en administrateur) lancez la commande suivante :

Wevtutil.exe cl “Microsft-Exchange-MailboxDatabaseFailureItems/Operational”

Le service redémarre automatiquement et les réplications entre les MailboxDatabases reprennent normalement.

Nous avons une VM associée à un service. Nous allons ici mettre à jour le service en installant une application virtualisée : SumatraPDF

Notre service nommé Generic Server 2K12 a été installé à partir du service Template ST –Generic Server 2K12.

Pour mettre à jour notre service, nous allons dupliquer le service Template ST –Generic Server 2K12, effectuer notre modification sur celui-ci et ensuite l’appliquer à notre service en production.

Aller sur le service Template à éditer

Faites un clic droit et cliquer Copy

Une copie apparait dans la console.

Sur celui-ci à l’aide d’un clic droit allez dans Open Designer

La fenêtre d’édition du service Template apparait

Double-cliquer sur votre service Template

Aller dans la section Application Configuration et cliquez sur Add et sélectionner Virtual application

Cliquez sur Browse

Sélectionner votre Package. Pour l’exemple, nous allons sélectionner notre package correspondant à SumatraPDF.

Cliquez sur OK.

Donnez un nom à votre application virtuelle et cliquez sur ok.

Cliquez maintenant sur Save and Validate.

Faites maintenant un clic droit sur le service Template dupliqué et cliquer sur Publish.

Nous allons maintenant appliquer notre service Template sur le service en production.

Remarque : pour que la modification apportée sur le service soit effective, il faut que la/les VM présente sous le service dispose(nt) de l’agent App-V. (Celui-ci est présent dans la librairie VMM)

Affichez les services et faites un clic droit sur le service à updater et sélectionner Set Template

Cliquez sur Browse pour sélectionner le service précédemment configuré.

Cliquer sur Next

Sélectionner Apply updates to existing to virtual machines in-place et cliquer sur Next.

Cocher la case Apply the updates et cliquer sur Next puis sur Finish

Le job se lance.

Une fois celui-ci finit, rendez vous sur la / les VMs concernés.

SumatraPDF s’est bien installé sur l’ensemble des VMs de notre service.

Introduction

Cet article est un retour d'expérience sur un incident rencontré dans le cadre d'une infrastructure ADFS possédant une fédération avec Yammer. Ce dernier s'est produit lors du renouvellement de certains certificats de l'environnement ADFS. L'authentification unique n'était plus fonctionnelle. En effet, une mise à jour doit être réalisée du côté de Yammer lorsque l'un des certificats ADFS est renouvelé. Pour rappel, contrairement à d'autres services qui peuvent être fédérés (comme Office 365), il n'est pas possible de configurer automatiquement le SSO. Cette opération doit être réalisée via une demande au support Office 365.

Dans un premier temps, il sera question de faire quelques rappels sur les certificats ADFS puis d'étudier leurs renouvellements. Enfin, nous verrons comment mettre à jour Yammer pour que le l'authentification ne soit pas indisponible lorsque les certificats sont renouvelés. Ce dernier nous permettra de voir comment gérer les certificats avec des services fédérés qui ne peuvent pas récupérer les métadatas automatiquement.

Cette manipulation a été réalisée sur une infrastructure sous Windows 2012 R2 (ADFS 3.0).

ADFS

Dans une infrastructure ADFS, 3 certificats sont nécessaires au bon fonctionnement de celle-ci :

• Un certificat public portant le nom DNS du service de fédération. Il s'agit d'un certificat web permettant de sécuriser les communications via SSL.

• Un certificat auto-généré de type X.509 permettant de signé les tokens d'authentification (Token-Signing). Celui-ci permet de certifier que le token provient bien de la ferme ADFS.

• Un certificat auto-généré de type X.509 permettant de décrypter des tokens (Token-Decrypting) provenant d'un autre fournisseur de revendications.

Renouvellement du certificat Service-Communications

Le renouvellement pour le certificat public de type Service-Communications se fait manuellement. Lorsque vous posséder votre nouveau certificat, il est nécessaire de l'importer dans le magasin personnel de l'ordinateur des serveurs ADFS (comme lors de la configuration d'ADFS) et des serveurs Web Application Proxy (si vous en posséder) .

Sur les serveurs ADFS, lorsque le certificat est importé, il faut ajouté les permissions de lecture sur la clé privée. Pour réaliser cette opération, il faut effectuer un clic droit sur le certificat (lorsque l'on se trouve dans le magasin personnel de l'ordinateur) puis choisir “All Tasks” puis “Manage Private Keys”.

Dans l'onglet sécurité, il suffit d'ajouter les comptes “NT Service\ADFSSRV” et “NT Service\DRS” (pour la fonctionnalité Workplace Join) puis d'attribuer le droit “Read”. Attention, cette opération est à réaliser sur l'ensemble des serveurs de la ferme ADFS.

Les commande Powershell ci-dessous nous permettent ensuite de mettre à jour la configuration des serveurs ADFS.

Sur les serveurs ADFS :

On récupère, le certificat en utilisant la commande suivante :

Cette dernière permet d'interroger le magasin personnel de l'ordinateur (pensez à remplacer NOM_DNS_FERME_ADFS par le nom de votre ferme de serveurs ADFS). Il est nécessaire de récupérer la valeur de l'attribut thumbprint (Pour rappel, ce champ est unique pour chaque certificat).

Ensuite, on modifie la configuration du service ADFS pour utiliser notre nouveau certificat en spécifiant la valeur de l'attribut thumbprint.

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

Sur chacun des serveurs ADFS d'une ferme, il faut exécuter la commande ci-dessous pour mettre en place le bindings HTTPS avec le nouveau certificat :

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

Enfin, il est nécessaire de redémarrer le service ADFS sur chacun des serveurs de la ferme.

On peut ensuite vérifier les valeurs grâce aux commandes suivantes :

La seconde cmdlet doit être exécuté sur chacun des serveurs de la ferme ADFS pour effectuer une vérification complète.

Les serveurs Web Applications Proxy se mettent à jour via les commandes suivantes :

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

Tout d'abord on change le certificat. Dans un second temps, on redémarre le service ADFS pour que le changement de configuration soit pris en compte. Ces deux commandes sont à exécuter sur chacun des serveurs Web Applications Proxy que vous possédez.

Renouvellement des certificats Token-Signing et Token-Decrypting

Au sujet, des autres certificats, il existe deux possibilités :

• Renouvellement manuel

• Renouvellement automatique

Le renouvellement automatique est la configuration par défaut d'ADFS. 20 jours avant l'expiration d'un certificat, ADFS en génère un nouveau. Celui-ci possède le statut de certificat secondaire. Au bout de 5 jours (soit 15 jours avant l'expiration du certificat), il est promu comme certificat primaire.

Les paramètres d'auto renouvèlement se consultent/configurent via Powershell. Pour cela, il faut utiliser la commande “Get-ADFSProperties”. C'est l'attribut AutoCertificateRollover qui permet de déterminer si l'auto renouvèlement des certificats de type Token-Signing et Token-Decrypting est activé.

Voici les paramètres ADFS qui peuvent être modifiés par la commande Set-ADFSProperties et qui concernent le mécanisme évoqué précédemment :

• CertificateDuration : Durée de validité d'un certificat auto généré (par défaut : 365 jours)

• CertificateGenerationThreshold : Nombre de jours avant la génération d'un nouveau certificat Token Signing or Token Decrypting (par défaut 20).

• CertficatePromotionThreshold : Nombre de jours avant la promotion du nouveau certificat (passage du status Secondary au status Primary, valeur par défaut : 5 jours).

• CertificateRolloverInterval : Interval de temps (en minutes) entre chaque vérification de la validité d'un certificat (par défaut 720 minutes).

• CertificateCriticalThreshold : Nombre de jours avant qu'un certificat expire et qu'un renouvèlement critique ne soit déclenché (ce paramètre intervient lors d'un problème avec le système d'auto renouvellement).

Point d'attention :

Lors du renouvèlement d'un certificat, les métadatas changent. Aussi, si l'un des relying party trust n'est pas capable de récupérer par lui même les métadatas alors l'authentification ne sera plus fonctionnelle.

Yammer

La configuration de l'authentification unique via Yammer se fait manuellement. Il est nécessaire d'ouvrir un ticket auprès du support. Celle-ci ne nécessite pas d'envoyer les certificats mais simplement les métadatas. Néanmoins lorsque les certificats ADFS se renouvèlent, il est nécessaire de les transmettre au support Yammer via une demande de service sur le portail d'administration Office 365. Pour se faire, il suffit de créer une archive contenant les nouveaux certificats et de les joindre…

Cependant, il peut arriver que le délais soit trop court pour que le ticket soit traité à temps par le support si l'on se trouve presque à la fin de la période de 5 jours après le renouvellement des certificats (voir paragraphe précédent) ou pire, si le nouveau certificat a déjà été défini comme certificat primaire. Ce dernier cas aura pour effet de couper totalement l'authentification unique auprès de Yammer et ainsi causé une coupure de service pour les utilisateurs. En effet, Yammer n'est pas capable de récupérer les nouvelles métadatas contenant les nouvelles informations des certificats.

Dans ce cas, on obtient l'erreur ci-dessous lorsque l'on essaie de s'authentifier :

De plus dans l'observateur d'évènements, on remarque des events avec l'id 364 avec pour message :

Lorsque ce problème est rencontré, il faut transmettre le nouveau certificat au support Office 365, ce qui peut peut demander un temps de traitement long. Cependant, si l'ancien certificat est encore valide (c'est à dire qu'il est passé en statut secondaire), il existe une méthode pour rétablir le service temporairement pendant la durée de validité dudit certificat. Pour ce faire, il faut repasser le certificat en statut primaire. Cette opération peut être réalisée via la console graphique.

Dans la console ADFS Management, il faut se rendre dans la section “Service” puis “Certificate” puis effectuer un clic droit sur le certificat concerné et choisir l'option “Set as Primary”. Celle-ci peut être grisée. Cela survient lorsque le renouvellement automatique est activé. Il faut donc le désactiver temporairement via la commande suivante :

Lorsque le certificat sera de nouveau en statut primaire, le service sera rétabli. Attention, n'oubliez pas de changer le certificat primaire lorsque le support Office 365 vous aura informé de la prise en compte du nouveau certificat.

Aujourd’hui mon blog va porter sur l’erreur WINRM : 2147749890                    que l’on peut retrouver sur tout les serveurs de :                                                                                                                                 - Windows 2003 SP2 à Windows 2012 R2. Même en regardant dans l’observateur d’évènement ID 4 qui correspond à une solution TechNet qui n’est pas adapter à la situation.

PERIMETRE: Dans le cadre de l’organisation des reboots de serveurs chez un de nos client, j’ai mis en place une vérification Post-démarrage de ces serveurs.

Voici la commande du script powershell qui permet de vérifier si le service MSDTC commun à tout les serveurs de Windows 2003 SP2 à Windows 2012 R2.

MON SCRIPT DE BASE:

######SERVEURS A REDEMARRER################

$Computerdestination = "SRV02"

###SERVICES A ARRETER, REDEMARRER ou VERIFER##

$Servicesname = "MSDTC"

######LOG CREER POUR LA VERIFICATION DES SERVICES SUR CHAQUES SERVEURS + GESTION ERREUR ###

$StatusSvcRebootSRV = $NULL                                                                                $StatusSvcRebootSRV =

try {

Invoke-Command -ScriptBlock {param($ServicesName) Get-Service $ServicesName -ErrorAction stop | select PScomputerName,Status,Name   } -ArgumentList $ServicesName -ComputerName $Computerdestination 

}catch{

"error : " + $error[0]

}       

#GESTION ERREUR DES SERVICES

$ExitCodeService =

try {

if ($($StatusSvcRebootSRV.Status.value) -eq "Running") {

"success : $Computerdestination or $Servicesname"    

} else {

"error : " + $error[0]

}

}catch{

"Error : Syntaxe command ExitCodeService "

}   

$ExitCodeService

RESULTAT: malgré winrm activer et enable-psremoting + port 5985 ok

-SessionOption (New-PSSessionOption -NoMachineProfile) qui a permis de résoudre le problème

MON SCRIPT CORRIGE BASE:

######SERVEURS A REDEMARRER################

$Computerdestination = "SRV02"

###SERVICES A ARRETER, REDEMARRER ou VERIFER##

$Servicesname = "MSDTC"

######LOG CREER POUR LA VERIFICATION DES SERVICES SUR CHAQUES SERVEURS + GESTION ERREUR ###

$StatusSvcRebootSRV = $null

$StatusSvcRebootSRV =

try {

Invoke-Command -ScriptBlock {param($ServicesName) Get-Service $ServicesName -ErrorAction stop | select PScomputerName,Status,Name   } -ArgumentList $ServicesName -ComputerName $Computerdestination -SessionOption (New-PSSessionOption -NoMachineProfile)

}catch{

"error : " + $error[0]

}       

#GESTION ERREUR DES SERVICES

$ExitCodeService =

try {

if ($($StatusSvcRebootSRV.Status.value) -eq "Running") {

"success : $Computerdestination or $Servicesname"

                                    } else {

"error : " + $error[0]

                                    }

}catch{

"Error : Syntaxe command ExitCodeService "

}   

$ExitCodeService

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.