"server not operational"

[brian]

We have seen this in our environment historically and are trying to
eradicate. recently, we had a big flurry of these errors. It is
almost impossible to reproduce .. an exception gets thrown, "the server
is not operational" and here is the code

dirConn.DirRootAD.Username = ConvertToCorrectUserNameFormat(sUserName,
ADConnManager.Domain)
dirConn.DirRootAD.Password = Password
dirConn.DirRootAD.AuthenticationType =
AuthenticationTypes.ServerBind
mySearcher.Filter =
"(&(objectCategory=user)(|(sAMAccountName=" + sUserName +
")(userPrincipalName=" + sUserName + ")))"
dirConn.DirRootAD =
mySearcher.FindOne().GetDirectoryEntry()

....

Finally
If Not objDirEntry Is Nothing Then objDirEntry.Dispose()
If Not dirConn Is Nothing Then dirConn.Dispose()




I hear this may be due to a BUG in the .NET framework? any truth to
that? Any suggestions would be helpful.

[Joe Kaplan \(MVP - ADSI\)]

Did you specify a server name in your path property for the root
DirectoryEntry? If not, then you are relying on the ADSI "serverless
binding" feature. Serverless binding allows you to infer a domain
controller to use automatically.

Unfortunately, serverless binding works based on the current security
context of the thread. Specifically, it must be a domain account in order
for it to work. In ASP.NET, you may or may not be running under a domain
account depending on the current process account settings and the current
impersonation settings.

If you can specify a specific domain controller to use and that fixes the
problem, then you know that was your problem.

Joe K.

"brian" <katiesoft1@yahoo.com> wrote in message
news:1109698497.284347.294550@z14g2000cwz.googlegr oups.com...

> We have seen this in our environment historically and are trying to
> eradicate. recently, we had a big flurry of these errors. It is
> almost impossible to reproduce .. an exception gets thrown, "the server
> is not operational" and here is the code
>
> dirConn.DirRootAD.Username = ConvertToCorrectUserNameFormat(sUserName,
> ADConnManager.Domain)
> dirConn.DirRootAD.Password = Password
> dirConn.DirRootAD.AuthenticationType =
> AuthenticationTypes.ServerBind
> mySearcher.Filter =
> "(&(objectCategory=user)(|(sAMAccountName=" + sUserName +
> ")(userPrincipalName=" + sUserName + ")))"
> dirConn.DirRootAD =
> mySearcher.FindOne().GetDirectoryEntry()
>
> ...
>
> Finally
> If Not objDirEntry Is Nothing Then objDirEntry.Dispose()
> If Not dirConn Is Nothing Then dirConn.Dispose()
>
>
>
>
> I hear this may be due to a BUG in the .NET framework? any truth to
> that? Any suggestions would be helpful.
>

[brian]

thanks for the reply Joe. We do not specify a specific controller, but
we do that so we can get redundancy. We can't have a single point of
failure in our environment. We do run the code under a service
account.

with serverless bindings, how does it work out what dc to use? Could
it be picking a DC not on that subnet and the call is timing out?

Based on my findings, I think the issue could be related to a memory
leak in this call "mySearcher.FindOne().GetDirectoryEntry()" ... as it
is a sporadic issue (maybe caused by unusual load?). One guy was
quoted as saying "never use FindOne" as there are known issues with it.
We used to authenticate off of a Domino directory, and we experienced
sporadic issues like this too. However, when using domino, we did
specify the exact server.

its very strange error ...i used to have a monitoring service running
to catch the error ... it would happen 1 out of every 400 calls in
domino. we hadn't seen it in AD for the first month of operation, now
it is an everyday occurance.

[Joe Kaplan \(MVP - ADSI\)]

Ah, perhaps it could be a memory leak. You need to be super careful with
SDS in long running processes and make sure you religiously use the "using"
construct on all of the disposables (DirectoryEntry, DirectorySearcher,
SearchResultCollection). You can also use this safely on all of the
properties that return DirectoryEntry objects as they all return new
objects, not an object held as a member of the containing class.

The bug in FindOne only happens if it finds nothing as it will leak the
underlying SearchResultCollection in that case. However, I'm pretty sure
this was fixed in the recent .NET service packs.

Serverless binding works based on the DsGetDCName API (read it for more
details). Essentially, it tries to find a DC in the current site that
matches the domain of the current account. I'm not actually sure how it
behaves in an actual fail over situation. It is supposed to just fail you
over if you lose the connection to the DC, but this is pretty hard to test
in practice.

There's actually a trick with IADsObjectOptions that allows you to discover
the current server. You can also do that by getting dnsHostName off of
RootDSE.

..NET 2.0 gives you some more control over serverless binding by exposing the
API directly through the new DomainController class in the ActiveDirectory
namespace. Something to look forward to.

HTH,

Joe K.

"brian" <katiesoft1@yahoo.com> wrote in message
news:1109728831.474101.206770@z14g2000cwz.googlegr oups.com...

> thanks for the reply Joe. We do not specify a specific controller, but
> we do that so we can get redundancy. We can't have a single point of
> failure in our environment. We do run the code under a service
> account.
>
> with serverless bindings, how does it work out what dc to use? Could
> it be picking a DC not on that subnet and the call is timing out?
>
> Based on my findings, I think the issue could be related to a memory
> leak in this call "mySearcher.FindOne().GetDirectoryEntry()" ... as it
> is a sporadic issue (maybe caused by unusual load?). One guy was
> quoted as saying "never use FindOne" as there are known issues with it.
> We used to authenticate off of a Domino directory, and we experienced
> sporadic issues like this too. However, when using domino, we did
> specify the exact server.
>
> its very strange error ...i used to have a monitoring service running
> to catch the error ... it would happen 1 out of every 400 calls in
> domino. we hadn't seen it in AD for the first month of operation, now
> it is an everyday occurance.
>