Holy cow, I wrote a book!
When you connect to another computer via Remote Desktop,
you have the option of injecting your local drives
into the remote computer,
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
And the word client
refers to the local computer, the one that is connected to the remote
In Terminal Services terminology, the machine you are connect from is
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
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.