Have you checked the NIC and switch port
that both are configured for the same duplex and port speed? Force them to
1000 Full if they are not. While you're looking at the switch see if
there are any other errors on the port. I had a backup server that even though
both it and the switch were set to 100F periodically, they would revert to
auto-negotiate and my backup window would explode into days.
Dave
------------------------------------------------
David J. Perdue
Network Security Engineer, InDyne
Inc
------------------------------------------------
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, November 05, 2004
7:55 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [ActiveDir] Odd Logon
Delay with 2byte transfers
Hi everyone,
I
have a truly intriguing one for you. We have recently begun to experience
an inconsistent problem where by interactive network logon onto a Windows 2000
or Windows 2003 server may take upwards of 40 mins to complete. The
authenticating domain controller is on a gigabit link to the respective member
servers (campus network). We've tried tests from various locations using
a couple of domain controllers. It doesn't appear to be a specific domain
controller. We've hit the KB articles and have been talking to MS. We've
tried the "Opportunistic Lock" settings in it's permutable
combinations from server and client.
One
of the things that does appear to be constant is that of the phases of the
logon process, "Applying Registry settings" appears to last the
absolute longest period of time during the logon process. It doesn't
matter which 'registry.pol' that is being applied. Both Usrenv logs and
network traces show that the delay corresponding the 'applying registry
settings' occurs regardless as to the policies being evaluated/applied. Also,
the largest 'registry.pol' is 554 bytes. With that size, two 'registry.pol'
files could be transferred in one transfer.
Another
consistency being seen during this delay is that during the transfer of the
'registry.pol' file, the communication is in 2byte snippets. Can't
explain that one. Can't even find any documentation on this phenomenon. Microsoft
appeared to have found some internal documentation to that end, but it related
to "opportunistic locking" and the respective changes did not produce
a change in our environment as indicated by our network traces. We lean in
this direction as the problem or at least a very significant anomaly.
Load
is not a question as we are early in our physical deployment of Active
Directory (domain controllers...etc). There are only about 550 user in
our AD environment and most of them authenticate to their respective domain
controller at their corresponding locations. Of the clients
authenticating at our hub site, which include the servers in this case numbers
less than 200. Utilization on the hub DC is well in reason for both processor,
memory, and TCP/IP interface utilization. But, just to rule out anything
flaky with that DC, I temporarily switch subnets and sites with another DC,
that at most does only DNS and carries the PDCE role. Same results.
We
continue to work with Microsoft. We've turned up logging on must hosts
involved and will turn up logging on the remaining hosts today. In terms
of errors, the eventlog is naked as a Jaybird. I'm also taking the route
of disabling all unnecessary services on all domain controllers to simplify the
troubleshooting.
Because
it is inconsistent, it is proving very hard to determine progress. Inconsistency
breeds doubt and requirements for retesting and validation....not very fun...
Any
useful ideas, suggestions, golden nuggets, Easter eggs, "PXE"
dust...etc would be greatly appreciated.
Thanks,
Eric Jones, Senior SE
Intel Server Group
(W) 336.424.3084
(M) 336.457.2591
www.vfc.com
