En effet dans 365, les utilisateurs peuvent créer facilement des groupes Office 365.

il est important de contrôler les personnes autorisées à créer des groupes.

Pour cela, nous allons voir comment créer un groupe de sécurité pour des utilisateurs qui ont besoin de créer des Groupes dans Office 365

Pres requis :

Installer la version préliminaire d’Azure Active Directory PowerShell pour Graph

Etape 1 : Installer la version la plus récente d’Azure Active Directory PowerShell pour Graph

Depuis la console powershell Vérifiez le module installé :

Get-InstalledModule -Name "AzureAD*"

Désinstaller la version précédente de AzureADPreview ou AzureAD, en exécutant la commande suivante :

Uninstall-Module AzureADPreview ou Uninstall-Module AzureAD

Maintenant il faut installer la dernière version de d’Azure Active Directory PowerShell pour Graph :

Install-Module AzureADPreview

Etape 2 : Exécuter le script PowerShell

Premièrement il faut créer le groupe de sécurité dont les personnes membre, seront autorisées à créer des groupes dans 365

Exemple : GG_APP_ALLOW_CREATEGROUP_0365

$GroupName = "GG_APP_ALLOW_CREATEGROUP_O365"

$AllowGroupCreation = "False"

$username = "LOGIN"

$password = ConvertTo-SecureString "PASSWORD" -AsPlainText -Force

$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $password

Connect-AzureAD -Credential $cred

$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id

if(!$settingsObjectID)

{

      $template = Get-AzureADDirectorySettingTemplate | Where-object {$_.displayname -eq "group.unified"}

    $settingsCopy = $template.CreateDirectorySetting()

    New-AzureADDirectorySetting -DirectorySetting $settingsCopy

    $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id

}

$settingsCopy = Get-AzureADDirectorySetting -Id $settingsObjectID

$settingsCopy["EnableGroupCreation"] = $AllowGroupCreation

if($GroupName)

{

    $settingsCopy["GroupCreationAllowedGroupId"] = (Get-AzureADGroup -SearchString $GroupName).objectid

}

Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy

(Get-AzureADDirectorySetting -Id $settingsObjectID).Values

Étape 3 : vérifier qu’elle fonctionne

Connectez-vous à Office 365 avec le compte d'utilisateur d'une personne qui ne doit PAS être autorisée à créer des groupes. C’est à dire les personnes qui ne sont pas membre du groupe « GG_APP_ALLOW_CREATEGROUP_0365 », groupe contenant des personnes autorisées à créer des groupes.

1. Sélectionnez la vignette planificatrice.
2. Dans le planificateur, sélectionnez nouveau plandans le volet de navigation de gauche pour créer un plan.
3. Vous devriez recevoir un message indiquant que la création de plan et de groupe est désactivée.

Restaurer des milliers d'éléments supprimés par une personne sur un site Sharepoint peut être une opération fastidieuse, voici donc un script Powershell pour le faire à votre place et vous bénéficierez aussi d'un rapport d'état ("Success", "Failure") pour chacun des éléments.

1 - Prérequis Powershell

Dans un premier temps nous allons avoir besoin d’installer le module Powershell nécessaire à la gestion de Sharepoint, pour ce faire utilisez la commande suivante :

# Installation du Module Powershell
Install-Module SharePointPnPPowerShellOnline

Une fois le module Powershell installé nous allons pouvoir nous connecter au site et atteindre sa corbeille de là nous pourrons faire le filtrage et l’export des éléments.

2 - Script Powershell

# Script to Restore RecycleBin elements
# By : Mathieu ADELAÏDE
# Date : 06/09/2019
# Version : V0

#######################
# Step 0 : Management #
#######################
#region - Step 0
# Folder Definition
# Get Current Path
$currentPath = (Get-Location).Path


$RootFolder = "C:\Temp\Sharepoint"
$LogFolder = "$RootFolder\Log"

#Folder Creation
$AllFolder = $RootFolder, $LogFolder
$AllFolder | foreach {
    $FolderName = $_
    If (!(Test-Path $FolderName)) {
        New-Item $FolderName -ItemType Directory
        }
    }

# Files Definition
$ResultState = "$LogFolder\RestaurationReport.csv"
Add-Content $ResultState -Value "Title;ItemType;Size;ItemState;DirName;DeletedByName;DeletedDate;ID;State"
$logFilePath = "$logFolder\SP_Restauration.log"

#Define Array
$Array = @()

#Config Variables
$SiteURL = "https://MySite.sharepoint.com/sites/Recrutement"
#endregion - Step 0

#######################
# Step 1 : Connection #
#######################
#region - Step 1
#Connect to Sharepoint Online
Try {
    Connect-PnPOnline -Url $SiteURL -Credentials (Get-Credential)
    }
Catch {
    $tmpError = $_.Exception.message
	Write-Output "The following error occurred: $tmpError" | Add-Content $logFilePath
	Write-Output "The error occurred while we trying to Connect to Sharepoint Online" | Add-Content $logFilePath
    }
#endregion - Step 1

#######################################
# Step 2 : Collection and Restoration #
#######################################
#region - Step 2
# List all Items
$RecycleBin = Get-PnPRecycleBinItem

# Filter result
$FilteredRecycleBin = $RecycleBin.Where({$_.DeletedByName -eq "DUPONT Jean"})
$FilteredRecycleBin | foreach {
    $Title = $_.Title
    $ItemType = $_.ItemType
    $Size = $_.Size
    $ItemState = $_.ItemState
    $DirName = $_.DirName
    $DeletedByName = $_.DeletedByName
    $DeletedDate = $_.DeletedDate
    $ID = $_.id
    $Guid = $ID.Guid
    
    # Restore
    Try {
        Restore-PnPRecycleBinItem -Identity $Guid -Force -ErrorAction Stop
        Write-Output "Successfully Restored File $Title" | Add-Content $logFilePath
        $State = "Succes"
        }
    Catch {
        $tmpError = $_.Exception.message
	    Write-Output "The following error occurred: $tmpError" | Add-Content $logFilePath
	    Write-Output "The error occurred while we trying to Restore $Title" | Add-Content $logFilePath
        $State = "Failed"
        }
    $Array += New-Object psobject -Property @{
        Title = $Title
        ItemType = $ItemType
        Size = $Size
        ItemState = $ItemState
        DirName = $DirName
        DeletedByName = $DeletedByName
        DeletedDate = $DeletedDate
        State = $State
        Id = $id
        }

    # Release variable
    $Title = $null
    $ItemType = $null
    $Size = $null
    $ItemState = $null
    $DirName = $null
    $DeletedByName = $null
    $DeletedDate = $null
    $ID = $null
    $State = $null
    $Guid = $null
    }
#endregion - Step 2

###################
# Step 3 : Export #
###################
#region - Step 3
Try {
    $Array | Export-Csv $ResultState -Encoding UTF8 -NoTypeInformation -Delimiter ";"
    Write-Output "Successfully Export Data" | Add-Content $logFilePath
    }
Catch {
    $tmpError = $_.Exception.message
	Write-Output "The following error occurred: $tmpError" | Add-Content $logFilePath
	Write-Output "The error occurred while we trying to Export Data" | Add-Content $logFilePath
    }
#endregion - Step 3

Récemment j’ai été confronté à un sujet délicat, une synchronisation entre Sharepoint Online et un poste client s’est terminée par la suppression de la majorité des dossiers et fichiers du site en question.

Pour pouvoir connaitre l’étendue des dégâts il a fallu faire un audit de ce qui avait été supprimés par erreur.

On pourrait le faire graphiquement via le portail, mais lorsque le nombre d’éléments s’élève à plusieurs milliers ce n’est pas pratique.

Voici une petite astuce pour faire un export au format CSV des éléments dans la corbeille et en option comment les filtrer sur un utilisateur en particulier.

1 - Prérequis Powershell

Dans un premier temps nous allons avoir besoin d’installer le module Powershell nécessaire à la gestion de Sharepoint, pour ce faire utilisez la commande suivante :

# Installation du Module Powershell
Install-Module SharePointPnPPowerShellOnline

Une fois le module Powershell installé nous allons pouvoir nous connecter au site et atteindre sa corbeille de là nous pourrons faire le filtrage et l’export des éléments.

2 - Script Powershell

2.1 Version avec tous les éléments de la corbeille.

#Config Variables
$SiteURL = "https://Monsite.sharepoint.com/sites/Recrutement"
$Items = "C:\temp\RecycleBinItems.csv"
Add-Content $Items -Value "Title;ItemType;Size;ItemState;DirName;DeletedByName;DeletedDate"
$Array = @()
 

#Connect to PnP Online
Connect-PnPOnline -Url $SiteURL -Credentials (Get-Credential)

# List and export all Items in Recycle bin
$RecycleBin = Get-PnPRecycleBinItem
$RecycleBin | foreach {
    $Title = $_.Title
    $ItemType = $_.ItemType
    $Size = $_.Size
    $ItemState = $_.ItemState
    $DirName = $_.DirName
    $DeletedByName = $_.DeletedByName
    $DeletedDate = $_.DeletedDate

    $Array += New-Object psobject -Property @{
        Title = $Title
        ItemType = $ItemType
        Size = $Size
        ItemState = $ItemState
        DirName = $DirName
        DeletedByName = $DeletedByName
        DeletedDate = $DeletedDate
        }
    }

$Array | Export-Csv $Items -Encoding UTF8 -NoTypeInformation 

2.2 Version avec option de filtrage.

Dans cette version nous faisons la même requête, en ajoutant un filtrage sur un utilisateur bien précis.

#Config Variables
$SiteURL = "https://Monsite.sharepoint.com/sites/Recrutement"
$Items = "C:\temp\RecycleBinItems.csv"
Add-Content $Items -Value "Title;ItemType;Size;ItemState;DirName;DeletedByName;DeletedDate"
$Array = @()
 

#Connect to PnP Online
Connect-PnPOnline -Url $SiteURL -Credentials (Get-Credential)

# List and export all Items in Recycle bin
$RecycleBin = Get-PnPRecycleBinItem
$FilteredRecycleBin = $RecycleBin.Where({$_.DeletedByName -eq "DUPONT Jean"})
$FilteredRecycleBin | foreach {
    $Title = $_.Title
    $ItemType = $_.ItemType
    $Size = $_.Size
    $ItemState = $_.ItemState
    $DirName = $_.DirName
    $DeletedByName = $_.DeletedByName
    $DeletedDate = $_.DeletedDate

    $Array += New-Object psobject -Property @{
        Title = $Title
        ItemType = $ItemType
        Size = $Size
        ItemState = $ItemState
        DirName = $DirName
        DeletedByName = $DeletedByName
        DeletedDate = $DeletedDate
        }
    }

$Array | Export-Csv $Items -Encoding UTF8 -NoTypeInformation 

Il m'est arrivé il y a peu de temps un cas un peu spécifique, quelqu'un qui bénéficiait de droit "Full Control" sur Sharepoint online se voyait gratfié d'un "Access Denied" à chaque tentative de connexion sur l'url de son site et ceux même en cliquant sur le lien envoyé par Sharepoint lorsqu'on lui attribuait les droits.

La Cause:

En fait cette personne avait bénéficié de droits divers et variés (en accès direct, via l'appartenance à des groupes, via les demandes, Full Control, Edit, Read Only, Limited Access...) car personne parmis les gestionnaires Shrepoint ne parvenait à lui donner les droits.

Par conséquent nous sommes tombé dans un conflit de droits d'accès qui n'a pu être résolu de manière graphique, mais via Powershell.

La Solution: 

Afin de solder le problème il a fallu passer par Powershell et supprimer les dépendances de ce compte via la suppression du compte de la "UserInfo List".

Pour ce faire nous avons utilisé les commandes ci-dessous (Attention le module Sharepoint Online pour Powershell est nécessaire):

# Connexion à Sharepoint Online
Connect-SPOService -Url https://monnorganisation.sharepoint.com -Credential "adm-maade@monorganisation.com"

# Vérification des groupes d'appartenance pour mon Utilisateur
$AllUsers = Get-SPOUser -Site https://monnorganisation.sharepoint.com/sites/Toto
$FilterMonUser = $AllUsers.where({$_.loginname -eq "tartanpion@globule.net"})

# Afficher les groupes de mon Utilisateur
$FilterMonUser.groups

# Suppression de mon utilisateur de la UserInfo List
Remove-SPOUser -Site "https://monnorganisation.sharepoint.com/sites/Toto" -LoginName "tartanpion@globule.net"

Une fois la commande terminée, j'ai pu réaffecter les bons droits au travers du bon groupe dans l'interface du site Sharepoint.

Info supplémentaires:

https://docs.microsoft.com/en-us/sharepoint/remove-users

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

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 !

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

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…).

Vivement la suite des fonctionnalités !

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 : 

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

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.

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 :

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.

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”

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.

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

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

Figure 2 – Schéma cible de l’architecture

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!

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!

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.