PI Services

Le blog des collaborateurs de PI Services

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.

SCOM – Faire correctement échouer une tâche


Sous ce titre qui peut prêter à sourire se cache une fonctionnalité peu connue et finalement pas vraiment indispensable, mais qui donnera une touche un peu plus finie et professionnelles à vos management packs.

Lorsque vous exécutez une tâche basée sur un script Powershell, il peut arriver que ce dernier échoue à remplir son but pour diverses raisons. Dans ce cas, par défaut, la tâche présentera malgré tout un résultat en succès ou, au mieux, un résultat ressemblant au suivant :

clip_image002

Vous avez cependant déjà vu des tâches qui échouent « proprement », avec un symbole d’échec et le message d’erreur associé dans la sortie de la tâche.

Pour obtenir le même résultat dans vos propres développements, c’est très simple, il y a deux conditions à remplir :

- Lever une exception dans le script, via une commande Throw

- Ajouter le paramètre <StrictErrorHandling>true</StrictErrorHandling> à la WriteAction ou à la Probe utilisée dans votre tâche :
clip_image004

Et vous obtiendrez alors une sortie indiquant bien un Status Failed, avec l’icone « rouge » et le texte envoyé dans le Throw dans la sortie lorsque la tâche échoue :

clip_image006