Notes de publication relatives à Exchange 2013

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 Avec succès 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 de version 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 de Configuration nommage. Si aucune modification de 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 annuaire Active Directory a été mis à jour et qu’il est prêt pour la publication d’Exchange 2013 que vous installez.

  • Le programme d’installation demande incorrectement .NET Framework 4.0 : si vous essayez d’installer Exchange 2013 sans que .NET Framework ne soit installé sur l’ordinateur, le programme d’installation demande incorrectement que vous installiez .NET Framework 4.0 quand.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 les prérequis d’Exchange 2013.

  • Les fichiers de configuration d’application XML Exchange sont remplacés lors de l’installation de mise à jour cumulative : tous les paramètres Exchange ou Internet Information Server personnalisés par serveur que vous créez dans les fichiers de configuration d’application XML Exchange, 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, sont remplacés lorsque vous installez une mise à jour cumulative Exchange ou 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 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 Shell sur un serveur Exchange 2013 entraînait l’ouverture d’une connexion au serveur local ou à un autre serveur exécutant Exchange 2013. Une fois la connexion é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, Shell 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, Shell 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 de conception. 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 sur le déplacement de la boîte aux lettres d’arbitrage, consultez l’interpréteur de commandes Exchange Management Shell et l’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 incorrectement l’ajout d’un serveur Exchange 2013 à un groupe de disponibilité de base de données 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)

  • La taille de la boîte aux lettres augmente lors de la migration à partir des 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îte 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 boîte aux lettres est due à l’inclusion de toutes les propriétés d’élément dans les calculs de quota, fournissant un calcul plus précis de l’espace consommé par les éléments au sein de 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 tenir compte du 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 hors connexion : si l’URL interne du carnet d’adresses hors connexion (OAB) n’est pas accessible à partir d’Internet, les clients Outlook 2007 et Outlook 2010 peuvent ne pas pouvoir télécharger l’OAB.

    Pour contourner ce problème pour les clients Outlook 2007 et Outlook 2010, rendez l’URL interne OAB 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 entraîner le téléchargement de l’OAB par tous les clients : 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 de l’AUTHENTIFICATION, ce qui entraîne une saturation du réseau et des problèmes de performances du serveur. Ce problème se produit parce qu’Exchange 2013 crée une nouvelle OAB par défaut dans l’organisation qui remplace exchange 2007 ou Exchange 2010 OAB. Les boîtes aux lettres qui n’ont pas d’OAB spécifique affectée, ou qui se trouvent sur une base de données de boîte aux lettres qui n’a pas d’OAB spécifique affectée, téléchargent le nouvel OAB par défaut.

    Pour empêcher les clients de télécharger une nouvelle copie de l’AUTHENTIFICATION lors de l’installation d’Exchange 2013, affectez une adresse OAB à chaque boîte aux lettres ou à la base de données de boîte 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 OAB qui n’est pas responsable de l’AUTHENTIFICATION demandée : Exchange 2013 CU5 et les unités de requête ultérieures ont modifié la façon dont les OAB sont liées aux boîtes aux lettres de génération oAB. Cette modification permet à un utilisateur d’être routée vers une boîte aux lettres de génération OAB qui n’est pas responsable de l’AUTHENTIFICATION demandée par l’utilisateur. Cela peut se produire si tous les éléments suivants sont vrais :

    • Vous disposez de plusieurs boîtes aux lettres de génération OAB 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 OAB 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 client exécutent une version antérieure à CU5.

    Pour contourner ce problème, veillez à mettre à niveau vos serveurs d’accès 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 client savent comment proxyer les demandes vers la boîte aux lettres de génération OAB responsable de la génération de l’OAB de l’utilisateur.

    Pour en savoir plus sur les modifications apportées à la mise à jour cumulative 5 dans Exchange 2013 CU5, consultez Les améliorations apportées à 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 a permis 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 les expéditeurs externes envoient des messages à des dossiers publics à 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 des versions précédentes.

Flux de messagerie

  • Les applets de commande TransportAgent sur les serveurs d’accès client nécessitent une Windows PowerShell locale : 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 des agents de transport sur des serveurs d’accès client à l’aide d’Exchange Management Shell. Pour installer, désinstaller et gérer des agents de transport sur des serveurs d’accès 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, de désinstaller ou de 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 client, procédez comme suit sur le serveur d’accès au client que vous souhaitez gérer :

    Avertissement

    Le chargement des Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell des applets de commande enfichables et en cours d’exécution autres que les applets de commande -TransportAgent n’est pas pris en charge et peut entraîner des dommages irréparables à votre déploiement Exchange.

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

    Important

    Effectuez la procédure suivante sur les serveurs d’accès 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 les tâches de gestion de l’agent de transport comme d’habitude.

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

Connectivité client

  • Échec de l’authentification NTLM 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.

    • Modifiez le type d’authentification que le client utilise de NTLM à l’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 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 d’application sur le serveur d’accès client Exchange 2013 qui a reçu la connexion avec les informations suivantes :

    • Source : MSExchangeFrontEndTransport

    • ID d’événement : 1035

    • Description : Échec de l’authentification entrante avec erreur IllegalMessage pour le serveur frontal <server name>du client du connecteur Receive. Le mécanisme d’authentification est Gssapi. L’adresse IP source du client qui a essayé de s’authentifier auprès d’Exchange est [<client IP address>].

    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 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 client Exchange 2013 qui pourrait recevoir des connexions 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 rencontrer des performances médiocres lorsque vous effectuez une mise à niveau vers Exchange 2013 SP1 : si vous effectuez une mise à niveau cumulative d’Exchange 2013 vers Exchange 2013 SP1 et que vous activez MAPI via 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 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 ultérieur.

    Notes

    Il s’agit uniquement d’un problème si le protocole MAPI sur HTTP est activé sur vos serveurs d’accès client. Elle est désactivée par défaut. Si MAPI sur HTTP est désactivé, les clients utilisent plutôt le protocole RPC via HTTP.

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

    1. Sur les serveurs exécutant le rôle serveur Accès 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îte 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 via des serveurs d’accès client Exchange 2013 : dans certains cas, la demande de proxy entre les serveurs d’accès client Exchange 2013 et Exchange 2010 Service Pack 3 (SP3) sans correctif cumulatif 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-

      • Autre option utilisateur dans le Centre d’administration Exchange

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

      • Le serveur d’accès client Exchange 2010 a été mis à niveau vers Exchange 2010 SP3 à partir de la version de production (RTM) d’Exchange 2010 ou d’un service pack Exchange 2010 précédent.

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

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