Discussion:
AD global catalog server query delay in application.
(too old to reply)
bigman
2008-03-17 20:26:01 UTC
Permalink
Greetings to all,

I have a question that is perplexing me (novice) Please help :-) I am
basically looking for direction or specifics. Our organization has a
vendor's server which needs to query group policy information from AD in
order for it to work with documents. If a user is accessing a document at a
remote location (say America) the query takes 20 seconds which has to
complete before they can view the document. Many test have been performed
to rule out the network (so it seems :-) My question is based on AD
querying remote locations for group information what would be the best
approach at isolating this issue or is there a known issue within AD query?
The servers are windows 2003. Could it be based on user access to the
global catalog? (someone mentioned that it worked fine under the
pre-windows2000domain admin group - but this isn't from a good source so it
may be suspect) If so we don't want to give an outside vendor that kind of
power so maybe we can create a special group? I know I don't have all the
details listed but based on this limited information what would you suggest?
I would greatly appreciate any and all responses. Thank you in advanced.
Paul Weterings
2008-03-17 20:08:43 UTC
Permalink
Does the site where your application is running have a local DC? And
ifso, is that DC configured to hold the GC? (check sites & services).
That should speed things up considerably (if I understand your question
correctly)

Another thing that might speed up things is enabling universal group
membership caching at the site where the application is running. It
depends on what your application is doing and the layout of your network.

regards,

Paul
Post by bigman
Greetings to all,
I have a question that is perplexing me (novice) Please help :-) I am
basically looking for direction or specifics. Our organization has a
vendor's server which needs to query group policy information from AD in
order for it to work with documents. If a user is accessing a document at a
remote location (say America) the query takes 20 seconds which has to
complete before they can view the document. Many test have been performed
to rule out the network (so it seems :-) My question is based on AD
querying remote locations for group information what would be the best
approach at isolating this issue or is there a known issue within AD query?
The servers are windows 2003. Could it be based on user access to the
global catalog? (someone mentioned that it worked fine under the
pre-windows2000domain admin group - but this isn't from a good source so it
may be suspect) If so we don't want to give an outside vendor that kind of
power so maybe we can create a special group? I know I don't have all the
details listed but based on this limited information what would you suggest?
I would greatly appreciate any and all responses. Thank you in advanced.
bigman
2008-03-17 23:27:17 UTC
Permalink
Paul thanks for the quick response. The issue here is that I don't really
know the details. I do know that there is a local GC server and one on the
remote site. I was wondering wouldn't the GC have all of the group
information? They seem to think it is permissions related. One of the
issues here is that I don't think our guys would make changes to the setup
if it is going to create more traffic or issues. Would enabling universal
group membership caching create a problem for the WAN link? Which is
currently using only 15% capacity. FYI: I'm not one of the server guys,
I'm just a tech who is trying to help. I also had a friend mention that I
should check the sites & services. This problem seems to be ongoing for a
few months. Again I really appreciate your help.
Does the site where your application is running have a local DC? And ifso,
is that DC configured to hold the GC? (check sites & services). That
should speed things up considerably (if I understand your question
correctly)
Another thing that might speed up things is enabling universal group
membership caching at the site where the application is running. It
depends on what your application is doing and the layout of your network.
regards,
Paul
Post by bigman
Greetings to all,
I have a question that is perplexing me (novice) Please help :-) I am
basically looking for direction or specifics. Our organization has a
vendor's server which needs to query group policy information from AD in
order for it to work with documents. If a user is accessing a document at a
remote location (say America) the query takes 20 seconds which has to
complete before they can view the document. Many test have been performed
to rule out the network (so it seems :-) My question is based on AD
querying remote locations for group information what would be the best
approach at isolating this issue or is there a known issue within AD query?
The servers are windows 2003. Could it be based on user access to the
global catalog? (someone mentioned that it worked fine under the
pre-windows2000domain admin group - but this isn't from a good source so it
may be suspect) If so we don't want to give an outside vendor that kind of
power so maybe we can create a special group? I know I don't have all the
details listed but based on this limited information what would you suggest?
I would greatly appreciate any and all responses. Thank you in advanced.
Paul Weterings
2008-03-18 00:01:20 UTC
Permalink
If there is a local GC, then the app should be able to find all the AD
information that it needs at LAN speed, as the GC holds a copy of all
the domain objects. (note: the domain,not the forest or other domains in
the forest, if its bigger)

You won't be able to figure this one out without being able to do some
digging I'm afraid.

Universal Group membership may help if your users would experience
delays because of security groups needing to be checked at a remote DC.
I wonder though if it would solve this issue.

rather than attempting different things to hope & find a cure, the
better approach is to try & understand what is going wrong & find the
bottleneck.

As mentioned this would involve some 'hands-on' work, for example with
process explorer (sysinternals) and or wireshark.

Would it be possible to reproduce the problem in a lab environment?

regards,

Paul
Post by bigman
Paul thanks for the quick response. The issue here is that I don't really
know the details. I do know that there is a local GC server and one on the
remote site. I was wondering wouldn't the GC have all of the group
information? They seem to think it is permissions related. One of the
issues here is that I don't think our guys would make changes to the setup
if it is going to create more traffic or issues. Would enabling universal
group membership caching create a problem for the WAN link? Which is
currently using only 15% capacity. FYI: I'm not one of the server guys,
I'm just a tech who is trying to help. I also had a friend mention that I
should check the sites & services. This problem seems to be ongoing for a
few months. Again I really appreciate your help.
Does the site where your application is running have a local DC? And ifso,
is that DC configured to hold the GC? (check sites & services). That
should speed things up considerably (if I understand your question
correctly)
Another thing that might speed up things is enabling universal group
membership caching at the site where the application is running. It
depends on what your application is doing and the layout of your network.
regards,
Paul
Post by bigman
Greetings to all,
I have a question that is perplexing me (novice) Please help :-) I am
basically looking for direction or specifics. Our organization has a
vendor's server which needs to query group policy information from AD in
order for it to work with documents. If a user is accessing a document at a
remote location (say America) the query takes 20 seconds which has to
complete before they can view the document. Many test have been performed
to rule out the network (so it seems :-) My question is based on AD
querying remote locations for group information what would be the best
approach at isolating this issue or is there a known issue within AD query?
The servers are windows 2003. Could it be based on user access to the
global catalog? (someone mentioned that it worked fine under the
pre-windows2000domain admin group - but this isn't from a good source so it
may be suspect) If so we don't want to give an outside vendor that kind of
power so maybe we can create a special group? I know I don't have all the
details listed but based on this limited information what would you suggest?
I would greatly appreciate any and all responses. Thank you in advanced.
Paul Weterings
2008-03-18 00:02:43 UTC
Permalink
p.s. lets stop crossposting. I'll keep my responses in
microsoft.public.windows.server.active_directory

Paul
Post by Paul Weterings
If there is a local GC, then the app should be able to find all the AD
information that it needs at LAN speed, as the GC holds a copy of all
the domain objects. (note: the domain,not the forest or other domains in
the forest, if its bigger)
You won't be able to figure this one out without being able to do some
digging I'm afraid.
Universal Group membership may help if your users would experience
delays because of security groups needing to be checked at a remote DC.
I wonder though if it would solve this issue.
rather than attempting different things to hope & find a cure, the
better approach is to try & understand what is going wrong & find the
bottleneck.
As mentioned this would involve some 'hands-on' work, for example with
process explorer (sysinternals) and or wireshark.
Would it be possible to reproduce the problem in a lab environment?
regards,
Paul
Post by bigman
Paul thanks for the quick response. The issue here is that I don't
really know the details. I do know that there is a local GC server
and one on the remote site. I was wondering wouldn't the GC have all
of the group information? They seem to think it is permissions
related. One of the issues here is that I don't think our guys would
make changes to the setup if it is going to create more traffic or
issues. Would enabling universal group membership caching create a
problem for the WAN link? Which is currently using only 15%
capacity. FYI: I'm not one of the server guys, I'm just a tech who
is trying to help. I also had a friend mention that I should check
the sites & services. This problem seems to be ongoing for a few
months. Again I really appreciate your help.
Post by Paul Weterings
Does the site where your application is running have a local DC? And
ifso, is that DC configured to hold the GC? (check sites & services).
That should speed things up considerably (if I understand your
question correctly)
Another thing that might speed up things is enabling universal group
membership caching at the site where the application is running. It
depends on what your application is doing and the layout of your network.
regards,
Paul
Post by bigman
Greetings to all,
I have a question that is perplexing me (novice) Please help :-) I am
basically looking for direction or specifics. Our organization has a
vendor's server which needs to query group policy information from AD in
order for it to work with documents. If a user is accessing a document at a
remote location (say America) the query takes 20 seconds which has to
complete before they can view the document. Many test have been performed
to rule out the network (so it seems :-) My question is based on AD
querying remote locations for group information what would be the best
approach at isolating this issue or is there a known issue within AD query?
The servers are windows 2003. Could it be based on user access to the
global catalog? (someone mentioned that it worked fine under the
pre-windows2000domain admin group - but this isn't from a good source so it
may be suspect) If so we don't want to give an outside vendor that kind of
power so maybe we can create a special group? I know I don't have all the
details listed but based on this limited information what would you suggest?
I would greatly appreciate any and all responses. Thank you in advanced.
Loading...