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 #30: Windows 10 – Enable .NET Framework 3.5 Without Internet Connection

tl:dnr;

using your source (I chose to use a Windows 10 .iso file I had recently created using the Windows Media Creator Tool for another project…) and using an elevated command prompt, point dism at the “online” image and feed in the source (in my case, D drive housed my mounted .iso, so D:\Sources\SXS), thusly: dism /online /enable-feature /featurename:netfx3 /source:D:\Sources\SXS /limitaccess

===

The Longer Explanation

Many reasons, actually, might make a person wish to install/enable .NET Framework 3.5; so much so, this is now a “feature enable” option on Windows 10. However, nearly every “how to” do this demonstrates downloading the full (aka “offline”) installer from Microsoft’s download page and then just run the installation. Problem with this is that this kicks off the feature enable, and tries to download a package from Windows Updates to enable the feature. Which means you wasted your time downloading the offline, full installer anyway, but if that works, YAY you! If not… 😦

Usually we get some error, like “Error code 0x800F0954” which never seems to exist when researched but largely boils down to “unable to download/unzip/whatever the package”. In my case, with that error, it was traceable back to my WSUS server not caching the confounded package. No idea why it’s trying to do this, when I’ve downloaded the (full, offline) installer, but whatevs, yo! GRR!

So what to do about it?
As noted at the beginning, we can simply use a cached .iso (or other source) for our installation set and dism. We just need to assemble the correct series of options/parameters, and wham-oh! In like Flynn.

Thank you to Matt Brown for posting this how-to on Spiceworks!

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 #24: “Cracking” into Windows 10 When You’ve Forgotten Your (Local Account) Password

Steps lifted from this website, which just happens to be the first one I found when I was digging for these instructions (again) recently. I do this kind of stuff about once every 2 years, it seems, so I always forget the details. SO here ’tis:

NOTE: Windows 10 1809 and later (to date) have different steps (included below) than prior versions (up until 1803) so watch for that.

Before the latest feature update of Windows 10, Windows 10 version 1809, users could boot into the recovery environment, replace utilman.exe with cmd.exe, and click on the “ease of access” button to spawn a command prompt window to change the user password.

In newer versions of Windows, extra steps are required. Here is the entire process, including both versions:

1. Load the recovery and troubleshooting environment, e.g. by clicking on “Repair your computer” during Windows Setup if you boot from Windows installation media.
2. Select Troubleshoot > Command Prompt.
3. Switch to the drive letter that Windows is installed on and there in the system32 directory, e.g. cd c:\windows\system32
4. Type rename utilman.exe utilman.bak.
5. Type copy cmd.exe utilman.exe.
6. Restart the computer and boot from the Window installation this time.
7. If you run Windows 10 version 1803 or earlier, click on the Ease of Access button to open a command prompt window.
8. If you run Windows 10 version 1809 or later, do the following first:
   1. Hold Shift-key on the keyboard and click on the Power button to select Restart.
   2. After the Restart, hold down the Shift-key again and select Restart from the Power menu again to boot into startup repair.
   3. Select Troubleshoot > Advanced Options > Startup Settings > Restart
   4. When the Startup Settings screen appears after the Restart, select 8) Disable early launch anti-malware protection.
9. Click on the Ease of Access button on the next start on the login screen to open the command prompt window.
10. Type net user to display the names of all user accounts.
11. Use the command net user [username] [password] to change the password of the account, e.g. net user bob badpassw3rd to change the password of the user bob to badpassw3rd .

Thank you, Martin, for having posted this.