When the FQDN (fully qualified domain name 'server.company.com' ) is used as a scan target name, the ACL is not retreived from a DFS share.
FQDN => owner is retrieved, but no ACL
As a workaround you can use the NetBIOS name ( 'server_name' ) instead of the FQDN ( 'servername.company.com' ).
FQDN => owner is retrieved, but no ACL NetBIOS => owner is retrieved as well as ACL
This is related to whether the file server is able to determine if the calling machine is within the domain or not. This scenario is touched on in MS KB http://support.microsoft.com/kb/816818.
An issue has also been discovered with DFS where it can not resolve the owner or ACL. The native call LookupAccountSid fails with the error: "The RPC server is unavailable". This call is trying to resolve the SID on the DFS server host, so it doesn't seems that there's anything specific to DFS but a general behavior when the SID can not be resolved. This might tie into the MS KB mentioned above. As reference Etrack-1386264 and Etrack-1310001 are tracking this issue
In case both approaches fail ( NetBIOS vs. FQDN) you can also set where the SID gets resolved (Discover Server or the actual File Server).
On the Discover Server go to Vontu\Protect\config\Crawler.properties and modify the setting from
# Should the SID be resolved on the discover server ? filesystemcrawler.localusernamelookup = false
# Should the SID be resolved on the discover server ? filesystemcrawler.localusernamelookup = true
If the setting is set to false, the ACL and owner information is retrieved from the share ( = File Server ). If it is set to true the Discover server will try to resolve the information.
Imported Document ID: TECH219017
Subscribing will provide email updates when this Article is updated. Login is required.