Partager via

Notes de publication relatives à Exchange 2013

  • Article

S’applique à : Exchange Server 2013

Bienvenue dans Microsoft Exchange Server 2013. Cette rubrique contient des informations importantes que vous devez connaître pour déployer Correctement Exchange 2013. Veuillez lire entièrement cette rubrique avant de commencer votre déploiement.

Cette rubrique comprend les sections suivantes :

  • Installation et déploiement

  • Environnement de ligne de commande Exchange Management Shell

  • Boîte aux lettres

  • Dossiers publics

  • Flux de messagerie

  • Connectivité client

  • Coexistence avec Exchange 2010

Installation et déploiement

  • msExchProductId ne reflète pas la version release d’Exchange 2013 installée Une fois qu’Exchange a étendu votre schéma Active Directory et préparé Active Directory pour Exchange, plusieurs propriétés sont mises à jour pour indiquer que la préparation est terminée. L’une de ces propriétés est msExchangeProductId sous le CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain> conteneur dans le contexte d’affectation de Configuration noms. Si aucune modification du schéma Active Directory n’est introduite dans la version d’Exchange 2013 que vous installez, cette propriété n’est pas mise à jour ou peut afficher une valeur inattendue. Cela peut entraîner une confusion si la valeur ne correspond pas à la version d’Exchange 2013 en cours d’installation.

    Ce comportement est attendu, car la valeur de msExchProductId ne reflète pas la version d’Exchange 2013 en cours d’installation. Cette propriété reflète la version d’Exchange 2013 qui a apporté les dernières modifications au schéma Active Directory. Pour éviter toute confusion, nous vous recommandons de suivre les étapes décrites dans la section Comment savez-vous que cela a fonctionné ? de Préparer Active Directory et les domaines pour vérifier que votre Active Directory a été mis à jour et qu’il est prêt pour la version d’Exchange 2013 que vous installez.

  • Le programme d’installation demande incorrectement .NET Framework 4.0 : si vous essayez d’installer Exchange 2013 sans .NET Framework installé sur l’ordinateur, le programme d’installation vous demande à tort d’installer .NET Framework 4.0 quand, en fait, .NET Framework 4.5 ou version ultérieure est requis.

    Pour contourner ce problème, installez .NET Framework 4.5 ou version ultérieure. Vous n’avez pas besoin d’installer .NET Framework 4.0. Pour obtenir la liste complète des prérequis, consultez Configuration requise pour Exchange 2013.

  • Les fichiers de configuration d’application Exchange XML sont remplacés lors de l’installation de la mise à jour cumulative : tous les paramètres exchange ou Internet Information Server personnalisés par serveur que vous définissez dans les fichiers de configuration d’application Exchange XML, par exemple, les fichiers web.config sur les serveurs d’accès au client ou le fichier EdgeTransport.exe.config sur les serveurs de boîtes aux lettres, seront remplacés lorsque vous installez une mise à jour cumulative Exchange ou un Service Pack. Veuillez enregistrer ces informations pour configurer à nouveau votre serveur après l’installation. Vous devez reconfigurer ces paramètres après avoir installé une mise à jour cumulative Exchange ou un Service Pack.

  • L'installation d'Exchange à l'aide d'autorisations d'administration déléguée entraîne l'échec de la configuration Lorsqu'un utilisateur membre du groupe de rôles Installation déléguée uniquement tente d'installer Exchange sur un serveur préconfiguré, l'installation échoue. Cela s'explique par le fait que le groupe Installation déléguée ne dispose pas des autorisations requises pour créer et configurer certains objets dans Active Directory.

    Pour contourner ce problème, effectuez l’une des opérations suivantes :

    • Ajoutez l’utilisateur installant Exchange au groupe de sécurité Administrateurs du domaine Active Directory.

    • Installez Exchange en vous servant d'un utilisateur membre du groupe de rôles Gestion de l'organisation.

Pour plus d’informations sur l’installation d’Exchange 2013, consultez Planification et déploiement.

Environnement de ligne de commande Exchange Management Shell

  • L’interpréteur de commandes charge de manière inattendue les applets de commande Exchange 2007 ou Exchange 2010 Auparavant, l’ouverture de l’interpréteur de commandes sur un serveur Exchange 2013 entrait l’ouverture d’une connexion au serveur local ou à un autre serveur exécutant Exchange 2013. Lorsque la connexion est établie, les applets de commande Exchange 2013 sont chargées. À compter d’Exchange 2013 CU11, l’interpréteur de commandes se connecte au serveur Exchange où se trouve la boîte aux lettres de l’utilisateur connecté. Si l’utilisateur connecté n’a pas de boîte aux lettres, l’interpréteur de commandes se connecte au serveur où se trouve la boîte aux lettres d’arbitrage SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}. Le serveur cible peut être n’importe quelle version prise en charge d’Exchange. Cela signifie que si la boîte aux lettres de l’utilisateur connecté (ou la boîte aux lettres d’arbitrage si l’utilisateur n’a pas de boîte aux lettres) se trouve sur un serveur Exchange 2010, l’interpréteur de commandes se connecte à ce serveur et charge les applets de commande Exchange 2010. Cela peut vous empêcher d’effectuer certaines tâches, car les applets de commande Exchange 2010 ne peuvent pas gérer la configuration ou les serveurs Exchange 2013.

    À compter d’Exchange 2013 CU11, ce comportement est par nature. Pour vous assurer que l’interpréteur de commandes charge les applets de commande Exchange 2013, déplacez la boîte aux lettres de l’utilisateur connecté vers Exchange 2013. Si l’utilisateur connecté n’a pas de boîte aux lettres, déplacez la boîte aux lettres d’arbitrage SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} vers un serveur Exchange 2013.

    Pour plus d’informations et sur la façon de déplacer la boîte aux lettres d’arbitrage, consultez Shell de gestion Exchange et ancrage de boîte aux lettres sur le blog de l’équipe Exchange.

Boîte aux lettres

  • Les serveurs de boîtes aux lettres exécutant différentes versions d’Exchange peuvent être ajoutés au même groupe de disponibilité de base de données L’applet de commande Add-DatabaseAvailabilityGroupServer et le centre d’administration Exchange autorisent de manière incorrecte l’ajout d’un serveur Exchange 2013 à un groupe de disponibilité de base de données (DAG) basé sur Exchange 2016, et inversement. Exchange prend en charge uniquement l'ajout de serveurs de boîte aux lettres exécutant la même version (Exchange 2013 et Exchange 2016, par exemple) à un DAG. En outre, le Centre d'administration Exchange affiche les serveurs Exchange 2013 et Exchange 2016 dans la liste des serveurs disponibles pour être ajoutés à un DAG. Cela pourrait permettre à un administrateur d'ajouter par inadvertance un serveur exécutant une version incompatible d'Exchange à un DAG (par exemple, d'ajouter un serveur Exchange 2013 à un DAG Exchange 2016).

    Il n'existe actuellement aucune solution pour contourner ce problème. Les administrateurs doivent faire preuve de vigilance lors de l'ajout d'un serveur de boîte aux lettres à un DAG. Ajoutez uniquement des serveurs Exchange 2013 à des DAG Exchange 2013, et uniquement des serveurs Exchange 2016 à des DAG Exchange 2016. Vous pouvez différencier chaque version d'Exchange en consultant la colonne Version dans la liste des serveurs du Centre d'administration Exchange. Voici les versions de serveur pour Exchange 2013 et Exchange 2016 :

    • Exchange 2013 15.0 (Build xxx.xx)

    • Exchange 2016 15.1 (Build xxx.xx)

  • Augmentation de la taille de la boîte aux lettres lors de la migration à partir de versions précédentes d’Exchange : lorsque vous déplacez une boîte aux lettres d’une version antérieure d’Exchange vers Exchange 2013, la taille de boîte aux lettres signalée peut augmenter de 30 % à 40 %. L’espace disque utilisé par la base de données de boîtes aux lettres n’a pas augmenté, seule l’attribution de l’espace utilisé par chaque boîte aux lettres a augmenté. L’augmentation de la taille de la boîte aux lettres est due à l’inclusion de toutes les propriétés d’élément dans les calculs de quota, ce qui fournit un calcul plus précis de l’espace consommé par les éléments dans leur boîte aux lettres. Cette augmentation peut amener certains utilisateurs à dépasser leurs quotas de taille de boîte aux lettres lorsque leur boîte aux lettres est déplacée vers Exchange 2013.

    Pour empêcher les utilisateurs de dépasser leurs quotas de taille de boîte aux lettres, augmentez les valeurs de quota de base de données ou de boîte aux lettres pour prendre en charge le nouveau calcul de quota. Pour configurer des valeurs de quota de base de données ou de boîte aux lettres, utilisez les paramètres IssueWarningQuota, ProhibitSendQuota et ProhibitSendReceiveQuota sur les applets de commande Set-MailboxDatabase et Set-Mailbox , respectivement.

  • Les clients Outlook 2007 et Outlook 2010 peuvent ne pas pouvoir télécharger le carnet d’adresses en mode hors connexion : si l’URL interne du carnet d’adresses en mode hors connexion (OAB) n’est pas accessible à partir d’Internet, les clients Outlook 2007 et Outlook 2010 risquent de ne pas pouvoir télécharger le carnet d’adresses en mode hors connexion.

    Pour contourner ce problème pour les clients Outlook 2007 et Outlook 2010, rendez l’URL interne du carnet d’adresses en mode hors connexion accessible à partir d’Internet. Outlook 2013 n’est pas affecté par ce problème.

  • L’installation d’Exchange 2013 dans une organisation Exchange existante peut amener tous les clients à télécharger le carnet d’adresses en mode hors connexion : l’installation du premier serveur Exchange 2013 dans une organisation Exchange 2007 ou Exchange 2010 existante peut amener tous les clients de l’organisation à télécharger une nouvelle copie du carnet d’adresses en mode hors connexion, ce qui entraîne la saturation du réseau et des problèmes de performances du serveur. Ce problème se produit car Exchange 2013 crée un nouveau carnet d’adresses en mode hors connexion par défaut dans l’organisation qui remplace le carnet d’adresses en mode hors connexion Exchange 2007 ou Exchange 2010. Les boîtes aux lettres qui n’ont pas de carnet d’adresses en mode hors connexion spécifique ou qui se trouvent sur une base de données de boîtes aux lettres qui n’a pas de carnet d’adresses en mode hors connexion spécifique, téléchargent le nouveau carnet d’adresses en mode hors connexion par défaut.

    Pour empêcher les clients de télécharger une nouvelle copie du carnet d’adresses en mode hors connexion lors de l’installation d’Exchange 2013, affectez un carnet d’adresses en mode hors connexion à chaque boîte aux lettres ou à la base de données de boîtes aux lettres sur laquelle se trouvent les boîtes aux lettres. Cette opération doit être effectuée avant l’installation d’Exchange 2013 dans l’organisation.

  • Les utilisateurs peuvent être routés vers une boîte aux lettres de génération de carnet d’adresses en mode hors connexion qui n’est pas responsable du carnet d’adresses en mode hors connexion demandé : Exchange 2013 CU5 et les versions ultérieures ont modifié la façon dont les OAB sont liées aux boîtes aux lettres de génération de carnet d’adresses en mode hors connexion. Cette modification permet à un utilisateur d’être routé vers une boîte aux lettres de génération de carnet d’adresses en mode hors connexion qui n’est pas responsable du carnet d’adresses en mode hors connexion demandé par l’utilisateur. Cela peut se produire si toutes les conditions suivantes sont remplies :

    • Vous avez plusieurs boîtes aux lettres de génération de carnet d’adresses en mode hors connexion dans votre organisation.

    • Vous mettez à niveau les serveurs de boîtes aux lettres qui hébergent les boîtes aux lettres de génération de carnet d’adresses en mode hors connexion avant de mettre à niveau vos serveurs d’accès au client.

    • Vous mettez à niveau vos serveurs Exchange 2013 d’une version antérieure à CU5 vers une version ultérieure (par exemple, la mise à niveau d’Exchange 2013 CU3 vers Exchange 2013 CU6).

    • Vos serveurs d’accès au client exécutent une version antérieure à CU5.

    Pour contourner ce problème, veillez à mettre à niveau vos serveurs d’accès au client vers Exchange 2013 CU6 ou version ultérieure avant de mettre à niveau vos serveurs de boîtes aux lettres. Cela permet de s’assurer que les serveurs d’accès au client savent comment proxyer les demandes vers la boîte aux lettres de génération de carnet d’adresses en mode hors connexion qui est chargée de générer le carnet d’adresses hors connexion de l’utilisateur.

    Pour en savoir plus sur les modifications du carnet d’adresses en mode hors connexion dans Exchange 2013 CU5, consultez Améliorations du carnet d’adresses en mode hors connexion dans la mise à jour cumulative 5 d’Exchange 2013.

Dossiers publics

  • Les expéditeurs non autorisés ne peuvent plus envoyer de messages à des dossiers publics à extension messagerie : avant Exchange 2013 CU6, les expéditeurs non autorisés pouvaient envoyer des messages à des dossiers publics à extension messagerie. Cela permettait aux expéditeurs externes d’envoyer des messages à des dossiers publics à extension messagerie, quelles que soient les autorisations définies sur le dossier public.

    À compter d’Exchange 2013 CU6, si vous souhaitez que des expéditeurs externes envoient des messages à un dossier public à extension messagerie, l’utilisateur anonyme doit disposer au moins de l’autorisation Créer des éléments . Si vous avez configuré des dossiers publics à extension messagerie et que vous ne l’avez pas fait, les expéditeurs externes recevront une notification d’échec de remise et les messages ne seront pas remis au dossier public à extension messagerie.

    Vous pouvez utiliser l'environnement de ligne de commande Exchange Management Shell ou Outlook pour définir les autorisations de l'utilisateur Anonyme. Pour en savoir plus sur la définition des autorisations de l'utilisateur Anonyme, consultez la rubrique Activation ou désactivation de la messagerie pour un dossier public.

  • Le nombre maximal de dossiers publics pouvant être migrés vers Exchange 2013 à partir de serveurs Exchange hérités est de 500 000. Pour plus d’informations sur la migration de dossiers publics, consultez Utiliser la migration par lots pour migrer des dossiers publics vers Exchange 2013 à partir de versions précédentes.

Flux de messagerie

  • Les applets de commande TransportAgent sur les serveurs d’accès au client nécessitent des Windows PowerShell locales : il existe un problème avec les applets de commande *-TransportAgent qui empêche ces applets de commande d’installer, de désinstaller et de gérer les agents de transport sur les serveurs d’accès au client à l’aide d’Exchange Management Shell. Pour installer, désinstaller et gérer les agents de transport sur les serveurs d’accès au client, vous devez charger manuellement le composant logiciel enfichable Exchange Windows PowerShell, puis exécuter les applets de commande *-TransportAgent. Si vous tentez d’installer, désinstaller ou gérer des agents de transport à l’aide d’Exchange Management Shell, vos modifications seront appliquées au serveur de boîtes aux lettres Exchange 2013 auquel vous êtes connecté.

    Pour installer, désinstaller ou gérer des agents de transport sur des serveurs d’accès au client, procédez comme suit sur le serveur d’accès au client que vous souhaitez gérer :

    Avertissement

    Le chargement du Microsoft.Exchange.Management.PowerShell.SnapIn composant logiciel enfichable Windows PowerShell et l’exécution d’applets de commande autres que les applets de commande -TransportAgent ne sont pas pris en charge et peuvent entraîner des dommages irréparables pour votre déploiement Exchange.

    Vous devez être administrateur local sur le serveur d’accès au client sur lequel vous souhaitez installer, désinstaller ou gérer les agents de transport. Nous ne prenons pas en charge la modification des listes de contrôle d’accès (ACL) sur les fichiers, répertoires ou objets Active Directory Exchange.

    Importante

    Effectuez la procédure suivante sur les serveurs d’accès au client uniquement. Vous n’avez pas besoin de charger le composant logiciel enfichable Exchange Windows PowerShell si vous souhaitez gérer les agents de transport sur les serveurs de boîtes aux lettres.

    1. Ouvrez une nouvelle fenêtre Windows PowerShell.

    2. Exécutez la commande suivante :

      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

    3. Effectuez normalement des tâches de gestion de l’agent de transport.

    4. Répétez cette procédure sur chaque serveur d’accès au client que vous souhaitez gérer.

Connectivité client

  • L’authentification NTLM échoue pour les clients non joints à un domaine : l’authentification entre un client, comme Windows Live Mail, et Exchange 2013 peut échouer lorsque les conditions suivantes sont remplies :

    • Ensuite, la méthode d’authentification utilisée par le client est NTLM.

    • L’ordinateur n’est pas joint au domaine.

    Pour contourner ce problème, vous pouvez effectuer l’une des opérations suivantes :

    • Joignez l’ordinateur sur lequel le client s’exécute au domaine.

    • Remplacez le type d’authentification utilisé par le client de NTLM par Authentification de base sur TLS.

  • L’authentification GSSAPI échoue lorsqu’elle est utilisée avec l’applet de commande Send-MailMessage : L’authentification GSSAPI (Generic Security Service Application Program Interface) peut échouer lorsque l’applet de commande Send-MailMessage, qui est incluse avec les installations par défaut de Windows PowerShell, est utilisée pour envoyer des messages authentifiés à Exchange 2013. Dans ce cas, vous verrez une entrée dans le journal des événements de l’application sur le serveur d’accès au client Exchange 2013 qui a reçu la connexion avec les informations suivantes :

    • Source : MSExchangeFrontEndTransport

    • ID d’événement : 1035

    • Description : L’authentification entrante a échoué avec une erreur IllegalMessage pour le nom> du serveur frontal < du client du connecteur de réception. Le mécanisme d’authentification est Gssapi. L’adresse IP source du client qui a tenté de s’authentifier auprès d’Exchange est [<adresse >IP du client].

    Pour contourner ce problème, vous devez supprimer la Integrated méthode d’authentification du connecteur de réception du client sur vos serveurs d’accès au client Exchange 2013. Pour supprimer la Integrated méthode d’authentification d’un connecteur de réception client, exécutez la commande suivante sur chaque serveur d’accès au client Exchange 2013 susceptible de recevoir des connexions à partir d’ordinateurs exécutant l’applet de commande Send-MailMessage :

    Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS

  • MAPI sur HTTP peut présenter des performances médiocres lors de la mise à niveau vers Exchange 2013 SP1 : si vous effectuez une mise à niveau à partir d’une mise à jour cumulative Exchange 2013 vers Exchange 2013 SP1 et que vous activez MAPI sur HTTP, les clients qui se connectent à un serveur Exchange 2013 SP1 à l’aide du protocole peuvent rencontrer des performances médiocres. Cela est dû au fait que les paramètres requis ne sont pas configurés lors d’une mise à niveau à partir d’une mise à jour cumulative vers Exchange 2013 SP1. Ce problème ne se produit pas si vous effectuez une mise à niveau vers Exchange 2013 SP1 à partir d’Exchange 2013 RTM ou si vous installez un nouveau serveur Exchange 2013 SP1 ou version ultérieure.

    Remarque

    Il s’agit d’un problème uniquement si le protocole MAPI sur HTTP est activé sur vos serveurs d’accès au client. Il est désactivé par défaut. Si MAPI sur HTTP est désactivé, les clients utilisent le protocole RPC sur HTTP à la place.

    Pour contourner ce problème, procédez comme suit :

    1. Sur les serveurs exécutant le rôle serveur d’accès au client, exécutez les commandes suivantes dans une invite de commandes Windows :

      set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"

    2. Sur les serveurs exécutant le rôle Serveur de boîtes aux lettres, exécutez les commandes suivantes dans une invite de commandes Windows :

      set AppCmdLocation=%windir%\System32\inetsrv
set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiMailboxAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiMailboxAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiMailboxAppPool"

%AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiAddressBookAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiAddressBookAppPool_CLRConfig.config"
%AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiAddressBookAppPool"

Coexistence avec Exchange 2010

  • Les demandes d’accès aux boîtes aux lettres Exchange 2010 peuvent ne pas fonctionner lorsqu’elles sont transmises par proxy via des serveurs d’accès au client Exchange 2013 : dans certains cas, la demande de proxy entre les serveurs d’accès au client Exchange 2013 et Exchange 2010 Service Pack 3 (SP3) sans correctif cumulatif installé peut ne pas fonctionner correctement et une erreur s’affiche. Cela peut se produire si toutes les conditions suivantes sont remplies :

    • Un utilisateur disposant d’une boîte aux lettres Exchange 2013 tente d’ouvrir une boîte aux lettres Exchange 2010 à l’aide de l’une des méthodes suivantes :

      • L’option Ouvrir une autre boîte aux lettres dans Outlook Web App -OR-

      • L’option Autre utilisateur dans le Centre d’administration Exchange

      • Le serveur d’accès au client auquel l’utilisateur s’est connecté exécute Exchange 2013.

      • Le serveur d’accès au client Exchange 2010 a été mis à niveau vers Exchange 2010 SP3 de la version de mise en production (RTM) d’Exchange 2010 ou d’un Service Pack Exchange 2010 antérieur.

    Si toutes les conditions ci-dessus sont remplies, l’utilisateur ne peut pas accéder aux options Exchange 2010 Outlook Web App de l’autre utilisateur et une page vierge peut s’afficher.

    Pour contourner ce problème, installez exchange 2010 SP3 Correctif cumulatif 1 ou version ultérieure sur chaque serveur Exchange 2010.