We are exploring SLED 12 in our environment for desktop purposes. When I am trying to take a windows machine remotely using Remote desktop viewer from SLED, it cannot give any connection. Please suggest how to take remote desktops of windows machine or any best practices need to follow to access the windows remote desktop.
The command to connect via RDP to a system is ‘rdesktop’. If you are
using that and it is not working then you likely need to tweak the windows
system to allow remote connections.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I can’t use the remote desktop viewer on SLED 12 either. At first I thought it was because I was trying to connect to a RDP server on a non standard port (3389) and perhaps there was a bug with that or I was some how putting in the port syntax incorrectly.
I tried one that was listening on port 3389. Tested connection to these on CentOS and Windows rdp clients and they work. Just doesn’t on my patched SLED 12.
I would be extremely surprised if this product has been out for months and not working for other people. So Im thinking there might be some config at my end?
Would be awesome if some one can actually verify that the out of the box RDP clients works on SLED 12?
Remote server is listening btw
user@my-desktop:~/Desktop> telnet server 3389
Trying xx.xxx.xx.xx…
Connected to server
Escape character is ‘^]’.
Symptoms I get with the client is when I find a legitimate connection is the client window goes black for about a second then the client comes back to its normal gray window. No error message box. Nothing.
A bogus connection (where I intentionally put in a screwy port just goes black)
Run the command from the command line, as you may get output there
which you do not see when calling it straight from the GUI.
Be SURE that your windows boxes are not rejecting things. Newer (but
not anywhere near new) versions of windows reject older RDP clients by
default as I recall, so if you have them configured to not allow older RDP
clients then you may not get more than a start of the connection followed
by rejection. I THINK this will show up in STDOUT/STDERR so launching
from the command line should help. If not the windows-side logs should
indicate something too.
Setup a LAN trace to see which side (client or server) is tearing down
the connection.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I’ve just been playing with this trying to connect to a Windows 7 machine. I got it to work by specifying ‘–sec rdp’ in the ‘Advanced options:’ field.
strace reveals that vinagre is actually calling the FreeRDP binary xfreerdp to do the connection, which makes my suggestion earlier in the thread to try FreeRDP instead of vinagre invalid.
You can install tsclient from the repos. tsclient requires rdesktop, which is no longer used or available in SLED12
vinagre, the GUI that should work with xfreerdp (the replacement for rdesktop) doesn’t catch xfreerdp’s CLI interaction to enter the password or approve certificates if you aren’t using the old authentication method so you have to call vinagre from a CLI to use it.
I created a script that takes the arguments for rdesktop and runs xfreerdp instead so I could continue using tsclient, where all of my destinations are saved. I still have to run tsclient from a CLI to enter passwords.
Huh. This is an issue which has come up before because rdesktop was removed from SLED 11 as of SP3. The tsclient package on SLED 11 SP3 has been fixed.
[CODE]mike@linux:~> cat /etc/SuSE-release
SUSE Linux Enterprise Desktop 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3
mike@linux:~> rpm -q --changelog tsclient | head -4
Somehow the tsclient package in SLED 12 hasn’t had the patch applied to it, strace shows it still looks for the rdesktop binary.
Yep, can reproduce that. It appears to be an upstream issue since there’s a bug report about it for Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1062213
Last comment indicates bug is present in Red Hat Enterprise 7 too
I talked to someone about the tsclient issue when it was discovered in SLED 11 SP3 so I’ll see if I can raise it again via same channel. But if you can raise a Service Request and if not use https://www.suse.com/support/report-a-bug/ Two reports get twice the attention than one. Maybe.