From reading the DFS documentation, AD appears required.
This is a problem for us because our servers are either stand alone (not in AD), or part of our hosting service AD, and AD is out of our hands.
The question is: How to do DFS, or something like DFS, when the servers are:
Machines are Win2012-R2 and/or Server 2016
Looking to automagically mirror tlog backups and sql backups across machines, on a close-to-the-minute basis.
Here are two slightly different, but similar scenarios:
2. There is a PST for a POP/IMAP account located in My Documents. Documents is then Folder Redirected to a network share. Now, Outlook has trouble accessing the PST associated with the account, despite the fact that the Data Files tab indicates the correct network path for the file (\\server\share\user.name\Documents\outlook.pst). Outlook loads, but it claims the PST cannot be found, hence the Inbox for the associated account cannot be viewed. *
*Turns out this was a specific known issue. I'll post a link later
Why do things "break" when performing these types of redirection, even though the path to the files is still the same from a front-end point of view?
Several users are using offline folders to refer to a server we want to decommission... actually the server is already offline and people have pending updates to this share.
What is the best way to move these cached files to a new server with a new name without losing the new data?
Our DFS namespace is set-up so that \\company.local\users is hosted on both a UK server and USA server with referral based upon the user's site. Works a treat except we suspect today, DFS failed over to the USA for some users. Only suspect because the only evidence we can see is their private files (e.g. cookies, roaming profile) replicating BACK from the USA. Normally, they go the other way.
How can a user determine where \company.local\users is resolving to in their session? Is there a command line tool or something they can look at? Something like net use but for DFS namespaces.
Thanks, Rob.
We've recently migrated our Windows network to use DFS for shared files. DFS is working well, except for one annoying problem: users experience a significant delay when they try to access a DFS namespace that they have not accessed for some time. I have tried to troubleshoot the issue but have not had any success so far, and I was hoping someone here may have some pointers to help resolve the problem.
Firstly, some background on our network:
The network uses a Windows 2008 functional level Active Directory domain with two Windows 2008 DCs and two DNS servers (one on each of the DCs). The network is DNS only - no WINS. All computers are located at the same site and connected by Gigabit Ethernet. We have approximately 20 Domain-based DFS namespaces in Windows 2008 mode, and each DFS namespace has two Windows 2008 DFS namespace servers (the same two servers for all namespaces). All namespace servers are in FQDN mode and all folder targets are specified using their FQDN. All computers are up-to-date with Service Packs and patches.
The actual folder targets (i.e. the SMB shares our DFS folders point to) are scattered across several file and application servers, all running Windows 2008 bar two application servers which run Windows 2003 R2, with no replication setup at all (e.g. all DFS folders currently only have one folder target).
Some more detail on the problem:
The namespace access delay is generally 1 - 10 seconds long and seems to occur when a particular computer has not accessed the requested namespace for approximately five minutes or more.
For example, if the user has not accessed \\domain.name\namespace1\ for more than five minutes and attempts to access \\domain.name\namespace1\ via Windows Explorer, the Explorer window will freeze for 1 - 10 seconds before finally resuming and displaying the folders that exist in \\domain.name\namespace1. If they then close the Explorer window and attempt to access \\domain.name\namespace1\ again within five minutes the contents will be displayed almost instantly - if they wait longer than five minutes it will go through the 1 - 10 second pause again.
Once "inside" the namespace everything is nice and snappy, it's just the initial connection to the namespace that is slow.
The browsing delays seem to affect all variants of Windows that we use (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - it is possibly a bit worse in Windows XP / 2003 than in Windows 2008, but I'm not sure if the difference isn't just psychological.
Accessing the underlying folder targets directly exhibits no delay at all - i.e. if the SMB shares pointed to by DFS are accessed directly (bypassing DFS) then there is no pause.
During trouble-shooting I noticed that the "Cache duration" for all of our DFS roots is set to 300 seconds - 5 minutes. Given that this is the same amount of time required to trigger the pause I assume that this caching is somehow related, although I am unsure exactly what is cached on the client and hence what needs to be looked up again after 5 minutes have elapsed.
In trying to resolve the problem I have already tried / checked the following (without success):
So that's where I'm up to - and I'm out of ideas. Can anyone suggest what may be causing the delays and/or what I should be trying next?