Time does pass quickly. I just realized it has been over two months since I had time to write an article here. I finally found something new I want to write about, so I am taking time to do that now. Please feel free to leave a comment.
Today I am working to finish setting back up a Microsoft XP Professional based Dell Optiplex 755 system for one of my local clients. It had a dinked-up Windows Registry and needed to have a fresh install done. This model does not include PS/2 mouse and keyboard ports. When I took this system in on Friday I did not realize I have no available USB optical mouse to use. Nor do I have a PS/2 to USB adapter on hand. While this will be corrected in the future, the only USB mouse I have on hand is a small Belkin mouse for use with a laptop. This mouse uses a ball instead of optics to move the pointer and it has a very short cord. A USB extension cable solved the short cord problem. This would be a good solution if the mouse were not worn out from use causing the pointer to not be easy to move all the time. As a result, to say I hate using this mouse is an understatement. During the reinstall of XP Professional on this PC I finally got to the point where I had to do something to relieve the pain.
When I originally worked on the systems for this client I set up TightVNC on all the systems at the location. Then, using non-standard ports, I configured their router for remote access to be able to support these systems remotely using the Java based web connector in TightVNC from my Firefox web browser. This works wonderfully for all the systems at the location … except for this #@$% Dell Optiplex 755. For some reason TightVNC would never receive a remote connection on this system. I tried over and over to get it working but never was able to resolve the problem. However, in reinstalling the system I had hopes that TightVNC would now work so I would not have to use this awful mouse to finish setting up the system. Unfortunately, even after a wipe and reinstall of Microsoft XP Professional TightVNC will not make a connection. At this point I suspect it may have something to do with the Intel video built-in on the motherboard. Apparently the Microsoft Windows driver for this Intel video chip is incompatible with TightVNC. It is rare that TightVNC will not work, but it does happen. However, I still needed a way to connect to this PC for remote support as well as to end my scroll-mouse pain trying to set it up using this horrid, worn out Belkin mouse.
Suddenly, as if a light from Heaven illuminated my head, I recalled there is another tool for remote access to Microsoft Windows based computers. I could not remember the name so I did a quick web search. Sure enough I found references to ‘rdesktop‘ for connection to Microsoft based Remote Desktop Protocol (RDP) servers from Unix and GNU/Linux. A check of the installed packages on my Mandriva 2010 PC found that rdesktop was already installed and waiting for me to use. I checked the rdesktop manual page (man rdesktop) to see how it works. Following that I set up remote desktop support on the Microsoft XP Professional PC. Then I used the following line to connect to the Microsoft XP Professional PC:
rdesktop -a 16 -u MSUSER -p MSPASS -g 1024×768 REMOTEIP:REMOTEPORT
Success! It worked! Not that I had doubts it would work … okay, I admit I did have some doubt. After the TightVNC problem I was concerned that no remote access would work on this PC. Fortunately for me I was wrong.
I will explain what that rdesktop line above does. The “-a 16″ specifically sets the color depth to 16 bpp for the connection. One may use 8, 15, 16 or 24 bpp for the color depth. I tried 24 bpp but received a message from rdesktop that it was not supported in this instance. The “-u MSUSER -p MSPASS” passes the Microsoft user login name and password for that user to rdesktop to send to the RDP server on the Microsoft PC. This bypasses the login prompt one would otherwise have to use. The “-g 1024×768″ sets the local rdesktop window geometry to 1024 width by 768 height. The “REMOTEIP:REMOTEPORT” in this case are 10.10.10.101:3389, which are the values for the system while connected to my LAN. One may leave off the port number of 3389 as that is the default port. However, I am going to be using this over the internet with a non-standard port so I am practicing including the port now to ingrain it in my memory.
Below is a screen shot showing this working on my system:
XP Pro in rdesktop at ERACC
Click to view the full size image.
Now I have a new, to me, tool to use to support my clients that insist on running Microsoft operating systems. After about ten years of looking into and using GNU/Linux for my own use I have not found a thing that I need to do that I cannot do using GNU/Linux. I expect over the next ten to twenty years more and more people will discover the same results with GNU/Linux for themselves. I look forward to watching that happen.
This article has had this many unique views:
| design schools |
Notice: All comments here are approved by a moderator before they will show up. Depending on the time of day this can take several hours. Please be patient and only post comments once. Thank you.
on Jan 19th, 2010 at 8:11 pm
[...] GNU/Linux: rdesktop – Working on a Windows Based PC Remotely [...]
on Jan 21st, 2010 at 11:55 pm
I know that you have to use Wine to get this to work but you can also use teamviewer which is a great way to connect to those that you need to connect to.
on Jan 22nd, 2010 at 4:13 am
Specifiying password on the command-line is usually bad, since these
can be read by any user of the system with the help of ‘ps axw’ (
all users, processes without controlling tty, wide output).
on Jan 22nd, 2010 at 4:21 am
A good alternative to VNC or RDP in case where you can’t/don’t want to open ports on a customer’s router is the (free for personal use, $ for commercial use) TeamViewer solution (www.teamviewer.com): Both the user and techie connect out to TeamViewer’s server so that there’s no need to fidget with the router. From experience, it offers very good performance.
Alternatively, UltraVNC (www.uvnc.com) can dial out to the techie’s support host, but I assume that it wouldn’t work with the above built-in Intel video chip.
on Jan 22nd, 2010 at 4:27 am
It would be great if it supported NLA on newer windows systems (vista, 2008, 7)
on Jan 22nd, 2010 at 9:15 am
I have around 50 OptiPlex 755 desktops deployed with Windows XP SP3 and have found that the Intel NIC really requires the Intel management software to be installed for everything to work properly. I forget what exactly they call it, but it’s the software that allows the NIC to support SNMP. All of these units are connected with Cat 6 on gigabit switch ports. What I have found is that you need to disable some of the power saving features and this can only be accomplished by installing the management software. Specifically the setting to reduce the link speed when in power saving mode and enabling the “Wait for Link” setting seem to solve multiple issues I was having. It’s possible that they’ll help you as well.
on Jan 22nd, 2010 at 9:16 am
This is the power of a Linux system. We can do more even for people needs when it is about Window-users. Nice text you shared with us.
ASAP I’ll ask my friend here to let me try the same with his pc running Windows 7. I have two machines running Windows 7 and my beloved notebook running Mandriva free 2010 so it’ll be a nice tool to use when I need to operate those machines using some remote access. Thanks!
on Jan 22nd, 2010 at 9:27 am
Um, why suggest folks drop to scary bash to do that when Terminal Server Client is installed everywhere? Great app as a front-end to rdesktop (and other things).
on Jan 22nd, 2010 at 9:56 am
[...] GNU/Linux: rdesktop – Working on a Windows Based PC Remotely [...]
on Jan 22nd, 2010 at 10:05 am
Try ‘Remmina’ - its on sourceforge. It integrates RDP,VNC & SSL & the GUI’s the best linux RDP client yet. I use it every day to login to my work VPN. You can run it as a panel applet in Gnome, where you can left click it & up comes a list of all the connections you’ve set up. The best thing though is that the full screen works properly, a tab auto-hides at the top, a bit like Windows RDP client, but with more functionality. The older clients full screen didn’t let you minimise it.
on Jan 22nd, 2010 at 1:28 pm
John (comment #2), thanks for reading.
No, one does not need WINE for rdesktop at all.
on Jan 22nd, 2010 at 1:31 pm
Rainer Weikusat (comment #3), I appreciate your comment.
Yes, if anyone else had access to my systems I use for support that would be a concern. However, I am the only one that uses the desktop PC and laptop PC that is used to support these remote clients. On a multi-user shared system I would not place the login credentials on a command line.
on Jan 22nd, 2010 at 1:37 pm
adminZ (comment #8), thank you for the expected anti-CLI response.
I recommend the CLI because any excellent administrator knows that is where the true power of GNU/Linux lay. Perhaps it is ironic to use the CLI to start a connection to a neutered GUI based operating system. But I think irony is delicious.
on Jan 22nd, 2010 at 1:41 pm
Dave (comment #6), I appreciate your comment!
I will look into that and see if I can find that Intel management software. If your suggestion solves the TightVNC problem on this PC where do I send the pizza?
on Jan 22nd, 2010 at 4:15 pm
Terminal Service is the key
on Mar 18th, 2010 at 7:31 am
Using VNC requires opening of inbound TCP ports, which can endanger security. You can go for RHUB remote access. It gives you the protection of your own firewall. It is an on-premise appliance that can be deployed behind your firewall. Security is further reinforced through access control by IP address.
on Mar 18th, 2010 at 12:43 pm
BrainTiller (comment #16) thanks for the comment.
The devices you link to are nice, but costly for a small business or local charitable organization that needs to keep expenses down. Using a Linux firewall with port forwarding using non-standard ports and IP access control with VNC will be “safe” too. I have yet to have a PC compromised, or even attempted to be accessed by unauthorized access, behind a Linux firewall or business firewall appliance I set up that uses this type of configuration. Plus the Linux firewall can run on an existing “old” PC and costs nothing other than the setup labor which is going to be less than your devices plus setup labor for them.
Your devices seem more targeted to mid-sized and larger businesses.
on Jul 14th, 2010 at 3:40 pm
I have been very pleased with the software from proxy networks in terms of remote desktop software. I continue to be impressed by the flexibility of these programs and the productivity they afford me, especially from the road. Thanks for the write-up! Sounds like you may have learned a thing or two, if nothing else!