Why doesn’t the New Folder command work in the root of a redirected drive resource in a Remote Desktop session?


When you connect to another computer via Remote Desktop, you have the option of injecting your local drives into the remote computer, known as Device and Resource Redirection. These injected drives are available under the UNC \\tsclient\X where X is a drive letter on the local machine.

The name TSCLIENT combines a bunch of internal technical terminology, so it makes perfect sense to the people who wrote it, but not as much to outsiders. (They may have chosen this name just to make themselves look smart.) The letters TS stand for Terminal Services, which was the former name of the technology now known as Remote Desktop. And the word client refers to the local computer, the one that is connected to the remote computer. In Terminal Services terminology, the machine you are connect from is the client, and the machine you are connecting to is the server.

There's another level of confusion in the name of the feature. People often call these \\tsclient\X thingies Redirected Drives, which collides with the existing name for local drive letters that have been mapped to a network resource. In the user interface, these are usually called Mapped Network Drives. From the command line, you create these things via the NET USE command.

Okay, enough with the confusing terminology. For today, we're talking about Remote Desktop Device Redirection, where the redirected device is a drive letter.

If you open My Computer and look under Other, you'll see those drives which were injected from the local computer. Your first tip-off that there's something funny about these drives: They don't show up in the Network Location section like other mapped drives; instead they show up under the rather generic-sounding Other.

That's because these drives aren't really drives. They are folder shortcuts, a special type of shortcut that grafts one part of the shell namespace into another. The ones created by Remote Desktop Device Redirection are shell instance objects, which is a way of creating certain types of shell extensions using just a handful of registry keys.

Since they aren't really drives, some things that work for real drives don't work for these fake drives. And one of those things is that Explorer thinks that they don't support the New Folder command because when Explorer asks, "Do you support IStorage?" (because that's the interface that Explorer uses to create new folders), the answer is "No, you silly rabbit. I'm an Other!"

Now, it turns out that the Terminal Services folks could've customized their Other to say, "Actually, yeah, I do support IStorage." You do this by setting the bit 0x00000008 in the Attributes value of the ShellFolder key when you registered your instance object. The Terminal Services folks forgot to set that bit, and the result is no New Folder button.

Sorry about that.

As a workaround, you can create your new folder by typing \\tsclient\X into the address bar. That folder is the thing that the folder shortcut is pointing to (so it's just another name for the same thing), but since it's the real thing, it correctly reports the SFGAO_STORAGE flag, and the New Folder button appears.

Comments (27)
  1. Joshua says:

    I must be more confusing. I call them local drives.

  2. alegr1 says:

    The real question is: even though the address line shows \tsclient<x>, why you cannot go back in the Explorer history, if the terminal session reconnected? Is it because the history keeps some ephemeral token, instead of the UNC name (which would have made much more sense)? And why tsclient is so slow, even slower than SMB?

    [If you reconnect, you might be reconnecting from a different machine, so \tsclientx refers to a potentially unrelated drive. As I noted in the article, \tsclientx is not the actual reference. It is to a circuit set up just for the lifetime of that connection. -Raymond]
  3. Henke37 says:

    I take it that this detail has been fixed by now.

    [I believe so, yes. -Raymond]
  4. MItaly says:

    > In Terminal Services terminology, the machine you are connect from is the client, and the machine you are connecting to is the server.

    So someone actually got this right (contrast this with the X terminology, where what you expect to be a server is a client and viceversa).

  5. dave says:

    The X terminology mirrors the terminology used for terminal servers, in the earlier sense of a box on a network to which physical terminals are physically connected, which itself reflects usage such as printer server, a box on a network to which printers are physically connected.

    A terminal server serves up terminals!

  6. Gabe says:

    And to think — here I was marvelling at the cleverness of finding a name that wouldn't ever conflict with an actual server on a real network!

    For a little background, the original terminal server did not create what look like network shares. It just mapped your local drive letters (C:, D:) to the terminal server session's drive (C:, D:). So how did your local C: drive avoid conflicting with the server's C: drive? Well, when you installed a terminal server, it called its install drive M: instead of C: — obviously that only worked because you were installing Terminal Server as a separate OS product.

    When they integrated terminal services into the OS for remote administration, obviously installing to the M: drive isn't going to work, and that's presumably where TSCLIENT came from.

  7. JonPotter says:

    Any reason they couldn't just, I dunno, fix it by setting that bit?

    [I believe that was exactly my recommendation to the TS team. -Raymond]
  8. Rob says:

    How does Explorer utilize IStorage to create a folder?  I would surmise it calls IStorage::CreateStorage, but the documentation for that and RenameElement both indicate that the maximum length of the names is 31 characters.  The file system supports longer names, though, so how does the delta get rationalized?

  9. alegr1 says:

    >If you reconnect, you might be reconnecting from a different machine, so \tsclientx refers to a potentially unrelated drive

    Explorer can (semi)perfectly handle that for directories on other media and on network shares: it gives a modal (ugh!) dialog that the location is gone. But even if the UNC of some folder on \tsclientx is still reachable, explorer won't try to open it at all.

    [If the drive goes away, that's the easy case. But what if you connect from machine 1, open \tsclientcfile1, then disconnect, reconnect from machine 2, then click Save. Oops, you overwrote some unrelated file. This is the TS version of changing floppy disks. -Raymond]
  10. Azarien says:

    I tend not to use the \tsclient drives, because for some reason they work much slower than other means of data transfer. At least for me. So if possible, I just use regular network shares, or FTP, or even e-mail attachments.

  11. Nick says:

    Azarien: That's probably because of some sort of deep packet inspection on a firewall-type device.

  12. alegr1 says:

    [But what if you connect from machine 1, open \tsclientcfile1, then disconnect, reconnect from machine 2, then click Save. Oops, you overwrote some unrelated file. This is the TS version of changing floppy disks. -Raymond]

    As currently implemented, it absolutely works as you describe. You open a document in Notepad by its UNC, you save it back by its UNC. If the UNC goes to a different place now, too bad. It can happen with SMB shares, too. It's only Explorer that messes up its history by using some tokens in it instead of strings.

  13. Karellen says:

    "In Terminal Services terminology, the machine you are connect from is the client, and the machine you are connecting to is the server."

    "So someone actually got this right (contrast this with the X terminology, where what you expect to be a server is a client and viceversa)."

    But…they're both the same, and both right!

    In both cases, and in all client-server (basically all non-equal-peers) instances, the machine doing the connecting is the client, and the machine listening for and accepting (or rejecting) the connection is the server.

    If you RDP to a remote computer, the machine you are connecting from – the one you are sitting at – is the client, and the machine you are connecting to – the remote one – is the server.

    If you SSH to a remote computer, the machine you are connecting from – the one you are sitting at – is the client, and the machine you are connecting to – the remote one – is the server.

    If you run an X program on a server you have SSHd to, the X program initiates a connection to the X server. The machine which is doing the connecting – the remote one – is the client, and the machine being connected to – the one you are sitting in front of – is the server. The X program on the remote machine is the X client, requesting a service (draw my window please) from the display on your local machine, which is the X server.

    (Is this *really* so hard to understand, or is it just haters intentionally feigning confusion?)

    "Now, it turns out that the Terminal Services folks could've customized their Other to say, "Actually, yeah, I do support IStorage." You do this by setting the bit 0x00000008 in the Attributes value of the ShellFolder key when you registered your instance object."

    Wha….? Surely the way to say "I support IStorage" is to return S_OK from IUnknown::QueryInterface(IID_IStorage, &ppv); Because, you know, that's how COM works. Isn't it?

    [Oh, the do respond S_OK to QI(IStorage). The problem is that Explorer has a performance optimization that short-circuits QI, and if you don't declare that you support IStorage, then Explorer says "Well, I won't bother creating this object to get an interface I know it doesn't support." This is part of the moniker/pidl duality I discussed some time ago. The shell namespace's original design tried hard to avoid creating objects unnecessarily. -Raymond]
  14. Engywuck says:

    in a Citrix XenApp 6.5 (former MetaFrame, dunno what they call it in its latest incarnation), the clients drives are mapped as \ClientC$ (so at least the "UNC"s are invisible to the explorer :-)) and show as "Lokale Festplatte (C: on MYCLIENT)" on my german localized Servers Explorer, below all other drives. New Folder seems to work.

    @alegr: well, in most cases a UNC path is not changed while still being logged on. If it points to a server then the administrators deliberately have to change the name of the servers and convince all clients that nothing really happened when their sessions dropped, just move on (and relogon to the share). If it points to DFS, well then it's the administrators who have to take care that all servers with the same DFS name have the same content (greatly helped by DFS-Replication and such). Only in the case of TSClient-"UNC"-Paths the user itself can do so himself, perhaps without knowing what he's doing.

    [Exactly. If an administrator takes a server down, they know that they are screwing everybody who was using that server. But you don't expect disconnecting and reconnecting to a remote desktop machine to screw you. Indeed, the whole point of remote desktop is so that your state gets preserved across the disconnect/reconnect! -Raymond]
  15. asdbsd says:

    > The ones created by Remote Desktop Device Redirection are shell instance objects, which is a way of creating certain types of shell extensions using just a handful of registry keys.

    So when I connect through RDP, registry keys are being added? What if I connect from two places at once, in different sessions? Or if the power is yanked out, wouldn't the keys remain present?

  16. Fleet Command says:

    Are these shell objects accessible in a process with elevated token?

    And am I correct to assume the article applies to Windows 8.1 and all its previous releases?

  17. Joshua says:

    @Fleet Command: I don't know about the shell icons (MS made getting an elevated explorer a real pill in 8.1) but \tsclientX works just fine from elevated processes.

  18. alegr1 says:

    [@alegr: well, in most cases a UNC path is not changed while still being logged on. If it points to a server then the administrators deliberately have to change the name of the servers and convince all clients that nothing really happened when their sessions dropped, just move on (and relogon to the share).]

    You can have an IP address as a UNC host name, and the IP address may change in the meantime because of DHCP refresh.

    Showing a "new folder" command is a property of shell object in Explorer, but accessing \tsclient in applications doesn't in any way depend on shell objects.

  19. alegr1 says:

    As I see, the arguments boils down to following:

    Me: If RDP session gets reconnected, the explorer's back history should not get invalidated. If Explorer cannot go back because the folder is not there anymore, it's OK to display an error (just like for other cases of missing local and network locations). Other programs don't care, anyway, and will happily save a file back, if possible.

    Raymond: If RDP session gets reconnected, it's OK to make it impossible to return back in Explorer history, even though the UNC still points to the same existing location.

  20. Fleet Command says:

    @Joshua: I don't mean an elevated explorer. Let's say an admin runs a system utility like Resource Monitor with elevated privileges and wants to save a report. Will he be able to see to those pseudo-drives in Save As… dialog box?

  21. alegr1 says:

    \tsclient is even more broken than I thought. If you make a shortcut to a location on it, it may or may not work after reconnect, depending on how you created the shortcut. If you opened the folder by \tsclientc path, you have more chances.

    You have an Explorer window open with some \tsclient location. After reconnect, you will not be able to reopen that location in that window, even if you type the UNC path in it. But if you open another explorer window, and type the path in it, it will work. If in the meantime you open a CMD window, and type dir \tsclientc, it may not work, either. But dir \tsclientd (if there is D:) will work. After another reconnect, dir \tsclientc may now work.

    If you have a pleasure of using Virtual PC for Windows 7, remember that \tsclient connection will break and reconnect EVERY TIME you resize the window, or switch to full screen. If you are copying any files to/from your host during that, you're SOL. I haven't checked if the HyperV client connection has the same bug.

  22. Engywuck says:

    having IP address is already in the "you should know what you're doing" category. Using non-static ones raises the bar quite a bit towards "you have to be insane to use it". At least in my opinion :-)

    Despite that, you have additionally to be really unlucky (or have a really dumb DHCP server) so that the server you use loses it's IP during DHCP refresh and another server where you *also* have write access *and* which answers to the same UNC path coming along getting the same IP address while you notice nothing. Sure, if you work on detached sessions or so, but most use cases save work at least every few hours :-)

  23. Joshua says:

    @Fleet Command: I know my local machine drive letters well enough that I never actually tried to see them. Enumeration is so slow it's more efficient on my time to browse locally and copy the path via the clipboard. I've got enough paths memorized that I can usually type them in.

  24. George says:

    Oddly enough, you can "map" the drive with

    net use * \tsclientd

    and then everything works on the mapped drive

  25. alegr1 says:

    @George:

    SUBST works, either.

  26. arghhhhhhhhhhh says:

    I wish Microsoft added a FUSE-like framework to Windows. Then shell drives could be implemented as "real" drives.

  27. 640k says:

    Removable media has been a problem since DOS 1.0. And since unix 1.0.

    Why isn't this solved year 2013? How hard could it be?

Comments are closed.