|
That was the first thing that came to my mind when I saw
that as well but I would assume they would have seen that in the trace as it is
pretty obvious when you see it if tracing both sides of the conversation. I
would be curious though if they have discussed that possibility with
MS.
joe
Sounds
similar in description to something we have experienced. We had some 2000
and XP workstations having incredibly long login times. Turned out the
issue was related to dropped udp packets over our wan links and
kerberos.
The fix
in the following article got those affected workstations fixed up while we
addressed the network issue.
"How to force Kerberos to use TCP instead of
UDP"
Clyde
Burns
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
This message is confidential, intended only for the named
recipient(s) and may contain information that is privileged or exempt from
disclosure under applicable law. Any patient health information must be
delivered immediately to intended recipient(s). If you are not the intended
recipient(s), you are notified that the dissemination, distribution or copying
of this message is strictly prohibited. If you receive this message in error, or
are not the named recipient(s), please notify the sender at either the e-mail
address or telephone number above and discard this e-mail. Thank you.
|
