Partager via

Comptes d’utilisateur avec changement rapide d’utilisateur et bureau à distance

  • Article

Les comptes d’utilisateur Windows XP permettent à plusieurs utilisateurs d’être connectés simultanément, chacun avec ses propres paramètres et chacun exécutant ses propres applications. Étant donné qu’un utilisateur n’a pas besoin de se déconnecter pour autoriser l’accès à un autre utilisateur, le bureau de chaque utilisateur est facilement accessible à l’aide de la fonctionnalité de changement rapide d’utilisateur. Les comptes d’utilisateur incluent également la fonctionnalité Personal Terminal Server ou le bureau à distance, qui permet aux utilisateurs d’accéder à leur compte de bureau à partir de systèmes distants.

Les rubriques suivantes sont présentées.

Configuration requise pour l’utilisation de l’infrastructure

L’infrastructure sous-jacente héritée de Windows 2000 prend en charge la séparation de l’état des données utilisateur, des paramètres utilisateur et des paramètres d’ordinateur. En tirant parti de cette infrastructure, les éléments suivants sont nécessaires pour exécuter correctement votre application sous Windows XP.

  • Prend comme valeur par défaut le dossier Mes documents pour le stockage des données créées par l’utilisateur.
  • Classifiez et stockez correctement les données d’application.
  • Dégradez normalement lorsque vous recevez des messages « Accès refusé ».

Les fichiers temporaires, les fichiers mappés en mémoire et les documents doivent tous être stockés dans le sous-répertoire approprié du répertoire de profil de l’utilisateur. Utilisez SHGetFolderLocation ou SHGetFolderPath pour déterminer l’emplacement de stockage approprié pour ces fichiers. Le passage de l’indicateur CSIDL_APPDATA à ces fonctions retourne le chemin d’accès d’un répertoire de système de fichiers qui sert de référentiel commun pour les données spécifiques à l’application. Utilisez l’indicateur CSIDL_LOCAL_APPDATA à la place de CSIDL_APPDATA pour les données qui doivent changer lorsque l’utilisateur change, comme les fichiers temporaires.

Les exigences répertoriées ci-dessus sont un sous-ensemble de celles du programme Microsoft Certification. Pour plus d’informations, consultez la page Exigences en matière de certifications pour les applications de bureau Windows.

Compatibilité avec les applications existantes

Le changement rapide d’utilisateur et Personal Terminal Server utilisent la technologie Terminal Services et sont donc compatibles avec les applications Microsoft Win32 les plus anciennes. Si une application est conforme au logo Windows 2000, implémentant des fonctionnalités de gestion de l’alimentation et de séparation de profil de base, cette application doit s’exécuter correctement sous des comptes d’utilisateur Windows XP individuels.

Inscription à une notification de changement de session

En règle générale, une application n’a pas besoin d’être avertie lorsqu’un changement de bureau se produit. Toutefois, les applications qui doivent être averties lorsque le compte sous lequel ils s’exécutent est le bureau actuel, telles que les applications qui accèdent au port série ou à d’autres ressources partagées, peuvent s’inscrire à la notification de changement de bureau. Pour vous inscrire à une notification, utilisez la fonction WTSRegisterSessionNotification.

Une fois cette fonction appelée, la fenêtre avec handle hWnd est inscrite pour recevoir un message WM_WTSSESSION_CHANGE via sa fonction WndProc. L’ID de session est envoyé dans le paramètre lParam et un code qui indique l’événement qui a généré le message est envoyé dans wParam comme l’un des indicateurs suivants.

  • WTS_CONSOLE_CONNECT
  • WTS_CONSOLE_DISCONNECT
  • WTS_REMOTE_CONNECT
  • WTS_REMOTE_DISCONNECT
  • WTS_SESSION_LOGOFF
  • WTS_SESSION_LOGON

Les applications peuvent utiliser ce message pour suivre leur état, ainsi que pour libérer et acquérir des ressources spécifiques à la console. Les bureaux utilisateurs peuvent être changés dynamiquement entre le contrôle distant et la console. Les applications doivent utiliser le message WM_WTSSESSION_CHANGE pour se synchroniser avec l’état de connexion distante ou locale.

Lorsque votre processus ne nécessite plus ces notifications ou s’arrête, il doit appeler WTSUnRegisterSessionNotification pour annuler l’inscription à la notification.

Important

Les valeurs hWnd passées à WTSRegisterSessionNotification sont comptabilisées par référence. Vous devez donc effectuer un nombre égal d’appels à WTSUnRegisterSessionNotification pour garantir la libération de toutes les ressources allouées.

 

S’assurer qu’une seule instance de votre application est en cours d’exécution

De nombreuses applications doivent s’assurer qu’elles n’ont qu’une seule instance en cours d’exécution. Il existe plusieurs façons de procéder dans Windows XP. En voici quelques unes :

  • Utilisez FindWindow ou FindWindowEx pour rechercher une fenêtre connue que votre application ouvre. Si cette fenêtre est déjà ouverte, vous pouvez l’utiliser comme indication que l’application est déjà en cours d’exécution.
  • Créez un objet mutex ou sémaphore lorsque votre application est ouverte et fermez cet objet lorsque l’application se termine. L’espace de noms d’objet global est séparé pour chaque bureau, ce qui permet une liste unique d’objets mutex et sémaphores pour chacun d’eux.

Arrêt de votre application sur toutes les sessions

Une application peut avoir besoin de s’arrêter sur toutes les sessions. Par exemple, une application s’exécutant simultanément dans deux sessions ou plus peut télécharger un nouveau fichier à partir du web. Ensuite, elle devra peut être se fermer et redémarrer avec les bits mis à jour. Bien sûr, cela devrait être fait dans toutes les sessions en cours d’exécution. Votre application doit être écrite de façon à ce qu’elle se termine correctement lorsqu’une notification est reçue.

Interaction avec les services système

Du point de vue de la programmation, les cas suivants doivent être traités.

  • Le processus serveur reçoit une demande directe d’un processus client.

    Dans ce cas, le message est probablement transmis à l’aide d’un appel de procédure locale (LPC) ou d’un appel de procédure distante (RPC). Il existe des API pour LPC ou RPC qui permettent la récupération du jeton client. Une fois le jeton client obtenu, le serveur peut l’utiliser dans un appel à CreateProcessAsUser. Cela affiche le processus sur la station de fenêtre appropriée, en supposant que le jeton utilisateur client a une balise de session, qu’il doit avoir.

    Remarque

    CreateProcessAsUser ne prend pas en charge l’héritage entre les sessions pour l’instant.

     

  • Le processus serveur reçoit une notification et doit afficher l’interface utilisateur, mais l’affichage n’a pas besoin d’être dans le contexte de l’utilisateur actuel.

    Dans ce cas, le processus serveur peut dupliquer son jeton de processus principal et modifier l’identificateur de session en question pour qu’il corresponde à l’identificateur de session actuel. L’identificateur de session actuel peut être obtenu à l’aide de la fonction WTSGetActiveConsoleSessionId.

    Remarque

    Pour définir l’ID de session de jeton, vous avez besoin de SE_TCB_PRIVILEGE. Vous ne l’aurez qu’en tant que service s’exécutant dans NT AUTHORITY\SYSTEM.

     

Bureau à distance et bande passante

Avec l’ajout de la fonctionnalité de bureau à distance à Windows XP, les applications doivent faire un effort pour ne pas utiliser plus de bande passante que nécessaire, en évitant une abondance de dessins d’écran et d’effets d’animation si le bureau est connecté à distance. Pour déterminer si la session active est distante, vous pouvez appeler GetSystemMetrics avec SM_REMOTESESSION. Sachez toutefois que cet appel ne fait pas la distinction entre les états distant et déconnecté.