10.8. Logging In and Accessing Desktops

10.8.1. Users Cannot Access Their Desktops
10.8.2. A User Can Log in But Their Desktop is Not Responding
10.8.3. Error - "Currently There Is No Desktop Available Or Assigned to You"
10.8.4. The Sun Ray Client Is Cycling and Cannot Connect to a Virtual Machine
10.8.5. Users Cannot Log in to Ubuntu 8.04 Desktops Because the Network Is Not Enabled
10.8.6. Hotdesking Redirect Does Not Work With Windows XP Professional and Microsoft RDP
10.8.7. The Trust Relationship Between a Windows Desktop and the Domain Controller Fails

10.8.1. Users Cannot Access Their Desktops

  1. On a terminal trigger the following command:

    /opt/SUNWvda/lib/vda-client -u user
    
  2. If things work as expected, then the vda-client will trigger the startup of the corresponding desktop and should return an IP (for example. 10.16.46.208) or DNS name (for example, xpdesktop01) for accessing the user's desktop. If the RDP port differs from the default, then it will be appended to the IP/DNS name (for example. 10.16.46.208:49259 or xpdesktop01:49259)

  3. With that information it should now be possible to establish an RDP connection to the desktop.

  4. If no IP or DNS name is returned by vda-client, Oracle VDI might not be able to resolve the user ID in the user directory.

    To check that, change the log level for directory services as described in Section 10.3.1, “Increasing Logging to Troubleshoot User Directory Problems”.

  5. Check the Cacao log file for entries of the type:

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

    See Section 8.5.4, “Checking the Oracle VDI Log Files” for details.

  6. If <dn> is null, that means that no user matching the user id <test user> was found in the user directory. It might be necessary to customize the list of attributes ldap.userid.attributes to match the directory schema as explained in Section C.1, “Editing LDAP Filters and Attributes”.

  7. If <dn> is not null, that means that the user matching the user id <test user> was correctly found in the user directory.

10.8.2. A User Can Log in But Their Desktop is Not Responding

A user might find that they can log in to Oracle VDI, but they cannot use a desktop because the virtual machine is not responding.

If this happens, the solution is to restart the desktop. This can be performed by an administrator (for example with the vda desktop-restart command) or by the user.

For a user to restart their desktop, they must first disconnect from the desktop by moving the mouse up to the top of the screen and clicking the "X" on the remote desktop pulldown menu. When the Desktop Selector screen is displayed, the user selects the non-responsive desktop and clicks the Reset button to restart the desktop. Restarting a desktop is the same a rebooting a traditional PC, and users also see a warning that they might lose their unsaved data. Once the desktop is rebooted, it can be connected to from the Desktop Selector screen. Desktops provided by the following provider types cannot be restarted in this way:

  • Generic desktop provider

  • Microsoft Remote Desktop provider

  • Sun Ray Kiosk Session provider

10.8.3. Error - "Currently There Is No Desktop Available Or Assigned to You"

Oracle VDI typically returns the above message for the following reasons:

  • There are no desktops directly assigned to the user.

  • There is a pool assigned to the user, but no desktops in the pool are available or free to use.

  • A desktop has been selected, but it is in an unusable state, typically the startup of the desktop has failed for whatever reasons.

If this message occurs, check the Cacao log file, see Section 8.5.4, “Checking the Oracle VDI Log Files”.

To establish the root cause, complete the following steps:

  1. Check that your desktop/pool assignments are correctly recognized by your system.

    The Oracle VDI Kiosk login uses an internal command (vda-client) to retrieve that information. You can manually trigger this command from a terminal (root privileges are not necessary):

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

    The command asks for the user's password. So you have to enter the same credential information as on the Kiosk session login screen (if authentication is disabled on your system, the vda-client command will still prompt for a password, but you can leave this blank then - your input is not validated in this case).

    If everything works, then you should get a CSV list of desktop/pool assignments. The format is something like:

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

    If you get an error here, or the system reports no assignments, check the Cacao logs. Look for entries of the ClientRequestWorker that handles vda-client requests:

    ...
    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 that could cause problems:

    • Authentication failed

    • The user name could not be found in LDAP and as a result no user DN could be determined

    • No desktop assignments found for the determined user DN.

    The log entries between the request received and sent response should give you some insights here.

  2. If the above worked, request a desktop for your user.

    Again this can be done via the vda-client command:

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

    The pool-name and desktop-Id parameters are only necessary if multiple desktops are assigned and you want to start a specific desktop. If there is only one desktop or pool assigned (or you just want to start the default desktop), then you do not need to provide these parameters. If everything works, then the command will return the name (or IP) of the user's desktop/virtual machine optionally followed by a colon and the number of the RDP port.

    If that does not work (the command reports an error), then you should again take a look into the logs:

    ...
    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
    ....

Again the log entries between the request received and sent response should give you some insights about any issues here.

One typical issue is that no suitable host to start the desktop has been found. In that case you should first check the memory available for running the desktop/virtual machine.

10.8.4. The Sun Ray Client Is Cycling and Cannot Connect to a Virtual Machine

  1. Verify that you have a virtual machine available to connect to.

  2. Verify that remote access is correctly configured on your guest operating system.

  3. Verify that the Oracle VDI host can communicate with either your vCenter or your Oracle VM VirtualBox host.

    The firewall on the vCenter server might be blocking the communication.

    The user name or password might be incorrect.

  4. Verify that the VMware tools are installed on the Windows guest OS.

  5. If connecting to Windows 7 or Windows 8 desktops using Microsoft RDP, ensure that users log in within 30 seconds.

    By default Windows 7 and Windows 8 disconnect an RDP connection if no-one logs in within 30 seconds.

10.8.5. Users Cannot Log in to Ubuntu 8.04 Desktops Because the Network Is Not Enabled

Ubuntu has the old "Debian style" network behavior so that every MAC address change (every clone) bumps the network interface name by one. The result is that getting a working network configuration requires a few admin mouse clicks. The only solution to this is at template preparation time by excluding the Oracle VM VirtualBox MAC address range (08:00:27:*) from the "persistent net" machinery in /lib/udev/rules.d/75-persistent-net-generator.rules and then purging /etc/udev/rules.d/70-persistent-net.rules.

For more details on persistent net changes, refer to http://ubuntuforums.org/archive/index.php/t-1045715.html.

10.8.6. Hotdesking Redirect Does Not Work With Windows XP Professional and Microsoft RDP

For Windows XP Professional virtual desktops, the hotdesking redirect to the original Oracle VDI Center does not work if Microsoft RDP (MS-RDP) is selected as the desktop protocol for the pool.

For Windows desktops, Oracle VDI can distinguish between a desktop disconnect and a desktop logout. If a user selects Start > Logout from the Windows start menu, the user is logged out of the Windows desktop and the Oracle VDI (kiosk) session. If the user selects Start > Disconnect, then the user is disconnected from the Windows desktop while remaining logged into VDI. If disconnected but not logged out, the user is returned to the desktop selection screen and can, for example, select a different desktop without the need to log in again. This disconnect behavior is controlled by the client.logout.always setting, which is enabled by default for security reasons. When it is enabled, the user is automatically logged out of Oracle VDI upon disconnecting from a Windows desktop. If the setting is disabled, however, then a disconnect does not result in a logout from the Oracle VDI session.

As part of the Oracle VDI logout process, the Sun Ray Client is redirected to the initially/first contacted Oracle VDI Center. This behavior is especially useful when dealing with multiple VDI centers. Unfortunately, the distinction between logout and disconnect does not work for Windows XP Professional virtual desktops, if Microsoft RDP (MS-RDP) is used for displaying the desktop (and the desktop has joined a domain). In this specific case, because Windows XP returns the wrong exit code, Oracle VDI interprets a Start > Logout as a desktop disconnect. Consequently, the user is not logged out of Oracle VDI, and the Sun Ray Client is not redirected to the initial Oracle VDI Center.

The workaround is either to use VirtualBox RDP (VRDP) instead of MS RDP or to ensure that users are always logged out of Oracle VDI when they disconnect from their desktop. As explained above, the client.logout.always setting is already enabled by default. If you have changed this behavior, you can reset it with the following command:

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

10.8.7. The Trust Relationship Between a Windows Desktop and the Domain Controller Fails

Windows computers use the machine account password to authenticate with the domain. By default, Windows is configured to change the machine account password every 30 days. If the Oracle VDI pool's desktop recycling policy is configured to Reset to Snapshot, a mismatch between the credentials of the desktop and the domain controller may occur. When you revert to a snapshot of the desktop, all automatic password updates are erased. Under these circumstances, when a user logs in and the Windows desktop attempts to join the domain, the domain controller reports that the trust relationship between the workstation and the primary domain controller failed, or that there are unknown logon errors.

There are two workarounds:

Modifying Group Policy Object Settings

  1. Log in to the Windows desktop with an administrator account.

  2. From the Windows Start menu, run gpedit.msc.

    The Local Group Policy Editor is displayed.

  3. Use the tree navigation to go to this location: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.

  4. Double-click the policy named "Domain member: Disable machine account password changes" and set it to Enabled.

As a result, the machine account password is no longer changed. Because the desktops are part of a managed Oracle VDI Manager pool, this modification has no security impact.