无法快速响应AD检索

发布于 2024-08-16 14:07:55 字数 1363 浏览 7 评论 0原文

我正在开发一个 SharePoint 应用程序,它需要来自指定 Windows Server 2003 Active Directory 组织单位的用户。

首先,我并不关心 DirectoryServices 对象上的“Dispose”和“Close”操作。此时,检索操作快速且成功。

但这在两次尝试后导致“服务器无法运行”错误。这个错误使得整个应用程序运行得更糟,就像停止其他 AD 操作一样。

然后,我通过在每个 DirectoryEntry、DirectorySearcher 和 SearchResultCollection 对象上添加 using 语句来纠正此错误。

然后我就不再收到“服务器无法运行”错误了。但是,当我尝试使用 DirectorySearcher.FindAll 方法从 AD 检索用户 1 次或多次时,第一个操作快速且成功,其他操作速度较慢但成功。这有点需要超时的时间。您能帮我解决一下我的减速情况吗?

这是示例代码:

using (DirectoryEntry directoryEntry = new DirectoryEntry(connectionString, userName, password))
            {
                using (DirectorySearcher search = new DirectorySearcher(directoryEntry))
                {
                    search.SearchScope = SearchLevel.OneLevel;
                    search.ReferralChasing = ReferralChasingOption.All;
                    search.Filter = filter;
                    search.SizeLimit = 200;
                    //Limits the property count for search result
                    SetUserDirectorySearcherPropertiesToLoad(search);

                    using (SearchResultCollection result = search.FindAll())
                    {
                        foreach (SearchResult searchResult in result)
                        {
                            // Get user attributes
                        }}}}

提前致谢

I am developing a SharePoint application which needs users from a specified Windows Server 2003 Active Directory Organizational Unit.

Firstly I wasn't concerned about the 'Dispose' and 'Close' operations on DirectoryServices objects. In this point the retrieve operations were quick and successful.

But this was causing 'Server is not operational' error after 2ish attempts. And this error makes the whole application operates worse like stopping other AD operations.

Then, I corrected this error by adding using statements on every DirectoryEntry, DirectorySearcher and SearchResultCollection objects.

Then I have reached a point that I have no longer get 'Server is not operational' error. But when I try to retrieve users from AD 1 or more times by using DirectorySearcher.FindAll method, the first one operates quick and successfully, others more slowly but successfully. It kinda takes the duration of a timeout. Could you please help me with my situation about this slow down?

Here is the sample code:

using (DirectoryEntry directoryEntry = new DirectoryEntry(connectionString, userName, password))
            {
                using (DirectorySearcher search = new DirectorySearcher(directoryEntry))
                {
                    search.SearchScope = SearchLevel.OneLevel;
                    search.ReferralChasing = ReferralChasingOption.All;
                    search.Filter = filter;
                    search.SizeLimit = 200;
                    //Limits the property count for search result
                    SetUserDirectorySearcherPropertiesToLoad(search);

                    using (SearchResultCollection result = search.FindAll())
                    {
                        foreach (SearchResult searchResult in result)
                        {
                            // Get user attributes
                        }}}}

Thanks in advance

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

蛮可爱 2024-08-23 14:07:55

这里一切似乎都很正常。我正在使用类似的东西,唯一值得注意的区别是我通常将“propertiesToLoad”参数传递给 DirectoryEntry 的构造函数,并将过滤器传递给 DirectorySearcher 的构造函数。

另一个区别是您为 DirectoryEntry 使用“用户名”和“密码” - 也许值得使用应用程序池标识?我通常会对这些调用执行 SPSecurity.RunWithElevatedPrivileges(method point) 操作。

Everything seems to be normal here. I am using something similar, the only mentionable difference is that I usually pass the "propertiesToLoad" parameter to the constructor of DirectoryEntry, as well as I pass the filter to the constructor of DirectorySearcher.

Another difference is that you are using "username" and "password" for the DirectoryEntry - maybe it's worth using the application pool identity? I typically do SPSecurity.RunWithElevatedPrivileges(method pointer) for these calls.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文