[mthaler]

Windows 2000 server is set with Active directory in pure (non-mixed) mode. This is a small network with less than 10 users. There is only one 16 port 10/100 switch, not a lot of traffic.
When logging on with Windows 2000 Pro SP1, the workstations take a really long time during the "Loading Personal Settings" part. Is there a way to speed this up?

[clutch]

Is name resolution fast? Can you ping by PC name quickly?

------------------
Regards,

clutch

[tear]

I have the sam trouble. The name resolution isn't fast how do I fix it?

------------------

-==( fear the tear )==-

[mthaler]

Pings are instantaneous.
Pinging sue [10.10.10.103] with 32 bytes of data:
Reply from 10.10.10.103: bytes=32 time<10ms TTL=128
Reply from 10.10.10.103: bytes=32 time<10ms TTL=128
Reply from 10.10.10.103: bytes=32 time<10ms TTL=128
Reply from 10.10.10.103: bytes=32 time<10ms TTL=128
Ping statistics for 10.10.10.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Don't think that is the problem.

[clutch]

Try doing it on a fresh boot when the cache is all cleared out. Most of the slow logon performance I have seen has been due to slow name resolution. In Win2K, the workstation/server will not let you know that it didn't find a domain controller to authenticate your credentials. It will just go straight to your cached profile and compare your logon against the last successful attempt. It could be something else though, this is just a suggestion.

As far as improving name resolution, I will always recommend WINS/DNS on a network. This is the way that I have always done it, and I don't have any issues. Just have a dinky little NT box running WINS/DHCP, and you don't get browsing or name resolution problems. I am moving away from WINS to DDNS now however. But unfortunately it seems to *require* another box to sync against or it will write a bunch of alerts to the event viewer. SP2 is supposed to fix the remaining issues with DDNS and its updating system.

------------------
Regards,

clutch

[mthaler]

Pardon my ignorance, but which cache are you talking about, and how do I clear it out? Are we talking about the cache on the server or the workstation that is slow logging in?
Is there a way of telling it NOT to store massive amounts of data on the server that needs to be compared and downloaded each time?
Thanks

[clutch]

The cache that I was referring to is the local memory kept for mapping friendly names to their associated IPs. Here are a couple of links to get you guys started:

http://cramsession.brainbuzz.com/cramsession/microsoft/tcpip/guide.asp

http://support.microsoft.com/support/kb/articles/Q180/0/94.ASP

The first one covers basic name resolution in a Windows environment, and the second one covers how to write a LMHOSTS file that will speed up your domain controller hunt at logon. If I have more, I will post it later.

------------------
Regards,

clutch

[mthaler]

I have looked at all the suggestions and am convinced that we are looking in the wrong place. I am pretty sure it has to do with loading profiles and it takes FOREVER (well, over a minute). The machines connect to the server instantly, but the LOADING PERSONAL SETTINGS sits for an incredibly long period of time. Is there a setting on the server or workstation that can affect the speed this happens?

[clutch]

Are the profiles set to be local or roaming? If they are local (default), then is little being done aside from loading security policies.

------------------
Regards,

clutch

[mthaler]

clutch,
The profiles are definately set to local, but I have noticed that the drive light is rarely blinking and the NIC is blinking like crazy. I also have two machines I work on, each with a seperate login, and the both take this really long time. The second machine is an Athlon 1.1Ghz with an Intel Nic. Why would a profile take so long to load? How much security policy data could move over the network. We are talking over a minute while the message on the screen says "Loading your persoal settings ..."
Both these machines are 5 feet away from the server, and all are plugged into a 10/100 switch. The server is a mere 400mhz Pentium but it has 256Mb RAM and is doing very little actual work. Just running a blank screen saver, serving files and printing.

[HarU]

The problem is that the workstations are having a hard time locating the fastest route to the Domain Controller(s). Do you just have 1 domain controller? If so, then you can edit the lmhosts file on the workstations. This file tells the computer to automatically search for the specified entry at the time of login. It will directly go to your domain controller which will allow for replication faster.

The file can be found in c:\winnt\system32\drivers\etc

There are samples in there to guide you. If you have more than 1 DC, then you want to edit their's as well. Have them point to each other. Good luck

[Moniker]

Quote:

<font face="Verdana, Arial" size="2">Originally posted by mthaler:
Pardon my ignorance, but which cache are you talking about, and how do I clear it out? Are we talking about the cache on the server or the workstation that is slow logging in?
Is there a way of telling it NOT to store massive amounts of data on the server that needs to be compared and downloaded each time?
Thanks </font>

The command I believe clutch is speaking of is

C:\>arp -a <----will show you current entries

C:\>arp -d <----will clear entries

C:\>arp -d 192.xxx.xxx.xxx <----will delete specific entries(substitute the ip entry you want)

C:\>arp /? <----will tell you all variables and switches you can use with command

*****edit*****
It also sounds like you may be having broadcast problems (an out of control NIC). Does your network access improve once its logged on? Or, is it always slow?




[This message has been edited by Moniker (edited 26 March 2001).]

[clutch]

To me, it sounds like a name resolution issue. Try HarU's recommendation, and make sure that you state your server's name as a domain controller, like so:

200.200.200.50 titanic #PRE #DOM:SAVILLTECH

Check out this link for some more info on LMHOSTS. It shows using mulitple domain controller entries, but one will suffice.

http://www.windows2000faq.com/Articles/Index.cfm?ArticleID=13539

------------------
Regards,

clutch

[HarU]

Also, now that i think about it, you might want to look into how you do your DNS and WINS. Pretty much exactly what clutch said. Clutch, your original solution is exactly what this problem is based around. Definately a name resolution problem.

First, make sure you are running WINS. Its real easy. Just start the service on your DC and have all of the workstations enter the DC's ip in the WINS portion of your Network properties. If you have multiple DC's, you can just use one, or have two of them run WINS so you have a primary and a secondary.

Second, i recommend running an internal DNS between your workstations to provide for faster replication between your whole network. For instance, have your DC's run DNS. Set the primary DNS on your DC(s) as its own ip. Set the secondary DNS as the "static" ip that will provide for internet connectivity. Now, set all of your workstations as using the internal DC's ip as their primary DNS. So, ultimately, what will happen is, the workstations will always look to the DC's ip first for name resolution, then, from there they will have the gateway to the internet. This is how our internal network is set up at work. But, there may be differences between mine and yours. All of the internal boxes have an ip of 10.50.2.x, or 10.50.1.x. There are 4 DCs. The DCs use each other for primary DNS, and they use the 63.x.x.x.(i am not going to reveal this string) as secondary DNS. This way the internal network is very quick. The DCs also have each other entered into the lmhosts file to provide for faster replication between them.

I hope this helps....i am sure i left out some details, because its hard to think of all the steps to take right off the top of my head. Clutch, please add something if i missed anything.

[mthaler]

THANK YOU THANK YOU THANK YOU!!!!
I examined the whole server deal and realized that the DSL router was doing DHCP instead of the server. So, I disabled the DHCP on the router, enabled it and configured it on the server including specifying the Server as the first of threee DNS servers (the other two being the ISP's DNS servers) and I added the DHCP options that point to the server's WINS address.
VOILA, the machine now opens in about 5 seconds.

Much appreciated.

[Moniker]

that would do it. must be nice

[clutch]

Score 1 for the good guys!



------------------
Regards,

clutch

[JJ32]

Easy man. If it is lagging loading up a profile then optimize all the profiles by eliminating the garbage or asking your users to do so, then defragging your disk. Clean all temp garbage out. Assign static IP across a 10 user network and disable DHCP to decrease "look time". If you are using a router just default gateway to that and assign those static IP's and boom that sucker will fire up quick. Minimize the number of services you don't need too! Kill it if not needed. Go in BIOS and tweak your hardware performance out. Tweak out NIC card and set at 100 w/o the autoswitch. All kinds of stuff you can do man! My Advanced Server lags a little too, but there is a default look time on preparing network connections you really can't do too much about and I wouldn't mess with that part that would probably make things worse if anything. Too much work on a server OS anyway. Try these suggestions out and see if boosts your boot time.

[clutch]

His problems were based more around name resolution, rather than rogue DHCP servers or hardware settings. With all the defaults of the hardware, he should not have to wait more than 10 seconds for credential authentication. In addition, I am more of a fan of DHCP use than static IPs, as you can change settings for an entire subnet from one server, rather than walking to each client and having to adjust then manually (or from batch-driven processes). Also, relying on the broadcast nature of NetBIOS over TCP/IP provides for sloppy results in any of the Windows OSs and in Samba on *nix (I can only say this for Linux, as I am not a true Unix person; but the implementation should be quite similar for them all). You tend to have more issues with ghost machines (machines that *seem* to be on the network, but only the name of the PC is in the master browser listing) that keep the valid PC from getting online due name conflicts. The odds of timeouts increases as well, along with flaky credential verification.

While a good deal of people use Win9X in peer to peer mode, the vast majority of them do not stress their systems/network like the users do here. Therefore, they will not see (or notice) a lot of the problems that we would.

If you can't use some sort of name resolution system (hard to believe since a lot of people have "accquired" copies of various Windows server OSs ;)), then consider going with a LMHOSTS file and static IPs. Bear in mind that when playing with more modern networks, there are 3 major players to be concerned with;

1. Name resolution
2. Permissions
3. Time synchronization (more of an issue with AD security services; you know, that funny little w32time issue you probably have in your log).

Sorry for the long post, but I have seen quite a few networks have similar issues that were all solved by a proper name resolution scheme

/end soapbox

------------------
Regards,

clutch

[JJ32]

Clutch I don't think it is a name resolution issue if a workstation is hanging on loading personal settings. Personal settings is loading a user profile up mainly. That is what is lagging here. It's the workstation and he only has a 10 station network, so static IP assignment is easy. Obviously you don't want to staticize a huge network (lots of work..phew I get sick thinking about it). I think it is a user profile or something that is messed up. If it is indeed a name resolution issue then what kind of OS you have around network cause I need more info to start troubleshooting.