Exporter (0) Imprimer
Développer tout

Notes de publication relatives à Exchange 2013

 

S’applique à : Exchange Server 2013

Dernière rubrique modifiée : 2014-06-12

Bienvenue dans Microsoft Exchange Server 2013 ! Cette rubrique contient des informations importantes à connaître afin de déployer la mise à jour cumulative 5 pour Exchange 2013. Veuillez lire entièrement cette rubrique avant de commencer votre déploiement.

Cette rubrique comprend les sections suivantes :

  • Le programme d'installation demande à tort .NET Framework 4.0   Si vous essayez d'installer Exchange 2013 et que .NET Framework n'est pas installé sur l'ordinateur, le programme d'installation vous demande d'installer .NET Framework 4.0 alors qu'en fait, c'est .NET Framework 4.5 qui est nécessaire.

    Pour contourner ce problème, installez .NET Framework 4.5. Vous n’avez pas besoin d’installer .NET Framework 4.0. Pour obtenir la liste complète des composants requis, consultez la rubrique Conditions préalables pour Exchange 2013.

  • Les fichiers de configuration d’application XML Exchange sont remplacés lors de l’installation de la mise à jour cumulative   Les paramètres par serveur personnalisés de vos 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, seront remplacés lors de l’installation d’une mise à jour cumulative Exchange ou d’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.

  • Le répertoire virtuel MAPI n’est pas créé lors de la restauration du serveur   Lorsque vous exécutez Setup.exe avec le commutateur RecoverServer sur un serveur sur lequel le rôle serveur d’accès au client est installé, le répertoire virtuel MAPI n’est pas créé. Si le répertoire virtuel MAPI n’existe pas, les clients qui utilisent le protocole MAPI sur HTTP pour se connecter au serveur Exchange, tels qu’Outlook, ne pourront pas se connecter.

    RemarqueRemarque :
    Ce problème n’est observé que si le protocole MAPI sur HTTP est activé sur vos serveurs d’accès au client. Il est désactivé par défaut. Si le protocole MAPI sur HTTP est désactivé, les clients utilisent le protocole RPC sur HTTP à la place.

    Pour résoudre ce problème, suivez les étapes dans l’article de la base de connaissances KB2931223 (Le répertoire virtuel MAPI est absent du nœud de site web par défaut).

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

  • La taille de la boîte aux lettres augmente lors d'une migration à partir de versions précédentes d'Exchange   Lorsque vous migrez une boîte aux lettres d'une version précédente d'Exchange vers Exchange 2013, la taille signalée de la boîte aux lettres peut augmenter de 30 à 40 %. Ce n'est pas l'espace disque utilisé par la base de données de boîtes aux lettres qui a augmenté, mais l'attribution de l'espace utilisé par chaque boîte aux lettres. L'augmentation de la taille de la boîte aux lettres résulte de l'inclusion de toutes les propriétés des éléments dans le calcul du quota, ce qui produit un calcul plus précis de l'espace utilisé par des éléments dans leur boîte aux lettres. Pour certains utilisateurs, cette augmentation risque de provoquer un dépassement des quotas de taille de leur boîte aux lettres lorsqu'elles sont transférées vers Exchange 2013.

    Pour empêcher ce dépassement, augmentez les valeurs de quota des bases de données ou des boîtes aux lettres pour permettre le calcul du nouveau quota. Pour configurer les valeurs de quota des bases de données ou des boîtes aux lettres, utilisez les paramètres IssueWarningQuota, ProhibitSendQuota et ProhibitSendReceiveQuota des cmdlets Set-MailboxDatabase et Set-Mailbox, respectivement.

  • Les clients Outlook 2007 et Outlook 2010 ne peuvent pas télécharger le carnet d’adresses en mode hors connexion   Si l’URL interne du carnet d’adresses en mode hors connexion n’est pas accessible à partir d’Internet, les clients Outlook 2007 et Outlook 2010 ne pourront peut-être pas 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 concerné par ce problème.

  • L'installation d'Exchange 2013 dans une organisation Exchange existante peut provoquer le téléchargement du carnet d'adresses en mode hors connexion par tous les clients   L'installation du premier serveur Exchange 2013 dans une organisation Exchange 2007 ou Exchange 2010 existante peut provoquer le téléchargement d'une nouvelle copie du carnet d'adresses en mode hors connexion par tous les clients de l'organisation, ce qui peut entraîner une saturation du réseau et réduire les performances des serveurs. Ce problème vient du fait qu'Exchange 2013 crée un carnet d'adresses en mode hors connexion par défaut dans l'organisation, lequel remplace le carnet d'adresses en mode hors connexion d'Exchange 2007 ou d'Exchange 2010. Les boîtes aux lettres pour lesquelles un carnet d’adresses en mode hors connexion spécifique n’a pas été attribué, ou celles se trouvant sur une base de données de boîtes aux lettres pour lesquelles un carnet d’adresses en mode hors connexion spécifique n’a pas été attribué, 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, attribuez un carnet d'adresses en mode hors connexion à chaque boîte aux lettres ou à la base de données dans laquelle se trouvent les boîtes aux lettres. Cette opération doit réalisée avant l'installation d'Exchange 2013 dans l'organisation.

  • Les utilisateurs peuvent être acheminé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é   La mise à jour cumulative 5 d’Exchange 2013 modifie le mode de liaison des carnets d’adresses en mode hors connexion aux boîtes aux lettres de génération de ces derniers. Cette modification permet à un utilisateur d’être acheminé 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. Cette situation 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 les serveurs d’accès au client.

    • Vous mettez à niveau vos serveurs Exchange 2013 à partir d’une version antérieure à la mise à jour cumulative 5 vers cette dernière ou une version ultérieure (par exemple, la mise à niveau à partir de la mise à jour cumulative 3 d’Exchange 2013 vers la mise à jour cumulative 5 d’Exchange 2013).

    • Vos serveurs d’accès au client exécutent une version antérieure à la mise à jour cumulative 5.

    Pour contourner ce problème, assurez-vous que vous mettez à niveau vos serveurs d’accès au client vers la mise à jour cumulative 5 d’Exchange 2013 avant de mettre à niveau vos serveurs de boîtes aux lettres. Cela permettra de s’assurer que les serveurs d’accès au client savent comment rediriger via proxy les demandes vers la boîte aux lettres de génération de carnet d’adresses en mode hors connexion responsable de la génération du carnet d’adresses en mode hors connexion de l’utilisateur.

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

  • Les expéditeurs non autorisés peuvent envoyer des messages vers les dossiers publics   Les dossiers publics situés sur des serveurs exécutant Exchange 2013 SP1 ou versions ultérieures acceptent des messages provenant d’expéditeurs externes à l’organisation Exchange, quelle que soit la configuration du dossier public. À cause de ce problème, il se peut que les dossiers publics reçoivent du courrier indésirable et d’autres messages indésirables.

    Il n’existe actuellement aucune solution pour contourner ce problème.

  • Les dossiers publics hérités ne sont pas accessibles via les services web Exchange   Les dossiers publics qui se trouvent sur les serveurs Exchange 2007 ou Exchange 2010 ne sont pas accessibles par les clients qui se connectent à Exchange 2013 à l’aide des services web Exchange (EWS). Mac, Outlook et Outlook Web App font partie des clients qui utilisent EWS. Si un client EWS tente d’accéder à un dossier public hérité, une erreur sera renvoyée.

    La seule solution pour le moment est de migrer les dossiers publics hérités vers Exchange 2013. Toutefois, certaines questions doivent être prises en compte avant de migrer vos dossiers publics. Pour plus d’informations, consultez la rubrique Dossiers publics.

  • Les cmdlets TransportAgent sur les serveurs d'accès au client nécessitent Windows PowerShell local   Il existe un problème avec les cmdlets *-TransportAgent qui empêche les cmdlets d'installer, de désinstaller et de gérer les agents de transport sur les serveurs d'accès au client à l'aide de l'environnement de ligne de commande Exchange Management Shell. Pour installer, désinstaller et gérer les agents de transport sur des serveurs d'accès au client, vous devez charger manuellement le composant logiciel enfichable Windows PowerShell Exchange, puis exécuter les cmdlets *-TransportAgent. Si vous essayez d’installer, de désinstaller ou de gérer des agents de transport à l’aide de l’environnement de ligne de commande 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 à gérer :

    AttentionAttention :
    Ne chargez pas le composant logiciel enfichable Windows PowerShell Microsoft.Exchange.Management.PowerShell.SnapIn et n'exécutez pas de cmdlets autres que *-TransportAgent au risque de provoquer 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 n'autorisons pas la modification des listes de contrôle d'accès (ACL) dans les répertoires et les fichiers Exchange ou les objets Active Directory.
    ImportantImportant :
    Exécutez les opérations suivantes sur les serveurs d'accès au client uniquement. Il n’est pas nécessaire de charger le composant logiciel enfichable Windows PowerShell Exchange pour gérer des agents de transport sur des 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. Exécutez les tâches de gestion des agents de transport comme vous procédez habituellement.

    4. Répétez cette procédure sur chaque serveur d'accès au client à gérer.

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

    • La méthode d’authentification utilisée par le client est NTLM.

    • L’ordinateur n’est pas lié au domaine.

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

    • Liez l’ordinateur sur lequel le client est en cours d’exécution au domaine.

    • Changez le type d’authentification utilisé par le client, de NTLM à l’authentification de base sur TLS.

  • L’authentification GSSAPI échoue lorsqu’elle est utilisée avec la cmdlet Send-MailMessage   L’authentification GSSAPI (Generic Security Service Application Program Interface) peut échouer lorsque la cmdlet Send-MailMessage, qui est incluse avec les installations par défaut de Windows PowerShell, est utilisée pour envoyer du courrier authentifié vers Exchange 2013. Lorsque cela se produit, vous voyez 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 l’erreur IllegalMessage pour le connecteur de réception client frontal <nom du serveur>. Le mécanisme d’authentification est Gssapi. L’adresse IP source du client qui a essayé de s’authentifier auprès de Microsoft Exchange est [<adresse IP du client>].

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

    Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS
    
  • Le protocole MAPI sur HTTP peut rencontrer des problèmes de performances 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 de ce protocole peuvent rencontrer des problèmes de performance. En effet, 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 depuis Exchange 2013 RTM ou si vous installez un nouveau serveur Exchange 2013 SP1 ou versions ultérieures.

    RemarqueRemarque :
    Ce problème n’est observé que si le protocole MAPI sur HTTP est activé sur vos serveurs d’accès au client. Il est désactivé par défaut. Si le protocole 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%\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%\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"
      

  • Les demandes d’accès aux boîtes aux lettres Exchange 2010 peuvent ne pas fonctionner lorsqu’elles sont transférées par proxy via les serveurs d’accès au client Exchange 2013   Dans certaines situations, la requête proxy entre les serveurs d’accès au client Exchange 2013 et Exchange 2010 Service Pack 3 (SP3) sans correctif cumulatif peut ne pas fonctionner correctement et une erreur s’affiche. Cette situation peut se produire si les conditions suivantes sont remplies :

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

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

      • L'option Un autre utilisateur dans le Centre d'administration Exchange (CAE)

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

    • Le serveur d’accès au client Exchange 2010 a été mis à niveau vers Exchange 2010 SP3 à partir de la version 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 Outlook Web App Exchange 2010 de l’autre utilisateur et une page vierge risque de s’afficher.

    Pour contourner ce problème, installez le correctif cumulatif 1 d’Exchange 2010 SP3 ou une version ultérieure sur chaque serveur Exchange 2010.

 
Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft