Troubleshooting event ID 12317, “File Server Resource Manager failed to enumerate share paths or DFS paths.”September 29th, 2006 by Patrick S
A while ago Jabez Posted an article about FSRM: “Access is Denied” is logged in Event Viewer, Browsing Our Friends blog over at “The Filing Cabnit” It seems some light has been shed on the article as well as a small workaround. Please find most of the article below but dont forget to check out their blog to get the full story-You rock guys.
EVENT LOG Application
EVENT TYPE Warning
EVENT ID 12317
TIME 5/1/2006 12:15:45 PM
MESSAGE File Server Resource Manager failed to enumerate share paths or DFS paths. Mappings from local file paths to share and DFS paths may be incomplete or temporarily unavailable. FSRM will retry the operation at a later time.
Error: (0x80070005) Access is denied.
Although this event doesn’t affect quota functionality, the fact that it occurs hourly has prompted numerous support calls from customers. We’ve isolated the cause and the solution for this event…well, most of the cause anyway.
An Event 12317 showing access denied is caused when the NT AUTHORITY\Authenticated Users group is not a member of the BUILTIN\Users group in the domain. (As you might know, the local BUILTIN\Users group on a domain controller is mapped to the domain built-in group Users. Therefore, the effect of removing NT AUTHORITY\Authenticated Users from the BUILTIN\Users group on a domain controller has a domain-wide effect.)
Why does this cause the event error? Because the DFS RPC endpoint is configured to allow both BUILTIN\Administrators access and BUILTIN\Users access, the latter of which is assumed to contain NT AUTHORITY\Authenticated Users (the default setting). Without NT AUTHORITY\Authenticated Users in the mix, the NetDfsEnum API fails to enumerate the domain-based roots because the FSRM service is authenticating with that identity. The resulting ERROR_ACCESS_DENIED error causes the event to fire.
What we haven’t solved is why NT AUTHORITY\Authenticated Users would be removed from the BUILTIN\Users group. We’ve looked for Active Directory guidance indicating this is a best practice, but we couldn’t find any. We suspect that admins might intentionally remove this group in an attempt to increase security.
So, to resolve this event, add NT AUTHORITY\Authenticated Users to BUILTIN\Users group on the PDC emulator. You can check this by launching Active Directory Users and Computers and looking in the Builtin folder for the domain. The Users group must contain the Authenticated Users group. If it does not, you can add it using the snap-in. Next, stop and restart the FSRM-related services (srmreports and srmsvc) on the file servers where FSRM is running.
If you were one of the 39 people requesting updates on the article that Jabez posted a while back i will alert you ASAP with links to this article and the one at the File Cab.
Hope the information helps-All credit is to the guys at the Filing Cabnit Blog