PI Services

Le blog des collaborateurs de PI Services

SCOM – Requête SQL des Heartbeat Failure par Primary Management Server

 

La requête ci-dessous permet de lister depuis la base OperationsManager, avec un paramètre J-n, les alertes Heartbeat Failure des agents, par Primary Server, en affichant la durée de l’alerte, son eventuel ticket associé, son status et le status du maintenance mode de l’objet.

 

 

/****** HEARTBEAT FAILURE FOR AGENTS PRIMARY MANAGED BY SPECIFIC MS WITH DURATION, STATUS AND OBJECT MAINTENANCE MODE STATUS ******/

Use OperationsManager

DECLARE @PrimaryServer	VARCHAR(50)
DECLARE @startdate	datetime
DECLARE @Offset	int
DECLARE @enddate	datetime
DECLARE @seconds int
DECLARE @AlertPattern VARCHAR(50)
DECLARE @TicketPattern VARCHAR(50)

SET @PrimaryServer = 'MyPrimaryMS' – Provide a name of Primary if you need to filter on.
SET @enddate = GETDATE()
SET @Offset = 4 – Provide number of days to look back (limited to operational db retention
SET @startdate = DATEADD(day,-@Offset,@enddate)
SET @AlertPattern = 'heartbeat'
SET @TicketPattern = 'Ticket_Number'	-- Provide string pattern that must be found in each ticket


;

WITH 
PrimaryRelation (SourceEntityId,agent,PrimaryServer,TargetEntityId)
AS
(
SELECT R.SourceEntityID,SourceBME.DisplayName as Agent,TargetBME.DisplayName as PrimaryServer, R.TargetEntityID
FROM Relationship R WITH (NOLOCK) 
JOIN BaseManagedEntity SourceBME 
ON R.SourceEntityID = SourceBME.BaseManagedEntityID 
JOIN BaseManagedEntity TargetBME 
ON R.TargetEntityID = TargetBME.BaseManagedEntityID 
WHERE R.RelationshipTypeId = dbo.fn_ManagedTypeId_MicrosoftSystemCenterHealthServiceCommunication() 
AND TargetBME.IsDeleted <> '1'  -- AND THE PRIMARY SERVER IS NOT WAITING TO BE DELETED
AND SourceBME.IsDeleted <> '1' -- AND THE AGENT IS NOT WAITING TO BE DELETED
)


-- Get alert

SELECT
PrimaryServer 
,AlertStringName
,MonitoringObjectDisplayName AS Computer
,(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)) as DownDateTime
,(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)) as RestoredDateTime

,Duration = (
	SELECT CONVERT(varchar, (DateDiff (s, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)), (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)))) / 86400 ) + ' days ' + 
	CONVERT(varchar, (DateDiff (s, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)), (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)))) % 86400 / 3600) + ' hours ' +
	CONVERT(varchar, (DateDiff (s, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)), (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)))) % 86400 % 3600 / 60) + ' min ' +
	CONVERT(varchar, (DateDiff (s, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)), (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)))) % 86400 % 3600 % 60 % 60) + ' sec ' 
	
	)

,TicketID = CASE
	WHEN TicketID is null THEN 'NO_TICKET'
	WHEN TicketId not like '%'+@TicketPattern+'%' THEN 'NO_TICKET'
	ELSE TicketID
	END
,Alert_ResolutionState = CASE
	WHEN AV.ResolutionState = '255' THEN 'Closed'
	WHEN AV.ResolutionState = '254' THEN 'Resolved'
	WHEN AV.ResolutionState = '251' THEN 'Blackout'
	WHEN AV.ResolutionState = '250' THEN 'Scheduled'
	WHEN AV.ResolutionState = '249' THEN 'Acknowledge'
	WHEN AV.ResolutionState = '248' THEN 'Assigned to Engineering'
	WHEN AV.ResolutionState = '247' THEN 'Awaiting Evidence'
	WHEN AV.ResolutionState = '3' THEN 'Notified'
	WHEN AV.ResolutionState = '0' THEN 'New'
	END
,'Object_was_InMM' = CASE
	WHEN av.MonitoringObjectInMaintenanceMode = '0' THEN 'NO'
	WHEN av.MonitoringObjectInMaintenanceMode = '1' THEN 'YES'
	END
FROM [dbo].[AlertView] av
INNER JOIN [OperationsManager].[dbo].[MTV_HealthService] as MTV_HS on MTV_HS.DisplayName = MonitoringObjectDisplayName
INNER JOIN PrimaryRelation on PrimaryRelation.SourceEntityId = MTV_HS.BaseManagedEntityId
WHERE name like '%'+@AlertPattern+'%'
AND (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)) between DATEADD(day,-@Offset,@enddate) and @enddate
--AND PrimaryServer like '%'+@PrimaryServer+'%' -- Uncomment to see agents managed from specific primary server

Quest RUM : Bien préparer ses machines avant une migration

Bonjour à tous !

Comme vu dans le billet précédent, la plupart des erreurs rencontrées sur RUM proviennent plus de votre infrastructure (IP manquantes/non à jour dans les zones DNS, découverte réseau Windows désactivée, ...) que de RUM en lui même.

Afin de minimiser ces erreurs, sur les postes concernés par la migration, il convient de mettre en place un certain nombre de pré-requis que nous allons détailler ci-dessous.

Les pré-requis

Droits d'accès administratifs sur les postes de travail

Le serveur RUM utilise deux comptes de services distincts :

  • Le compte de service du service RUM Controller
    • Il correspond au compte renseigné lors de l'installation du logiciel RUM
    • Il peut être configuré depuis la console RUM en allant dans le menu Tools -> Manage Controller Credentials

  • Le compte de service du service Dell Migration Manager RUM Agent Service
    • Il correspond au compte utilisé par l'agent RUM quand il est installé sur un poste
    • ll peut être configuré depuis la console RUM en allant dans le menu Project -> Manage Domains Credentials

Le compte de service du service Controller RUM doit faire partie du groupe local Administrateurs du serveur RUM.

Le compte de service du service Dell Migration Manager RUM Agent Service doit faire partie du groupe local Administrateurs sur tous les postes devant être migrés.

Le firewall Windows/d'Entreprise

Pour la liste complète des ports, je vous renvoie à ce lien : What firewall ports need to be opened for Migration Manager for AD / Resource Updating

Pour la partie qui nous intéresse, à savoir le poste à migrer, il faut bien entendu une connectivité à minima vers les serveurs Active Directory des domaines sources et cibles.

La liste des ports à ouvrir entre un poste client et un serveur RUM est quelque peu longue, la faute au RPC Dynamique.

Vous devrez donc ouvrir de manière bi-directionnelle, entre un poste et un serveur RUM, les ports suivants :

  • 135-139
  • 445
  • 1024-65535

La résolution de noms d'hôtes

Le poste doit être capable de résoudre les noms d'hôtes pour les domaines sources et cibles donc il faut penser à ajouter des redirecteurs conditionnels sur les serveurs DNS utilisés par vos postes clients.
Une fois les redirecteurs mis en place, la résolution de nom FQDN est assurée sur les postes ciblés.

Mais RUM utilisant également des noms d'hôtes courts, le poste doit être capable de les résoudre aussi.

Pour cela, il faut configurer sur les postes ciblés le paramètre de Liste de recherche de suffixes DNS comme ceci :

  • Nom de domaine du domaine AD source
  • Nom de domaine du domaine AD cible

Astuce : Ce paramètre peut aussi être mis en oeuvre sur votre serveur RUM si vous voulez travailler avec des noms d'hôtes courts (non FQDN).

Les services Windows

Sur les postes à migrer, les services Windows suivants doivent être démarrés et configurés en mode Démarrage automatique :

  • Server
  • Workstation
  • Netlogon
  • Remote Procedure Call
  • Remote Procedure Call Locator
  • Remote Registry
  • Function Discovery Provider Host
  • SSDP Discovery
  • UPnP Device Host

Mise en place des pré-requis

Deux méthodes peuvent être utilisées afin de mettre en place les pré-requis décrits précédemment :

  • Par GPO
  • Par script

Par GPO

Voici un exemple de GPO pouvant être déployée sur les postes du domaine source :

Par Script

Voici un exemple de script pouvant être utilisé sur les postes du domaine source :

A savoir : La commande net localgroup ne supporte pas l'ajout d'un groupe étant composé de plus de 20 caractères (NET.EXE /ADD command does not support names longer than 20 characters)

REM Set startup type for services
sc config RpcSs start= auto
sc config SSDPSRV start= auto
sc config upnphost start= auto
sc config fdPHost start= auto
sc config RpcLocator start= auto
sc config Netlogon start= auto
sc config RemoteRegistry start= auto
sc config LanmanServer start= auto
sc config LanmanWorkstation start= auto

REM Start services
net start RpcSs
net start SSDPSRV
net start upnphost
net start fdPHost
net start RpcLocator
net start Netlogon
net start RemoteRegistry
net start LanmanServer
net start LanmanWorkstation

REM Disable Firewall on Domain profile
netsh advfirewall set DomainProfile state off

REM Add group to local Administrators group
net localgroup Administrateurs XXX\CORP-QUEST-ADMIN /ADD

REM Set DNS Suffix Search list
REG ADD HKLM\System\CurrentControlSet\Services\TCPIP\Parameters /v SearchList /t REG_SZ /f /d "domaine_source_fqdn,domaine_cible_fqdn"

 

Quest RUM : Les erreurs les plus courantes

Bonjour à tous !

Aujourd'hui nous allons voir quelles sont les erreurs les plus courantes lorsque vous travaillez avec Quest RUM (Resource Updating Manager) et quelles sont leurs solutions.

C'est parti !

The RPC Server is unavailable

Derrière son nom trivial qui indique que le serveur RPC de la machine que vous essayez de joindre n'est pas disponible, vous pouvez avoir deux comportements :

  • L'erreur arrive juste après un Discovery/Processing/Move : RUM n'arrive pas à résoudre le nom de l'hôte. Vérifiez si le poste est bien référencé dans les DNS configurés sur votre serveur RUM.
  • L'erreur arrive environ 20/30 secondes après un Discovery/Processing/Move : RUM arrive bien à résoudre le nom de l'hôte mais celui-ci n'est pas joignable. Vérifiez en priorité que le pare-feu Windows est correctement configuré ou désactivé et vérifiez si la découverte réseau Windows est bien activé dans les options du Centre Réseau et Partage.

En dernier, comme son nom l'indique, vous pouvez toujours vérifier si le service Serveur RPC est bien lancé mais c'est le cas le moins souvent rencontré.

Access is denied

L'erreur indique le poste est joignable mais que le serveur RUM n'arrive pas à atteindre le partage administratif du poste ciblé pour y effectuer ses opérations.

Bien qu'étant assez générique, cette erreur se rencontrera surtout lors des trois cas suivants :

  • La découverte réseau Windows n'est pas active sur le poste ciblé
  • Le serveur RUM ne contacte pas la machine voulue car l'IP de la machine ciblée n'est pas à jour dans les serveurs DNS utilisés
  • La machine ciblée n'est pas dans le domaine renseigné (déjà migrée ou autre domaine)

Log path RUM_Server_Name is not accessible

L'erreur indique que l'agent RUM sur le poste n'arrive pas à contacter le serveur RUM ou/et n'arrive pas à accéder au partage QuestResourceUpdatingLogs$ pour y transférer ses logs.

Vous êtes plus susceptible de rencontrer cette erreur si votre poste et le serveur RUM sont dans des domaines différents. Bien souvent, cela indique que le poste n'arrive pas à résoudre le nom du serveur RUM car l'agent utilise le nom d'hôte court du serveur et non son nom FQDN pour le contacter.

Dans ce cas, la solution consiste à vérifier dans la liste de recherche de suffixes DNS Windows si le nom de domaine du serveur RUM est bien présent.

The network path was not found

De manière générale, cette erreur concerne plus les problèmes de résolution de nom NetBIOS des postes, cela étant dit, vous pouvez rencontrer également les deux comportements suivants :

  • L'erreur se produit lors d'un Discovery/Processing alors que le poste était joignable juste avant : Le poste a été éteint entre temps ou son IP n'est pas à jour dans les DNS
  • L'erreur se produit lors d'un Move : Il faut désactiver la recherche LMHOSTS dans les paramètres TCP/IP avancés du poste ciblé

A security package specific error occurred

Cette erreur se produit lors d'un Discovery. Une installation manuelle de l'agent RUM se terminera par la même erreur sur le poste ciblé.

La solution la plus souvent appliquée est d'utiliser l'IP du poste plutôt que son FQDN pour faire le Discovery.

The parameter is incorrect

Cette erreur se produit lors d'un Move.

Elle peut être rencontrée lorsque le serveur RUM contacte un contrôleur de domaine sous Windows Server 2012 R2 pour migrer le poste dans le domaine cible.

Deux solutions à ce problème :

  • Utiliser un contrôleur de domaine non 2012 R2 pour effectuer la bascule (voir l'article Définition des contrôleurs de domaine préférés)
  • Ne pas utiliser l'option "Create the computer object in this OU in the target domain" mais les attributs RestrictedKrbHost/ComputerName SPN ne seront pas repris pour l'objet ordinateur migré

Office 365 - Nouvelle interface d'administration pour Skype for Business et Teams

Depuis quelques temps Microsoft propose une nouvelle interface d'administration pour Skype for Business et Teams.

Pour y accéder vous pouvez utiliser le lien suivant : https://adminportal.services.skypeforbusiness.com/analytics/home

2017-11-24_151049

Pour le moment toutes les fonctionnalités annoncées ne sont pas encore actives. Cependant on peut déjà analyser les appels passés via Skype Online !

2017-11-24_151427

Sur un appel / une conférence de mauvaise qualité il est possible de voir quel utilisateur a eu des problèmes.

2017-11-24_151650

Tout comme dans Skype for Business OnPremise les rapports nous permettent d’avoir des informations précises sur l’incident (micro de mauvaise qualité, jitter trop élevé, nombre de paquet perdu…).

2017-11-24_151810

2017-11-24_151856

Vivement la suite des fonctionnalités !

Office 365 - Script de récupération des fonctionnalités O365 pour l'ensemble des utilisateurs

Contexte

Dans un environnement Office 365 il peut être nécessaire de savoir quelles fonctionnalités (Exchange, Skype, Yammer...) sont actives sur les utilisateurs.

Script

J'ai écrit le script suivant afin de récupérer automatiquement ces informations :

Get-UsersO365Features.ps1 (6,44 kb)

Pré-requis : 

  • Avoir un compte administrateur dans Office 365
  • Avoir un dossier C:\temp\ sur sa machine

Limites :

  • Actuellement le script ne prend en compte que les licences E1, E3 et K1

Résultat :

Une fois le script exécuté, vous avez dans le dossier C:\temp\ un dossier Export contenant :

  • Trois fichiers contenant l'ensemble des utilisateurs et leur utilisation
  • Trois dossiers contenant chacun le nombre de fonctionnalités actives et inactives

Licence du script : 

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

Exchange Online – Erreur avec les listes de distribution dynamiques et le filtre UsageLocation

Contexte

Dans Exchange Online il est possible de créer des listes de distribution dynamiques en se basant sur l’attribut UsageLocation. Cet attribut est défini par l’administrateur lors de l’attribution d’une licence à un utilisateur.

2017-11-21_151051

Cependant lorsque vous créez une liste de distribution il se peut que le filtre ne fonctionne pas et que l’erreur suivante apparaisse lorsque vous tentez de lister les membres de la liste :

2017-11-21_144233

Explications

Lorsque l’on regarde le filtre via la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que la valeur pour l’attribut UsageLocation est en Français. Ceci est causé par le fait que l’outil Microsoft Sign-In Assistant a été installé en Français.

2017-11-21_143648

Même si l’on créé le filtre à l’aide de la norme ISO 3166 (comme décrit dans la KB suivante https://technet.microsoft.com/en-us/library/bb738157(v=exchg.160).aspx), l’outil remplace le code par le texte en Français avant de l’envoyer au serveur Exchange.

Après avoir contacté le support Microsoft, nous avons eu une confirmation de ce problème et une mise à jour doit être apportée dans le code source de l’outil.

Solution

La solution en attendant le fix est de supprimer la liste de distribution et de la recréer depuis une machine où l’outil est installé en anglais. Pour cela, lancez les commandes suivantes :

Remove-DynamicDistributionGroup “dl_language_it”

2017-11-21_144451

New-DynamicDistributionGroup "dl_language_it" -RecipientFilter {UsageLocation –eq “IT”}

La liste des codes ISO pour l’ensemble des pays sont disponibles au lien suivant : https://www.iso.org/obp/ui/fr/

Si l’on vérifie avec la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que l’attribut UsageLocation est maintenant en Anglais.

2017-11-21_144550

Si l’on utilise la commande suivante pour lister les membres, l’erreur n’apparait pas et les membres du groupes apparaissent.

$group = Get-DynamicDistributionGroup ‘”dl_language_it”
Get-Recipient –RecipientPreviewFilter $group.RecipientFilter

2017-11-21_144739

Gestion de WSUS en Powershell - Partie 4

1- Décliner des KB

Voici comment décliner toutes les KB de sécurité remplacées (Superseded).

# Decline Action
$KBState = $Wsus.GetStatus()
$DeclinedBefore = $KBState.DeclinedUpdateCount
$DeclineSupersed = $Wsus.GetUpdates() | Where-Object {($_.UpdateClassificationTitle -eq "Security Updates") -and ($_.IsSuperseded -eq $True)}
$DeclineSupersed | ForEach-Object -Process {$_.Decline()}
$DeclinedAfter = $KBState.DeclinedUpdateCount

Write-Host "Before we had $DeclinedBefore KB declined, and now  $DeclinedAfter"

2 - Approuver des KB

 Pour approuver des KB de sécurité non approuvées et non remplacées.

# Approve Action
$AproveKB = $Wsus.GetUpdates() | Where-Object {($_.UpdateClassificationTitle -eq "Security Updates") -and ($_.IsSuperseded -eq $false) -and ($_.IsApproved -eq $false) -and ($_.State -ne "NotNeeded")}
$MyTarget = $wsus.GetComputerTargetGroups() | Where-Object {$_.Name -eq "TEST-Workstations"}
$AproveKB[0].ApproveForOptionalInstall($MyTarget)

Attention dans l'exemple ci-dessus nous approuvons les KB "nécessaires" pour un groupe appelé "TEST-Workstations", pensez à modifier la variable "$MyTraget" avec le nom de votre ou vos groupes.

Exemple:

# Approve Action
$ApprovedKB = $Wsus.GetUpdates() | Where-Object {($_.UpdateClassificationTitle -eq "Security Updates") -and ($_.IsSuperseded -eq $false) -and ($_.IsApproved -eq $false) -and ($_.State -ne "NotNeeded")}
$MyTarget = $wsus.GetComputerTargetGroups() | Where-Object {$_.Name -eq "Prod_Servers"}
$AproveKB[0].ApproveForOptionalInstall($MyTarget)

 

Office 365 migration tenant-to-tenant – Retour d’expérience 1/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant. La première partie traitera de l’architecture et des pré-requis à la migration. La seconde partie traitera du plan d’action et de la migration. Enfin la troisième partie traitera des problèmes rencontrés lors de celle-ci.

Architecture

L’architecture de cette migration est assez simple. Deux environnements similaires contenant chacun Active Directory, Azure AD Connect, ADFS et O365. Le but de la migration est de migrer l’ensemble des données du tenant A vers le tenant B. Les comptes Active Directory ne sont pas migrés et l’ADFS A sera toujours utilisé par les utilisateurs de l’Active Directory A. La synchronisation vers le tenant utilisera bien évidemment le serveur AD Connect B. Enfin les adresses emails garderont le même nom de domaine de la source vers la destination.

Figure 1 – Schéma source de l’architecture

schemaSource

Figure 2 – Schéma cible de l’architecture

schemaCible

Pré-requis

Le premier pré-requis est d’avoir une relation d’approbation inter-forêt entre les deux forêts AD.

La migration tenant-to-tenant nécessite également un outil tiers afin de migrer l’ensemble du contenu des boites aux lettres (emails, contacts, calendrier…).

Un nombre de licences suffisant dans le tenant B est également indispensable pour accueillir les comptes du tenant A.

Enfin il est important d'avoir un compte administrateur global utilisant le domaine par défaut de microsoft (@domaine.onmicrosoft.com).

 

Voilà qui conclut la première partie de mon retour d'expérience. Stay tuned!

Office 365 migration tenant-to-tenant – Retour d’expérience 2/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la seconde partie qui traitera du plan d’action et de la migration.

Plan d’action

Lors de la migration les noms de domaine des adresses emails étant conservés, une coupure de service est obligatoire. Il est donc primordial de bien préparer la migration et d’effectuer en avance de phase toutes les tâches pouvant être traitées pré-migration.

Le plan d’action sera le suivant :

    1. Avoir un export de l’ensemble des données du tenant A. Pour chaque compte connaître son adresse de messagerie, ses alias, ses droits… Idem pour l’ensemble des objets Exchange (boites partagées, listes de distribution, contacts...)
    2. Créer des utilisateurs cloud uniquement dans le tenant B correspondant aux utilisateurs du tenant A. Exemple : john.doe@domainea.com aura un compte john.doe@domaineb.onmicrosoft.com
    3. Assigner des licences aux utilisateurs dans le tenant B
    4. Créer le reste des objets Exchange (attention certains objets peuvent-être synchronisés avec l’AD et d’autre uniquement dans le cloud) du tenant A dans le tenant B
    5. Commencer les migrations via l’outil de migration. Exemple : l’ensemble des mails plus vieux que les 30 derniers jours
    6. Arrêter la synchronisation de l’ensemble des objets de l’Active Directory A vers le tenant A (supprimer la synchronisation des OU dans Azure AD Connect A). L’ensemble des comptes dans le tenant A sont à présent en Soft-Deleted
    7. Utiliser la commande suivante pour restaurer l’ensemble des comptes en tant que comptes cloud uniquement :
      Get-MsolUser –ReturnDeletedUsers –All | Restore-MsolUser
    8. Supprimer l’ensemble des références aux noms de domaine présent sur le tenant A (alias, adresses SIP,…). Tous les objets doivent avoir uniquement des adresses avec l’adresse par défaut de Microsoft
    9. Supprimer les noms de domaine du tenant A
    10. Ajouter les noms de domaine sur le tenant B
    11. Modifier l’UPN des comptes cloud du tenant B pour qu’ils soient égaux aux UPN des comptes de l’Active Directory A.
    12. Créer un nouveau connecteur sur l’AD Connect B pour synchroniser les comptes de l’Active Directory A. Une fois la synchronisation terminée, les comptes cloud du tenant B ont fusionné avec les comptes de l'Active Directory A.
    13. Finaliser la migration via l’outil (attention, les adresses sources et destinations ont changé, il est peut-être nécessaire de les mettre à jour dans l’outil utilisé pour la migration)
    14. Mettre à jour l’ADFS A via les commandes suivantes :
      Set-MsolDomainFederationSettings –domainname "domainea.com" –ActiveLogOnUri "https://<url ADFS A>/adfs/services/trust/2005/usernamemixed" –issuerUri "http://<domainea.com>/adfs/services/trust/" –logoffuri "https://<url ADFS A>/adfs/ls/" –metadataexchangeuri "https://<url ADFS A>/adfs/services/trust/mex" –PassiveLogOnUri "https://<url ADFS A>/adfs/ls/"
      Update-MsolFederatedDomain –DomainName "domainea.com" –SupportMultipleDomain

 

Migration

La planification

La planification de la migration est importante. En effet lorsque l’on se réfère au plan d’action on remarque que beaucoup d’actions sont à faire pendant l’interruption de service (de l’étape 6 à l’étape 12). Il est donc important de bien planifier la migration sur un weekend et de vérifier qu’aucune autre action est prévue à cette date là (paye, bilan comptable…).

Il est également très important de communiquer avec les utilisateurs tout au long du projet. Expliquer pourquoi une telle migration (intégration de la messagerie dans la messagerie groupe par exemple), bien indiquer les dates de la migration, prévenir de l’interruption de service et informer des éléments qui ne sont pas pris en compte par cette migration (signature…).

Y penser !

Une fois la migration terminée, le support utilisateur peut être amener à avoir une surcharge de travail. Avoir une équipe renforcée lors des premiers jours post-migration aidera grandement à la résolution des problèmes et à la gestion du stress des équipes.

Les actions post-migrations

Une fois la migration terminée, certaines actions sont nécessaires côté utilisateur (création d’un nouveau profil sur Outlook par exemple) mais aussi côté administrateur (donner de nouveaux droits d’administration aux équipes sur le tenant B par exemple).

Mettre en place un fichier de suivi pour les problèmes rencontrés est fortement conseillé. Cela permet de centraliser et donc de faciliter la résolution des problèmes et de ne pas oublier certains points (notamment si c’est un problème mineur).

 

Voilà qui conclut la seconde partie de mon retour d'expérience. Stay tuned!

Office 365 migration tenant-to-tenant – Retour d’expérience 3/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la dernière partie qui traitera des problèmes rencontrés lors de la migration.

Problèmes rencontrés et solutions

Eléments de calendrier non-migrés

Un point important pour que la migration des calendrier se fasse, la time-zone de la boite aux lettres de destination doit être renseignée. La commande PowerShell suivante permet de mettre à jour cet attribut

Set-MailboxRegionalConfiguration –Identity "<UserPrincipalName>" –TimeZone "GMT Standard Time"

Les valeurs possibles de la time-zone sont indiqués ici : https://support.microsoft.com/en-us/help/973627/microsoft-time-zone-index-values.

Migration OneDrive

Tout comme la migration des éléments de calendrier, la partie OneDrive nécessite une initialisation des comptes cibles pour que la migration s’effectue.

Lors de cette migration j’ai utilisé le script présent à l’adresse suivante pour initialiser l’ensemble des comptes.

https://support.office.com/fr-fr/article/Comment-configurer-des-sites-utilisateur-dans-OneDrive-entreprise-ceef6623-f54f-404d-8ee3-3ce1e338db07

Mauvaise synchronisation des comptes Active Directory

Au moment de la synchronisation de l’Active Directory A vers le tenant B, il est possible que certains comptes ne fusionnent pas avec leur compte cloud correspondant et que des doublons soient présent.

Il peut y avoir diverses raisons à cela :

  • Une erreur dans l’UPN du compte cloud
  • Un contact déjà présent dans le tenant B avec l’adresse email du compte A
  • Un compte invité dans le tenant B avec l’adresse email du compte A

Dans ce cas, il faut tout d’abord supprimer l’objet (le contact ou le compte invité) du tenant B (en le supprimant également de la corbeille O365). Ensuite il faut désynchroniser le compte AD (en déplaçant le compte dans un OU non-synchronisée). Une fois le compte désynchronisé il faut supprimer ce compte de la corbeille O365. Lancer une nouvelle synchronisation pour que la métaverse de l’AD Connect prenne en compte la modification. Enfin resynchroniser le compte AD. Il doit alors fusionner correctement.

Si ce n’est pas le cas, il est possible que le compte cloud ne récupère par l'attribut ImmutableID. Cet attribut est le "lien" entre le compte dans l'Active Directory (et donc celui de la métaverse AD Connect) et le compte cloud O365.

Pour modifier l'attribut il faut de nouveau désynchroniser le compte AD et le supprimer de la corbeille O365 puis il faut utiliser les commandes PowerShell suivantes.

Sur l’Active Directory A :

$adUser = Get-ADUser "<SamAccountName>" –Properties *

$id= $adUser.ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($adUser.ObjectGUID)).tobytearray())}

Sur le tenant B :

Set-MsolUser –UserPrincipalName "<UserPrincipalName>" –ImmutableID $id

Resynchroniser le compte AD.

Conclusion

Ce billet termine mon retour d'expérience sur cette migration tenant-to-tenant. J'espère qu'il vous a été utile.