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 #25: Repair Windows With DISM and Installer “Disk”

Copied from https://answers.microsoft.com/en-us/windows/forum/all/how-to-repair-corrupt-system-files-from-a/329649e1-112f-44b9-bfd4-d1be00a77fc1

and placed here are those steps which served me well.

BleckfieldReplied on November 11, 2015

In reply to Geezanansato’s post on September 2, 2015

Using DISM to repair windows from the install disc:

Assuming d: drive is where the cd/dvd is

launch cmd prompt as administrator

mkdir c:\mount

DISM.exe /mount-Image /ImageFile:d:\sources\install.wim /index:1 /mountdir:C:\mount\ /readonly

( server 2008, R2, without SP1 (because that is what I was trying to get installed) had to use DISM.exe /mount-wim /wimfile:d:\sources\install.wim /index:1 /mountdir:c:\mount\ /readonly )

make sure this results in:

Mounting image
[==========================100.0%==========================]
The operation completed successfully.then you can run

DISM.exe /Online /Cleanup-image /Restorehealth /Source:c:\mount\windows /LimitAccess

---

LoftyUIReplied on December 12, 2016

In reply to aaronfranke’s post on September 28, 2016

Not claiming to be an expert here but i’ve been dealing with the same issue.

Win pe is preinstall environment, since you are not running windows technically the os image is not online so /online wont work.

Use diskpart, then “list vol” to find what letter your OS partition is and what letter the installation media is then modify the command as such.

“DISM.exe /Image:*letter here*:\ /Cleanup-image /Restorehealth /Source:c:\mount\windows /LimitAccess”

To save having to mount the image beforehand change source to

“DISM.exe /Image:C:\ /Cleanup-image /Restorehealth /Source:WIM:*Install media letter*:\x64\sources\install.wim:1 /LimitAccess”

Depending on the install media you are using if it is only 64 bit install with no option for 32

“DISM.exe /Image:C:\ /Cleanup-image /Restorehealth /Source:WIM:*Install media letter*:\sources\install.wim:1 /LimitAccess”

Some installers use ESD instead of WIM so.

“DISM.exe /Image:C:\ /Cleanup-image /Restorehealth /Source:ESD:*Install media letter*:\x64\sources\install.ESD:1 /LimitAccess”

Still sometimes this fails and thats how i found myself here….

Anyone have any ideas as to why sometimes with a specified offline image /cleanup-image is not recognised as a command? or can someone please further correct my syntax if there are any errors? Thanks

---

I’m just placing this here, where I can find it again.

I’ll be doing this again, soon, and expect I’ll update here when I have a friendly reminder of what actually works. Funny thing, that, once something we do every 2 years or so works, we just move on. Til the next time…

update 8/5/2020. None of this worked for me on the Server 2008 R2 that I needed to get SP1 onto. But the “System Update Readiness” tool, surprisingly, DID fix the whole thing. Weird thing to note: you simply run the “update” (kb 947821) and it “fixes” stuff, logs it, etc. Here’s a link: https://support.microsoft.com/en-us/help/947821/fix-windows-update-errors-by-using-the-dism-or-system-update-readiness#!en-us%2Fhelp%2F947821%2Ffix-windows-update-errors-by-using-the-dism-or-system-update-readiness

It just looks like a standard KM updater, runs like one, but works more like DISM or other toosl when used for repair.

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.

SYPAK #23: Magic Variables (%~dp0) in Windows Command Shell

I’ve used them for…well, since Windows XP, I think. There is a whole slew of “magic variables” made possible by the command shells expansion of “for” shorthand using the tilde (~) and some other metacharacters, that you can use in your Windows “scripts”, i.e. batch files, and the more modern substitutions for those.
This document from Microsoft does a bad job of explaining them (like most of what Microsoft releases), but it’s nevertheless a reference for them. Check the “for” section.
This website actually does a nice job of listing them, and is where I’m lifting the list, the reason for which I’m creating the post. I once had a very lovely chart of all these sitting on my desk (yep, in hardcopy) which I can no longer find. I can also no longer find the electronic version, and searching for this online has yielded little result. Thus, this post.

%~I – expands %I removing any surrounding quotes (“)
%~fI – expands %I to a fully qualified path name
%~dI – expands %I to a drive letter only
%~pI – expands %I to a path only
%~nI – expands %I to a file name only
%~xI – expands %I to a file extension only
%~sI – expanded path contains short names only
%~aI – expands %I to file attributes of file
%~tI – expands %I to date/time of file
%~zI – expands %I to size of file
%~$PATH:1 – searches the directories listed in the PATH
environment variable and expands %1 to the
fully qualified name of the first one found.
If the environment variable name is not
defined or the file is not found by the
search, then this modifier expands to the
empty string.

The modifiers can be combined to get compound results:

%~dpI – expands %I to a drive letter and path only
%~nxI – expands %I to a file name and extension only
%~fsI – expands %I to a full path name with short names only
%~dp$PATH:1 – searches the directories listed in the PATH
environment variable for %1 and expands to the
drive letter and path of the first one found
(but this would work only in called functions and
only for numbered variables)
%~ftzaI – expands %I to a DIR like output line

The way this typically manifests in batch writing is thus:
cd %~dp0
runfile.exe >> %~d\log.txt

Enjoy, future me!

SYPAK #21: Tricking SCCM 2012 R2 Into Re-Running a Deployment

I have yet to find any solid sources on HOW this is ACTUALLY supposed to work, so I’m popping my (re)discovery into the ether in hopes it will help me remember this in the future.

To TRICK SCCM into re-running a deployment (because, for example, you’d like it to try to push to new members of the collection) change the schedule to some point in the future. It will then try to do the deployment then. If you are impatient, and working with a small collection, try changing it (back) to “as soon as possible” (or whatever the exact phrasing is).

 

You, future me, looking for this, are welcome.

SYPAK #15: Kill a Process Which is Spawning New Processes — Windows

So I was attempting to learn something about Microsoft Visio. I was using version 2013. Humming along nicely, learning virtually nothing, but going through the motions…

Anyway, it crashed. I said “Yes, please report this, try to find a solution, and restart the program.” BAD MOVE

It started spawning endless copies of Visio.exe doing God-knows-what and crashing the computer…

So, I decided Microsoft surely was not stupid enough to NOT make a “killall”…

WOW!

A quickly search on google found “taskkill”. AND it worked!!!

To give credit where due, here’s the guide I followed: http://www.techrepublic.com/blog/windows-and-office/quick-tip-kill-rogue-processes-with-taskkill-in-microsoft-windows/

But in short, taskkill.exe is built in (at least in Windows 7), so open a command prompt, run taskkill.exe /IM visio.exe (substitute your cancerous process for “visio.exe”). The darn thing worked! It actually fought the battle with the auto-spawn, killing 150 rogue suches and allowing me to save my other work.

Whew. Shocking.

Oh, it also works for other things you might like to do, like killing all processes for a particular user (taskkill /F /FI “USERNAME eq username”), on a remote machine (if you have creds) (taskkill /s IP_ADDRESS /u DOMAIN\USERNAME /IM process.exe), etc.

 

Enjoy!

SYPAK #14: Re-encode CamStudio’s .avi File to MP4

I admit to being a complete idiot when it comes to video. I just don’t care that much. And I know, “get a Mac, everything just works because rainbows and ponies and unicorns…” But I should not have to use a Mac to get video. Especially for Microsoft Office 365 Video portal, which is the major reason for my  looking into this now. Some background:

I usually record a lecture using a USB microphone (technically a Logitech mic sold for use with Karaoke Revolution, but that’s kind of another story) and CamStudio to capture the slides and any demos I run. It records to whatever kind of .avi file CamStudio outputs. I then upload to YouTube. It works a treat. Now my place of employ wants to move to Office 365 Video portal instead of using Youtube. Mind, I’m fully in favor of this as I hate putting corporate “stuff” onto “we actually now own all your intellectual property; didn’t you read the EULA when you signed-up for it?” sites like YouTube. However, now my process “is broken”. That’s weird. When I do exactly what I’ve always done, it STILL works fine to YouTube, but not to Office 365 Video. Right. It must be that my process is broken. Phffft.

No matter. I am a techie (of sorts). I should be able to figure this out. Right? Well, after hours of wasting time trying to:

1. discover “what kind” of AVI CamStudio outputs
2. convert that to one of the “supported formats” for Office 365 (notice how .avi is listed?)
3. change what CamStudio outputs (oh, wait, .swv and .swf are NOT supported!?!)
4. GRRRRR!
5. using VLC to convert to some other format (any, other format. seriously. None of them worked for me. At all! I can PLAY all the video I want, but I can’t re-format squat!)
6. finally stumbling upon AN answer.

So here ’tis. I’m not saying this is the best way, or the easiest. But it worked for me, so for you, if you’re video stupid like me, using mencoder, which is part of mplayer freeware software

1. Download/install mencoder
   • For Ubuntu, as I stared out using, you can use Software Center, search for mencoder and install; or sudo apt-get install mencoder and follow prompts; or download and install from source.
   • For Windows (7) as I also used, search the web for “mencoder for windows” (here at time of this writing) and just extract mencoder.exe to somewhere handy)
2.  mencoder is a command-line tool.
   1. For Ubuntu open a terminal window. Your command string should look something like this:    mencoder -ovc x264 -ofps 30 -oac mp3lame -af volnorm=1:0.5 out.avi -o out.mp4
   2. For Windows open a cmd window. Your command string should look something like this:          mencoder.exe -ovc x264 -ofps 30 -oac mp3lame -af volnorm=1:0.5 out.avi -o out.mp4
3. et, voilà After waiting for the finish, you will have a functioning, compressed MP4 which WILL work on the Office 365 Video portal, and though untested by me, many other places, as well, I’ll bet!
   

*** Epilogue

I’m willing to bet the x264 encoder from VideoLAN (same company as VLC which I’ve used for eons) will work, but I’ve found didly online about using it. I have just discovered it has a help swtich that spits out lots of info, so that might be another way to accomplish something similar, and VLC “looks nicer” when it comes to the Windows download (plus, been using their VLC player for years).

*** Epilogue #2: 20160519

I had some trouble encoding this way on Windows. It appeared to work fine, but the quality was total crap. So I did some more playing around. I (re) discovered that mencoder is a dead project, and no longer developed. I don’t know why that would matter. If it works on Linux, it should work on Windows, right? But.. Every time I dug into it people said “just get ffmpeg, and a new version. It works better with newer OSes.” So i did. From here: https://ffmpeg.zeranoe.com/builds/

FYI, download, use 7zip (or whatever you use) to extract the program, then open a command prompt, CD into the /bin directory, and run ffmpeg.exe (with all the necessary switches, etc.)

You CAN put it in the path, but it’s not really that much easier, in my opinion…

Then I followed roughly these directions:

http://superuser.com/questions/525249/convert-avi-to-mp4-keeping-the-same-quality

and the commmand I used:

ffmpeg -i input.avi -c:v libx264 -crf 19 -preset slow -c:a libfaac -b:a 192k -ac 2 out.mp4

Worked a treat! Now have lovely output working on Windows 7 as well, with ffmpeg…

 

SYPAK #5 What I was actually fixing in SYPAK#4: Logon failure: the target account name is incorrect

SYPAK #4 was on the mechanics of what actually fixed this issue, but this is what I was ACTUALLY trying to fix.

One day I unwittingly blew up my NFS share by updating the firmware on our NAS. There were claims of better integration, but in the end, it hosed everything up by moving from NFSv3 to NFSv4. The long and short of it:

I ended up doing things I’m not proud of to get my backup server operational. It then began failing on backing up one of my DCs and complained of credential issues. Because I could use the DC, I didn’t worry too much about it. I got the whole thing ironed out, but was left with this nagging backup issue. Then I blew up the DC in another long story. I then discovered the backups were more hosed than I had thought, and this became a priority.

So, here’s what was failing on the backups:

Unable to index file system due to incorrect credentials. (That’s funny, you WERE using them fine…)

Here’s what it actually meant:

logon failure: the target account name is incorrect

It took me an hour or 2 to figure out WHICH target name was incorrect, and it turns out, due to KERBEROS issues, the server hosting the share I was trying to map to had failed.

So there’s the long and short of why I fixed “The trust relationship between this workstation and the domain could not be established”, but actually it was a share map issue that started it all…