File d'attente ExchangeDélais d’expiration d’OWA, dépannage avec cmdlet et bien plus encore

KC Lemson and Nino Bilic

Q : Nous avons récemment migré d’Exchange Server 2003 à Exchange Server 2007. Nous recevons des plaintes concernant le délai d’expiration d’Outlook® Web Access (OWA) pour les utilisateurs restreints qui ont sélectionné l’option « Ordinateur privé » en se connectant à OWA 2007. Quelle est la commande Exchange Management Shell permettant de vérifier le délai d’expiration pour les ordinateurs privés ?

R : Commençons par remettre les choses dans leur contexte. Tout d’abord, j’expliquerai pourquoi il est possible de sélectionner un ordinateur privé ou un ordinateur public (voir la figure 1) et je vous montrerai la différence de comportement de ces options. Le but est de permettre à l’utilisateur d’indiquer à Exchange le niveau de sécurité nécessaire : qu’il se connecte à OWA en utilisant une borne publique à un aéroport, par exemple, ou à partir de l’ordinateur installé à son domicile. L’administrateur Exchange peut choisir de traiter différemment ces types de sessions. Par exemple, l’administrateur peut amener les sessions authentifiées à expirer plus vite sur les machines publiques (par exemple, en quelques minutes) que sur les machines privées (jusqu’à trois jours maximum). L’administrateur peut également configurer différemment d’autres paramètres en fonction du choix de l’utilisateur. Par exemple, l’administrateur peut réserver l’accès à la bibliothèque de documents SharePoint® et aux partages de fichiers Windows® uniquement à une connexion privée. Bien entendu, pour cela, l’utilisateur doit spécifier la bonne option. Si les administrateurs ne font pas confiance aux utilisateurs pour prendre la bonne décision, ils peuvent donner à chaque option les mêmes valeurs de délai d’expiration et autres options de configuration.

Figure 1** Les types de session publique et privée permettent différents paramétrages des délais d’expiration et autres options de configuration **(Cliquer sur l'image pour l'agrandir)

L’option en question provient d’Exchange 2003, lorsque l’authentification basée sur les formulaires a été tout d’abord introduite dans OWA. (Remarque historique : la première mise en œuvre d’une authentification basée sur les formulaires a été conçue en partie par un brillant responsable de programme. Je ne révèlerai pas son identité, mais vous dirai simplement qu’elle est ensuite devenue riche et célèbre en rédigeant un article bimensuel pour TechNet Magazine).

Le paramétrage est stocké dans le registre, mais comme Windows PowerShell™ a une interface pour mettre à jour le registre, vous pouvez configurer ce paramètre en utilisant Exchange Management Shell. L’exemple suivant fixe le délai d’expiration à 1440 minutes, soit une journée, lorsque les utilisateurs choisissent l’option ordinateur privé lors de l’ouverture de session :

set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout 
-value 1440 -type dword

Bien entendu, comme le paramètre se trouve dans le registre, vous pouvez vous-même mettre à jour la clé en utilisant regedit, si vous le souhaitez :

#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>

Quoi qu’il en soit, vous devrez redémarrer IIS pour vous assurer qu’OWA intègre le nouveau paramètre. Pour cela, sélectionnez Démarrer | Exécuter puis exécutez iisreset/noforce.

Q : Nous conseillons à toutes les personnes qui utilisent les clients Outlook MAPI complets d’archiver tous les éléments non urgents dans des fichiers de dossiers personnels (.pst). Toutefois, les éléments archivés ne sont ensuite plus disponibles lorsque les utilisateurs se connectent à Outlook Web Access depuis leur domicile. Comment rendre ces fichiers .pst disponibles via l’interface OWA ?

R : OWA ne prend malheureusement pas en charge l’accès aux fichiers .pst. OWA a été conçu dès le départ pour être un client uniquement en ligne. Nous avons beaucoup travaillé pour nous assurer que nous ne laissons pas de traces de données personnelles sur l’ordinateur local. Notamment par des fonctionnalités comme le mécanisme de déconnexion sécurisé apparu dans Exchange 2003 et WebReady Document Viewing d’Exchange 2007, qui veille à ce que des copies cachées de pièces jointes ne restent pas sur le disque dur. En conséquence, accéder aux fichiers .pst depuis OWA ne correspond pas à notre objectif qui est de proposer un client uniquement en ligne, simple à déployer.

Cela étant dit, l’utilisation des fichiers .pst en général est un scénario intéressant que nous aimerions aborder. L’automne dernier, nous avons rencontré un client qui avait des utilisateurs avec des quotas de boîte aux lettres d’environ 200 Mo, et presque chaque utilisateur avait au moins un, voire plusieurs, fichiers .pst. Parce que cette société avait une stratégie qui permettait de nettoyer et de remplacer les machines d’utilisateur avec un minimum d’effort, il a été demandé à tous les utilisateurs d’enregistrer leurs fichiers .pst sur un partage réseau. Ce partage réseau était, à son tour, sauvegardé par un système central.

Tout d’abord, il existe des problèmes connus en accédant aux fichiers .pst à partir des partages réseau. Tout comme OWA a été conçu dès le début pour être uniquement en ligne, les fichiers .pst ont été prévus au départ pour être enregistrés localement. Quelle que soit l’excellence de votre réseau, il est soumis à latence et autres problèmes qui peuvent rendre le stockage à distance des données (auxquelles les utilisateurs doivent également accéder en même temps) problématique.

Deuxièmement, cette entreprise avait ce que nous appellerions un quota de boîte aux lettres assez petit (admettons-le, nous vivons dans le luxe avec une boîte aux lettres d’entreprise d’environ 2 Go) parce qu’elle ne voulait pas avoir toutes ces données dans Exchange, ce qui l’aurait obligée à sauvegarder toutes les données. Pourtant, les utilisateurs enregistrant les données dans des fichiers .pst sur un partage réseau qui était sauvegardé, le travail des administrateurs n’était pas diminué pour autant. En fait, cela créait probablement plus de travail en raison de divers facteurs, tels que : absence de stockage à une seule instance sur de multiples fichiers .pst ; coûts de support technique liés aux problèmes avec les fichiers .pst (tels que mots de passe oubliés et friabilité générale du réseau) ; difficulté à nettoyer les messages dans les fichiers .pst après une attaque de virus ; difficulté à découvrir les messages dans les fichiers .pst lorsqu’un problème juridique se pose ; surcharges liées à la gestion d’un système de sauvegarde différent ; et ainsi de suite.

Nous vous invitons donc à étudier tous les coûts associés à vos décisions de configuration. Vous pourriez découvrir que les coûts s’additionnent et qu’une autre configuration pourrait finalement s’avérer être un meilleur choix.

Q : J’ai un problème avec une commande Exchange Management Shell. Ca ne marche pas. Quel est le problème ?

R : Nous ne pouvons pas répondre à cette question, mais nous pouvons vous dire que pour bénéficier de la meilleure aide possible, quelle qu’elle soit, vous devriez utiliser le cmdlet intégré dans Windows PowerShell appelé start-transcript pour enregistrer les commandes que vous essayez et les résultats que vous obtenez. Vous pourrez ensuite coller les détails exacts dans un message électronique, blog ou question sur un forum.

Ouvrez une session Exchange Management Shell et entrez start-transcript, comme sur la figure 2. Exchange Management Shell commence automatiquement à enregistrer toutes les futures commandes dans un fichier texte semblable à celui de la figure 3 (ne vous inquiétez pas, l’application indique l’emplacement du fichier texte). Pour arrêter l’enregistrement, il suffit de taper stop-transcript.

Figure 2** Utilisez le cmdlet start-transcript pour enregistrer les commandes que vous utilisez et leurs résultats  **(Cliquer sur l'image pour l'agrandir)

Figure 3** Windows PowerShell enregistre la transcription des commandes que vous utilisez dans un fichier .txt **(Cliquer sur l'image pour l'agrandir)

Disposer de la liste complète des commandes utilisées et des résultats obtenus est très utile pour quiconque essaie de résoudre votre problème. Mais avant de partager le journal avec une personne que vous ne connaissez pas ou à laquelle vous ne faites pas confiance, assurez-vous d’en supprimer toutes les données confidentielles ou sensibles susceptibles d’y figurer.

Q : Je remarque que l’installation d’Exchange 2007 crée une nouvelle Unité d’organisation (UO) dans le domaine racine. Elle s’appelle Groupes de sécurité de Microsoft Exchange et contient cinq nouveaux groupes de sécurité Exchange 2007. Pouvons-nous déplacer ces groupes dans une autre UO ? Et vers un autre domaine ?

R : Cette question fait référence aux cinq groupes universels de sécurité créés dans le domaine racine à l’étape de préparation d’Active Directory. Les groupes en question sont :

• Administrateurs d’organisation Exchange
• Administrateurs de destinataires Exchange
• Administrateurs Affichage seul d’Exchange
• Serveurs Exchange
• ExchangeLegacyInterop

À l’époque d’Exchange 2000 et d’Exchange 2003, la possibilité de déplacer les groupes de sécurité par défaut (Serveurs de domaine Exchange et Serveurs d’entreprise Exchange) était limitée. Autrement dit, il était possible de les déplacer, mais avec des dégâts. (Consultez support.microsoft.com/kb/260914 pour plus d’informations sur ce problème). En conséquence, l’effet était très limité.

Dans Exchange 2007, les choses sont différentes. Les cinq groupes par défaut peuvent être déplacés. Vous pouvez les déplacer dans une autre UO dans le même domaine ou dans un domaine différent.

Au cas où vous « perdriez » ces cinq groupes et ne sauriez plus où vous les avez transférés (autrement dit, dans quelle UO ou dans quel domaine), vous pouvez toujours vérifier la valeur de l’attribut otherWellKnownObjects sur le conteneur suivant :

CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com

Lorsque les groupes sont déplacés, leur emplacement est mis à jour sur cet attribut, ce qui vous permet de toujours savoir où les groupes se trouvent. Parfait !

Q : J’ai trouvé un groupe de sécurité global appelé « Serveurs de domaine Exchange » dans mon domaine. À quoi sert-il ?

R : Vous conservez le suivi sur votre Active Directory®. En fait, il y a un groupe appelé Serveurs de domaine Exchange dans chaque domaine sur lequel des serveurs Exchange 2007 sont installés. Ce groupe est créé dans l’UO Objets système Microsoft Exchange. Si vous étudiez ce groupe, vous verrez qu’il fait partie du groupe Serveurs Exchange du domaine racine, qui est un groupe universel de sécurité.

Pour résumer, Serveurs de domaine Exchange est un groupe utilisé pour travailler sur des cycles de réplication d’Active Directory éventuellement longs si vous exécutez l’installation d’Exchange 2007 dans l’un de vos domaines enfants. Par exemple, disons que vous avez un domaine racine appelé Racine, un domaine enfant appelé Enfant et un domaine enfant appelé Petit-enfant. (D’accord, ces noms ne sont pas vraiment originaux ! Vous pensez pouvoir deviner nos mots de passe ?)

Pour lancer l’installation d’Exchange 2007 dans cette organisation, vous devez étendre le schéma et préparer votre domaine Racine. Cela crée les cinq groupes universels de sécurité originaux dont nous avons parlés dans la réponse précédente.

Ensuite, indiquez que vous voulez lancer l’installation dans le domaine Petit-enfant. Afin de pouvoir lancer les services Exchange 2007 dans le domaine local, l’installation place un compte d’ordinateur de la machine sur laquelle Exchange 2007 est installé dans le groupe Serveurs Exchange à partir du domaine Racine. Mais comme vous êtes dans le domaine Petit-enfant, la réplication de l’appartenance du groupe Serveurs Exchange peut durer assez longtemps.

Serveurs Exchange est un groupe universel et son appartenance est répliquée dans la forêt. En raison de la latence de réplication potentielle, il est possible que l’installation dans le domaine Petit-enfant ne puisse pas démarrer les services, les autorisations n’étant pas répliquées alors que l’installation est terminée. C’est pourquoi lorsque le premier serveur Exchange 2007 est installé dans un domaine, il crée le groupe Serveurs de domaine Exchange dans le domaine local.

Le compte d’ordinateur Exchange est placé comme membre dans ce groupe dans le cadre de l’installation. Une appartenance à ce groupe donne aux services une autorisation suffisante pour démarrer à la fin de l’installation, même si l’appartenance du groupe Serveurs Exchange n’a pas encore été répliquée depuis le domaine Racine. Veuillez noter que la réplication de domaine locale est généralement plus rapide que la réplication entre les domaines.

Q : La documentation d’Exchange 2007 indique qu’il convient d’exécuter l’installation avec le commutateur /PrepareLegacyExchangePermissions, même avant que je développe mon schéma pour Exchange 2007. Pourquoi ? (Et auriez-vous pu donner un nom plus long à ce commutateur ?)

R : Nous sommes heureux d’apprendre que vous lisez la documentation avant d’exécuter l’installation. Qu’en pensez-vous ?

Le /PrepareLegacyExchangePer­mis­sions (ou /pl en résumé) est un commutateur qui donne aux services de mise à jour de destinataire Exchange 2000 et Exchange 2003 les autorisations d’écrire sur les ensembles de propriétés Informations Exchange et Informations personnelles. Pendant le processus d’extension du schéma Exchange 2007, plusieurs attributs (tels qu’adresses proxy) sont déplacés de l’ensemble de propriétés Informations publiques d’Active Directory dans l’ensemble de propriétés Informations Exchange. Par défaut, les services de mise à jour de destinataire Exchange 2000 et Exchange 2003 n’ont pas le droit d’écrire sur les ensembles de propriétés Informations Exchange. En pratique, cela signifie que si vous exécutez votre extension de schéma Exchange 2007 en premier, vous brisez vos services de mise à jour de destinataire Exchange 2000 et Exchange 2003 parce qu’ils sont incapables d’estampiller un nouveau destinataire ! (Pour plus d’informations sur ces ensembles de propriétés, consultez notre blog sur msexchangeteam.com).

Il est en conséquence très important que vous exécutiez le commutateur /pl avant l’extension du schéma pour Exchange 2007. Veillez également à ce que ce changement soit répliqué dans tous les domaines ayant des destinataires Exchange 2000 ou Exchange 2003 (ainsi des services de mise à jour de destinataire existent pour ces domaines). Si de nouveaux domaines sont ultérieurement ajoutés à la forêt et que vous deviez y intégrer des services de mise à jour de destinataire Exchange 2000 ou Exchange 2003, vous devriez exécuter le commutateur /pl dans ces domaines également.

À ce sujet, veuillez noter que, en exécutant un commutateur /pl pour la première fois, il est beaucoup plus simple d’exécuter le commutateur avec un compte ayant des droits Administrateur d’entreprise. Ensuite, l’installation à partir du domaine racine identifie sur quels domaines /pl doit être exécuté et elle exécute le commutateur /pl sur tous ces domaines. Si vous n’utilisez pas un compte Administrateur d’entreprise, vous devez exécuter un commutateur /pl en utilisant un Administrateur de domaine pour chaque domaine. Heureusement, la documentation d’Exchange 2007 indique toutes les exigences relatives aux autorisations.

Et pour finir, vous avez demandé si nous aurions pu donner un nom encore plus long à ce commutateur. Essayez juste de dire /PrepareLegacyExchangePermissions trois fois très rapidement :

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

Nous avons pensé utiliser /PrepareLegacyExchangePermissionsOuahC’estUnNomVraimentLong, mais nous avons finalement préféré la version plus courte et plus conviviale, /PrepareLegacyExchangePermissions.

Voila pour l’explication. Mais vous pouvez toujours utiliser l’abréviation /pl. Et celle-là est vraie, c’est promis !

KC Lemson est Directeur expérience utilisateur pour Exchange Server. Elle consacre son temps libre à attendre l’arrivée d’e-mails lui indiquant sur quels supports elle devrait investir les économies qui lui permettront d’envoyer ses enfants à l’université.

Nino Bilicresponsable technique pour Exchange Server, est occupé à comptabiliser le nombre de parties de Halo qu’il peut jouer pendant une journée normale de travail.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.