Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Error during heavy searching of Active Directory

262 views
Skip to first unread message

Matrix Technician@discussions.microsoft.com Pickle Matrix Technician

unread,
Aug 26, 2007, 8:30:00 PM8/26/07
to

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.

Joe Kaplan

unread,
Aug 26, 2007, 10:13:01 PM8/26/07
to
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
Techn...@discussions.microsoft.com> wrote in message
news:D6231313-2B0F-4B73...@microsoft.com...

Pickle Matrix Technician

unread,
Aug 27, 2007, 12:44:00 AM8/27/07
to
Thanks Joe, your help is greatly appreciated :)

nelson arasu

unread,
Jan 17, 2011, 11:57:29 PM1/17/11
to
can you tell how to authenticate active directory from the c# client application


>>> 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

0 new messages