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.