web-dev-qa-db-fra.com

Comment réconcilier l'utilisateur avec les boîtes aux lettres sur site et cloud?

Nous sommes au milieu d'une migration de coexistence hybride d'Exchange 2010 sur site vers Office 365. Cela signifie que nous avons ADFS et "Dirsync" (maintenant appelé Windows Azure AD Sync) en cours d'exécution. Nous sommes à plus de la moitié de la migration de la boîte aux lettres, donc environ 60% des boîtes aux lettres de nos utilisateurs sont dans le cloud et les 40% restants se trouvent toujours dans des bases de données Exchange 2010 sur site.

Aujourd'hui, nous avons découvert que l'un de nos utilisateurs possède à la fois une boîte aux lettres sur site et Office 365 liée à son seul compte AD. Cela signifie que s'il ouvre Outlook sur un ordinateur joint à un domaine et passe par la configuration initiale, il utilise la découverte automatique pour le connecter à sa boîte aux lettres sur site, mais s'il se connecte au portail Office 365, il affiche sa boîte aux lettres cloud.

Pire encore, lorsqu'un utilisateur dont la boîte aux lettres se trouve dans le cloud lui envoie un e-mail, celui-ci ne va que dans sa boîte aux lettres cloud, et lorsqu'un utilisateur dont la boîte aux lettres est encore sur site, il ne va que dans sa boîte aux lettres sur site. Il ne peut donc pas voir tout son courrier au même endroit.

Comment pouvons-nous "fusionner" ses données de messagerie (destination finale: Office 365) et nous assurer que son Outlook "découvre automatiquement" la boîte aux lettres Office 365 et tout le courrier est acheminé vers cette boîte aux lettres?

exchange-2010microsoft-office-365exchange-migration
7
Todd Wilcox

J'ai décidé que je ne voulais pas exporter tout le courrier de la boîte aux lettres cloud à l'aide d'Outlook, supprimer la licence Office 365 (ou simplement la licence EOL) de l'utilisateur, puis utiliser Powershell pour supprimer définitivement la boîte aux lettres, puis migrer la prémisse boîte aux lettres dans le cloud, puis réimportez les données exportées dans la nouvelle boîte aux lettres cloud. Je savais que ça marcherait, mais je semblais détourner. Ce que j'ai fini par faire aurait pu l'être davantage, mais voici une autre façon:

  • J'ai changé les adresses de messagerie de la boîte aux lettres sur site pour empêcher le courrier d'y accéder, puis j'ai utilisé le shell Exchange pour exporter la boîte aux lettres sur site vers PST.
  • J'ai désactivé la boîte aux lettres sur site (qui la supprime essentiellement dans Exchange 2010 - anciennement appelé "suppression des fonctionnalités Exchange").
  • J'ai créé un nouvel utilisateur de messagerie dans Exchange 2010, connecté à l'utilisateur existant en question. Cela m'a donné un début sur un objet nécessaire pour le routage du courrier vers Office 365 à partir du site, qui est un objet appelé Boîte aux lettres distante (Il semble que vous ne pouvez pas utiliser le Nouvelle boîte aux lettres distante ... si la boîte aux lettres distante existe déjà). Lors de la création de l'utilisateur de messagerie, je me suis assuré que l'adresse cible était <user alias>@<our custom domain>.mail.onmicrosoft.com.

Une fois l'objet utilisateur de messagerie trié, j'ai pensé que j'avais plusieurs choses à ajuster dans les attributs Active Directory:

  • Tout d'abord, j'ai mis en majuscule le protocole pour l'adresse de réponse correcte dans l'attribut proxyAddresses .
  • J'ai vérifié que l'attribut targetAddress était <user alias>@<our custom domain>.mail.onmicrosoft.com.
  • Copie à partir d'un autre utilisateur correctement configuré, j'ai changé msExchRecipientDisplayType de vide à -2147483642.
  • Comme ci-dessus, j'ai changé msExchRecipientTypeDetails de vide à 2147483648.
  • J'ai changé msExchRemoteRecipientType en 4.
  • Enfin, il semblait que je devais remplir l'attribut msExchMailboxGuid , ce qui s'avère plus compliqué qu'il n'y paraissait. J'ai trouvé la propriété ExchangeGuid pour la boîte aux lettres cloud à l'aide d'une session PowerShell connectée à Exchange Online avec Get-Mailbox -Identity <alias> | fl. L'astuce est quand il est signalé là-bas, il est au format text et pour éditer le attritube AD, il faut le saisir au format hex. J'ai utilisé un convertisseur en ligne (il y en a plusieurs, que j'ai découvert après avoir fait une recherche sur le Web sur le décalage de format) pour obtenir la version hexadécimale et mettre à jour l'attribut AD.
  • À ce stade, il semblait que j'avais terminé dans AD, j'ai donc exécuté une synchronisation d'annuaire, je me suis assuré qu'il n'y avait pas d'horribles erreurs, puis j'ai contacté l'utilisateur pour les exécuter à nouveau dans la configuration initiale d'Oulook, qui "a découvert automatiquement" la boîte aux lettres en ligne et a fonctionné comme un charme.
  • En ce moment, je termine la copie des éléments du fichier PST exportés au début dans la boîte aux lettres en ligne à l'aide d'Outlook.

Un utilisateur anonyme a suggéré ce qui suit, au lieu d'utiliser le convertisseur GUID. Cela permettrait également l'automatisation Powershell du processus.

Plutôt que d'utiliser le convertisseur GUID, vous pouvez simplement copier le GUID à partir de 365 et mettre à jour la propriété utilisateur dans Active Directory:

$365MboxGUID = get-mailbox -identity $samaccountname | select -ExpandProperty ExchangeGuid

Set-ADUser $samaccountname -replace @{msExchMailboxGuid=$365MboxGUID}
5
Todd Wilcox

J'ai le même problème dans mon domaine. Quelqu'un crée manuellement la boîte aux lettres o365 pour les utilisateurs qui ont déjà une boîte aux lettres sur site

J'ai trouvé ce moyen de le réparer:

  • Exporter la boîte aux lettres Office 365 dans PST
  • Supprimer la licence utilisateur Office 365 (cela supprimera sa boîte aux lettres cloud)
  • Supprimer un utilisateur Office 365 d'Office 365 AD:
  • DirSync (recréer l'utilisateur dans Office 365 AD)
  • Réaffecter la licence Office 365 pour l'utilisateur
  • Migrer l'utilisateur vers Office 365
  • Restaurer PST

Je pense que c'est plus simple et plus direct. Vous pouvez également migrer à nouveau votre boîte aux lettres sur site (hors-bord) si vous en avez besoin.

7
Mauro

Merci Mauro! Cela a fonctionné pour moi, U a dû ajouter -UserPrincipalName à votre commande et cela a fonctionné pour moi!

Remove-MsolUser -UserPrincipalName youruser@youroffice365domain -Force
Remove-MsolUser -UserPrincipalName youruser@youroffice365domain -RemoveFromRecycleBin -F
1
Tony