Re: Remote office users slow logon

On Apr 24, 5:23 pm, Sean <S...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I just installed a T1 at my remote office and am still experiencing 1.5 - 2
minute login times.

I am running SBS 2003 standard and Server 2003. There is a pair of Sonicwall
TZ-170s with a site-site VPN tunnel bridging the two offices. Remote server
is a BDC and replicates correctly with SBS. There are no errors in any logs
between the two servers. I have a T1 connecting each office to the internet.

Each user sees the black login script window and we are waiting for the
setup command to run/complete.

I tried rem'ing the line out and everything works fast. I know several posts
here ask what this does, and I know this don't work right without it, so.......

Any suggestions on how to improve the login time for these users, the SBS
local users finish the script in 10-20 seconds, versus 1.5 minutes.....

File transfers and access are quite fast, so I don't think it's a network
issue, and now I have upgraded our old DSL to a T1 at this remote office and
would have expected this to be better.

Thanks in advance.
--
Sean

It sounds like your login script is running something across the WAN.
It wasn't clear above, but I'm guessing what you mean by reming the
line out is that you are commenting out the default setup commands in
the default sbs_login.bat batch file (sp?) and that the batch file is
triggered by the profile in AD and not a GPO. With these assumptions
in mind, I see two solutions:

Solution 1: Convert from simple fileshares to DFS. Properly organize
and use sites in AD, and edit the batch file to call the setup program
from DFS. This will effectively have the clients calling the program
from the nearest replicated DFS point and avoid the WAN.

Solution 2: Remove the batch file from the profiles tab on the user's
properties. Instead, write a login script for each site where the
login script calls the program from a share on fileserver for that
site. You obviously will need to copy the files to a local fileserver
to do so. Programs such as syncback can help ensure they stay
synchronized.

I've done the former myself. I've heard of the latter being deployed
successfully, but obvoiusly requires a little more maintenance. And a
lot of it depends on what your login script is doing. If you've added
custom calls, you'll need to test and make sure they work properly
locally, or with DFS, or whichever method you choose to take as much
of the WAN out of the loop as possible.

-Cliff
.

Relevant Pages

  • Re: Remote office users slow logon
    ... It's checking for software installations that might be waiting because a) it's a newly created computer account and this is it's first login; or b) you've run the wizard to deploy something. ... Fact is, these are actually rare circumstances in most cases, so rather than have that batch file run *every* login, enable it only when you need it - or, just run it manually when it's needed. ... Les Connor [SBS MVP] ... Each user sees the black login script window and we are waiting for the ...
    (microsoft.public.windows.server.sbs)
  • Re: Windows 2k server help.
    ... Beside the login script, is there ... >> I ran win2k advanced server. ... >> option that allow you to have one section per login. ... >For file serving/network sharing (Incidentally, ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Integrating WinXP with Win2003 Server Q
    ... > Is there a way on the server that automatically on login, ... Have you looked into assigning a login script through GPO? ...
    (microsoft.public.windowsxp.setup_deployment)
  • Re: Not logging in properly win2k
    ... I set up a login script ... run the login script, and furthermore where not always pushing the ... What was even more discouraging was one day the server ... My only guess is that it's pulling the local cached profile ...
    (microsoft.public.win2000.networking)
  • Re: Remote office users slow logon
    ... Although I agree that just disabling the batch file will address the ... have that batch file run on each login. ... It sounds like your login script is running something across the WAN. ...
    (microsoft.public.windows.server.sbs)