Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
The Directory Service Referral interface failed to service a client request. RFRI is returning the error code:[0x3f0].
|English: Request a translation of the event description in plain English.|
|Concepts to understand:|
What is the role of the Microsoft Exchange System Attendant (MSExchangeSA) service?
What is a directory service?
In my case, I found that this error was caused by a failed Exchange Server that used to be our DC and still had authority as a Global Catalog publisher. We got a new Exchange Server but forgot to take off the check mark under the old server to remove that function. Once we set that function on the new server and took it off the old one, the errors went away. You can find that setting in Active Directory Sites and services, then drill down to your server, right click on NTDS settings and select properties.
This event can occur if File and Printer Sharing for Microsoft Networks is not enabled on the domain controller or the TCP/IP NetBIOS Helper service is disabled. See ME257435 for information on how to solve this problem.
As per Microsoft: "This issue may occur if the Exchange Enterprise Servers security group does not have Manage auditing and security logs permissions on the domain controller. The Exchange Enterprise Servers group must have Manage auditing and security logs permissions on all the domain controllers in the domain". See ME328662 for details on this problem.
As per Microsoft: "This event basically states that the DSPROXY component of the System Attendant Service on the Exchange server failed to service a client request. This failure could be because of issues ranging from failed network connectivity to permissions problems". See MSEX2K3DB for more information.
See ME895858 and ME896703 for additional information on this event.
If your Exchange servers are showing DSAccess errors and you see EventID 9074 errors, this refers to a stale GC referral entry in the DNS. E.g., a GC once existed in the DNS but when it was removed from the environment, the DNS never flushed it out completely. Therefore, Exchange servers still get a referral back to this GC.
Though this has been fixed in the DNS if you see any servers depicting this behavior do a “ipconfig /flushdns” on the Exchange box to force it to reload the DNS cache. You might also want to do a “nbtstat –R” to purge and reload the remote cache name table.
For information in this issue, refer to ME300114.
Anne Jan Elsinga
We have had the same event when the Global Catalogs were not available.
In a fit of service disabling in the name of server hardening, I discovered that this event (along with the related 9057, 9143 & 9176 events) can be generated by disabling the TCP/IP NetBIOS Helper Service.
As per ME279742, this problem is caused by the File and Printer Sharing services not being bound to all the network cards in a multihomed machine. Apparently, Windows 2000 is attempting to access its Sysvol share through the primary network adapter to read the group policies. Because the share is unavailable through that adapter, the operation does not work.
The ME314294 suggests that this error may occur if the "Manage Auditing and Security Log" right (SeSecurityPrivilege) was removed for the Exchange Enterprise Servers domain local group on some or all of the domain controllers.
|Private comment: Subscribers only. See example of private comment|
|Links: ME257435, ME279742, ME300114, ME314294, ME328662, ME895858, ME896703, MSEX2K3DB|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (1) - More links...|
Send comments or solutions
- Notify me when updated