Logging onto MSCS (Cluster Node) via NetSupport remote desktop

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a question that maybe you can help me with...please.

We have are running MSCS Servers for one of our crtical applications in an
Enterprise Win2K Child Domain with DNS and WINS Servers. The Cluster Server
is on a subnet that has a DNS Server and w2k Domain Controller.

People from other Child domains of the parent are complaining that when they
logon remotely using "Netsupport" (Remote Desktop pkg) they connect to the
console fairly quickly but then it is taking them forever to actually logon
to the Cluster Server Node. It says applying security settings....
Of course, this is mainly for those remote users trying to remote desktop
into these nodes from across a WAN connection T1 or better. If I logon with
a Domain or local account with Admin priviledges it works great and I see no
pain at all. They , however want me to add additional parent domain
prefix/suffix's on the DNS (advanced tab) of the public tcp/ip properties
page. They also want me to add WINS Server entries for name resolution?
I currently have the DNS tab(public adapter)set with my local DNS Server
along with a secondary and use only my immediate domain prefix/suffix and my
parent domain.
I also am not using WINS Server entries and have disabled the use of Netbios
over TCP/IP (the same as the private adapter has been setup).

What is the preferred method to setup the Public Adapter?
Do I have to add WINS Server entries and add the domain entries for their
DNS search order?

Should I enable Netbios over TCP/IP? What are the pros and cons of each?
Name resolution problems with WINS duplicate entries or opening up security
holes by allowing the Netbios over tCP/IP?

Any other ideas on how to get the remote users to logon faster (since they
are members of a different domain?)> Please help!

Thanks, Kevin

(e-mail address removed)
 
Hi Kevin-

I'm not familiar with the application you're clients are using to remotely
connect, but if this is essentially an interactive logon then there are a
few things to look at.

What domain controller in their accounts domain the cluster nodes are using
for the user authentication would of course be top of the list. Even if it
is relatively close and unburdened the logon could take longer if there are
roaming profiles, policies or scripts from the accounts domain in the mix.

For a typical Windows logon in the scenario you have outlined I would
suggest starting with a USERENV.LOG of some affected users logging onto the
cluser node(s). This is the debug logging of the creation of the user logon
session environment. This will tell you what they are logging on with and
from where, and give time indexes of each step of logon creation so you can
get a good idea of what's fast and what's slow.


How to enable user environment debug logging in retail builds of Windows
(221833)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;221833


--

Tim Springston
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top