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.
Best Answer
As documented by Microsoft:
For more, see: How do I create a UNC to an IPv6 address?
Also note that, strangely enough, Microsoft doesn't actually own that domain name, and the actual owner is unknown. While Windows shouldn't send these queries out to the network, there is still the possibility of leakage if this sort of literal gets reused in other contexts. You would be well advised to set up DNS for your network.