Well Gary, after being hopeful about this approach, I've now been told by my AD friend that this tuple index won't work, due to how GPMC implements the query for GP link objects. In his words, they are "stupid" about the query they use. Essentially, what they do is to query for GP Links using an LDAP query string that does not include the gpLink attribute. As a result, their queries won't benefit from indexing of that attribute. Too bad. Sorry about that. I'm definitely bringing this up with the GP product team at the MVP summit next month, and I'm going to do some more testing on this to see if there isn't another way. Its an interesting problem. Darren From: Darren Mar-Elia [mailto:darren@xxxxxxxxxx] Sent: Thursday, February 21, 2008 4:40 PM To: 'gptalk@xxxxxxxxxxxxx' Subject: RE: [gptalk] Re: GPMC Gary- I got some news for you. I spoke with a couple AD experts. It appears that there is a way to possibly improve your situation significantly, but it involves some AD modifications that may or may not fly in your environment. Essentially, AD can create something called a tuple index. This is an index designed exactly for the kind of searches that would occur within the gpLink attribute. It's a fairly expensive index to maintain but it can have a dramatic impact on performance. You can read about it here http://msdn2.microsoft.com/en-us/library/ms676931(VS.85).aspx?PHPSESSID=7c61 ntavm1dmu84rl10kephll5 , including how you can enable it on the gpLink attrib. I would, if possible, create a test environment that mirrors your production domain first, and try it there, because one of the side effects is an increase in disk usage to maintain the index. If you are able to implement this, let us know how it goes. Darren From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Gary Noyes Sent: Thursday, February 21, 2008 12:41 PM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: GPMC Ok, just got an OU total, 53171 so that would stand to reason my delay when using that wonderful GPMC tool :-) ----- Original Message ----- From: Darren Mar-Elia <mailto:darren@xxxxxxxxxx> To: gptalk@xxxxxxxxxxxxx Sent: Thursday, February 21, 2008 12:58 PM Subject: [gptalk] Re: GPMC This is a big flaw in GP design, as far as I'm concerned. The fact that gp links are stored as a single concatenated string instead of a multi-valued attribute was a big mistake for larger environments. There's effectively no way to speed this up, because even if you were to index this attribute in AD, you still end up having to parse the string for each GPO GUID. Really lame. Darren From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Gary Noyes Sent: Thursday, February 21, 2008 9:53 AM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: GPMC I'm pretty sure it's the amount of OU's as this tool hangs no matter where I use it from. I will try your tool and let you know. Thanks Gary ----- Original Message ----- From: Darren Mar-Elia <mailto:darren@xxxxxxxxxx> To: gptalk@xxxxxxxxxxxxx Sent: Thursday, February 21, 2008 11:53 AM Subject: [gptalk] Re: GPMC You'd probably have to script it. In any case, for the enumeration to take minutes means you have a lot of OUs and potentially lots of GPOs linked to each of those. Either that or something is broken. You might try a network trace from the machine running GPMC and see if anything stands out. Outside of that, you could downloading the trial version of my Backup Manager for GP product and see if it takes the same lengthy time to show links. If so, then you know its not a GPMC thing. From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Gary Noyes Sent: Thursday, February 21, 2008 8:43 AM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: GPMC Don't really have a number how can I get that? ----- Original Message ----- From: tools@xxxxxxxxxx To: gptalk@xxxxxxxxxxxxx Sent: Thursday, February 21, 2008 10:53 AM Subject: [gptalk] Re: GPMC How many OUs are we talking about here Gary? When you try to get information on where a given GPO is linked, GPMC is having to search the entire domain, looking at every container object, and searching its gpLink attribute for the GUID of the GPO. Those attributes are not multi-valued, which means its doing a string compare across each of the GUIDs in the link list. So, yes, this will be an expensive process. I do this in fact in one of my products and it usually doesn't take very long, but your environment may be very different. Darren From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Gary Noyes Sent: Thursday, February 21, 2008 7:48 AM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: GPMC Ok, even in AD Users and Computers when you click on the links tab it hangs so it looks like the GPMC is probably automatically searching for all links when you click on a GPO. Now the question is how do I change this behavior with the GPMC tool? Thanks Gary ----- Original Message ----- From: Darren Mar-Elia <mailto:darren@xxxxxxxxxx> To: gptalk@xxxxxxxxxxxxx Sent: Wednesday, February 20, 2008 10:48 PM Subject: [gptalk] Re: GPMC Gary- I can't think of any reason this would be the case under normal circumstances. What might be interesting is to see if you get the same delay when accessing GPO information via the GPMC scripts? Darren From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of gwnoyes@xxxxxxxxxxx Sent: Wednesday, February 20, 2008 7:02 PM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] GPMC We have a large AD 2003 domain, about 75 thousand objects and lots & lots of OUs. When I open the GPMC and click on one the GPO's it takes about 10 minutes for it to display the information about that GPO, it hangs at an hour glass. I made sure the tool is pointing to the right DC and it still sits at an hour glass for about 10 minutes. All servers are talking on Gig links so bandwidth isn't a problem. If anyone has seen this an has a fix I would greatly appreciate your assistance with this as it drives me crazy. Thanks in advance Gary