PI Services

Le blog des collaborateurs de PI Services

Office365/Exchange 2013/2016_Installation et configuration de l'agent des stratégies de routage du carnet d'adresses

Problématique:

Si vous avez plusieurs GAL dans l'environnement de messagerie séparées à l'aide de politiques de carnet d'adresses, un utilisateur de la GAL1 peut afficher les informations de contact de l'utilisateur GAL2. Pour éviter ça, vous pouvez activer l'agent de routage ABP.

Le routage des stratégies de carnet d’adresses contrôle la façon dont les destinataires sont résolus dans les organisations utilisant des stratégies de carnet d’adresses. Lorsque l'agent de routage ABP (Address Book Policy) est installé et configuré, les utilisateurs affectés à différentes listes d’adresses globales (GAL) apparaissent en tant que destinataires externes.

Pour Installer l'agent de routage des stratégies de carnet d'adresses :

  1. Exécuter la commande suivante dans un environnement Exchange powershell :

Install-TransportAgent -Name "ABP Routing Agent" -TransportAgentFactory "Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent.AddressBookPolicyRoutingAgentFactory" -AssemblyPath $env:ExchangeInstallPath\TransportRoles\agents\AddressBookPolicyRoutingAgent\Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent.dll

Ignorer pour le moment le message d’avertissement indiquant que le service de transport doit être redémarré pour que vos modifications soient appliquées et passer à l'étape 2 de manière à ne redémarrer le service de transport qu'une seule fois.

  1. Activer l’agent en exécutant la commande suivante :

Enable-TransportAgent "ABP Routing Agent"

  1. Redémarrer le service de transport en exécutant la commande suivante :

Restart-Service MSExchangeTransport

  1. Après le redémarrage du service, vérifier que l'agent de routage des stratégies de carnet d'adresses est installé et activé en exécutant la cmdlet suivante :

Get-TransportAgent

Si l’agent de routage de carnet d’adresses est répertorié, donc il a été correctement installé.

  1. Activer par la suite le routage des stratégies de carnet d'adresses pour l'organisation en exécutant la commande suivante :

Set-TransportConfig -AddressBookPolicyRoutingEnabled $true

Désormais, les autres utilisateurs de la liste d’adresses globale GAL1 ne peuvent plus afficher les autres utilisateurs de la liste d’adresses globale GAL2

Exchange Onprem_Déterminer le nombre d'utilisateurs utilisant réellement POP et IMAP

 

Contexte

Il existe de nombreuses boîtes aux lettres dans Exchange onpremise pour lesquelles IMAP et POP sont activés, mais est ce que réellement ces protocoles sont utilisés pour se connecter à Exchange ou pas ?

Démarche

Récupérons tout d'abord les utilisateurs pour lesquels IMAP et POP sont activés dans l'environnement Exchange Onpremise, puis comparons-les aux journaux IMAP et POP.

  1. Télécharger l’outil Log Parser Download Log Parser 2.2 from Official Microsoft Download Center puis installer-le au niveau du poste depuis lequel l’analyse sera effectuée.
  2. Filtrer les utilisateurs avec IMAP et POP activés en exéxutant tout d'abord les commandes suivantes au niveau de l'interface Exchange Powershell :

    $ImapEnabled = Get-CASMailbox -Filter {Imapenabled -eq $true} -ResultSize unlimited

    $PopEnabled = Get-CASMailbox -Filter {Popenabled -eq $true} -ResultSize unlimited

  3. Analyser les journaux IMAP et POP pour voir quels comptes se connectent réellement à ces protocoles.

  4. Examiner et comparer les deux ensembles de données :

Utiliser Excel ou des commandes similaires à celles ci-dessous :

Compare-Object $ImapLogs $($ImapEnabled.name) | Where sideindicator -eq “<=”

Compare-Object $POPLogs $($POPEnabled.name) | Where sideindicator -eq “<=”

 

Les utilisateurs qui utilisent activement IMAP et POP sont stockés respectivement dans les $IMAPLogs et $POPLogs. Tous les autres trouvés dans $IMAPEnabled et $POPEnabled et qui ne sont pas dans $IMAPLogs et $POPLogs pourraient avoir les protocoles potentiellement désactivés. 

 

Exchange_Erreur de suppression de l'abonnement Edge 2010 dans une infrastructure Exchange 2013

Description du problème

Lorsqu’il s’agit de supprimer l’abonnement Edge 2010 dans une organisation contenant des serveurs Exchange 2013, le message d'erreur ci-dessous apparaît suite à l'exécution de la commande Remove-EdgeSubscription servername, 

Remove-EdgeSubscription : Impossible d’effectuer cette modification car la propriété ExchangeVersion de l’objet est 0.20 (15.0.0.0), ce qui n’est pas pris en charge par la version actuelle 0.1 (8.0.535.0). Vous aurez besoin d’une version plus récente d’Exchange pour effectuer cette modification. Nom de la propriété : ExchangeVersion
At line:1 char:24 + Remove-EdgeSubscription <<<< edge2 -Verbose
+ CategoryInfo : NotSpecified: (0:Int32) [Remove-EdgeSubscription], DataValidationException
+ FullyQualifiedErrorId : D8A49A14,Microsoft.Exchange.Management.SystemConfigurationTasks.RemoveEdgeSubscription

 

Explication et Résolution

La commande Remove-EdgeSubscription supprime à la fois l’abonnement et tous les objets abonnés de la base de données ADAM locale sur le serveur Edge. Mais si l’un de ces objets abonnés a été créé sur Exchange 2013 après son installation, ils auront une version ExchangeVersion égale à 0.20 (15.0.0.0) et Exchange 2010 SP3 ne peut pas traiter cet objet d'ou le message d'erreur dessus.

 

Pour résoudre ce problème, via ADSIEDIT, recherchez et supprimez manuellement l’objet avec une version Exchange 0.20 (15.0.0.0) de la base de données AD LDS, puis réexécutez la cmdlet Remove-EdgeSubscription, cela devrait maintenant fonctionner (sauf si vous avez deux objets ou plus avec le numéro de version le plus élevé à chercher et à supprimer).

  1. Pour rechercher des objets avec une version ExchangeVersion supérieure à "0.1 (8.0.535.0)", correspondante à la version qu’Exchange 2010, ouvrez ADSIEdit sur le serveur Edge.

2. Cliquez avec le bouton droit sur le nœud ADSI Edit en haut de la fenêtre et choisissez Connect to...

3. Dans la boîte de dialogue Paramètres de connexion (illustrée ci-dessus), définissez le champ Sélectionner un contexte d’appellation connu sur Configuration . Tapez le nom du serveur local et le port AD LDS dans le champ Sélectionner ou taper un domaine ou un serveur. La valeur "server:port" doit être EDGESERVERNAME:50389

5. Développez l’arborescence jusqu’à ce que vous atteigniez CN=First organisation,CN=Microsoft Exchange,CN=Services,CN=Configuration,CN={...................}

6. Vous devez maintenant examiner chaque objet dont la valeur msExchVersion n’est pas 4535486012416. Par exemple, si vous aviez créé un domaine accepté en raison de la fédération dans Exchange 2013, il s’agirait d’un nouvel objet depuis 2010. Cet objet (sous CN=Accepted Domains,CN=Transport Setting,...) a la valeur 88218628259840. 

  • Pour vérifier qu’il s’agit de l’objet correct à supprimer manuellement, entrez Get-Object |FT name,ExchangeVersion à partir de l’environnement de ligne de commande Exchange Management Shell sur le serveur Edge où Object est la cmdlet que vous cherchez à interroger - dans le présent cas, ce serait Get-AcceptedDomain. Cet objet a une version ExchangeVersion plus récente et c’est donc (au moins) cet objet empêche la suppression de l'abonnement Exchange.
  • Supprimez manuellement l’objet dans ADSI Edit (vous pouvez le faire en toute sécurité, car il sera resynchronisé à partir de l’organisation Exchange si vous recréez l’abonnement Edge ultérieurement). Ne le supprimez pas d’Active Directory avec ADSI Edit, mais uniquement d’AD LDS. Veillez à ne supprimer que cet objet et non l’objet parent.

7. Une fois cet objet est supprimé, réessayez Remove-EdgeSubscription servername. S’il s’agit du seul objet, l’abonnement Edge sera supprimé du serveur Edge.

 

 

 

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 MSExchange Autodiscover_Event ID 1

Dans Exchange 2016, vous remarquerez des messages d'erreurs  "MSExchange Autodiscover" avec l'Event ID 1 dans le journal des événements d'application du serveur :

 

Ce problème a été résolu dans Exchange 2016 CU15 et Exchange 2019 CU4, mais apparaît parfois dans des versions plus récentes.

Il s'agit d'un problème connu chez Microsoft et la solution de contournement est simple:

  • Définissez la propriété ExternalURL du répertoire virtuel Autodiscover, comme ceci:

Get-AutodiscoverVirtualDirectory -Server | Set-AutodiscoverVirtualDirectory -ExternalUrl https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml

Exchange Hybride_Configuration TLS pour les connecteurs de réception

Si vous souhaitez utiliser TLS ou utilisez l'authentification TLS dans un environnement Office 365 hybride ou encore vous avez modifié ou renouvelé manuellement le certificat SSL, vous pouvez toujours obtenir des erreurs indiquant que vous ne pouvez pas lancer la session TLS (STARTTLS), même si le certificat SSL a été correctement renouvelé.

Il ne suffit pas de définir le certificat SSL à utiliser avec SMTP pour que TLS fonctionne correctement. Vous devez également (re)configurer le nom du certificat TLS sur vos connecteurs de réception.

Pour formater correctement le contenu du TlsCertificateName, vous pouvez l'extraire du certificat via des commandes ci-dessous.

  • Dans un environnement Exchange Management Shell, récupérez les certificats actuels :

Get-ExchangeCertificate

  • Vous obtiendrez une liste de tous les certificats, mais vous n'aurez besoin que de celui à utiliser pour TLS, que vous pouvez extraire en spécifiant son empreinte :

$cert = Get-ExchangeCertificate -Thumbprint DE67EC3C8D679DC35D171341FEC5148D012B1BAE2

  • À partir de la variable précédemment créée, vous pouvez maintenant compiler la valeur pour le nom du certificat TLS :

$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"

  • Avec la nouvelle variable, vous pouvez maintenant changer chaque connecteur de réception en activant le TLS et modifiant le nom du certificat TLS :
    Set-ReceiveConnector "Inbound from Office 365" -RequireTLS $True -TlsCertificateName $tlscertificatename

Erreur Setup /PrepareSchema dans un environnement existant d'Exchange hybride

Lors de la préparation d'Active Directory pour Exchange 2016 ou pour l'installation d'CU à l'aide du commutateur /PrepareSchema pour un environnement existant d'Exchange hybride, l'erreur suivante est (parfois) générée :

Un problème similaire se produira si vous spécifiez uniquement /PrepareAD

--> Pour résoudre le problème il faut générer le fichier de configuration XML depuis le tenant office 365 puis l'utiliser avec la commande /PrepareAD.

  • Pour générer le fichier de configuration XML, connectez-vous à Exchange Online à l'aide de PowerShell. Une fois connecté et authentifié, exécutez la commande suivante:

Get-OrganizationConfig | Export-Clixml -Path C:\Temp\MyTenantOrganizationConfig.XML

  • Le commutateur /TenantOrganizationConfig ne peut être combiné qu'avec le commutateur /PrepareAD, il ne peut pas être utilisé avec  /PrepareSchema. Si vous le faites, cela générera un message d'erreur "Le paramètre 'tenantorganizationconfig' n'est pas valide pour l'opération en cours 'PrepareSchema'". Exécutez alors la commande ci-dessous dans un environnement CMD exécuté en tant qu'administrateur:

Setup.exe /PrepareAD /TenantOrganizationConfig C:\Temp\TenantOrganizationConfig.XML /IAcceptExchangeServerLicenseTerms

A noter:

Dans ce scénario, l'exécution du commutateur /PrepareAD déclenchera automatiquement le commutateur /PrepareSchema. Par conséquent, vous devez avoir en plus, les droits d’administrateur de schéma pour effectuer les modifications du schéma.

Exchange 2013/2016 - Configuration de plusieurs répertoires virtuels OWA/ECP

Vous pouvez ajouter des répertoires virtuels OWA/ECP supplémentaires pour les raisons suivantes :

  • Vous souhaitez séparer l'accès ECP administrateur et utilisateur pour empêcher l'accès au Centre d'administration Exchange à partir d'Internet.
  • Vous avez différents utilisateurs au sein d'une même organisation qui ont besoin d'une expérience OWA différente, comme un accès aux fichiers public/privé différent ou d'autres fonctionnalités de stratégie ou de segmentation.

Microsoft supporte l'utilisation de plusieurs répertoires virtuels Outlook Web App (OWA) et Exchange Control Panel/Admin Center (ECP) sur un serveur Exchange 2013/2016 lorsque chacun a son propre site Web et est nommé "OWA" et "ECP". Chaque répertoire virtuel doit être à l'écoute sur le port TCP 443 standard pour le site.

Vous devez vous assurer que le site Web par défaut est défini sur "Toutes non attribuées" pour les adresses IP, sinon des problèmes surviendront avec PowerShell.

Ci-dessous les instructions pour la création et la configuration des répertoires virtuels OWA/ECP sur Exchange 2013/2016.

  1. Ajoutez une adresse IP secondaire au serveur - cela peut être avec une autre carte réseau ou simplement en ajoutant une adresse IP à une carte réseau existante.
  2. Si vous avez ajouté une carte réseau, dans les propriétés de la carte, décochez « "enregistrer les adresses de cette connexion dans le système DNS" 
  3. Créez le site Web supplémentaire dans IIS dans un nouveau dossier racine (C:\inetpub\OWA_SECONDARY) et liez-le à la nouvelle adresse IP.
  4. Activez SSL en choisissant le certificat à utiliser pour ce site.
  5. Accordez au groupe IIS_IUSRS l'autorisation de lecture et d'exécution sur le dossier C:\inetpub\OWA_SECONDARY.
  6. Copiez le contenu du dossier racine du site Web par défaut dans son intégralité, y compris les sous-dossiers, dans le nouveau dossier racine du site (c'est-à-dire copiez le contenu %SystemDrive%\inetpub\wwwroot\ dans C:\inetpub\OWA_SECONDARY).
  7. Créez de nouveaux sous-dossiers OWA et ECP dans le dossier racine de votre nouveau site Web (C:\inetpub\OWA_SECONDARY\OWA, C:\inetpub\OWA_SECONDARY\ECP).
  8. Copiez l'intégralité du contenu des dossiers OWA et ECP du site Web par défaut, y compris les sous-dossiers, dans les nouveaux sous-dossiers du nouveau site Web. (Copié à partir de C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy).
  9. Exécutez ce qui suit (en remplaçant <Server> par le nom de votre serveur;
    New-OwaVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path "C:\inetpub\OWA_SECONDARY\OWA"
    New-EcpVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path "C:\inetpub\OWA_SECONDARY\ECP"
  10. Exécutez les commandes suivantes;
    Set-OwaVirtualDirectory -Identity "<serveur>\owa (site Web par défaut)" -FormsAuthentication $false -WindowsAuthentication $true
    Set-EcpVirtualDirectory -Identity "<serveur>\ecp (site Web par défaut)" -FormsAuthentication $false -WindowsAuthentication $true
  11. Effectuez un IISReset.

L'installation de CU ne mettra PAS à jour correctement les fichiers du site Web secondaire OWA ou ECP, et le site secondaire ne fonctionnera pas correctement. La seule solution prise en charge consiste à supprimer les Vdirs secondaires et le site Web et refaire toutes les étapes. Alors, assurez-vous d'avoir noté tous les paramètres non définis par défaut que vous aviez sur le site, puis supprimez les Vdirs, supprimez le site Web, supprimez tout contenu des dossiers et recommencez à l'étape 3 indiquée ci-dessus. Recréez le site Web, recréez les Vdirs, copiez les derniers fichiers et réappliquez toute configuration ou paramètre personnalisé que vous avez précédemment appliqué. Ne sautez aucune étape et ne prenez aucun raccourci.

Microsoft Exchange - les OUs ne s'affichent pas lors de la création d'une nouvelle BAL depuis l'EAC

Exchange Server 2013/2016 n’affiche pas la liste complète des unités d’organisation lors de la création d’une boîte aux lettres depuis la console d'administration Exchange.

RAISON:

  • Par défaut, l'ensemble de résultats du sélecteur d'unité d'organisation contient 500 entrées uniquement.
  • Lorsqu’il y a plus de 500 entrées, une nouvelle fenêtre est générée et cette fenêtre est vide ou contient un message (il existe d’autres éléments à afficher dans cet affichage).
  • Le sélecteur d'unité d'organisation n'interroge pas Active Directory avec -ResultSize Unlimited.

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

  1. Déterminez le nombre d’utilisateurs sur Exchange Server de boîtes aux lettres. Pour ce faire, exécutez la commande suivante (Get-OrganizationalUnit -ResultSize unlimited).count
  2. Sur le Exchange Server de boîtes aux lettres, allez dans le dossier suivant "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp"
  3. Ajoutez les lignes suivantes dans le fichier web.config juste au-dessus </appsettings> 

<!-- allows the OU picker when placing a new mailbox in its designated organizational unit to retrieve all OUs - default value is 500 -->
<add key="GetListDefaultResultSize" value="2000" />

 

4. Dans le Gestionnaire IIS, redémarrez le pool d’applications MSExchangeECPAppPool.

 Notes:

  • La valeur de GetListDefaultResultSize la clé doit dépasser le nombre d’utilisations trouvées à l’étape 1.
  • Vous devez modifier le fichier web.config sur tous les serveurs mailbox
  • Vous devez ajouter cette valeur chaque fois que vous installez une mise à jour cumulative.

Comment réduire la taille des boîtes aux lettres de découverte dépassant la limite de 50 Go

Les boîtes aux lettres de découverte dans Exchange sont utilisées pour stocker les résultats de recherche eDiscovery.

La taille maximale des boîtes aux lettres de découverte est 50 Go. Il est possible d'augmenter le quota à plus de 50 Go, mails il faut prendre en considération les limites suivantes:

  • Elles ne sont pas prises en charge.

  • Elles ne peuvent pas être migrés vers Microsoft Office 365.

  • S’il s'agit des boîtes aux lettres de découverte Exchange Server 2010, elles ne peuvent pas être mises à niveau vers des versions ultérieures.

Pour résoudre ce problème, vous pouvez créer plusieurs boites aux lettres eDiscovery et copier les résultats de la recherche de la grande boîte aux lettres de découverte dans les nouvelles:

  • Créer la boîte aux lettres de découverte via la commande:

New-Mailbox -Name <discovery mailbox name> -Discovery

Afin d'accéder à cette boîte aux lettres de découverte et visualiser les résultats de la recherche, attribuer des autorisations à un utilisateur ou à un groupe:

Add-MailboxPermission <discovery mailbox name> -User <name of user or group> -AccessRights FullAccess -InheritanceType all

  • Copier les résultats de la recherche dans une boîte aux lettres de découverte en créant tout d'abord une recherche de découverte:

New-MailboxSearch -Name "Search results from 2019" -SourceMailboxes "Discovery Search Mailbox" -StartDate "01/01/2019" -EndDate "12/31/2019" -TargetMailbox "Discovery Mailbox Backup 01" -EstimateOnly -StatusMailRecipients admin@contoso.com

puis démarrer la via la commande:

Start-MailboxSearch "Search results from 2019"

Si besoin régler la plage de dates pour augmenter ou diminuer le nombre de résultats de recherche renvoyés et copier les résultats dans la boîte aux lettres de découverte cible:

Set-MailboxSearch "Search results from 2019" -EstimateOnly $false

Start-MailboxSearch "Search results from 2019"

  • Supprimer les recherches de la boîte aux lettres de découverte d'origine afin de réduire sa taille

Remove-MailboxSearch -Identity <name of search>

Avant de supprimer une recherche, identifier la taille des résultats de recherche qui ont été copiés dans une boîte aux lettres de découverte via l'exécution de la commande:

Get-MailboxSearch | Format-List Name,TargetMailbox,ResultSizeCopied