Unsolved
This post is more than 5 years old
44 Posts
0
13491
Release:vWorkspace Connector for Android 1.1.1
Quest has just released version 1.1.1 of the vWorkspace Connector for Android. This is a minor patch release and is obtainable from the Android Market here. Devices that are enabled with auto-updates for the vWorkspace Coonector for Android version 1.1 will receive version 1.1.1 automatically.
This release corrects the following issues:
Issue | Defect ID |
---|---|
Using the vWorkspace Connector for Android v1.1 with EOP Xtream enabled may prevent the Connector from connecting to a remote host when the connection is proxied by Quest Secure Gateway. | 171941 |
The vWorkspace Connector for Android v1.1 may hang after a log off action from a virtual desktop when using the Motorola Xoom. | 172171 |
The vWorkspace Connector for Android v1.1 may crash during logoff of a virtual desktop if the Connector toolbar is clicked multiple times. | 172272 |
The Android back button does not work while connected to a virtual desktop from the vWorkspace Connector for Android v1.1 | 172273 |
If the disconnect button is clicked, after initiating a logoff from a virtual desktop session, a disconnect notice will persist after the logoff has completed. | 172550 |
Active sessions to a virtual desktop from an Android device will terminate with the error "The terminal server reset connection before license negotiation completed. Possible cause: connection timeout” after the Android device screen has been turned off. | 172568 |
This release is fully supported by Quest, but as always we are also here in the community to help
omniw0lf
14 Posts
0
October 18th, 2011 04:00
Hi,
I'm trying to get the android connector working in my company, but running into some problems. We have tried with the iPad connector and it works fine, however with the android one it can never connect. We are able to connect to the farm, so it displays all the icons i can click on, but when i click any of them, i get the error message:
Could not establish a connection to the server
Any ideas? The only thing i could think of is we have legal text that comes up before you can login to the terminal server (RDSH), and maybe the android client can't handle it? on the iPad client after you click an icon to load, it shows the legal text, you click OK, and then the rest works perfectly.
I'm having this issue on both an android phone (samsung Galaxy S II), and an android tablet (asus transformer).
Thanks in advance, and if you'd prefer that i start a new thread about this please let me know.
Nick.
DELL-David Y
228 Posts
0
October 18th, 2011 05:00
Hi Nick
Can you confirm that you are using version 1.1.1 of the Android Connector and not an earlier version, such as 1.1?
Did you enable the application logging to see if that shows any more information about the connection failure. The User Guide describes how to enable the logging option.
Kind Regards
David
omniw0lf
14 Posts
0
October 18th, 2011 23:00
Hi David,
Yes, both devices are a fresh install - v1.1.1.
I have enabled logging during a connect and uploaded the results here: http://twosx.net/work/vWorkspace_10-38-19-10-11.txt
Nick.
DELL-David Y
228 Posts
0
October 19th, 2011 07:00
Hi Nick,
Thanks for uploading the log file. Can you tell me how your Android device is connected to the network, are you using a 3G connection or WIFI?
During the test was the device on a network that is connected to your vWorkspace servers, or would it have been an external connection across the Internet?
I can not see anything in the log to suggest the legal text is to blame for the connection failure. The connection details show the IP address of the server but the connection fails due to a timeout.
Are you able to install a Telnet client onto the device and check connectivity to the IP 10.1.91.33 on port 3389
Regards
David
DELL-David Y
228 Posts
0
October 19th, 2011 08:00
Nick,
I was able to locate an Android device in the office and have tested a connection to my vWorkspace farm both with and without the legal text pre-logon message, it works just fine.
David
omniw0lf
14 Posts
0
October 19th, 2011 22:00
Hi David,
I'm connecting via Wifi on the public internet. We then have a public NAT'd address to our SecureIT box. The connection broker is 10.1.91.33, so there's no way i'd be able to telnet to it from the internet.
the location settings on the android are as follows:
broker name/IP: our public facing IP
broker TCP port: 98443
NAT: unticked
RDP over SSL: ticked
secure gateway name/ip: our public facing IP
secure gateway tcp port: 443
our secureIT settings are as follows:
RDP proxy
local IP: secureIT box IP (which the public IP gets translated to)
local port: 443
Web interface proxy
local ip: secureIT box IP
local port: 443
destination host: 10.1.91.33
destination port 443
enable SSL: ticked
connection borker proxy
local ip: secureIT box IP
local port: 98443
destination hosts: 10.1.91.33
destination port: 8080
enable SSL: ticked
i assume you are referring to this line in the logs:
INFO: com.provisionnetworks.pntsc.PNTSC: Connecting to 10.1.91.33:3389 ...
is this saying that my android is directly trying to connect to 10.1.91.33 on port 3389? or is it saying "through the magic of tunnelling via your secureIT box our resultant connection will be to 10.1.91.33 on port 3389"? because if it's the former.. that'll never work.
This setup works fine for the iPad.
Nick.
DELL-Andrew W1
378 Posts
0
October 20th, 2011 08:00
Hi Nick,
You need to use the FQDN for the RDP over SSL.
This obviously needs to resolve to the external address of the SSL Gateway and you need to have a certificate installed so you trust it too.
If you want to raise a case for this issue so you can send me the connection details (FQDN, Username, Password) I'll happily test it from here for you.
Thanks, Andrew.
DELL-David Y
228 Posts
0
October 20th, 2011 09:00
Hi Nick,
Thank you for replying with the additional information. Now I know that you are not on an internal network I can see why the connection is failing. Your connection must traverse the Secure-IT (SSL Gateway) server in order to be able to connect to the internal host, otherwise as you say, it will never work.
In the connection log file that you posted the other day there is a section that would show the server name/IP and the port for the SSL gateway, in your case this is not correctly set, i.e. empty:
command:s:pnstart.exe
enablesso:i:0
enablekerberos:i:0
sslgateway:s::
This means it is attempting a direct connection without going via the SSL Gateway and is why you are getting a connection timeout.
I understand this works on your iPad so imagine that Android is more picky about the settings used. I suggest raising a case, as Andrew requested, we can then work with you to correct this.
Regards
David
omniw0lf
14 Posts
0
October 20th, 2011 21:00
ok strange, because i definitely have the SSL gateway set in my location settings.
in the android client settings above i lied a bit - for the "broker name/IP" and "secure gateway name/ip" i said our public IP, but actually i have in there the FQDN (blah.com)
i'll raise a case..
rene11
74 Posts
0
October 27th, 2011 10:00
We are trying the latest Android client with our vWorkspace environment.
How should users connect to the farm if we are using the secure SSL gateway + RSA?
If I'm correct they should just go to the sucre website, login, and then the .pit should be automaticly opened with the android client. Without configuring anything.
Is this the right way? Because that doesn't seem to work.
After login, the user tabs his VDI icon. The VDI session starts in the background, but nothing happens on the Android.
mounty1
2 Posts
0
October 27th, 2011 11:00
Just trying the Android client on an Asus Transformer. Works good except for the keyboard. The first letter after holding shift gets swallowed. Example: holding shift and pressing qqww results in QWW. I also tried an external usb keyboard with the same result :/
Kelly Craig
44 Posts
0
October 27th, 2011 17:00
Thanks Mounty,
we are working this issue and it should be resolved in the next release of the Android connector.
Kelly Craig
Kelly Craig
44 Posts
0
October 27th, 2011 17:00
Are you using Web Access for two-factor?
rene11
74 Posts
0
October 31st, 2011 07:00
Yes, web access for two factor!
They can login into web access, click on their virtual desktop, and then nothing happens.
Kelly Craig
44 Posts
0
October 31st, 2011 12:00
I suggest you open a support case regarding this.