Previous
Next
Fixed font
Subject: Re: Error during heavy searching of Active Directory
Author: nelson arasu Date: 18 Jan 2011
References:
Author: nelson arasu Date: 18 Jan 2011
References:
can you tell how to authenticate active directory from the c# client application
> On Sunday, August 26, 2007 8:30 PM Pickle Matrix Technicia wrote:
> Hi all,
>
> I'm working on a C# application that must collect properties (specifically
> objectguids) from deleted objects that belonged to a given subtree. I can get
> the deleted objects from the Deleted Objects container, but I have a problem
> when checking that they came from within the given subtree. I check this by
> searching for an object with a 'distinguishingName' matching a deleted
> object's 'lastKnownParent' attribute using the given subtree as the top level
> of the search. If an object is found the deleted object is one of the ones
> I'm looking for, otherwise I can ignore it.
>
> This works with a small number of deleted objects, but when I do this with a
> large number of deleted objects (>3500 or so), I get a the following COM
> Exception:
> System.Runtime.InteropServices.COMException was unhandled by user code
> Message="The server is not operational.\r\n"
> Source="System.DirectoryServices"
> ErrorCode=-2147016646
> StackTrace:
> at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
> at System.DirectoryServices.DirectoryEntry.Bind()
> at System.DirectoryServices.DirectoryEntry.get_AdsObject()
> at System.DirectoryServices.DirectorySearcher.FindAll(Boolean
> findMoreThanOne)
> at System.DirectoryServices.DirectorySearcher.FindOne()
> ...
>
>
> If I close the app and run it again immediately, I get the same exception as
> soon as I try to connect to the server, and must wait a little while until I
> can connect again (so maybe it is to do with the number of connections). I'm
> running AD on Windows 2003 Server.
>
> So my question is: is there a better way to check whether a deleted object
> came from within a given subtree, and if not, how can I stop this error from
> occurring?
>
> Thanks.
>
> I'm working on a C# application that must collect properties (specifically
> objectguids) from deleted objects that belonged to a given subtree. I can get
> the deleted objects from the Deleted Objects container, but I have a problem
> when checking that they came from within the given subtree. I check this by
> searching for an object with a 'distinguishingName' matching a deleted
> object's 'lastKnownParent' attribute using the given subtree as the top level
> of the search. If an object is found the deleted object is one of the ones
> I'm looking for, otherwise I can ignore it.
>
> This works with a small number of deleted objects, but when I do this with a
> large number of deleted objects (>3500 or so), I get a the following COM
> Exception:
> System.Runtime.InteropServices.COMException was unhandled by user code
> Message="The server is not operational.\r\n"
> Source="System.DirectoryServices"
> ErrorCode=-2147016646
> StackTrace:
> at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
> at System.DirectoryServices.DirectoryEntry.Bind()
> at System.DirectoryServices.DirectoryEntry.get_AdsObject()
> at System.DirectoryServices.DirectorySearcher.FindAll(Boolean
> findMoreThanOne)
> at System.DirectoryServices.DirectorySearcher.FindOne()
> ...
>
>
> If I close the app and run it again immediately, I get the same exception as
> soon as I try to connect to the server, and must wait a little while until I
> can connect again (so maybe it is to do with the number of connections). I'm
> running AD on Windows 2003 Server.
>
> So my question is: is there a better way to check whether a deleted object
> came from within a given subtree, and if not, how can I stop this error from
> occurring?
>
> Thanks.
>> On Sunday, August 26, 2007 10:13 PM Joe Kaplan wrote:
>> This sounds like an issue with the ADSI connection caching model.
>> Essentially, your code is not reusing an existing LDAP connection and is
>> opening a new one with each DirectoryEntry or DirectorySearcher you are
>> creating. Eventually you run out of TCP/IP wild card ports with all the
>> sockets being opened and closed because the closed sockets stay in "TIME
>> WAIT" for 60 seconds before they can be recycled.
>>
>> You usually work around this issue by opening a single DirectoryEntry object
>> to the server in question with the credentials you are using and then
>> keeping this object open for the duration of the program. For it to bind
>> using the NativeObject property (or calling RefreshCache) and then stick it
>> in a static variable so it doesn't get collected. That should fix it
>> (unless you are changing credentials frequently, in which case this won't
>> work). You should also get much better perf.
>>
>> It is ok and actually a good idea to continue calling Dispose on the rest of
>> your DirectoryEntry, DirectorySearcher and SearchResultCollection objects
>> (and any other IDisposable objects you are using), just not the first one.
>>
>> If you want to see the wild card port issue in action, check the results of
>> netstat while you are having the problem.
>>
>> There is a bit more detail on this issue in ch 3 of my book (see link in
>> sig).
>>
>> Joe K.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services Programming"
>> http://www.directoryprogramming.net
>> --
>> "Pickle Matrix Technician" <Pickle Matrix
>> Technician@discussions.microsoft.com> wrote in message
>> news:D6231313-2B0F-4B73-8523-59B2C506BEDF@microsoft.com...
>> Essentially, your code is not reusing an existing LDAP connection and is
>> opening a new one with each DirectoryEntry or DirectorySearcher you are
>> creating. Eventually you run out of TCP/IP wild card ports with all the
>> sockets being opened and closed because the closed sockets stay in "TIME
>> WAIT" for 60 seconds before they can be recycled.
>>
>> You usually work around this issue by opening a single DirectoryEntry object
>> to the server in question with the credentials you are using and then
>> keeping this object open for the duration of the program. For it to bind
>> using the NativeObject property (or calling RefreshCache) and then stick it
>> in a static variable so it doesn't get collected. That should fix it
>> (unless you are changing credentials frequently, in which case this won't
>> work). You should also get much better perf.
>>
>> It is ok and actually a good idea to continue calling Dispose on the rest of
>> your DirectoryEntry, DirectorySearcher and SearchResultCollection objects
>> (and any other IDisposable objects you are using), just not the first one.
>>
>> If you want to see the wild card port issue in action, check the results of
>> netstat while you are having the problem.
>>
>> There is a bit more detail on this issue in ch 3 of my book (see link in
>> sig).
>>
>> Joe K.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services Programming"
>> http://www.directoryprogramming.net
>> --
>> "Pickle Matrix Technician" <Pickle Matrix
>> Technician@discussions.microsoft.com> wrote in message
>> news:D6231313-2B0F-4B73-8523-59B2C506BEDF@microsoft.com...
>>> On Monday, August 27, 2007 12:44 AM PickleMatrixTechnicia wrote:
>>> Thanks Joe, your help is greatly appreciated :)
>>> Submitted via EggHeadCafe
>>> SQL Server Best Practices
>>> http://www.eggheadcafe.com/tutorials/aspnet/56efb426-550b-48cc-b52a-eca25b6cd427/sql-server-best-practices.aspx
>>> SQL Server Best Practices
>>> http://www.eggheadcafe.com/tutorials/aspnet/56efb426-550b-48cc-b52a-eca25b6cd427/sql-server-best-practices.aspx
Previous
Next