1

I am configuring a new DFS setup that will utilize Namespaces and Replication. The two member servers are virtual machines running Windows Server 2012 R2.

Since many of the shares range from hundreds of gigabytes to several terabytes, I want to store these shares on their own virtual disks rather than having one big (10's of terabytes) virtual disk for all shares. Instead of assigning a drive letter for each disk, I expected to be able to use junctions to create a unified logical structure as follows where each shared folder is really a junction pointing to a folder on another volume (of course, on each member server the corresponding volumes have different identifiers, and the junctions account for this):

  • C:\File Shares\
    • Share1\ ===Junction===> \\?\Volume{11111111-1111-1111-1111-111111111111}\File Shares\Share1\
    • Share2\ ===Junction===> \\?\Volume{22222222-2222-2222-2222-222222222222}\File Shares\Share2\
    • Share3\ ===Junction===> \\?\Volume{33333333-3333-3333-3333-333333333333}\File Shares\Share3\

Applications such as Windows Explorer and Command Prompt have no problem navigating this structure, and I am able to create shares from each C:\File Shares\ShareX junction and access them without issue. DFS-R, however, doesn't seem to like it. After creating a replication group using one of the above junctions, event 6064 is generated in the Event Log:

The DFS Replication service failed to replicate the replicated folder at local path C:\File Shares\Share1 because the local path is not the fully qualified path name of an existing, accessible local folder.

I suspected the issue is that DFS-R simply doesn't support using a junction as a replicated folder. DFS Replication: Frequently Asked Questions (FAQ) states "Junction points also are not replicated, and DFS Replication logs event 4406 for each junction point it encounters.", but that seems to be referring to when a replicated folder contains a junction rather than when a replicated folder is a junction. In fact, if I assign drive letters X:, Y:, and Z: to the volumes above then DFS-R does work with these junctions:

  • C:\File Shares\
    • Share1\ ===Junction===> X:\File Shares\Share1\
    • Share2\ ===Junction===> Y:\File Shares\Share2\
    • Share3\ ===Junction===> Z:\File Shares\Share3\

This is close to what I want because each share and replication group refer to a C:\File Shares\ShareX\ junction, but each junction still has to be defined using a drive letter and I'd like to take those out of the equation, if possible. To further confuse things, a few weeks ago I was able to get a share replicating using a junction referencing a volume without a drive letter, but now it no longer replicates because of the same 6064 error. I'm not sure how it is that worked in the first place.

Does anyone have any experience with this kind of setup? I can't seem to find any information on using DFS-R with volumes that have no assigned drive letter. Aside from a little extra work when creating new shares, are there any pitfalls or downsides to using junctions to organize replicated folders?

Lance U. Matthews
  • 271
  • 2
  • 17
  • By 'Junction', I assume you mean you're mounting the volumes in those locations, as opposed to giving them their own drive letters? – GregL Jul 07 '15 at 13:09
  • @GregL Correct. The `ShareX` directories are NTFS junctions (reparse points). Ideally, the only way to access those volumes would be through those junctions rather than assigning them a drive letter. – Lance U. Matthews Jul 07 '15 at 13:13
  • Right, that makes sense. You say the junction points to `\\?\Volume{11111111-1111-1111-1111-111111111111}\File Shares\Share1\ ` but I'm confused how that's possible. How are you mounting a folder inside the volume, or are you just mounting the whole volume to that location and including the "final" path here for clarity? – GregL Jul 07 '15 at 13:16
  • @GregL The junction target paths in my examples are indicative of the actual paths; they point to a subdirectory of another volume. Using `Disk Management` you can only create junctions that point to the root directory of a volume. However, if you know the volume device ID (`Get-WmiObject -Class 'Win32_Volume'`) you can use `mklink` to create a junction pointing to a directory of arbitrary depth on another volume. That particular junction would have been created by running `mklink /J "C:\File Shares\Share1\" "\\?\Volume{11111111-1111-1111-1111-111111111111}\File Shares\Share1\"`. – Lance U. Matthews Jul 07 '15 at 14:42
  • So are you saying you created them using `mklink` as opposed to using the GUI? And that you did so using the syntax in your last comment? – GregL Jul 07 '15 at 14:48
  • Yes, these are created using `mklink` and the `\\?\Volume{}\Subdirectory\ ` syntax. The share I created a few weeks ago (the one that worked with DFS-R...until it didn't) uses a junction created by `Disk Management`. Since that points to the root directory of that volume, the share and replication group have to be defined to include the subdirectory (`C:\File Shares\Share0\Subdirectory\ `); the target of the `C:\File Shares\Share0\ ` junction is of the form `\??\Volume{00000000-0000-0000-0000-000000000000}\ `. Both styles of junction function as expected except DFS-R refuses to work with them. – Lance U. Matthews Jul 07 '15 at 15:01
  • DFS-R won't work with either junction point (disk root, or subfolder)? – GregL Jul 15 '15 at 15:30
  • Correct. DFS-R fails with error 6404 when the junction references a volume using its device ID. Given that DFS-R works with junctions that reference a volume by its drive letter, it would seem that DFS-R is querying the target path of the junction and either doesn't know how to handle the device ID syntax or is specifically programmed to reject it. I can't find any documentation to support that theory, and that is not my expectation of how this would work as junctions are supported to be transparent to the application. – Lance U. Matthews Jul 15 '15 at 18:01
  • I can say for certain that DFS-R works with junctions in Windows Server 2008 R2 because all our file clusters use them and replication works flawlessly. That said, all our junctions are created using the GUI, and are joined into a volume with a drive letter. Hard to explain in comments how we do things, but suffice to say that I'm not sure I can be of much help since we're running different OSs and I've never tried what you're doing. – GregL Jul 15 '15 at 18:10

0 Answers0