Use of CNAME Records for availability in DFS / Offline Files integration
Offline folders, a.k.a. client side caching, is a great feature of Windows since 2000 and it allows for access to network shared files and folders for users when they are not connected to the network. Designed primarily for mobile users, this technology allows for users to access their files and folders when they are not connected to the network using the same path.
This is the complicated part about offline files in Windows. It is not a mere synchronization utility and is not meant to be one. It allows for the user to access the same \\server\share UNC path even when there is no network connection and to do this it uses a combination of components that exist in both the kernel and user mode parts of the operating system. The integration between the SMB mini-redirector and the offline files component is huge so if a fileserver is somehow not accessible over the SMB protocol, the offline files component will disable the whole namespace that starts with \\server.
This tight integration and marking of fileservers as offline and not parts of the path offline may in some cases be unideal, such as in the case of using a DFS path and making a part of this path available offline. Suppose that you have a \\domain\dfsroot\publicshare\user01 path that resides on a domain-based DFS path. Addding to this, suppose also that the user accesses other parts of this DFS path without making it available offline. The problem arises when Offline files decides that the above path becomes unaccessible. At this point, any path that starts with \\domain will be marked as offline. If the user then tries to access some other dfs root and another folder that resides on that root, he won't be able to do that, such as \\domain\dfsroot02\someotherfolder will also be offline.
To overcome this situation we need to understand how the redirector, mrxsmb.sys handles server objects. Suppose that you establish a file share connection to a fileserver using the following in a row:
a. \\fileserverNetBIOSName\Share
All these 3 different references to the same file server will have their own server object created, called an SRV_OPEN in the redir terminology. Essentially these will behave like 3 different connections to the same fileserver. If at this moment let's say that you are accessing the dfs path \\domain\dfsroot\publicshare\user01 and the fileserver that hosts this folder goes offline. Immediately after this all parts of the \\domain will be inaccessible.
To overcome this limitation, you can create a CNAME record for the domain name and configure your clients to access this path when accessing DFS. So instead accessing \\domain\dfsroot\publicshare\user01 you can create a cname such that users can connect to \\CNAMEforDomain\dfsroot\publicshare\user01 . With this configuration even if a single fileserver in that path goes down, offline folder and the redirector will mark the bogus \\CNAMEforDomain path as offline and you will still have access to the original domain and all hosted domain based root under this domain through \\domain.
One thing to note is when you create a CNAME and immediately try to access the path you may get a "Duplicate name exists on the network" error back. This occurrs because by default the SMB file server in Windows does not allow connections to a different name than the registered name on the machine. So you can't - by default - access a file server named FILESERVER by CNAMEFILESERVER. There is a key that can be used to disable this security check and it is called DisableStrictNameChecking, when set to one, the above workaround for DFS / Offline files integration will work without any issues. DisableStrictNameChecking is a parameter of the LanManServer and you can check "Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name", https://support.microsoft.com/kb/281308. The hotfix mentioned in this article is meant for Windows 2000 and you do not need to install this hotfix on Windows Server 2003, the key can be configured directly.
Comments
Anonymous
January 01, 2003
Thanks. Initially this was going to be a KB article, but I thought it was better to get this published in the blog as the solution is a very specific one.Anonymous
January 01, 2003
Hi. This depends on how the users reference the domain, the solution above will apply if the users access the DFS namespace over the domain FQDN. If you create a CNAME and have users access this for their redirected my documents folder or similar, even when that CNAME (which actually at the end is a fileserver somewhere), the user can still access DFS namepsaces through \DomainFQDN or \DomainNetbiosName. Hope that clarifies it a bit.Anonymous
January 20, 2009
Great article, can you provide any references to KB articles or have you just done the debug work?Anonymous
January 27, 2009
Can you clarify your creation of the cname record? i.e i'm confused. alias name (leave blank) fqdn -> domain name