Windows Server Backup fails before starting with message "The directory is not a subdirectory of the root directory."

Question

When using "Windows Server Backup" in Windows Server 2008, I get the error message "The directory is not a subdirectory of the root directory." when trying to backup to a remote shared directory.

I am logged in through remote desktop, and the destination for the backup is "\\tsclient\c\users\me\desktop\backup\". Initially, it accepts this directory, and moves on to the final "Confirmation" step. When I click "Backup", it gives me the error message I mentioned.

Does anyone have any idea what this means, or why this particular remote shared directory would cause this message?

I've even tried mapping it as a drive and doing a backup to a local drive, but mapped drives don't show up in the local drive list. Also, this is a virtual machine (no other local drives, no dvd burners, and no other accessible machines on the LAN), so the tsclient remote shared folder seems like my only possible target for a backup destination. I was feeling so good about Windows Server 2008 until this happened... why can't their software ever just work :(.

Update:

The error message seems to mean literally what it states. I shared the target folder on my desktop and mapped it as a local drive "B", and made it available for remote desktop. When I use the path "\\tsclient\b", Windows Server Backup accepts it and begins transfering the data. So.. "\\tsclient\b" is a valid path, but "\\tsclient\b\subdirectory" is not? Wtf?

Answer 1

I think their software works fine, except that you're "pushing" a feature beyond its intended limits and seeing an artifact of a protocol implementation. I'm don't think that running backups through the TS client drive redirection feature is going to work. I would say that the "subdirectory" behaviour you're seeing is because of artifacts of the TS client drive redirection feature (which is its own protocol and not "normal" SMB2/CIFS/SMB file and print sharing).

I'm running the following command on a W2K8 server computer daily with success, for example:

%SYSTEMROOT%\System32\WBADMIN.EXE start backup -backupTarget:\\adminserver\backups\FTPServer -allCritical -quiet

The path specified there is another server computer accessible over SMB/CIFS. Backup to a subdirectory that way is no problem.

Is the a compelling reason not to just give the VM access to another machine via SMB2/SMB/CIFS?

Edit:

You're misunderstand me when I say that you're "pushing" the feature. I'm not trying to "apologize" for them. The TS client drive mapping feature should act just like any other networked filesystem. It should be reliable enough to push potentially tens of gigabytes across in a backup scenario like you describe. It should work.

What I'm saying is: As far as I can tell, by looking at the "tone" of docs re: the TS client drive mapping feature it's intended to be used for casually moving data between the client the server. Further, it's a virtual channel protocol for RDP that's wholly and totally unrelated to SMB/CIFS, so it doesn't have the years of being "beaten on" that SMB/CIFS does.

I've heard reports of the feature being very unreliable when used as the location for saving documents from the Microsoft Office programs, for example. My take on this is that while this feature should work fine, it seems very likely that Microsoft isn't testing it for use as a general-purpose networked file system. As such, what you're doing is "pushing" the feature beyond its unstated design goals.

I'm right there with you re: UNC's making remote resources "just be a folder". The MUP driver should make any UNC act like "just a folder". After years of dealing with problems in older versions of the SMB redirector (remember "Oh, just disable oplocks", anyone?), the Novell Netware client, various NFS client implementations, and Microsoft's own WebDAV functionality I don't just trust any UNC-based network filesystem provider to work.

It's infuriating when I find a feature in any application or operating system that doesn't work "as advertised" (either from Microsoft or otherwise-- it just seems like Microsoft does it more often). What you're doing is the same thing that all of us in the industry do-- trying a feature out to see if it meets our real world requirements as well as the marketing gimmick requirements.

You're finding out that this feature doesn't meet your requirements. You have two choices-- complain to Microsoft or find a different way. To my mind, complaining to Microsoft is futile (unless you're a large enough Customer to attract attention with your complaints), so the alternative is to find another way.

That's why I said what I said. Not because I think you're doing anything wrong, because I'm apologizing for Microsoft's shoddy programming on this feature, or because I think it's right for the feature to be "sold" as being a true UNC-based networked filesystem drive when it's obviously "got issues". It is what it is, and you just have to deal with it or move on and find another way.