Notes de publication Exchange 2013

• 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.
  
• L’aide du programme d’installation contient un paramètre de mode Uninstall non pris en charge   L’aide sur la ligne de commande d’installation indique que vous pouvez utiliser le paramètre Roles pour désinstaller Exchange 2013 via le mode d’installation Uninstall. C'est incorrect. Le paramètre Roles n’est pas pris en charge avec le mode d’installation Uninstall. Lorsque vous désinstallez Exchange 2013, tous les rôles serveur sont désinstallés de l’ordinateur. La désinstallation de rôles individuels n’est pas possible.
  

Pour plus d’informations sur la désinstallation d’Exchange 2013, consultez la rubrique Planification et déploiement.

• Coexistence avec Exchange 2007 et Exchange 2010   Exchange 2013 ne peut pas être installé dans la même forêt Active Directory qu’Exchange 2007 ou Exchange 2010. Utilisez une forêt Active Directory sans installation d’Exchange 2007 ou d’Exchange 2010. La coexistence avec Exchange 2007 et Exchange 2010 sera possible ultérieurement.
  

  Attention :
  Vous ne pouvez pas installer Exchange 2007 ou Exchange 2010 dans une forêt qui a été préparée pour Exchange 2013, et non pour Exchange 2007 ou Exchange 2010. Pour installer Exchange 2007 ou Exchange 2010 dans une forêt, ne la préparez pas pour Exchange 2013.

• La taille de la boîte aux lettres augmente lors d’une migration à partir de versions précédentes d’Exchange   Lorsque vous déplacez 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 augmente de 30 à 40 pour cent. 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.
  

• Le serveur d’accès au client ne prend pas en charge l’authentification NTLM   Le serveur d’accès au client ne propose aucune prise en charge de l’authentification NTLM lorsque des serveurs et clients SMTP se connectent au serveur. Les serveurs et clients SMTP qui nécessitent NTLM ne pourront pas envoyer de messages au serveur d’accès au client.
  Pour contourner le problème, vous devez configurer des serveurs et des clients SMTP pour qu’ils utilisent un autre mécanisme d’authentification, tel que l’authentification de base, lors de leur connexion au serveur d’accès au client.
  
• Les cmdlets TransportAgent sur les serveurs d’accès au client nécessitent le Windows PowerShell local   Il existe un problème avec les cmdlets *-TransportAgent. Il 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 :
  

  Attention :

  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 le fichiers Exchange ou les objets Active Directory.

  Important :
  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.
     
     Copier

     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 que vous souhaitez gérer.
     

• Types de pièces jointes non prises en charge dans les règles de transport   Dans Exchange 2013, l’agent de règles de transport traite les fichiers .png et .gif comme des types de fichiers pris en charge. Toutefois, même si ces types de fichiers sont pris en charge, l’agent de règles de transport n’en extrait pas correctement les métadonnées. Puisque ces types de fichiers sont considérés comme étant pris en charge, les règles de transport contenant le prédicat AttachmentIsUnsupported n’ont aucune action sur les types de fichiers .png ou .gif.
  Si vous avez configuré une règle de transport avec le prédicat AttachmentIsUnsupported, elle ne sera pas exécutée en présence de fichiers aux extensions .png ou .gif. Si vous souhaitez qu’une règle de transport s’exécute également en présence de ces types de fichiers, vous devez créer une autre règle pour les fichiers .png et .gif afin de déclencher la stratégie ou l’action souhaitée. Pour ce faire, utilisez la condition AttachmentExtensionMatchesWords.
  Par exemple, si votre stratégie consiste à rejeter tous les types de pièces jointes non traités, vous pouvez configurer une règle qui présente les paramètres suivants :
  
  • AttachmentIsUnsupported: True
    
  • RejectMessageEnhancedStatusCode: 5.7.1
    
  • RejectMessageReasonText: Ce message contient des types de pièces jointes non pris en charge.
    
  Toutefois, la règle de transport ne s’exécute par pour les types de fichiers .png ou .gif. Pour appliquer une stratégie semblable aux types de fichiers .png ou .gif, vous devez ajouter une règle qui reconnaisse ces types de pièces jointes à l’aide du paramètre AttachmentExtensionMatchesWords associé aux valeurs « GIF, PNG ». La commande suivante illustre la création d’une telle règle :
  
  Copier

  New-TransportRule "Process GIF and PNG files" -AttachmentExtensionMatchesWords GIF,PNG -RejectMessageEnhancedStatusCode 5.7.1 -RejectMessageReasonText "This message contains unsupported attachment types."
  
  

  Pour obtenir une liste complète des types de fichiers pris en charge dans les règles de transport, consultez la rubrique Types de fichiers pris en charge dans les règles de transport.
  
• La création d’une stratégie DLP risque d’échouer en raison de caractères non valides   Lorsque vous créez des stratégies de prévention des pertes de données (DLP) à partir de modèles qui présentent certains paramètres régionaux, l’opération échoue en présence de caractères non valides dans les données localisées. De la même façon, certains paramètres régionaux non-anglais peuvent contenir du texte en anglais dans les descriptions ou modèles de stratégies DLP.
  Pour contourner ce problème, téléchargez les derniers modèles de stratégies DLP Microsoft et installez-les. Pour plus d’informations, consultez cet article de la Base de connaissance Microsoft.
  
• Les règles de transport et les stratégies DLP risquent de ne pas détecter le contenu d’objets de messages joints   Des mots sensibles sur la ligne Objet d’un message joint risquent de ne pas être détectés même s’ils correspondent à la condition La pièce jointe contient les mots des stratégies de prévention des pertes de données (DLP, Data Loss Prevention) ou des règles de transport Exchange. Dans ce cas, les actions définies dans les règles de transport ou les stratégies DLP ne seront pas appliquées au message ou à ses pièces jointes.
  Il n’existe actuellement aucune solution.
  
• Les dates de début et de fin sont toujours interprétées au format MM/JJ/AAAA dans une recherche de découverte légale   Lorsque vous effectuez une recherche de découverte légale via la console de découverte électronique fédérée Microsoft SharePoint, les dates de début et de fin sont toujours interprétées à l’aide du format de date MM/JJ/AAAA. Ce format de date est utilisé quels que soient les paramètres régionaux de l’ordinateur local. Ce problème se pose également lorsque vous utilisez l’API SearchMailboxes des services Web Exchange fournie par Exchange 2013.
  Lorsque vous procédez à une recherche de découverte légale, utilisez le format de date MM/JJ/AAA pour les dates de début et de fin.