Long Login Times

Please Help - THanks.

The background: Upgraded from NT4 to W2k3.
NT4: 1 PDC, 1 BDC
Build a second BDC called UPG1a. Took PDC offline. Upgraded the UPG1a to
W2k3.
Rebuilt new the old BDC as "DC2". Tested by creating user accounts logins
and basic communication. Then rebuilt the PDC to a new DC. "DC1".
Transferred all the roles "D.R.I.P.S." to DC1 (D & S) and DC2(R, I, & S) also
put the Global Catalog on one or both of those servers. I think it was on
DC1. Took the Upgrade server down. DNS, DHCP, WINS on other servers not
DC's.

As leases expired (DHCP) we started having PC's with APPIPA addresses and
machines could not contact the domain. Fixed this by authorizing the DHCP
servers.

Now the network is complex as well... multiple VLANS on one LAN.

Most machines now when login, experience 10 minute login times. My PC and a
few others are fine. (I am on the same VLAN as the servers) On some of our
switches we have ACL's blocking some ports.

I need to know, if TCP was being blocked and it used IPX instead would it
increase login times? Isn't that the preferred method of communication? How
can I test this on the servers? Are there any tools from a windows
perspective to capture that information? Is there something else that I
should look at? Is it a misconfigured system? Any help or suggestion
would be appreciated..

B

 

My first thought is DNS. Active Directory requires DNS (properly configured
of course). I would check to make sure your DNS is correct on your DNS
server and that your workstations are pointing to the correct DNS server.

John

 

Yes, DNS is working properly. Our PC's have no network config, just grab the
information from the DHCP servers. From Active directory on the DC's, "Users
and Computers" I have complete lists of users and machines. I can use tools
such as NSlookup from the PC and it resolves properly.

?

 

Do all your workstations have the DNS entry to the local DNS server? Do all
the servers have it as well?

perform an ipconfig /all at a command prompt to verify.

John

 

You've probably already looked at these, but could it be either large
roaming profile, or large group policy settings that are taking the time? I
would suggest switching off roaming profile and all group policy from a
user, and testing that their login time is still slow.

Cheers,
Tony Woodhouse
Rugby - England

 

From my DNS server, I have hundreds of records for my PC's. I didn't know
that they created records for themselves since they use DHCP. Anyways, there
are records there.

And how do I check the roaming profiles? But does that really matter if I
use the same user to log into multiple Workstations with varied results? I
was told we did not use roaming profiles...

One PC can be fast under 30 seconds.... another slow. That is why I am
still leaning towards communication issues. What, I do not know.

 

We had a problem of this nature when we first installed
our new 2003 AD, it ended up being a problem with
Kerberos using port 88UDP for traffic, we changed it to
TCP and all has been working ok since, check this article

http://support.microsoft.com/default.aspx?scid=kb;en-
us;244474&sd=tech

Hope this helps

Kevin Ellis

 

Kevin, what did you change? The article talks about modifying the
Workstations. That's way too many for me to change. At the
router/switches/vlans, we do have ACL's in place to block TCP traffic on
quite a few ports. So I wonder that since that fails, should we open it up
and let it fly?

 

The setting I changed was under the following key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\
Kerberos\Parameters

and is the DWord MaxPacketSize which needs to be 1.

First of all I would try the registry setting in the
article on one machine having a problem and see if that
works, if it does you have the solution.

If that doesn't work try removing the ACL's you have in
place and test two machines, the one with the registry
setting and the one without. If the machine without the
registry setting works, then you can ignore the article
as it must just be one of the restrictions causing the
problem. If that machine doesn't work and the one with
the registry setting does then it must be a combination
of the two and some debugging of the restrictions is in
order but the registry setting also needs applying to all
machines.


At the bottom of the article there is a way of making the
changes via group policy, if not then it is a registry
hack, you could write a batch file to push out the
settings.

Let me know how you get on

Kevin

 

Thanks everyone for the ideas. We have AD running good right now. Login
times under a minute.

What we did was remove the ACL's that blocked TCP communications over ports
135 thru 139.