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:
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.
Friday, February 5, 2010
Subscribe to:
Post Comments (Atom)
Quite informative article. Thanks...
ReplyDeleteRegards,
clipping path service provider