First published on TECHNET on Sep 29, 2006
We’ve seen numerous reports of the following event within Microsoft and from our customers.
EVENT LOG Application
EVENT TYPE Warning
SOURCE SRMSVC
EVENT ID 12317
COMPUTERNAME SERVER2
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…well, most of the cause anyway.
An Event 12317 showing access denied is caused when the NT AUTHORITYAuthenticated Users group is not a member of the BUILTINUsers group in the domain. (As you might know, the local BUILTINUsers group on a domain controller is mapped to the domain built-in group Users. Therefore, the effect of removing NT AUTHORITYAuthenticated Users from the BUILTINUsers 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 BUILTINAdministrators access and BUILTINUsers access, the latter of which is assumed to contain NT AUTHORITYAuthenticated Users (the default setting). Without NT AUTHORITYAuthenticated 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 AUTHORITYAuthenticated Users would be removed from the BUILTINUsers 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 AUTHORITYAuthenticated Users to BUILTINUsers 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.
--Jill (with much input from Dan Lovinger)
We’ve seen numerous reports of the following event within Microsoft and from our customers.
EVENT LOG Application
EVENT TYPE Warning
SOURCE SRMSVC
EVENT ID 12317
COMPUTERNAME SERVER2
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…well, most of the cause anyway.
An Event 12317 showing access denied is caused when the NT AUTHORITYAuthenticated Users group is not a member of the BUILTINUsers group in the domain. (As you might know, the local BUILTINUsers group on a domain controller is mapped to the domain built-in group Users. Therefore, the effect of removing NT AUTHORITYAuthenticated Users from the BUILTINUsers 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 BUILTINAdministrators access and BUILTINUsers access, the latter of which is assumed to contain NT AUTHORITYAuthenticated Users (the default setting). Without NT AUTHORITYAuthenticated 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 AUTHORITYAuthenticated Users would be removed from the BUILTINUsers 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 AUTHORITYAuthenticated Users to BUILTINUsers 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.
--Jill (with much input from Dan Lovinger)
Updated Apr 10, 2019
Version 2.0