There have been a couple of problems reported with international keyboards and the Sun Ray Connector for VMware VDM.
Some of the issues are:
Inability to enter characters that require Alt Gr combinations
When numlock is enabled the Enter, backspace and arrow keys don't work
In the Windows session, the keyboard is mapped as US
The first two are caused by a problem with Java and xkb. The solution is either to turn of the xkb extensions using this command '/opt/SUNWut/bin/utxconfig -k off' in the kiosk script: /etc/opt/SUNWkio/sessions/vdm/vdm. Using Java 6 also solves these problems, (you will need the Java 6 update 12 JDK, other versions can cause problems). You may need to change the kiosk script to point to the correct Java install. Change the line 'theJavaExec=/usr/java/bin/java' to point to the new location.
The third problem is due to the locale not being set for the windows session. You can set it in two ways. In the Sun Ray web administration go to Advanced > Kiosk Mode > Edit and enter the correct value for Locale. Or you can pass the locale as an argument to the kiosk script. On the same page add the argument -l <locale> after the double dashes.
The names of the locales can be found here. These solutions assume that everyone on the site is using the same keyboard layout. Other configurations will require some extra changes to the kiosk script, that's left as an exercise to the reader.
There is a long standing problem in VirtualCenter 2.5 where cloning fails with this error:
The VirtualCenter server is unable to decrypt passwords stored in the customization specification.
It happens apparently randomly, but can be caused by installing Internet Explorer 7 on the VirtualCenter host. There is an ongoing thread in VMware communities about it: http://communities.vmware.com/thread/54721. There were rumours that the problem was going to be fixed in update 3, but it shows up in update 1, 2 and 3.
One of the solutions is to export the customisation spec, edit it so that the password is stored in plain text, and import it back into VirtualCenter.
If storing the password in plaintext isn't acceptable, replacing the SSL
certificate in VirtualCenter can also fix the problem, provided the new certificate uses the password that is hardcoded into
VirtualCenter.
Fix the problem by using plain text passwords
Export the customisation spec, and edit the saved XML file.
Change the value <plainText>false</plainText> to <plainText>true</plainText> And <value>MJwe3zWdcKeAfZIB ... etc... </value> to the actual password, e.g. <value>Password01</value>. So the password section should look like this:
There is one step in the instructions needs to be modified, you have to change the password to the one that VirtualCenter expects.This command:
openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:vmware -out rui.pfx
Should be replaced with: openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx
After you have replaced the certificate you will have to reconnect the ESX servers in VirtualCenter, and recreate the customisation specs. At this point it is safe to install Internet Explorer 7 on the server.
Using virtual machines with more than one network interface can be problematic. Sun VDI expects RDP to be available on the primary interface. If RDP is actually running on a different interface, then the machine may not be prepared successfully or assigned to users.
The problem arises in determining which exactly is the primary interface. The VMware documentation would lead us to believe that it is the primary interface listed in Windows. But, this is not the case. In fact, the primary interface is determined by the order of the network adapters in VirtualCenter. The network adapter with the highest number, usually the one which was added most recently, is the primary network adapter.
How to change the network of the primary adapter
Edit the virtual machine settings in VirtualCenter.
Select the network adapter with the highest number, e.g Network Adapter 3.
This is the primary network interface. Change the network label to the appropriate network for RDP.
You may need to adjust the other network adapters so that the virtual machine is assigned to all the correct networks.
This page is updated as more solutions become available, also see this page for keyboard issues.
Log messages
The log messages for the VDM connector are located in /var/opt/SUNWut/log/messages Look for messages beginning with 'kiosk:vdm'.
It may also be helpful to look at the VDM Connection Broker log messages, they can be found in the VDM web administration under Events.
Error connecting to VDM server: javax.net.ssl.SSLException: java.lang.RuntimeException
Error message:
Error: Error connecting to VDM server: javax.net.ssl.SSLException:java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
This desktop is currently not available. Please try connecting to this desktop again later or contact your system administrator.
The desktop sources for this desktop are not responding. Please try connecting to the desktop again later, or contact your system administrator
There are several causes for these error messages. They usually means the desktop is not set up properly, or is already in use.
Some of the possibilities are:
Some one is already logged in that machine (over remote desktop or via the console in VirtualCenter).
The machine is powering on/off or suspending.
There are no free desktops for that user.
The VDM tools are not installed on the desktop, or are not working correctly. Check that the desktop status is available in the VDM web administration.
Active Directory and/or DNS is not setup properly on the desktop.
There is a network communication problem between the VDM server and the desktop.
Windows firewall is blocking connections to the desktop.
There may be more details in the VDM event log in the web administration. You can get help with the VDM configuration on the VMware communities site.
Connection tunneling is required to connect to the desktop but it is
not supported by this client
Connection tunneling provides security across a WAN. It allows an encrypted connection from the client to the desktop, by tunneling it through the VDM server. To use the Sun Ray VDM connector, you need to disable connection tunneling.
VDM 2/2.1:
Open the VDM web administration, go to Configuration and enable
"Direct Connect to virtual desktop"
VDM 3
Open the VDM web administration, go to Configuration > VDM Servers > Edit, and enable
"Direct connection to desktop"
Exception in thread "main"
java.lang.NoClassDefFoundError
Error message:
Nov 14 07:14:02 host kiosk:vdm[12464]: [ID 702911 user.error] Error: Could not locate Virtual Machine for 'pseudo.0836f860ab8': exit code: 1 Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/java/help/impl/SwingWorker Nov 14 07:14:02 host at com.sun.ut.vdm.VdmClient.<init>(VdmClient.java:27) Nov 14 07:14:02 host at com.sun.ut.vdm.VdmClient.main(VdmClient.java:38) Nov 14 07:14:02 host Caused by: java.lang.ClassNotFoundException: com.sun.java.help.impl.SwingWorker Nov 14 07:14:02 host at java.net.URLClassLoader$1.run(URLClassLoader.java:200) Nov 14 07:14:02 host at java.security.AccessController.doPrivileged(Native Method) Nov 14 07:14:02 host at java.net.URLClassLoader.findClass(URLClassLoader.java:188) Nov 14 07:14:02 host at java.lang.ClassLoader.loadClass(ClassLoader.java:306) Nov 14 07:14:02 host at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) Nov 14 07:14:02 host at java.lang.ClassLoader.loadClass(ClassLoader.java:251) Nov 14 07:14:02 host at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) Nov 14 07:14:02 host ... 2 more
Solution:
This error occurs if you are using an incorrect version of Java, Java 1.5 is the supported version. If you want to use Java 6 you will need the Java 1.6 update 12 JDK.
Desktop tries to open but immediately disconnects
Error message:
Dec 3 12:41:17 host kiosk:vdm[12656]: [ID 702911 user.error] uttsc
exited with errorcode: 1
Solution:
There are several reasons why this error message can occur. To diagnose the problem further, try to connect to the desktop manually from the Sun Ray Server using:
/opt/SUNWuttsc/bin/uttsc <desktop IP>
It should open a remote desktop connection to the virtual machine. If it fails, it can give you an error message with some further information.
This desktop is not currently available
Hotdesking is not enabled in the Sun Ray VDM Connector 1.0, so if your desktop session is already in use, it will be unavailable if you try to use it from a Sun Ray client. Yes, this is contradicatory to the behaviour of other clients, but it has been fixed in version 1.1.
Usernames containing spaces are not correctly detected
Problem:
If the user name assigned to a token contains spaces, then only part of the name will be automatically entered in the login window.
Solution:
There is a problem with how spaces in the user name are handled in the kiosk scripts. You can get versions of the scripts containing the fix here: vdm and vdm-user.sh. You will need to replace the files:
There is a problem with the certificate that comes with the VDM connector. The VDM server's certificate uses a
default host name, which won't match the actual host name, so the SSL authentication will fail. You'll need to generate one with the correct value and import it into the
connection broker.
Here's the full set of instructions for using SSL:
1. Using the Windows command prompt, create a new keystore containing a
public‐private key pair (filling in the appropriate password and hostname).
Open the VDM connection broker web interface. When you are asked to accept the
certificate, choose Examine Certificate and then Export. Save the certificate to file.
Internet Explorer:
Open the VDM connection broker web interface In the security alert, choose View Certificate, open the Details tab, and then Copy to File, and follow
the steps in the wizard.
2. Copy the certificate file to the Sun Ray server where the VDM connector is
installed.
3. Install the certificate into the keystore for VDM with the following command:
|
|
|
|
The issue with numlock is not limited to internati...
My mistake, jre 1.6.0_13-b03 does indeed fix the i...