Creating ‘This PC’ Namespace Items — New Utility

Another fantastic utility by Jacques Bensimon!

---

Citrix veterans will remember the days when redirected client drives only appeared in “My Computer” when they were mapped to a drive letter at logon.  There was even a MetaFrame setup option to change the Terminal Server’s local drive letters from C:, D:, … to something else (typically M:, N:, …), which also involved changing all local drive references in the Registry, shortcuts, etc., just in order to make C:, D:, … available for mapping client drives and thus avoid user confusion – good times!  But somewhere along the line (maybe circa Windows Server 2008?), Citrix decided to instead adopt Microsoft’s Terminal Server strategy, illustrated in the following old screenshot, of (somehow!) making client drives appear in “My Computer” without mapping them to a drive letter:

While I briefly wondered at the time whether this magic (“My Computer” drives with no associated drive letters) was specific to the RDP and ICA network providers or was an example of a broader Windows capability, it wasn’t until recently that curiosity got the better of me and I decided to investigate the mechanism behind these odd “My Computer” (“This PC” in current Windows versions) items.  And it turns out that not only is this a generic Windows Explorer capability but that such no-drive-letter items added to the “This PC” namespace need not represent entire drives but can in fact point to arbitrary network or local folders of arbitrary path depth!  I’ll give some thoughts later about why you might want to take advantage of this capability, but let me first describe the mechanism behind it and introduce my new utility that implements it:

It all starts with a new unique “{GUID}” Registry key with a particular subkey structure and contents created under “HKCU\Software\Classes\CLSID” (and also under “HKCU\Software\Classes\Wow6432Node\CLSID” on x64 platforms).  Somewhere in that key structure, the following items are specified:
(1) the display name of the item
(2) the fully-qualified network or local path to which it points (specified via UNC or existing drive letter)
(3) the item’s “tooltip” (hover text description)
(4) its display icon. 

Once this is in place, the item in question is made to appear in “This PC” by creating the key “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\SessionInfo\SessionID\MyComputer\Namespace\{GUID}”. 
A couple of things to note here:

• The fact that the session ID (decimal number) is part of the above key path entails that the created “This PC” namespace items are specific to a given session.  Other simultaneous sessions by the same user won’t see the same items unless also explicitly added to those sessions.  It’s also worth noting here that even local (non-remote) console sessions do have a session ID, so this capability (and the utility I’ll introduce) are not limited to remote (RDP/ICA/…) sessions – you can use it on locally accessed computers.
• All the Registry keys described above must be created as volatile, so they won’t survive logoff and must be recreated in future sessions if required.  This also means they can’t be created by standard means (like importing a .reg file), which is where the upcoming utility comes in.
• Under Windows 7/2008R2, the {GUID} keys corresponding to RDP/ICA client drives are created by Windows under HKLM\Software\Classes\CLSID (rather than HKCU\…), but the mechanism for adding new items still works when they’re created under HKCU\… instead, so the utility will work there as well.

So, now that I’ve mentioned it a half-dozen times, you can download the new ThisPC_Item command-line utility here.  It offers no syntax help, so all the necessary usage information follows:
Syntax:

Examples:
ThisPC_Item "Finance Folder" \\SERVER1\Groups\Finance "Shared Finance group data"
ThisPC_Item "Public Programs" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs"

• When no tooltip is provided, as in the second example, the item’s path will be used as its hover text.  Also, the utility doesn’t currently let you choose the item’s display icon.  As shown in the next screenshot, either a local or network folder icon will automatically be used, depending on the item’s location.
• As in the case of mapped and SUBSTed drives, these namespace items are “rooted” at the final directory in their path, so navigating back up from one of them brings you back to “This PC”, not to the target’s actual parent folder.
• The utility uses return code (ErrorLevel) 0 to report success, 99 for incorrect syntax (fewer than two arguments, unless using /ClearAll), and 1 to report an error (inability to generate a GUID, permissions issue, etc.).  When an error occurs, the utility will remove any key it may have already managed to create and will leave the system unchanged.
• The utility is compiled 32-bits, but can access the full 64-bit Registry view on x64 platforms, so no 64-bit version is provided or necessary.

Okay, cool factor aside, why would you want to do this?  A few things come to mind, but I’m sure some of you can come up with additional benefits and use cases:

• First the obvious:  you’re no longer restricted by available drive letters.  If the alphabet doesn’t suffice to cover all the mapped network drives (and SUBSTed local folders) you need to make available to users in “This PC” (including in all standard File Open/Save dialogs), you can use this approach via logon script to provide direct access to as many locations as you like.
• Creating these “My PC” namespace items is significantly faster than mapping network drives (via NET USE, GPP, etc.) because no checking for the existence and availability of the target items is performed – we’re just writing a few volatile Registry keys into memory.  On the flip side, however, accessing “This PC” in Windows Explorer could be slowed down by any unreachable items.
• You can create such namespace items to provide access to selected  folders on local drives that are otherwise blocked by policy from being displayed in “My PC” (“Hide these specified drives in My Computer” policy), though you can’t use them to defeat the “Prevent access to drives from My Computer” policy (which entirely prevents Windows Explorer from displaying  anything on a blocked drive – you can still resort to SUBST in such cases, using an unblocked drive letter).
• If you’ve configured any local drive (a DVD drive for example) to be accessed via a file system folder rather than a drive letter, you can use this approach to restore direct access to it in “This PC” (by linking to the folder in question).

That’s it for now.  Please let me know if you discover a killer use for this utility.
JB