Re: Slow boot at "Applying Computer Settings"

[Tom Felts]

That is some mighty fine sluething. We are having this issue as well, it is
particularly noticeable post SP2 on XP clients.
It is hard for me to believe that the stie discovery algorithm is that
brain-dead, but then again, we are talking about MicroSoft...

"It's not ready for production until SP3" is still as true today as it was
when NT 4.0 was released....


***sigh***

 

[Will Gillen]

I'm getting really close now. I've been doing alot of research on how
DFS generates a list of host servers hosing a shared volume. I've gone
over and over my sites and services and subnets, and everything looks
correct. I've even watched many, many clients choose the CORRECT site
when performing the main LDAP authentication at the first of the
bootup, it is ONLY when the client asks AD for the DFS referrals that
AD spits out some random garbage.

I've been reading through:
http://www.microsoft.com/windows2000/community/centers/fileservices/dfsfaq.mspx#EGAAA
which has a plethora of information about how DFS referral gets its
site information.

It looks like AD is "caching" some of the original site mappings back
when I built the domain controllers and before I used the Micrsoft
Sites and Services tool to "move" the DCs to their correct site. Well,
as it turns out according to the document I mentioned above (and some
others) that it is possible that the ORIGINAL site information may
still be stored somewhere in AD (even though the DC is already moved to
another site). Now, I just have to figure out how to view the DFS
referral information in AD about the SYSVOL share.

So far trying to use: dfscmd /view \\mydomain.com\sysvol : doesn't
work (says element not found).
And when I try to view it using dfsgui.msc and "view" the share:
\\mydomain.com\sysvol (says not found as well).

So, at this point I don't know how to view the DFS / Site mapping
information for the SYSVOL share in Active Directory.

Anyone?

Thanks.

-- Will Gillen.

 

[Will Gillen]

More findings, don't know if it is related yet, but:
I did find that I can view the MUP cache (multiple UNC provider as in
DFS) for a client PC.
This is what I saw on a client PC:

C:\Program Files\Support Tools>dfsutil /PktInfo

Microsoft(R) Windows(TM) Dfs Utility Version 4.0
Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved.

--mup.sys--
1 entries...
Entry: \mydomain.com\sysvol
ShortEntry: \mydomain.com\sysvol
Expires in 8955904 seconds
UseCount: 0 Type:0x1 ( DFS )
0:[\nsut-ad3.mydomain.com\sysvol] State:0x21 ( )
1:[\nsum-ad2.mydomain.com\sysvol] State:0x21 ( )
2:[\nsut-ad2.mydomain.com\sysvol] State:0x21 ( )
3:[\nsuba-ad2.mydomain.com\sysvol] State:0x21 ( )
4:[\nsuba-ad1.mydomain.com\sysvol] State:0x21 ( )
5:[\nsut-dns2.mydomain.com\sysvol] State:0x21 ( )
6:[\nsum-ad1.mydomain.com\sysvol] State:0x21 ( )
7:[\nsut-ad1.mydomain.com\sysvol] State:0x31 ( ACTIVE )
8:[\nsut-dns1.mydomain.com\sysvol] State:0x21 ( )


DfsUtil command completed successfully.

Now first of all, the order of provider is DEFINITELY wrong to me
because the second one on the list is in a site across a WAN (and I
have gone over and over my sites and services configuration), and from
what I have read, the default behavior of AD SYSVOL/DFS should be to
list providers in the client's site first, then random list of
providers in other sites (clearly this is not what's happening in my
environment). Then, the part that gets me is the expiration of:
8955904 seconds. So, let's see if my math is right here:
8955904 / 3600 = 2487.75 hours,
2487.75 / 24 = 103.65 days!

So, does that mean that this client (whose DFS provider order is wrong
already) will keep that order for 103.65 days before it feels the need
to refresh, or does it refresh on every boot cycle?

Man, I wish I could figure out WHY my domain is generating this stupid
out-of-site list of SYSVOL providers. I know this is the problem, I
just don't know how to solve it.


-- Will Gillen.

 

[Paul Williams [MVP]]

Isn't NETMON (or equivalent) great?!?!

You're doing REALLY well on the troubleshooting front!! Keep it up!!

Are all DCs registered under their correct sites? Better yet, are there any
typo's in the sites and subnets?

 

[Will Gillen]

Just got off the phone with Microsoft Support. Thank God I did this
packet sniffing. I pointed their attention to the fact that the SYSVOL
query was returning servers in sites not in the clients site (out of
order). They immediately referred me to the following KB:
831201

Basically it forced AD DCs to put the logon server as the primary DFS
provider for the SYSVOL query (on top of the list) using a new registry
key (only available with hotfix or 2003 SP1).

The regkey is:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs]
"PreferLogonDC"=dword:00000001

You have to add this to all your DCs and then restart the DFS service.
I havent' completely tested this out yet, but you can bet I will.

Interestingly, I asked the support techs if they could explain why the
list of DCs was being returned out of order to begin with, and they
fumbled for an answer, but ultimately just said "We've had several
clients reporting this similar problem, and this registry key has taken
care of the problem for them." I even went so far as to ask "Are you
sure we shouldn't take a look at other configurations, maybe something
is misconfigured in our sites/services, and that is what is causing the
list of DFS providers to be returned out of order". Their response:
"I don't think so, this registry key should take care of the problem
you are seeing."

Hmmmmmmm............................

I think I'm going to take paypal donations to help pay for the $245.00
registry key I just added to my DCs, if this works

 

[Darren Mar-Elia]

Will-
Definitely let us know if that works. I'm a little dubious of that solution,
since the packet trace I looked at had lots of TCP resets on those first few
servers, which would indicate a different problem. In any event, it will be
good to know if it makes a difference.

 

[Will Gillen]

I believe the resets were because those first few servers were in a
different site separated by our WAN link. I know that this WAN has
some ACLs and limitations on those links. The root problem seems to me
to be the fact that the list of DCs hosting the SYSVOL share was "out
of order" (showing DCs from other sites at the top of the list). The
first 3 servers on that list to contact were all 3 in different remote
sites. As the client tried to connect to each one, the ACLs on the WAN
links were forcing them to reset, and failover to other protocols, and
then other servers. Then, finally on the 4th server on this list, it
found a server at the local client's site and was able to successfully
communicate with the DC.

In the packet trace I sent you, look at packet numbers: 960-963. This
is where the client is asking the LogonDC for the list of servers
hosting the SYSVOL DFS Share. Packet 963 has the response (list of
servers). The first 3 servers are in remote sites. So the client then
proceded to try each of those 3 servers (finally ending in the NetBIOS
broadcast and port 80 request). Then, when it got to the 4th one, it
worked as you pointed out to me originally.

I'm not 100% sure about the "fix" that I recieved as of yet either. I
still want to fully test this out. I'll keep you posted, and thank you
very much for your help. I couldn't have gotten this far without yours
and everyone else's help. I love the community approach to
problem-solving. I only hope now that I'll be able to help someone
else out in the future.

-- Will Gillen

 

[Tom Felts]

It it's a known issue with a hotfix, it should be a non-dec, in other words,
a free call....
You should ask about that.....

 

[Paul Williams [MVP]]

That fix, sounds like it might help, but isn't the solution is it?
Microsoft need to find out why the list is coming back in a backwards order.

Mind you, have you by any chance disabled NetMask ordering at the client end
(the DNS Resolver does this by default)?