Gestion de la recherche Outlook dans des environnements bureau à distance non persistants

S’applique à : Windows Server (canal semi-annuel), Windows Server 2016

Un problème courant auquel les clients sont confrontés avec leurs environnements de services Bureau à distance non persistants (mis en pool) est la gestion des données Outlook des utilisateurs. Quand Outlook s’exécute en mode Exchange mis en cache, le . Ost stockant les données Outlook d’un utilisateur doit suivre l’utilisateur lors de son itinérance de l’hôte à l’hôte. Le service Recherche Windows indexe le . OST et crée un catalogue d’index pour activer la fonctionnalité de recherche dans Outlook. Dans les environnements RDS non persistants, le catalogue d’index n’est pas itinérant avec les données utilisateur et doit être reconstruit chaque fois que l’utilisateur se connecte à un nouveau PC, ce qui peut être à chaque connexion. Jusqu’à ce que le service Recherche Windows ait fini d’indexer le . OST, les utilisateurs bénéficient d’une fonctionnalité de recherche limitée ou incomplète.

Selon un rapport publié de RDS Gurus, FSLogix (un fournisseur de solutions tiers) propose une solution qui vise à résoudre ce problème : le conteneur Office 365 de FSLogix itinérant les données Outlook d’un utilisateur et son catalogue d’index de recherche, ce qui donne aux utilisateurs l’accès à leurs e-mails et permet aux utilisateurs de rechercher dans Outlook, même lorsqu’ils errent entre des sessions sur différents hôtes au sein d’une collection. 

Les gourous RDS ont effectué des tests sur le conteneur Office 365 de FSLogix, en le comparant à la solution d’itinérance de disque de profil utilisateur native de RDS. Les scénarios de test couvrent à la fois les environnements RDS locaux et Azure pour les sessions non persistantes sur un hôte de session Bureau à distance (RDSH). Les tests incluaient également des machines virtuelles mises en pool sur un hôte de virtualisation des services Bureau à distance (RDVH), uniquement pour les machines locales (RDVH n’est pas disponible dans Azure). Les gourous RDS se concentrent principalement sur l’expérience utilisateur lorsqu’il y a des « voisins bruyants » ou d’autres utilisateurs connectés au même hôte de session exécutant des charges de travail similaires sur le système.

Les compteurs de performances collectés dans ces tests ont révélé une utilisation similaire des ressources (processeur, RAM, activité réseau) avec UPD et FSLogix. La similarité de l’utilisation des ressources est due au fait que le service Recherche Windows limite son utilisation du processeur lors de l’indexation. En ce qui concerne l’expérience utilisateur, les gourous rds ont constaté que le conteneur Office 365 de FSLogix dépasse UPD dans la fonctionnalité de recherche Outlook. Dans le cas de l’UPD, la recherche ne retourne pas de résultats ou renvoie des résultats incomplets, car le service Recherche Windows indexe le . OST. Étant donné que FSLogix itinérant le catalogue d’index, les utilisateurs voient immédiatement les résultats de la recherche. Les gourous rds ont observé une amélioration significative de l’expérience utilisateur lors de la recherche dans Outlook dans des environnements RDS non persistants à l’aide de FSLogix.

Pour en savoir plus sur les résultats et les conclusions, consultez le blog RDS Gurus.