Monday, May 16, 2022
  • Home

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 don’t forget to check out their blog to get the full story-You rock guys.

EVENT LOG Application
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-specific details:
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 as 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

Posted in Bugs, Windows Server System | 2 Comments »

This entry was posted on Friday, September 29th, 2006 at 8:06 pm and is filed under Bugs, Windows Server System. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

2 Responses

  1. FSRM: “Access is Denied” is logged in Event Viewer » MSBLOG Says:

    […] UPDATE:- There has been an update posted HERE- this post explores a work around- There is no KB article yet but now that the FSRM team has been alerted to the issue it shouldnt be too far away. Want to share this story:These icons link to social bookmarking sites where readers can share and discover new web pages. […]

  2. Chris Says:

    This solved my problem. Thanks. To give you a pointer to the cause, my domain started out as NT4 and has migrated through W2K mixed, W2K native to finally be W2K3 R2. NT Authority\authenticaed users has never been manually removed from builtin\users but wasn’t there.