PI Services

Le blog des collaborateurs de PI Services

Exchange hybride : Impossible de partager le calendrier "tous les détails" et "détails limités" à partir d'Outlook

Problème

Lorsqu'un utilisateur On premises tente de partager son calendrier avec un utilisateur Office 365, il reçoit le message d’erreur suivant :

Cause

Ce problème se produit si la stratégie de partage n’autorise pas l’utilisateur à partager le niveau de détails que l’utilisateur a défini dans l’invitation de partage.

Solution

Pour résoudre ce problème, suivez les étapes suivantes :

  1. Ouvrez le Centre d’administration Exchange, cliquez sur Organization --> Sharing
  2. Double-cliquez sur "Default Sharing Policy (DEFAULT)"
  3. Cette règle indique que vous ne pouvez partager que l'autorisation « Disponibilité uniquement » avec les autres organisations.

    Vous pouvez soit modifier la règle de partage  « Toutes les informations de calendrier, notamment l'heure, l'objet, l'emplacement et le titre » pour tous les domaines

  4. Ou vous créez une nouvelle règle de partage pour votre domaine smtp qui est partagé dans Office 365 et attribuez "Toutes les informations de calendrier, notamment l'heure, l'objet, l'emplacement et le titre". 
  5. Cliquez ensuite sur "Enregistrer"

Erreur installation de correctif: L'assistant d'installation pour la mise à jour de sécurité Exchange s'est terminé prématurément

Lors de l'installation d'un correctif de sécurité pour Exchange Server 2016, l'erreur suivante a été rencontrée « Setup Wizard for Security Update for Exchange Server 2016 cumulative Update…. ended prematurely »

L'erreur est due à une installation incomplète qui a entraîné la désactivation des services messagerie.

Résolution:

  • Définir les services Exchange sur Automatique et démarrer-les:

Get-Service -Name MSE* | Set-Service -StartupType Automatic
Set-Service -Name MSExchangeImap4 -StartupType Disabled
Set-Service -Name MSExchangeIMAP4BE -StartupType Disabled
Set-Service -Name MSExchangePop3 -StartupType Disabled
Set-Service -Name MSExchangePOP3BE -StartupType Disabled
Write-Host "Starting Services..."
Get-Service -Name MSE* | where {$_.StartType -ne "Disabled"} | Start-Service

  • Démarrer aussi les autres services dépendants comme IIS, Search, etc
  • Exécuter le fichier de correctif cumulatif dans une invite de commande avec l'option « Exécuter en tant qu'administrateur ». Ceci donnera au programme d'installation l'autorisation nécessaire pour installer le correctif avec succès.

--> L'activation et le démarrage des services conduisent à une installation réussie de la mise à jour de sécurité.

Popup mot de passe répétitif lors de la création d'un profil Outlook 2016/365 pour se connecter à Exchange Onpremise 2016

Description

Dans les dernières mises à jour des versions Microsoft Office 2016,  lorsqu’un utilisateur ajoute un nouveau compte Exchange 2016 , il est invité à plusieurs reprises à saisir son nom d’utilisateur et son mot de passe pour aboutir finalement à un échec.

Ce problème est lié à la configuration de découverte automatique qu'Outlook utilise. Microsoft semble avoir défini Outlook pour utiliser leurs serveurs Office 365 comme point de configuration initial indépendamment de la façon dont la découverte automatique est configurée.

Résolution

La résolution consiste à définir une entrée du Registre sur l’ordinateur qui rencontre le problème ayant la valeur dessous:

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

 

Attention: Cette modification ne doit se faire que si un compte Exchange On-Premise est utilisé.

 

 

Echec de la connexion Outlook après migration des boîtes aux lettres Exchange 2010 vers Exchange 2013/2016

Symptômes

Lorsque les boîtes aux lettres sont déplacées depuis Exchange 2010 vers Exchange Server 2013/2016, les utilisateurs ne peuvent plus accéder à leur boîtes aux lettres.

Ce problème se produit dans le scénario suivant:

  • Un utilisateur utilise généralement Outlook Anywhere pour se connecter à sa boîte aux lettres Exchange Server 2010.
  • La boîte aux lettres de l'utilisateur est déplacée vers Exchange Server 2013 ou Exchange Server 2016.
  • Une fois la boîte aux lettres déplacée et l'utilisateur tente de se connecter, le message «L'administrateur Microsoft Exchange a effectué une modification qui requiert que Microsoft Outlook soit fermé puis redémarrer » apparaît.
  • Après le redémarrage d'Outlook, le client reste déconnecté.

Cause

ce problème n’arrive pas trop souvent mais il peut être gênant: Une fois le déplacement de la boîte aux lettres terminé, Exchange Server 2013 ou 2016 continue à transmettre par proxy la demande Autodiscover à Exchange Server 2010 qui rebondit ensuite sur Exchange 2016. Il s’agit de ping-pong des demandes de reconfiguration de profil Outlook jusqu’à ce que le cache d’application de découverte automatique expire et que les informations soient actualisées.

Résolution

Le recyclage du pool d’applications actualise le cache et Outlook se connecte avec succès. Ainsi, pour résoudre ce problème, redémarrer le pool d’applications de découverte automatique sur les serveurs Exchange Server 2013 ou Exchange Server 2016 en exécutant la commande:

Restart-WebAppPool MSExchangeAutodiscoverAppPool

A noter qu'Exchange 2016 est un serveur combinant tous les rôles, mais il s’affiche comme serveur de boîtes aux lettres, ainsi, il faut redémarrer le pool Autodiscover sur chaque serveur Exchange 2016.

Dans un environnement hybride, la boite aux lettres est marquée Remote Mailbox mais elle est introuvable sur Exchange Online

Dans un environnement hybride, un utilisateur avait une boîte aux lettres Exchange Online. La BAL est marquée en tant que boîte aux lettres distante (visible sur Exchange Onpremise) mais la boîte aux lettres Office 365 n'était pas disponible. Dans ce cas, le GUID Exchange Onpremise doit être mis à jour.

Pour ce faire, les étapes ci-dessous ont été réalisées :

  • Accéder à Exchange Management Shell (Onpremise) et sauvegarder les paramètres de la BAL via la commande suivante:

Get-Mailbox "affectedUser" | fl > mailboxinfo.txt

  • Mettre à jour le GUID Exchange à Null sur la boîte aux lettres affectée via l'exécution de la commande:

Set-remotemailbox "affectedUser"  -ExchangeGuid 00000000-0000-0000-0000-0000-0000000000000000000

  • S’assurer que Exchange Guid se reflète correctement :

Get-RemoteMailbox "affectedUser"  | Fl ExchangeGuid 

Get-MailUser "affectedUser"   | fl ExchangeGuid

  • L’étape suivante consiste à supprimer la licence exchange Online, synchroniser, puis à ré ajouter la licence et vérifier l’état :

Get-Mailbox "affectedUser" | fl exchangeGuid,RecipientTypeDetails

  • Récupérer la valeur d'ExchangeGuid
  • Dans Exchange Management Shell (Onpremise), rétablir l’attribut Exchange Online GUID sur la boîte aux lettres distante Set-RemoteMailbox "affectedUser" -ExchangeGuid " ExchangeGuidRecupéré"  Puis vérifier le paramètre via la commande: Get-RemoteMailbox "affectedUser"  | Fl ExchangeGuid 

  • Dans la console Exchange Online, vérifier aussi que l'objet s'affiche en tant que boîte aux lettres utilisateur.

Office 365 : Voir qui a réservé la salle de réunion

Aujourd'hui lorsque l'on utilise Exchange Online et les boites aux lettre de salle, la configuration par défaut du calendrier de ces boites ne permet de voir que le statut de celle-ci soit "Libre ou Occupée" en revanche il n'est pas possible de voir qui a réservé la salle.

C'est parce que par défaut les droits sur le calendrier sont en "AvailabilityOnly", comme le montre la capture ci dessous.

 

 

A l'aide de Powershell, il est possible de modifier les droits sur le calendrier pour afficher qui est la personne ayant fait la réservation, pour ce faire voici les cmdlets.

#Construction de la session Exchange Online
$cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $Cred -Authentication Basic -AllowRedirection

# Import de la session
Import-PSSession $Session

# Audit des droits
Get-MailboxFolderPermission -Identity Nom_de_la_Salle_de_réunion:\calendar

# Modification des droits
Set-MailboxFolderPermission -Identity Nom_de_la_Salle_de_réunion:\calendar -User default -AccessRights LimitedDetails

 

Maintenant il est possible de voir le statut de la salle de réunion ainsi que les personnes l'ayant réservé.

Convertir une boîte aux Lettres utilisateur en Boite aux Lettres Partagée dans un environnement hybride

Dans un environnement hybride, la conversion d’une boîte aux lettres utilisateur en une boîte aux lettres standard n'est pas prise en charge, même s'il existe un lien pour le faire depuis le Centre d'administration Exchange Online. Cela semble fonctionner, mais les modifications apportées dans Exchange online ne seront pas nécessairement synchronisées. Pour convertir une boîte aux lettres Utilisateur en boîte partagée, nous devons suivre trois étapes ci-dessous :

  1. Convertir la boîte aux lettres Utilisateur en BAL partagée dans Exchange Online
  2. Modifier les attributs AD Onpremise
  3. Retirer la licence Exchange Online.

Etape 1 :Conversion de la boîte aux lettres Utilisateur en BAL partagée dans Exchange Online :

  • Ouvrir Windows PowerShell et exécuter la commande suivante:

$UserCredential = Get-Credential

  • Dans la boîte de dialogue Demande d’informations d’identification Windows PowerShell, saisir le nom d’utilisateur et mot de passe, puis cliquer sur OK
  • Exécuter les commandes suivantes :

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session -DisableNameChecking

  • Une fois connecté sur Exchange Online, saisir la commande ci-dessous pour convertir la BAL utilisateur en BAL partagée :

Set-Mailbox MyuserMailbox -Type Shared

Etape 2 : Modification des attributs AD Onpremise

Avant d’apporter des modifications aux objets Active Directory, noter les valeurs avant ou encore sauvegarder tous les attributs AD et leurs valeurs dans un fichier texte: Get-ADUser MyUserMailbox -Properties *> BeforeAttributeModification.txt

 Dans la console Utilisateurs et ordinateurs Active Directory, s’assurer d'avoir activé les fonctionnalités avancées dans l'option de menu Affichage. Ensuite, accéder à l’objet AD (utilisateur), ouvrir ses Propriétés et accéder à l’onglet Editeur d’attribut puis mettre à jour les attributs suivants avec ces valeurs :

  • msExchRemoteRecipientType: 100
  • msExchRecipientTypeDetails: 34359738368

 

 

  Etape 3: Suppression de la licence Exchange Online

Vu que la boîte aux lettres partagée ne nécessite pas de licence, cette dernière est à supprimer : Utiliser tout simplement le portail Office 365, rechercher l'utilisateur sous Utilisateurs actifs et retirer la licence Exchange Online. Après la révocation de la licence, il est important de valider son statut dans Azure AD.

  • Se connecter au Module Microsoft Azure Active Directory pour Windows PowerShell
  • Installer la version 64 bits de l’Assistant de connexion Microsoft Online Services : Assistant de connexion Microsoft Online Services pour les professionnels des technologies de l’information RTW
  • Télécharger et installer le Module Microsoft Azure Active Directory pour Windows PowerShell via l'exécution de la commande Install-Module MSOnline 
  • Taper la commande Connect-MsolService, dans la boîte de dialogue Connectez-vous à votre compte, taper le nom d’utilisateur et le mot de passe du compte d’administration Office 365, puis cliquer sur OK.
  • Ouvrir une invite de commandes Windows PowerShell avec élévation de privilèges (exécuter Windows PowerShell en tant qu’administrateur).

Note : Si l’authentification multifacteur est activée, il est à suivre les instructions des boîtes de dialogue suivantes pour fournir des informations d’authentification supplémentaires telles qu’un code de vérification.

  • Pour vérifier que la licence a été correctement retirée, exécuter la commande :

Get-MSOLUser -UserPrincipalName MyUserMailbox@mylab.com | fl * lic *

L'attribut LicenseReconciliationNeeded devrait être False. Si LicenseReconciliationNeeded retourne True, Exchange Online voit que cette boîte aux lettres nécessite une licence et l’a marque pour suppression avec une période de grâce de 30 jours.

Le client Outlook n'arrive plus à accéder à la GAL sur Exchange Server 2013

Problème:

Les clients Outlook n'arrivent plus à accéder à la GAL sur Exchange, et donc les utilisateurs sont dans l'incapacité d'ajouter des salles de réunions ou de rechercher contacts qui ne sont pas dans leur cache Outlook. Le client se fige et le message d'erreur suivant apparait après quelques dizaines de secondes:

Troubleshooting:

  • Vérification des journaux d'événements .
  • Vérification de la réplication AD et Exchange.
  • Régénération de l'OAB et MaJ de la GAL. 
  • Déplacement de la boite mail contenant l'OAB vers un autre serveur.
  • Entrée dans le fichier host pour pointer directement sur le serveur hébergeant l'OAB.
  • Test d'accès sur l'URL EWS et l'URL OAB.
  • Vérification des logs IIS.

 

Solution:

Des erreurs 401 étaient retournées depuis le serveur dans les logs IIS. Pour résoudre cette erreur il a fallu redémarrer les services IIS, puis les services "RPC Client Access" et "MS Exchange Throttling", puis de nouveau redémarrer les services IIS.

 

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

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!