SYPAK #31: Windows – Command Line Access to Mapped RDP Disks

I have sniffed around this solution for quite some time, but just last week came up against an immovable need and finally got serious about making it work. Specifically, I was looking to copy some files from an old server to my local disk for “safe keeping” (until I figure out what to do with the junk utilities I’d amassed), and simple file copy was failing (annoyingly, as it does, For Shame! Windows, that in 202x we STILL just get a failure instead of “continue & log for remediation” report!). For the first time in my career, I didn’t have another server to move “it” to, so…

This is where I found this information: https://itworldjd.wordpress.com/2015/08/03/how-to-access-the-disks-mapped-through-rdp/

Thank you, Jacques Dalbera!

Not quite a reproduction of Jacques’ post, but here ’tis.

Since Windows XP, support for drive mapping to the client during a Microsoft Terminal Services Connection (aka Remote Desktop) session, allowing file copy from the server to the client and vice versa via the file system.

To my knowledge, this is supported only in the Microsoft Remote Desktop Connection (aka MSTSC, RDP) application, and is not supported in the Microsoft Universal Remote Desktop App. I hope to find I’m wrong one day and correct this post, but meantime…

In the Microsoft Remote Desktop Connection (MSTSC) interface, “Local Resources” tab, “Local devices and resources” section, hit “more” to see options for “Drives”. Each volume (removable, fixed, or network) available on the client workstation is enumerated, and can be selected to be connected to the server during the RDP session. Each will show in the server’s Windows Explorer as “volume on computer name”, (e.g. “C on Computer1” for C: drive, or “F on Computer1” for F: drive). This makes for reasonably useful GUI browsing and file manipulation, but what about command prompt access?

I’m so glad you asked.
Drives can also be addressed much like network shares via Universal Naming Convention (UNC), and/or mapped in a similar fashion if that suites the purpose. Volumes on the client are accessible to the server as \\TSCLIENT (note the client workstation’s machine name is not used, but is always referenced with the generic name “TSCLIENT”) followed by the volume’s drive letter, so using the same example as before “C on Computer1” could be connected through \\TSCLIENT\C or “F on Computer1” could be connected through \\TSCLIENT\F. We can display the content of C: drive on Computer 1 via UNC:
DIR \\TSCLIENT\C
and/or map a drive letter to it:
NET USE Y: \\TSCLIENT\C
We can also perform other command prompt actions, like copying files:
COPY \\TSCLIENT\C\USERS\ME\DESKTOP\*.XLS D:\DATA\EXCEL
or what I needed, Robocopying files:
ROBOCOPY \\TSCLIENT\C\ME\DESKTOP D:\DATA\EXCEL *.XLS /Z /ETA
ROBOCOPY Y:\ME\DESKTOP D:\DATA\EXCEL *.XLS /Z /ETA

Note from Jacques’ post, as I have not investigated this: the remote Terminal Services session inherits the user’s permission. So if you are logged on to the workstation as user A and you log in to the Terminal Services server as user B, the session will have access to the drives according to A’s permissions.

I hope this helps future me, and, with a little bit of luck, others out there seeking.

PS here’s another article I found while researching this, complete with some pictures. Thank you, Brandon Lee, even if your commenters feel that you did not write about what the title states. The pictures & process still helped me.

SYPAK #29: Query Windows 7, 10 Install Set for Supported Versions

This starts out pretty simple. Find your .iso or .wim. Mount it (double-clicking will suffice for .iso; dism must be used for .wim files). From there, most of the tutorials online only mention querying a specific .esd or .wim index, using a command like dism /Get-WimInfo /WimFile:F:\sources\install.esd /index:1 . The problem with this is it uses the index switch to tell dism which installer to check, and only (in my experience) returns THAT ONE in the case of multi-version images (which all of those downloaded for Windows Media Creator are, to my knowledge). Instead, one needs to ask dism what indices are available using a command more like dism /Get-WimInfo /WimFile:F:\sources\install.esd

I know they look very similar, because they are. But the big key difference is that the latter will show ALL indices, instead of just the ONE you’ve told it to look at. The difference can be astounding.

These are some of the sites I looked to when attempting to re-learn this little tidbit:

winaero

winhelponline

I was unable to find the ONE site I dug up once upon a time that laid this all out crystal clear, but thank you, anonymous blogger. Thanks to you, I know everyone else only gets it partially right.

SYPAK #28: Outlook Web Access (OWA) FINALLY!!! Gets Scheduled Send

Check this out for how to use https://mspoweruser.com/schedule-an-email-send-later-outlook-web/

Also, borrowing one of these images without permission. Thank you.

OWA is…well, to be frank, garbage, for those of us forced to use it because…well…whatever, but let’s say that your IT overlords have seen fit to NOT BOTHER fixing the problems with your tenancy, even if it were a simple call to THEIR overlords at Mickeysoft preventing an actual Outlook client from working in many of your workday scenarios. Among the mind-bogglingly idiotic discrepancies is the aggregated “Unread Items”. If you’re of a certain age, certainly, but even if not, you probably sort your email into folders for ease of finding later, etc. You probably have rules for helping with that, especially if you get auto-generated services messages that you want to have/keep/read when pertinent, but that do NOT need to be in your Inbox. How can you see these in OWA? Go digging. And good luck. And I’m sorry, Microsoft, but “conversations” is unwieldy at best, and search/filter from the inbox is equally useless. Seriously. Searching for an email that I have pulled up in one client, on another computer sitting on the same tabletop in OWA and it can’t be found. WTF?!?
Wait. Why were we here again?

Oh yeah. Another exploitable bug feature of Desktop Lookout that until June 2020 or so was not available in OWA is delayed send. In a rare move, though, M$ actually made this one BETTER because it’s server-side. That means you can set the send time to a point in the future, and walk away, and the server will send your message at the appointed time (y’know, assuming everything works as-planned – a stretch, I know). On the desktop version, this is still client-side, meaning you have to have your computer turned on and the Outlook client has to be loaded. Otherwise, the server will simply ignore the future-send request once it becomes current, because it knows nothing about it. Very frustrating for those of us who became accustomed to building time-sensitive emails over a period of time, expecting the “send at” to trigger that send at the appointed time regardless of our being logged into a computer at all, because SOME vendors had the sense to make this server-side, as it should be and always have been, unlike M$ who, bafflingly, decided this needed to be client dependent. So what’s to know? Why am I here, instead of just pointing you to Pradeep’s post about Mike’s post? Here is the interface for the new bug feature:

Why did I feel the need to make a post, to remind myself sometime in the future about something I probably already know (but perhaps can’t remember just this moment)?

Here’s my screen:

Where is MY pulldown?

So…where IS my pulldown? I can see it in the “Attach” button, but nada on the “Send” button… I guess my tenancy has not, five months hither, been granted this glorious functionality…

Of course there’s a “gotcha”. And in a way that only Microsoft seems capable of doing, they exploit what is obviously a failure on my part, but in the most irritating way. I have NEVER used the OTHER send button. In fact, I did not even realize until today that there are multiple send buttons. I just use the one that is obvious. As encircled above. It turns out, if you look carefully, there is another at the bottom of the window.

Here, you will find the pulldown arrow, and can then schedule your email to send at some point in the future, whether your computer is on or not; whether you are logged in or not; whether your Lookout client is running or not. Ah. A small bit of relief in the sea of suck that is using OWA.

Thank you, Microsoft, for finally adding this feature to your bugfeature list.

---

This is pretty funny, and warrants more research. I cannot save this post to WordPress using a category of Microsoft with subcategory of Lookout.