[gptalk] Re: Authentication

  • From: "Omar Droubi" <omar@xxxxxxxxxxxxxxxxxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Fri, 22 Sep 2006 11:42:49 -0700

yeah- looks like DFS may be your options but 30 minutes makes me think there
is something else really wrong.
I would create a test user just like your Texas users- login at Texas to
make sure all is well and then log the user in on the Far east workstations-
use DameWare or remote desktop or whatever your company uses.
just like Darren stated- just mapping drives should not be causing that long
of a delay- are any applications running or getting called as part of the
script- say to check for AV installation or something like that.
Once you recreate the slow logon for your test users- drop him from all
GPO's and scripts to see if that is the issue and add him back to each GPO
one by one. sounds like a daunting task but I can't really think of another
way to isolate it.
What do you get for a ping response to the USA file server from a far east
workstation- I would also wonder if you are encountering maybe DNS time outs
followed by NetBIOS Wins queries. If your ping response time- for both the
USA server short name and long name resolve fast and the latency is less
than 100ms this should not be the cause.
Are these users taking their texas laptops to the Far East offices or are
they using Far East machines that may be running additional Computer GPOs
with loopback enabled along with other checks. What does the GPresults show
on the affected workstations?
tough problem.


From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Attardo, Joe
Sent: Friday, September 22, 2006 11:23 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Authentication

Hi Omar, 
See my additional comments in red. 

-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Omar Droubi
Sent: Friday, September 22, 2006 1:24 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Authentication

I think that in order for the group to really help you out- as I have
already read a few suggestions- we need to 1st understand what is causing
the extended logon delay. It could be GPO but it also could be a different
When the user hits the remote site and logs in- how long does it take- and
if you drop to the command prompt afterwards- type Set <enter> and see what
the value is for the logon server. Also do an IPconfig /all and get the IP
address given from the local DHCP server and check to see that this subnet
exists in AD sites and services and that it is associated with the correct
It can take up to 30 minutes to get logged in once the user puts their
machine on the wire. They power up and get the logon screen and from there,
it is slow. The user Authenticates OK to the DC that is specific to the
location they are at and picks up a dhcp address from that same location.
The DHCP scope coincides with that site in AD sites and services. 
If everything looks good I would an interested in knowing if the slow logon
is for the user hitting the new site and only the 1st logon is slow and
after that all logons are much faster.... 
The slowness happens at every logon attempt.  Users are mapping drives from
the Far East to the USA and folder redirection of my documents folder to a
server in the USA.  The login script we use is based on group membership and
there is a separate logon script for each location. So, if you come from
Texas as your home office, you go to the Far East and still apply the Texas
login script. 
Also, someone mentioned DFS- DFS is a great solution for data that is read
only or data that will only be accessed by a single person. (in other words
the my docs folder redirection would be a great candidate.)   
Windows Server 2003 R1 has some really cool features for DFS- I forgot the
exact terms but the features I really like are as follows: You can configure
a DFS share to only be accessed from the local site. This means that while
you can create a DFS share and replicate between sites- the user will always
and only connect to the DFS replica in their local site. This removes the
problem of a user crossing the WAN to get to their MY docs. Once you have
that configured you can configure the folder redirection path to use the
domain name path. I.e --> folder redirection to
\\domain.com\dfssharename\Mydocs\%username%. I would recommend that you
create a separate folder redirection policy and filter it based on a group
called mobileUsers- and only place the users who use multiple offices in
that group- which points to a separate myDocs DFS share- so this way you
don't have to replicate every user's myDocs if they never leave the home
office. Does that make sense? 
This make sense with regard to the MY Documents folder. I will throw it out
to the team and see what I get for a response.  Can I upgrade a 2K3 server
to R1 or do the need to be rebuilt?
You can also- but I really don't recommend it- move the GPO for folder
redirection and logon script to the original AD site the users are from-
this way only when they are in the local site the policy will be applied-but
putting a GPO at the site means that you create good filters or every user
and computer in that site will need to process the GPO in one form or


From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Attardo, Joe
Sent: Friday, September 22, 2006 2:41 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Authentication

Good Morning, 

We have many people who travel to other offices as part of their jobs and
the logon experience when they get there is painfully slow. Is there a way
to set a policy so if a user authenticates to a domain controller away from
their "home office" that they will not receive any policies such as a logon
script or folder redirection.  Any suggestions would be appreciated. 




Other related posts: