Active Directory slow for certain users

  • Thread starter Thread starter xmeta4x
  • Start date Start date
X

xmeta4x

Hi All,

I have a problem with Active Directory (MMC) being slow for certain
users.

If certain users open AD, it takes around 30 seconds to open, and
operations such as opening property pages take much longer than usual.
However, for other users there's no problem. I've seen slow downs like
this before, and usually deleting the local profile solved it, but not
this time.

AD is installed on a server running terminal services in application
mode, so the same server is being used by all users for admin. This
seems to rule out a general misconfiguration and points the finger at
user specific settings.

Any ideas?

Thanks,

Andy
MCP MCDST
 
Try loading and running User Profile Hive Cleanup (UPHClean). This cleans
up all connections, etc... It is recommended to be run on all machines not
just TS servers anymore. I don't know why MSFT doesn't install this by
default. Anyway the link below should help keep your user hives clean.

http://www.microsoft.com/downloads/...b570-42470e2f3582&displaylang=en&Hash=3HRVHTC

--

Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
http://www.pbbergs.com

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Paul,

Thanks for your reply. I tried running UPHClean, but it hasn't made any
difference.I should have mentined that I have also installed the admin
tools on a local XP machine and the problem is the same - slow for one
user, fast for another.

For the "problem" users, I have set their profiles to be local, and
deleted them so they're starting with a clean profile, but the problem
persists.

Any more ideas?

Thanks,

Andy
 
Hi Paul,

Thanks for your reply. I tried running UPHClean, but it hasn't made any
difference.I should have mentined that I have also installed the admin
tools on a local XP machine and the problem is the same - slow for one
user, fast for another.

For the "problem" users, I have set their profiles to be local, and
deleted them so they're starting with a clean profile, but the problem
persists.
Click to expand...

Check DNS (server, DC, and ordinary clients). Very frequently
DNS is the cause of slow logons.

Run DCDiag against (most) all DCs and NetDiag on a sample
of problem clients.

Check the following DNS points:

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /server:DC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
 
Hi Andy,

While writing my post noticed the Heb's one.

Try to take a netmon trace when you are trying to open the ADUC. If it is
slow, most likely it has problems with the name resolution on one of the DNS
servers and falls back to another DNS server. Also check the trace for
re-transmits.

Also try to run FileMon and RegMon on the computer from where you open the
ADUC snap-in.

Is the same DC is referenced in the ADUC for the "working" and "failing"
users?

Vlad

Herb Martin said:
Hi Paul,

Thanks for your reply. I tried running UPHClean, but it hasn't made any
difference.I should have mentined that I have also installed the admin
tools on a local XP machine and the problem is the same - slow for one
user, fast for another.

For the "problem" users, I have set their profiles to be local, and
deleted them so they're starting with a clean profile, but the problem
persists.
Click to expand...

Check DNS (server, DC, and ordinary clients). Very frequently
DNS is the cause of slow logons.

Run DCDiag against (most) all DCs and NetDiag on a sample
of problem clients.

Check the following DNS points:

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /server:DC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Any more ideas?

Thanks,

Andy
Click to expand...
Click to expand...
 
Sorry about typo - I meant "Herb's" post :)
Vlad

Vlad said:
Hi Andy,

While writing my post noticed the Heb's one.

Try to take a netmon trace when you are trying to open the ADUC. If it is
slow, most likely it has problems with the name resolution on one of the DNS
servers and falls back to another DNS server. Also check the trace for
re-transmits.

Also try to run FileMon and RegMon on the computer from where you open the
ADUC snap-in.

Is the same DC is referenced in the ADUC for the "working" and "failing"
users?

Vlad

Herb Martin said:
Hi Paul,

Thanks for your reply. I tried running UPHClean, but it hasn't made any
difference.I should have mentined that I have also installed the admin
tools on a local XP machine and the problem is the same - slow for one
user, fast for another.

For the "problem" users, I have set their profiles to be local, and
deleted them so they're starting with a clean profile, but the problem
persists.
Click to expand...

Check DNS (server, DC, and ordinary clients). Very frequently
DNS is the cause of slow logons.

Run DCDiag against (most) all DCs and NetDiag on a sample
of problem clients.

Check the following DNS points:

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /server:DC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Any more ideas?

Thanks,

Andy

Paul Bergson wrote:
Try loading and running User Profile Hive Cleanup (UPHClean). This
cleans
up all connections, etc... It is recommended to be run on all machines
not
just TS servers anymore. I don't know why MSFT doesn't install this by
default. Anyway the link below should help keep your user hives clean.

http://www.microsoft.com/downloads/...b570-42470e2f3582&displaylang=en&Hash=3HRVHTC

--

Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
http://www.pbbergs.com

This posting is provided "AS IS" with no warranties, and confers no
rights.

Hi All,

I have a problem with Active Directory (MMC) being slow for certain
users.

If certain users open AD, it takes around 30 seconds to open, and
operations such as opening property pages take much longer than usual.
However, for other users there's no problem. I've seen slow downs like
this before, and usually deleting the local profile solved it, but not
this time.

AD is installed on a server running terminal services in application
mode, so the same server is being used by all users for admin. This
seems to rule out a general misconfiguration and points the finger at
user specific settings.

Any ideas?

Thanks,

Andy
MCP MCDST
Click to expand...
Click to expand...
Click to expand...
 
Hi Herb,

When I first researched this problem it seemed that DNS was the big
issue, but I believe this can be discounted as, for example, different
users on that same machine get different speeds.

If the only difference is, say, whoever is logged onto the PC at the
time that AD is opened, the DNS settings for the transaction should be
identical. Can different users have different DNS settings? That
doesn't make any sense to me....??

One interesting point is that if I log onto a PC or the server as a
"slow" user, and try and run AD as a fast user (Run as..) it is still
slow.

Andy
 
Hi Herb,

When I first researched this problem it seemed that DNS was the big
issue, but I believe this can be discounted as, for example, different
users on that same machine get different speeds.

If the only difference is, say, whoever is logged onto the PC at the
time that AD is opened, the DNS settings for the transaction should be
identical. Can different users have different DNS settings? That
doesn't make any sense to me....??
Click to expand...

As long as the different users are from the same domain
then likely it is something else (other than DNS).
One interesting point is that if I log onto a PC or the server as a
"slow" user, and try and run AD as a fast user (Run as..) it is still
slow.
Click to expand...

Also consider any shares involved -- if the two users
have different Home, My Documents, or (Roaming)
profile locations.

Also consider the overall SIZE of each user's profile.

Some users may actually be moving their "Temporary
Internet" files as part of their profile etc.
 
Andy,

May be it is a problem with the Kerberos session ticket which is getting too
big. What is the group membership for the "fast" and "slow" user. You may try
creating a test user, adding him to the same groups as "slow" user and try to
re-pro the issue. May be it is a problem with the Kerberos ticket which is
getting too big.

The following KBs may give you some clues:
- "How to force Kerberos to use TCP instead of UDP in Windows Server 2003,
in Windows XP, and in Windows 2000" http://support.microsoft.com/kb/244474
- "Kerberos authentication may not work if user is a member of many groups"
http://support.microsoft.com/kb/280830

Is it slow when you open the second instance of the ADUC while the first is
still running?

BTW, what happens when you log on as "fast" user and then use "runas" as a
"slow" user?

Vlad
 
Have you tried deleting a "Fast" users profile to see if there newly built
profile then slows down?

--

Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
http://www.pbbergs.com

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Paul Bergson said:
Have you tried deleting a "Fast" users profile to see if there newly built
profile then slows down?
Click to expand...

Suggestion: COPY the profile directly true before doing
that in case you want it back later.

Good idea though.

Also, try "copying" a Fast user and a Slow user and see
if either or both follow the same behavior.
 
Ok guys, here's the story so far...

Profiles can be discounted I think - fast users stay fast and slow
users stay slow regardless of deleting profiles etc.

Now, if I run TCPView (sysinternals.com) and open AD as a slow user, it
opens and drops about 30-40 connections to the DC on port 389 (LDAP) in
the period before it finally opens.
Logged on as a fast user, it opens 2 connections and opens straight
away.

If I log on as a fast user, then do a "Run as" with a slow user, it's
slow (with the 30+ connections). If I log on as a slow user and try to
do a "Run as" with a fast user, it is fast.

Does this give any clues? What are the multiple LDAP connections all
about?

Andy

(P.S. Thanks for all the help so far!)
 
This is probably something you already know but when you were dealing with
the profiles did you realize there is a Terminal Services Profile and a User
Profile? The TS profile pointer is defined on the "Terminal Services" tab
in the ADUC mmc on each user's property.

I'm stumped so I'm grasping for any possible over sight.

--

Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
http://www.pbbergs.com

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Paul Bergson said:
This is probably something you already know but when you were dealing with
the profiles did you realize there is a Terminal Services Profile and a
User Profile? The TS profile pointer is defined on the "Terminal
Services" tab in the ADUC mmc on each user's property.

I'm stumped so I'm grasping for any possible over sight.
Click to expand...

Ok, me too -- adding straws:

Check time on clients. Make sure it is within a minute
or so (5 minutes max) of DCs.

Still good idea to run DCDiag on every DC and NetDiag
on affected machines.

Is this is single domain forest?

What happens to my idea of copying (AD Users/Computers)
a Slow and Fast user? Do they follow their template or
act randomly? etc?
 
Good thought Paul, however the TS profile is blank.

Herb, you're on to something there. I copied a slow user, and the new
user was still slow. I then removed the new user from all groups
(couldn't think of what else to try) and this appears to have worked!
The downside being that the slow users need to be in the groups that
they're in...!

So, either a rogue group, sheer volume, or network design is the
problem.

Perhaps I should explain our network topology a little more. I'm in the
UK, and we've recently moved our office, and our network to a new MPLS
network. The rest of the world is still on a frame relay network, so
our traffic to global sites is being routed via our HQ in the western
US. This is causing general slowdowns already when accessing remote
sites etc.

The fast users aren't in as many groups, and particularly aren't in
groups from different sites - although with AD replication, I can't
grasp why this would be a problem? As long as the DCs are replicating
correctly the lookup should be local right?

(We're also merging another company's network/domain infrastructure
into our own in the US, so this probably isn't helping, although the
slowdown started before this process was initiated).

Any thoughts?

Andy
 
Do you have a local DC/GC? Do you have sites and services configured for
this particular site (IP's defined)? I'm guessing so by the details from
this past reply.

How are these different groups treated? Are you mapping drives to remote
machines based on group membership? Group membership should have zero
impact on speed if that is all that is happening, there must be some action
taken to users that belong to specific groups.

--

Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
http://www.pbbergs.com

This posting is provided "AS IS" with no warranties, and confers no rights.
 
We have a local DC here, and sites and services is configured to
replicate to both our main US DC, and also a DC in France which
previously served as a European hub (before MPLS migration) over IP.

The groups don't have any actions associated with them that I'm aware
of, they simply infer permission to access various shared resources
such as folder, public folders, admin tools, application servers etc.
(we don't use mapped drives at all, everything is based around UNCs)

As a workaround I can create an Admin user to use when logging in to
the TS to use ADUC, however I lose auditability and I'd really rather
find a solution. (if only because I hate not understanding what's going
on!)
 
How many groups? (Per user, especially slow user)

How many groups are those groups in total for the user?
 
Hi Herb,

Around 20 groups, which I don't think is excessive. I did discover that
there were some circular lookups going on as some of the groups
referenced each other (for example a UK admin group was a member of a
French admin group and vice versa). Correcting this didn't solve the
problem though unfortunately.

Is there a way to see which groups are member or which other groups
without manually looking?

Cheers,

Andy
 
Back
Top