Sorry Girish, there is no way to use VNC to take over a virtual terminal
server session. You can only take over the console screen.
A FEW VNC/TERMINAL SERVER TIPS
When you do connect to the Terminal Server console using VNC, you want to
make sure that certain settings are in effect:
1. Make sure that your server's screen saver is disabled. Switching to a
screen saver in a different resolution or even back to the login screen can
disconnect a VNC session. The problem here is that the server may not
always see VNC activity as, well, activity and will time-out.
2. If you are finding that you can not reconnect to the server, it is
probably because VNC is not running as a global service for the server.
Make sure that the VNC server is being launched by
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run and not
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, one of the
Startup folders or manually. You will then have to restart the machine.
What this will do is to ensure that VNC is running even before you login so
that you can connect to the machine at the login screen. If you need to
reboot the machine, you will be able to login again.
VNC (especially TightVNC over dial-up) is a great tool to use when
installing software at a remote location. The real trick of course is to
cross your fingers and toes and pray that your server comes back up when
you are finished rebooting.
TERMINAL SERVER / METAFRAME SOFTWARE INSTALLATION TIPS
You should not be installing software though a Terminal Server session. In
fact, you should really ensure that all users have logged out, all sessions
are closed (not just disconnected) and are disabled, and take the
opportunity to clear user TEMP files, *.TMP files and print spools while
you are at it. Installing though a virtual session can fail since files
that the install program wants to replace could be locked by your session
or the sessions of others. This is actually why install programs always ask
you to close all other running applications before proceeding. Also make
sure you are in "install mode" when installing software or you might find
that the software you installed only works for your user ID.
I also like to use SysDiff to examine the changes made while installing ANY
software, making sure that there were no critical system files that were
replaced (unless its a service pack or something like that). You wouldn't
believe some of the things programmers make their install programs blindly
do to a machine. Save the resulting SysDiff file too for future reference.
It will help you track down DLL and other conflicts (like CPU time) down
the line, especially if you outlined conflicts in DLL versions and kept a
copy of the before and after versions of system files that were changed.
When you are done, reboot the server one last time to make sure that
changes during the installation are committed to disk (especially when it
comes to registry changes) and that the machine will actually boot up. But
hey, as a system integrator, I am sure you know all of this as well as
other rules like:
- Have a good complete backup of your system before making any changes.
- Have a proven backup/restore procedures. You'd be surprised how many
backup systems can't seem to perform complete restores to an operating
system. And many Administrators don't usually realize it until it's too late.
- Backup your registry before and after any changes
- Never do anything in production before testing it first in a mirrored
test environment.
I learned these rules the hard way many years back when I had to rebuild a
WinFrame server and reinstall all its applications from scratch after
installing software that broke the server. Besides, you can take the
opportunity to document the installation/customization procedure in the
test environment, resolve any issues that may and usually do come up and
even optimize the procedure if necessary so that a) you require as little
time as possible from your client and b) the downtime has a minimal impact
on users.
Please forgive me if I am writing about stuff you already know about. If it
doesn't help you, hopefully it will benefit someone of the other readers.
Have a great day!
Michael Milette
At 07:28 AM 2002-06-20, you wrote:
>Hi,
>
>Am having trouble accessing one of the Windows Terminal Server via
>VNC.We hv a customer request for installing Apps on a Terminal Server &
>the
>connectivity is by a dialup to that server. Unfortunately the terminal
>server logoffs after sometime & our installtion aborts. (We suspect
>Terminal Server prob &
>also that there might be a bug in installing Apps via terminal server)
>
>Hence we proposed to hv a VNC access to that terminal server, but now it
>appears that the VNC is looking up the Terminal Server Display itself &
>am unable to get the screen display via VNC unless I have the Terminal
>Client window (with the Terminal Server Session) opened on my PC at the
>same time, By this am back to square one of logoff issue & unsuccessfull
>installation.
>
>Is there a way wherein I can hv a direct VNC Access to the Terminal
>server. Can you kindly let me as to how to go about resolving this
>problem?
>
>Thanks & Regards
>Girish
>
>[demime 0.99c.8 removed an attachment of type text/x-vcard which had a
>name of itops.ssi.vcf]
>_______________________________________________
>VNC-List mailing list
>[EMAIL PROTECTED]
>http://www.realvnc.com/mailman/listinfo/vnc-list
_______________________________________________
VNC-List mailing list
[EMAIL PROTECTED]
http://www.realvnc.com/mailman/listinfo/vnc-list
