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
Actually, you should be able to assign permissions the server side, at least a login. There may even be some default privileges being used. You need to provide more information about the server you're trying to connect to? Is this a service you have access to. Is it configured to use LDAP? Is it a password-less setup? Can you access the url from the browser?
You should be able to map the webdav location as a network drive in explorer:
net use z: https://servername/webdav /PERSISTENT:YES /USER:user password
Then, use robocopy to transfer the source to the destination:
http://technet.microsoft.com/en-us/library/cc733145(v=ws.10).aspx
This will help the transfer complete successfully over network connections.
Keeping a webdav folder mapped as a drive also has it's limitations. You need to tweak the webclient parameters to handle large file transfers. Here are a few important notes I've accumulated over time for trouble shooting webdav connections on Windows Server 2008:
System error 1397 has occurred. Mutual Authentication failed. The server's password is out of date at the domain controller.
You need to apply this patch: http://support.microsoft.com/kb/2489177
Failed to copy, (The file size exceeds the limit allowed and cannot be saved)
FileSizeLimitInBytes is set to 5000000 which limits your download so just set it to maximum! (this is client side btw on windows 7)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Error 0x80070079: The semaphore timeout period has expired
This is apparently a common issue for many ppl with windows 7 when working with webdav/sharepoint over https/ssl:
http://social.technet.microsoft.com/Forums/en-US/itprovistanetworking/thread/c3fc9f5d-c073-4a9f-bb3d-b7bb8f893f78/
http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/1e654537-fd40-4b89-ac1c-f66bdd9fcd2e
http://forums.iis.net/p/1182933/2001427.aspx