10.8. Connexion et accès aux bureaux

10.8.1. Les utilisateurs ne parviennent pas à accéder à leur bureau.
10.8.2. L'utilisateur peut se connecter, mais son bureau ne répond pas.
10.8.3. Erreur : "Il n'y a actuellement aucun bureau disponible ou vous étant assigné."
10.8.4. Le client Sun Ray Client effectue un recyclage et ne peut pas se connecter à une machine virtuelle
10.8.5. Les utilisateurs ne parviennent pas à se connecter aux bureaux Ubuntu 8.04, car le réseau n'est pas activé.
10.8.6. La redirection hot desking ne fonctionne pas avec Windows XP Edition Professionnelle et Microsoft RDP
10.8.7. Echec de la relation sécurisée entre un bureau Windows et le contrôleur de domaine

10.8.1. Les utilisateurs ne parviennent pas à accéder à leur bureau.

  1. Dans un terminal, déclenchez la commande suivante :

    /opt/SUNWvda/lib/vda-client -u user
    
  2. Si tout se passe comme prévu, la commande vda-client déclenchera le démarrage du bureau correspondant et renverra une adresse IP (par exemple, 10.16.46.208) ou le nom DNS (par exemple, xpdesktop01) permettant d'accéder au bureau de l'utilisateur. Si le port RDP n'est pas défini sur sa valeur par défaut, il sera ajouté à la fin de l'adresse IP ou du nom DNS (par exemple, 10.16.46.208:49259 ou xpdesktop01:49259).

  3. Ces informations devraient alors vous permettre d'établir une connexion RDP au bureau.

  4. Si la commande vda-client ne renvoie pas d'adresse IP ou de nom DNS, il est possible que Oracle VDI ne puisse pas résoudre l'ID de l'utilisateur dans le répertoire utilisateur.

    Pour vérifier, modifiez le niveau de journalisation des services d'annuaire selon les instructions de la Section 10.3.1, « Accroissement de la journalisation pour résoudre les problèmes du répertoire utilisateur ».

  5. Dans le fichier journal du Cacao, recherchez les entrées de type :

    FINEST: userId=<user ID> -> DN=<dn>

    Pour plus de détails, consultez Section 8.5.4, « Vérification des fichiers journaux Oracle VDI ».

  6. Si <dn> est nul, cela signifie qu'aucun utilisateur ne correspond à l'ID utilisateur <test user> dans le répertoire utilisateur. Il peut dans ce cas être nécessaire de personnaliser la liste des attributs ldap.userid.attributes en fonction du schéma d'annuaire, selon les instructions de la Section C.1, « Modification d'attributs et de filtres LDAP ».

  7. Si <dn> n'est pas nul, cela signifie que l'utilisateur correspondant à l'ID utilisateur <test user> a bien été trouvé dans le répertoire utilisateur.

10.8.2. L'utilisateur peut se connecter, mais son bureau ne répond pas.

Il peut arriver qu'un utilisateur puisse se connecter à Oracle VDI, mais ne puisse pas utiliser un bureau parce que la machine virtuelle ne répond pas.

Dans ce cas, la solution consiste à redémarrer le bureau. Cette opération peut être effectuée par un administrateur (par exemple, via la commande vda desktop-restart) ou par l'utilisateur lui-même.

Pour redémarrer son bureau, l'utilisateur doit d'abord se déconnecter du bureau en déplaçant la souris vers le haut de l'écran et en cliquant sur le "X" du menu déroulant du bureau distant. Lorsque la fenêtre Sélecteur de bureau s'affiche, l'utilisateur doit alors sélectionner le bureau qui ne répond pas et cliquer sur le bouton Réinitialiser pour démarrer ce bureau. Redémarrer un bureau ou un ordinateur traditionnel est la même opération, et un avertissement signale également à l'utilisateur qu'il peut perdre toutes les données non enregistrées. Après le redémarrage du bureau, l'utilisateur peut s'y connecter à partir de la fenêtre Sélecteur de bureau. Les bureaux fournis par les types de fournisseurs suivants ne peuvent pas être redémarrés de cette manière :

  • Fournisseur de bureau générique

  • Fournisseur Microsoft Remote Desktop

  • Fournisseur de session Sun Ray Kiosk

10.8.3. Erreur : "Il n'y a actuellement aucun bureau disponible ou vous étant assigné."

L'infrastructure Oracle VDI génère généralement le message ci-dessus pour les raisons suivantes :

  • Aucun bureau n'a été assigné directement à l'utilisateur.

  • Un pool a été affecté à l'utilisateur, mais il ne contient aucun bureau disponible/libre.

  • Un bureau a été sélectionné, mais il est dans un état inutilisable. En général, son démarrage a échoué pour une raison quelconque.

Si vous obtenez ce message, consultez le fichier journal du Cacao (voir laSection 8.5.4, « Vérification des fichiers journaux Oracle VDI »).

Pour identifier la cause racine, procédez comme suit :

  1. Vérifiez que votre système reconnaît correctement vos assignations de bureau/pool.

    L'écran d'ouverture de session Oracle VDI Kiosk utilise une commande interne (vda-client) pour extraire ces informations. Vous pouvez déclencher cette commande manuellement à partir d'un terminal (les privilèges d'utilisateur root ne sont pas nécessaires) :

    $ /opt/SUNWvda/lib/vda-client -a query -u user
    Password: xxxxx
    Windows 7,Windows7000003,8,User
    

    La commande vous invite à fournir le mot de passe de l'utilisateur. Vous devez dans ce cas saisir les mêmes informations d'identification que dans l'écran d'ouverture de session Kiosk (si l'authentification est désactivée dans votre système, la commande vda-client vous demandera tout de même un mot de passe, mais vous pouvez ne pas renseigner ce champ. Votre saisie ne sera pas validée dans ce cas).

    Si tout fonctionne parfaitement, vous pouvez obtenir la liste CSV des affectations de bureau/pool. Le format ressemble à :

    <pool-name>,<desktop-name>,<desktop-ID>,<origin>

    Si vous obtenez une erreur à ce stade, ou si le système signale qu'il n'y a pas d'assignation, consultez les journaux du Cacao. Recherchez les entrées du ClientRequestWorker qui gère les demandes de vda-client :

    ...
    Jun 26, 2009 12:10:47 PM com.sun.vda.service.client.ClientRequestWorker run
    FINEST: Received request from vda-client (127.0.0.1): query(user=username)
    ...
    Jun 26, 2009 12:10:49 PM com.sun.vda.service.client.ClientRequestWorker run
    FINEST: Sent response to vda-client: Windows 7,Windows70000003,8,User
    ...

    Situations pouvant entraîner des problèmes :

    • Echec de l'authentification

    • Le nom d'utilisateur est introuvable dans LDAP et aucun DN d'utilisateur ne peut être déterminé dans ce cas.

    • Aucune affectation de bureau n'a pu être détectée pour le DN utilisateur déterminé.

    Les entrées du journal enregistrées entre la réception de la demande et l'envoi de la réponse devraient vous permettre de comprendre le problème.

  2. Si l'opération décrite ci-dessus a fonctionné, demandez un bureau pour votre utilisateur.

    Là encore, cette opération peut être effectuée via la commande vda-client :

    $  /opt/SUNWvda/lib/vda-client -a start -u user \
    [-P pool-name [-D desktop-Id]]
    Password: xxxxx
    servername:49281
    

    Les paramètres pool-name et desktop-Id sont uniquement nécessaires si plusieurs bureaux sont assignés et que vous souhaitez démarrer un bureau spécifique. Lorsqu'un seul bureau ou pool a été assigné (ou lorsque vous souhaitez simplement démarrer le bureau par défaut), il n'est pas nécessaire de fournir ces paramètres. Si tout fonctionne, la commande renvoie le nom (ou l'adresse IP) du bureau/machine virtuelle de l'utilisateur, éventuellement suivi d'un caractère point-virgule et du numéro de port RDP.

    Si cela ne fonctionne pas (la commande signale une erreur), examinez de nouveau les journaux :

    ...
    Jun 26, 2009 12:25:14 PM com.sun.vda.service.client.ClientRequestWorker run
    FINEST: Received request from vda-client (127.0.0.1): start(user=username)
    ....
    Jun 26, 2009 12:25:18 PM com.sun.vda.service.client.ClientRequestWorker run
    FINEST: Sent response to vda-client: servername:49281
    ....

Là encore, les entrées du journal enregistrées entre la réception de la demande et l'envoi de la réponse devraient vous aider à comprendre le problème.

L'échec de détection d'un hôte adéquat pour démarrer le bureau est un problème typique. Dans ce cas, commencez par vérifier la mémoire disponible pour l'exécution du bureau/ordinateur virtuel.

10.8.4. Le client Sun Ray Client effectue un recyclage et ne peut pas se connecter à une machine virtuelle

  1. Vérifiez que vous avez une machine virtuelle disponible à laquelle vous pouvez vous connecter.

  2. Vérifiez que l'accès à distance est correctement configuré dans votre système d'exploitation invité.

  3. Vérifiez que l'hôte Oracle VDI peut communiquer avec vCenter ou votre hôte Oracle VM VirtualBox.

    Le pare-feu du serveur vCenter peut éventuellement bloquer la communication.

    Le nom d'utilisateur ou le mot de passe peut être incorrect.

  4. Vérifiez que les outils VMware sont installés sur le système d'exploitation invité Windows.

  5. Si vous vous connectez à des bureaux Windows 7 ou Windows 8 via Microsoft RDP, vérifiez que les utilisateurs se connectent en moins de 30 secondes.

    Par défaut, Windows 7 et Windows 8 déconnectent les connexions RDP si personne ne s'est connecté en 30 secondes.

10.8.5. Les utilisateurs ne parviennent pas à se connecter aux bureaux Ubuntu 8.04, car le réseau n'est pas activé.

Ubuntu utilisant l'ancien comportement réseau de "style Debian", chaque modification d'adresse MAC (chaque clone)décale d'une place le nom de l'interface réseau. Par conséquent, obtenir une configuration réseau qui fonctionne nécessite quelques clics d'administration. La seule solution à ce problème consiste, au moment de la préparation du modèle, à exclure la plage d'adresses MAC Oracle VM VirtualBox (08:00:27:*) du dispositif de "réseau permanent" dans /lib/udev/rules.d/75-persistent-net-generator.rules, puis de purger /etc/udev/rules.d/70-persistent-net.rules.

Pour plus d'informations sur les modifications de réseau permanent, consultez la page http://ubuntuforums.org/archive/index.php/t-1045715.html.

10.8.6. La redirection hot desking ne fonctionne pas avec Windows XP Edition Professionnelle et Microsoft RDP

Pour les bureaux virtuels Windows XP Professionnel, la redirection hot desking vers le centre Oracle VDI d'origine ne fonctionne pas lorsque Microsoft RDP (MS-RDP) est sélectionné en tant que protocole des bureaux du pool.

Pour les bureaux Windows, Oracle VDI peut faire la distinction entre une déconnexion du bureau et une fermeture de session du bureau. Si un utilisateur sélectionne Démarrer > Fermer la session dans le menu Démarrer de Windows, l'utilisateur est déconnecté du bureau Windows et de la session Oracle VDI (Kiosk). Si un utilisateur sélectionne Démarrer > Déconnexion, il est déconnecté du bureau Windows mais reste connecté dans VDI. S'il est déconnecté mais que la session n'est pas fermée, l'utilisateur est renvoyé à l'écran de sélection de bureau et peut, par exemple, sélectionner un bureau différent sans avoir à ouvrir une nouvelle session. Ce comportement de déconnexion est contrôlé par le paramètre client.logout.always qui est activé par défaut pour des raisons de sécurité. Lorsqu'il est activé, l'utilisateur ferme automatiquement sa session d'vdi; lors de la déconnexion du bureau Windows. Si le paramètre est désactivé, une déconnexion ne provoque par la fermeture de la session d'vdi;.

Dans le cadre du processus de fermeture de session d'vdi;, le client Sun Ray Client est redirigé vers le centre Oracle VDI contacté initialement. Ce comportement est particulièrement utile si vous devez gérer plusieurs centres VDI. Malheureusement, la distinction entre la fermeture de session et la déconnexion ne fonctionne pas sur les bureaux virtuels Windows XP Edition Professionnelle, si Microsoft RDP (MS-RDP) est utilisé pour afficher le bureau (et que le bureau a rejoint un domaine). Dans ce cas spécifique, Windows XP renvoyant le mauvais code de sortie, Oracle VDI interprète un Démarrer > Fermer la session comme une déconnexion du bureau. Par conséquent, l'utilisateur n'est pas déconnecté d'Oracle VDI et le client Sun Ray Client n'est pas redirigé vers le centre Oracle VDI initial.

Le contournement consiste à utiliser VirtualBox RDP (VRDP) au lieu de MS RDP ou de vous assurer que les utilisateurs ferment toujours leur session d'Oracle VDI lorsqu'ils se déconnectent de leur bureau. Comme expliqué ci-dessus, le paramètre client.logout.always est déjà activé par défaut. Si vous avez modifié ce comportement, vous pouvez le réinitialiser à l'aide de la commande suivante :

 # /opt/SUNWvda/sbin/vda settings-setprops -p client.logout.always=Enabled 

10.8.7. Echec de la relation sécurisée entre un bureau Windows et le contrôleur de domaine

Les ordinateurs Windows utilisent le mot de passe du compte pour s'authentifier auprès du domaine. Par défaut, Windows est configuré de manière à modifier le mot de passe du compte ordinateur tous les 30 jours. Si la stratégie de recyclage du bureau du pool Oracle VDI est configurée pour réinitialiser les instantanés, il peut se produire une non-concordance entre les informations d'identification du bureau et le contrôleur de domaine. Si vous rétablissez un instantané du bureau, toutes les mises à jour de mots de passe automatiques sont effacées. Dans ce contexte, lorsqu'un utilisateur ouvre une session et que le bureau Windows tente de se connecter au domaine, le contrôleur du domaine indique que la relation sécurisée entre la station de travail et le contrôleur de domaine principal a échoué ou qu'il existe des erreurs de connexion inconnues.

Il existe deux solutions de contournement :

Modification des paramètres de l'objet de stratégie de groupe

  1. Ouvrez une session sur le bureau Windows à l'aide d'un compte administrateur.

  2. Dans le menu Démarrer de Windows, exécutez gpedit.msc.

    L'éditeur de stratégie de groupe locale s'affiche.

  3. A l'aide de l'arborescence de navigation, accédez à l'emplacement suivant : Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité.

  4. Cliquez deux fois sur la stratégie nommée "Membre de domaine : désactive les modifications de mot de passe du compte ordinateur" et réglez-la sur Activé.

Par conséquent, le mot de passe du compte ordinateur n'est plus modifié. Ces bureaux faisant partie d'un pool géré par Oracle VDI Manager, cette modification n'a pas d'impact sur la sécurité.