PI Services

Le blog des collaborateurs de PI Services

Exchange: Could not find any available Global Catalog in forest and Event ID 2112

L'exécution des commandes dans un powershell Exchange montre des erreurs " Could not find any available Global Catalog in forest.."

Le journal d'évènement "Application" montre l'avertissement dessous:

Cet événement d'avertissement indique que l'autorisation «Gérer le journal d'audit et de sécurité» a été supprimée pour le groupe "serveurs Exchange" sur les contrôleurs de domaine.

Pour résoudre ce problème:

  1. Ouvrez la console de Gestion des stratégies de groupe (Démarrer / Exécuter / GPMC.MSC)
  2. Développez "Domaines", "Domain Controllers" et cliquez avec le bouton droit de la souris sur "Default Domain Controllers Policy" puis "modifier"
  3. Accédez au menu "Configuration de l'ordinateur", "Stratégies", "Paramètres Windows", "Paramètres de sécurité", "Stratégies locales" et double-cliquez sur "Attribution des droits d'utilisateur"
  4. Dans le volet des résultats, double-cliquez sur "Gérer le journal d'audit et de sécurité" et vérifiez que le groupe "Serveurs Exchange" est répertorié ou l'ajouter le cas échéant. 

Par défaut, le seul groupe du domaine avec ce droit est le groupe Administrateurs mais le processus /preparedomain pour la préparation à l'installation Exchange accorde ce privilège aux serveurs Exchange.

 

 

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é.

Nouveau module Exchange atténuant automatiquement les failles critiques

Microsoft a intégré un nouveau module à Exchange qui mettra en place automatiquement les mesures d'atténuation lorsqu'une nouvelle faille de sécurité est dévoilée. Ce nouveau composant se nomme "Microsoft Exchange Emergency Mitigation (EM)"

Les CU22 and CU11 pour Exchange 2016 et 2019 contiennent cette nouvelle fonctionnalité de sécurité supplémentaire :

  • L'idée n'est pas de vous protéger définitivement, mais temporairement, en attendant que vous ayez le temps d'installer le correctif de sécurité. Cela est valable aussi quand Microsoft n'a pas encore sorti le correctif, afin de vous protéger. Retenez que cela ne remplace pas les patchs de sécurité.
  • Cela installe un service Windows Exchange qui vérifie une fois par heure si une atténuation contre une vulnérabilité est disponible et l’installe le cas échéant,
  • Cette fonctionnalité est optionnelle et peut être désactivée
  • Seules les vulnérabilités jugées critiques auront une atténuation.

Le composant EM peut appliquer trois types d'atténuation :

  • Règle de réécriture d'URL dans IIS : Créer une règle pour bloquer les requêtes HTTP sur une URL spécifique
  • Gestion des services Exchange : Désactiver un service Exchange vulnérable
  • Gestion des pools d'applications : Désactiver un pool d'applications vulnérable

 La mise en place de cette nouvelle fonctionnalité nécessite :

    • l'installation du module IIS URL Rewrite, qui s’ajoute désormais aux prérequis systèmes à l’installation/mise à jour d’Exchange.
    • Le serveur doit accéder à l’url https://officeclient.microsoft.com/getexchangemitigations
    • Si Windows Server 2012 R2 est utilisé pour Exchange 2016, il faut installer la KB2999226.

Lors de l'installation/upgrade, il y a un changement d’accord de licence selon si vous souhaitez partager des données de diagnostics avec Microsoft ou non: Le switch /IAcceptExchangeServerLicenseTerms a été remplacé par:

    • /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
    • /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

Vous pouvez activer/désactiver le partage de des données de diagnostics unitairement par serveur avec la commande :

Set-ExchangeServer -Identity <ServerName> -DataCollectionEnabled $false

Vous pouvez activer/désactiver la fonctionnalité EM au niveau de l’organisation, ou au niveau serveur.

Set-OrganizationConfig -MitigationsEnabled $false

Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $false

Après l’application d’un Security Update (SU), la mitigation associée est conservée, il faut retirer la mitigation manuellement

- Les activités des mitigations sont logés dans le journal des évènements des serveurs : (source MSExchange Mitigation Service) et dans le répertoire V15\Logging\MitigationService

Comment déterminer le type de client (OWA, Outlook, Mobile) utilisé pour un mail envoyé

Dans certains cas, on nous demande de déterminer quel type de client a été utilisé pour envoyer un mail particulier. 

Pour ce faire, utiliser les journaux de suivi des messages dans Exchange 2010, Exchange 2013 ou Exchange 2016.

Dans les journaux de suivi des messages, il existe un champ SourceContext qui signale la propriété ClientType pour les événements SUBMIT. Les événements SUBMIT sont générés quand le service de soumission de transport de boîte aux lettres transmet un message au service de transport, c’est-à-dire lorsque le serveur Exchange récupère le courrier électronique de la boîte d’envoi de la boîte aux lettres et le transmet pour remise.

A noter qu'il n’y a pas d’événement SUBMIT lorsqu’un expéditeur externe envoie un e-mail à un utilisateur interne. Cela signifie qu’il n’y a pas de propriété ClientType pour ces e-mails.

  • Pour vérifier le type de client pour un e-mail envoyé, exécuter la commande suivante dans un environnement Exchange powershell et regarder le champ SourceContext pour l’e-mail en question:

Get-MessageTrackingLog -ResultSize Unlimited -Start "10/20/2021 10:00" -EventID SUBMIT | fl TimeStamp,Sender,Recipients,MessageSubject,SourceContext

  • La valeur du champ SourceContext peut être :
  • AirSync--> il s’agit du client ActiveSync : le mail est envoyé depuis un périphérique mobile
  • OWA--> il s’agit du client Webmail : le mail est envoyé depuis l’interface exchange web mail
  • MOMT--> il s’agit des clients qui se connectent à l'aide d'Outlook ou toute autre application via RPC/HTTP ou MAPI/HTTP 

 Les e-mails de surveillance ont également un type de client qui est Monitoring

Exchange - Redémarrage des serveurs après création du DAG

Symptômes et Diagnostic:

- Après la configuration du DAG, les serveurs Exchange redémarrent d'une manière inattendue et fréquente.

- Le message d'erreur "The computer has rebooted from a bugcheck.  The bugcheck was: 0x000000ef (0xffffe0016a359900, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 090915-32687-01" est repéré au niveau des journaux d'évènements système.

- Exécuter commande PowerShell suivante sur le serveur Exchange affecté afin de déterminer quel Probe provoquant le redémarrage des serveurs:

(Get-WinEvent -LogName Microsoft-Exchange-ManagedAvailability/* | % {[XML]$_.toXml()}).event.userData.eventXml| ?{$_.ActionID -like "*ForceReboot*"} | ft RequesterName

--> Responder ServiceHealthMSExchangeReplForceReboot entraine le redémarrage des serveurs Exchange Mailbox

- Afin de confirmer que le redémarrage du serveur est bien dû au ServiceHealthMSExchangeReplForceReboot, exécuter la commande:

Get-WinEvent -LogName Microsoft-Exchange-ManagedAvailability/* | where {$_.Message -like "*ServiceHealthMSExchangeReplForceReboot*"} | ft Message,TimeCreated

 Explications et Résolution:

- Avec le nouveau concept « Managed Availability » s’exécutant sur tous les serveurs Exchange pour surveiller l’intégrité des serveurs, ce processus analyse des centaines de mesures d’intégrité et lorsque quelque chose ne va pas se produit, une action sera appelée pour corriger ce problème.

- Dans certains cas, lorsque "Managed Availability" effectue une action de récupération à partir d’une erreur, il est intéressant de savoir quelles mesures d’intégrité "Probe" sont utilisées pour décider que le composant ou le serveur Exchange a besoin d’un correctif.

- Cause: Les cartes réseaux sont mal configurées sur les serveurs Exchange, ce qui entraîne une défaillance de la résolution du nom DNS et le redémarrage des serveurs.

- Dans ce cas de figure et pour résoudre le problème décrit ci-dessus, la case "Enregistrer les adresses de cette connexion dans le système DNS" doit être cochée.

 

 

Outlook 2016 : Problème du certificat de sécurité du serveur proxy après son changement

Description du problème
Après avoir remplacé un certificat wildcard par un certificat SAN, les clients distants utilisant Microsoft Outlook ne peuvent plus se connecter à leurs comptes de messagerie sur un serveur Exchange à l'aide de la méthode de proxy HTTP. Outlook affiche le message d'erreur dessous, puis demande à plusieurs reprises un mot de passe:

Explication et Résolution

Microsoft Outlook 2016 utilise exclusivement la découverte automatique pour configurer les comptes Exchange. Il faut donc s’assurer que l’autodiscover utilise le nom principal correct du certificat :

  • Se connecter au serveur Exchange et démarrer Exchange Management Shell puis exécuter la commande Get-OutlookProvider -Identity EXPR | fl
  • Vérifier les valeurs:
    CertPrincipalName - doit avoir le nom principal commun et correct du certificat SSL au format: msstd:mail.domain.com
    Server - doit être vide

--> si la valeur du paramètre CertPrincipalName est incorrecte, la commande suivante sera exécutée pour la modifier:
Set-OutlookProvider EXPR -CertPrincipalName msstd: mail.domain.com
 Vérifier le résultat via l’exécution de la commande : Get-OutlookProvider -Identity EXPR | fl CertPrincipalName

--> si la valeur du champ le serveur n'est pas vide, exécuter la commande suivante pour l'effacer: Set-OutlookProvider -id EXPR  $null

Vérifier le résultat via l’exécution de la commande : Get-OutlookProvider -Identity EXPR | fl server

Redémarrage automatique de Windows Server 2016

Dans Windows Server 2016, les mises à jour de Windows sont partiellement contrôlées par un nouveau service d'orchestrateur de mise à jour ainsi que par le service de mise à jour de Windows. Le service orchestrateur utilise une série de tâches planifiées pour vérifier les nouvelles mises à jour installées et planifie un redémarrage à tout moment en dehors des "heures actives" de 12 heures si le service détecte qu'une mise à jour a été installée.

Les modèles de stratégie ADMX pour la stratégie de groupe Windows Server 2016 ne semblent pas avoir de contrôle sur les redémarrages des mises à jour pour le moment.

Cependant, il y a une solution de contournement manuelle pour arrêter le redémarrage automatique via l'orchestrateur, tout en autorisant l'installation des mises à jour jusqu'à ce que Microsoft publie des contrôles avec plus de granularité.

Pour désactiver le redémarrage automatique des mises à jour:

  1. Ouvrir le planificateur de tâches puis naviguer dans la bibliothèque de tâches Microsoft --> Windows --> UpdateOrchestrator,
  2. Désactiver la tâche "Reboot" en cliquant droit sur la tâche de redémarrage comme ci-dessous et en sélectionnant Désactiver dans le menu contextuel.
  3. Une fois que la tâche "Reboot" ait le statut Désactivé, fermer le planificateur de tâches.
  4. Accéder au dossier C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator et cliquer droit sur le fichier de redémarrage puis sélectionner Propriétés. Dans la fenêtre Propriétés de redémarrage, sélectionner l'onglet Sécurité puis Modifier

  5. Pour tous les types d'accès, définir la sécurité des fichiers sur Refuser sur SYSTEME, SERVICE LOCAL , SERVICE RESEAU en sélectionnant chacun des utilisateurs mentionnés à tour de rôle et en cochant la case Refuser pour Contrôle total comme ci-dessous (cela empêche Windows de réactiver la tâche de Reboot)

Transfert des NDR/DSN dans une Boîte aux Lettres dédiée

Exchange Server utilise les notifications d'état de remise (DSN) pour fournir des rapports de non-remise (NDR) et d'autres messages d'état aux expéditeurs de messages.

Tous les rapports de non-remise générés peuvent être transférés vers une boîte aux lettres afin que vous puissiez surveiller les rapports de non-remise internes et externes et éviter d'être mis dans la black liste.

Les notifications d'état ne peuvent être transféré qu'à une boîte aux lettres nommé "Postmaster" et non pas à un groupe de distribution.

  • Etape 1

Créer une boîte aux lettres avec l'adresse principale: Postmaster@domainname  avec le nom d'adffichage: Postmaster

  • Etape 2

- Par défaut, l’adresse postmaster externe sera vide,

- Exécuter la commande suivante afin de récupérer tous les NDR externes (Courrier envoyé de la part d'une BAL externe vers une BAL interne inexistante):

Set-TransportConfig -ExternalPostmasterAddress postmaster@domainename

  • Etape 3

- Exécuter la commande suivante afin de récupérer tous les NDR internes (Courrier envoyé de la part d'une BAL interne vers une BAL interne inexistante)

Set-OrganizationConfig -MicrosoftExchangeRecipientReplyRecipient postmaster@domainname

 

  • Etape 4

Avec la cmdlet Set-TransportConfig, utiliser le paramètre GenerateCopyOfDSNFor afin de contrôler les rapports de non-remise (NDR) qui sont copiés sur une boîte aux lettres en spécifiant les codes DSN à surveiller séparés par des virgules.

Exemple:

Set-TransportConfig -GenerateCopyOfDSNfor 5.1.1,5.7.5

 

--> Pour supprimer ou ajouter des codes DSN :

 Set-TransportConfig -GenerateCopyOfDSNFor @{Add="5.7.1"; Remove="5.1.1"}

--> Pour seulement ajouter des codes DSN:

Set-TransportConfig -GenerateCopyOfDSNFor @{Add="5.7.1"}

 

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.