Powershell error: "A connection to the directory on which to process the request was unavailable. This is likely a transient condition." How to solve it?

Question

Hello,

We are experiencing issue:

A connection to the directory on which to process the request was unavailable. This is likely a transient condition.

We have it when we connect from Service Now using PowerShell and Import-Module ActiveDirectory command.

We found the following answer but it is rather old.
https://learn.microsoft.com/en-us/archive/msdn-technet-forums/a1d88f7f-56a9-4be3-b031-d0fa8944cb5e

Service Now is also aware of the error but they does not provide solution:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0761117

I wonder if there is any other solution as Service Now provides the commands based on PowerShell...

Maybe there are settings which needs to be changed? Like number of concurent connections?
Or maybe we should just update the powershell version?
And: is there any limitation for ADSI solution?

Best regards,
Konrad Wojciechowski

Answer 1

There should be no difference in PowerShell versions -- except version 5 was the last version of WINDOWS PowerShell. Version 6 and 7 are "cross-platform" and have no dependencies on Windows -- they are also somewhat more difficult to use if you depend on the ability of your scripts to work without modifications because you may have to use Windows Compatibility Mode when loading modules (https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_windows_powershell_compatibility?view=powershell-7.4).

I don't know if there are any limitations on the number LDAP queries. I've never run into any, though. The largest AD organization I worked with had about 28K "real" users, but they were spread out over the USA, Canada, Mexico, Brazil, Colombia, South Africa, Italy, Spain, France, Portugal, Germany, Belgium, The Netherlands, England, Australia, Japan, and probably a few places I've forgotten. The AD was geographically distributed so there wasn't usually a problem, and where there were concentrations of users there were also multiple DCs and AD sites.

The biggest benefit you'll derive from using ADSI over Modules it the time it takes to load a module. If you have to load a module it might take 300 - 500 ms, and then the time it takes to make the query. With ADSI you only spend the time to make the query (maybe a few tens of ms).

According to the link in your comment, ServiceNow's using ADWS. IIRC, ADWS (as installed, unmodified) has a limit of 10 concurrent connections. I'm pretty sure that's "per DC" but, depending on how ServicNows' connector works, they may be using only one (or a few) of the DCs in you AD site. If you're not sure how it's working, I think engaging ServiceNow would be appropriate.

Answer 2

Because the problem is "transient" it may related to number of things that are happening concurrently. I.e., a resource exhaustion problem. Perhaps too many processes attempting to access the same DC. I believe that limit has a default value of 5000 (but that may apply only to logons). A Active Directory SME would be better to answer that question (not a PowerShell one).

To answer the 2nd part of your question, yes, ADSI is an alternative, but (there's always a "but") it's probably a non-trivial change to the code.

You don't give any indication as to what (or how) the code is operating. Is it performing a background job (which runs in a separate process)? Does it launch a background job for every action, or does it batch actions so several are handled by one job?

How does the code react to the error? Does it pause for few seconds and then retry the action, or does it simply give up?