For years now, I’ve wondered why some of my RDP connections work only some of the time. Now I know why, and it’s provokes a Homer Simpson response “Doh!” Now that I’m done laughing at myself, let me explain how I got that RDP mystery finally resolved.
I was working with my various Thunderbolt docks this weekend, and I noticed that a previously not-working RDP connection started working again. Turns out that of necessity devices with both GbE and Wi-Fi adapters have separate and distinct IP addresses for each such adapter. Therein lies the key to the mystery, as shown in the lead-in graphic.
Explaining How RDP Mystery Finally Resolved Itself
This all started when I had to move my X12Hybrid dock upstairs. When I disconnected from the dock, and its GbE connection, the RDP connection defined for X12Hybrid (also the machine name used in RDP) resumed working. Then it hit me: because the GbE connection uses a different IP address from the Wi-Fi connection, my RDP definition works only when the IP address it knows about matches the address actually in use. Again: “Doh!”
You can see this clearly in the dual windows shown in the lead-in graphic. PowerShell is in top position, and shows that nslookup stores the IP address associated with the Wi-Fi interface (192.168.1.20). But when I plug the GbE interface in, it takes a different address instead. That private IP address ends with .39, as shown in the NetBScanner window at bottom of the same graphic.
How to Adapt to Changing Connections
The primary router on my local network is an Arris model: it comes from Spectrum as part of its Internet connection and services. I’ve not figured out how to forcibly reset its address tables for DNS lookups on Windows machine names. Instead, I use NirSoft NetBScanner when an RDP connection fails and enter the correct IP address instead of machine name in its “Computer” data field. This works every time.
By observation, it looks like this data updates every 24 hours or so. If I leave the RDP connection unchanged (no switch from Wi-Fi to GbE, or vice-versa) over that interval, nslookup eventually matches the current address. But at least I now know why this is happening, and why using the IP address for the NIC in use fixes the issue.
That’s the way things go here in Windows World, where I still manage to surprise myself by relearning the obvious. Sigh.
Here’s an interesting discovery. Or maybe it should be called a “realization.” Yesterday, upon trying out my new Belkin and CalDigit Thunderbolt 4 docks, I learned that USB-C port choice really matters. In fact, my reported GbE issues with the Belkin Thunderbolt 3 port are probably related. Please: let me explain…
Why USB-C Port Choice Really Matters
Simply put, if you plug a dock into the upper USB-C port in the Lenovo X12 hybrid laptop it works as it should. Plug it into the lower USB-C port and the GbE connection disappears. Also, the device does not show up in the Thunderbolt Control Center app, either.
The Ethernet controller built into the CalDigit unit depicted in the lead in graphic is an Intel I225-LMvP. When the unit is plugged into the upper USB-C port it appears in Device Manager. If plugged into the lower USB-C port it does not.
When I plug the dock into the lower USB-C port, it vanishes from Thunderbolt Control Center, which then shows no attached devices. Interestingly, Windows still finds attached storage devices. But wired networking through the dock no longer works.
What Does It All Mean, Mr. Wizard?
What it means is that on this Lenovo model, only one of its two USB-C ports also supports Thunderbolt (and it’s version 4, interestingly enough). Here’s my clue from the product family specifications page, which reads as follows under “Ports/Slots”:
USB 4 Type-C with Thunderbolt™ 4 (DisplayPort, Power Delivery and Data Transfer)
USB 3.2 Gen 2 Type-C
The reason why storage keeps working, but why networking and video — and presumably other high-bandwidth connections — do not, is because Thunderbolt support is required for such things. If I’d still had a monitor attached to the X12 (I sent it off to school with my son) I might have figured this out faster. But now I know . . . and so do you! And it goes to show that sometimes, where you plug in really matters, even if the “gozintas” look the same.
OK then, we’re sending my son off to college where he will have both a portable laptop (going with him) and a more powerful desktop (shipped in advance). Inspecting travel cable bag contents to take inventory, I find the following items:
2 2.4 Amp iclever dual USB port wall chargers
2 USB-A to lightning cables, 10 ft
1 USB-A to lightning cable, 2 ft
1 USB-A to USB-C cable, 2 ft
1 USB-C to USB-C cable, 2ft (for next item)
Sabrent USB-C NVMe drive enclosure PCIe x.3
1 RJ-45 Cat6e network cable, 6 ft
The whole thing weighs in at 795g (1 lb 12 oz). It fits nicely in the front pouch of my soft-sided Targus computer briefcase when we go on the road. I bought a duplicate for the boy to take with him to school.
After Inspecting Travel Cable Bag Contents…
We’re usually charging stuff — phones, mostly — until we go out the door, so the cable bag is one of the last items to go into my briefcase. Please note: the image serving as the lead-in graphic obviously belongs to an Apple-head. While we do all have iPhones (and thus, lightning cables) the rest of our stuff is Windows centric. So the picture doesn’t show the local story. I just grabbed it from Amazon for eye-candy.
This time out, the travel briefcase will start out with 3 laptops: my work unit, another for other family members, and the laptop for school use. Those items are, respectively:
A Lenovo X1 Extreme, i7 32 GB RAM, 1.5 TB across 2 SSDs
A Lenovo Yoga 7i 14″, 16 GB RAM, 1 TB SSD
A Lenovo X390 Yoga, 16 GB RAM, 1 TB SSD
It will probably make the TSA guys wonder why we need 3 laptops when we transit the x-ray machine tomorrow. It is what it is, and I’ll just have to tote the weight until we can do a little lightening when the boy heads off to his dorm on Sunday. Please: wish us all luck! Some of us may need it more than others, but you can never have too much…
There are two flavors of Realtek Audio drivers for Windows 10 and 11. The most prevalent are the High Definition Audio (or HDA) drivers. The less prevalent but slightly more capable are the Universal Audio Drivers (UAD). Confusingly, these show up in Device Manager as Realtek(R) Audio. More properly that would be Realtek® Audio, but DevMgr apparently doesn’t do metacharacters like the registered trademark symbol (®). Whatever you call it, the Realtek Audio Console Goes MIA in the MS Store.
Knowing When Realtek Audio Console Goes MIA
One used to be able to access this app through the Microsoft Store. No longer. Confusingly, the app says Realtek Audio Console in its title bar, but the Store listed it as Realtek Audio Control. Thus, for example, if you visit it at MajorGeeks.com (a usually safe and reliable download source), its Microsoft Store download link is broken. Likewise, a direct search at the Store produces no results. Ditto for a search at the Realtek downloads page.
Thus it looks to me that it’s at least possible that Realtek is de-emphasizing the UAD side of its audio drivers. In the absence of statements of direction or intent, it’s only possible to speculate. But it looks to me like UAD drivers and the app console may be orphaned, and no longer supported.
A Driver Search May Tell…
In looking at UAD drivers for Realtek, I see only Nahimic variants for the last half-dozen versions at Station-Drivers.com. None of these work with the plain vanilla FF00 audio codecs on my now-aging Z170 Skylake motherboard. I do have a B500 AMD rig that supports this Nahimic stuff, though. In a couple of weeks, I’ll probe this mystery further and see if the Audio Console is available (and working) for that set-up.
Right now, I have a working UAD set-up with drivers that are now about a year old (version 9215.1, dated 8/3/2021). I have been unable to find any newer variants that work. Ditto for a newer version of the Realtek Audio Console (or Control). Very interesting!
For the past couple of years I’ve been learning — and using — the Microsoft package manager, Winget, It helps me keep my PC apps updated. Just recently, I’ve learned to exploit Winget include unknown syntax to broaden its coverage. Basically, this will “upgrade packages even if their current version cannot be determined.” That quote comes from the upgrade command section of the MS Winget documentation.
How to Exploit Winget Include Unknown Syntax
First, that syntax couldn’t be simpler: just add the string --include-unknown
to the usual invocation for winget . For the record that’s winget upgrade --all
. This tells the program to apply upgrades for all packages with known versions. You can see this at work in the lead-in graphic for this story, in fact. Chrome shows up when unknowns are included, but not otherwise. (Compare top and bottom sections, or view the image full sized by clicking the following thumbnail.)
The difference between the unadorned “all” version of Winget upgrade and the one with unknowns included applies in large part to applications like Kindle, Chrome, Firefox, and more, which apparently do not report their current version numbers either consistently or well to Winget during its initial survey phase.
This addition to the command finds those things and attempts to upgrade them. Certain apps — most notably Teams — will not work with this tool because of version mismatches (and the prudent decision not to overwrite versions outside the same version tree). But this does improve its overall coverage. That lowers the number of apps and applications I must update manually. To me — and to you, too, I bet — that’s a good thing!
Note: Winget works in PowerShell with equal facility for both Windows 10 and Windows 11. It’s become one of my go-to tools for keeping my small fleet of PCs (currently numbered 12, with 2 going off to college with my son soon) up to date.
Here’s an interesting tidbit that’s making the rounds right now. KB5012170 appeared on August 9 on the latest Patch Tuesday. According to various sources — see this Neowin story, for example — some users’ PCs boot into BitLocker Recovery after the mandatory post-update restart, rather than business as usual. Thus, applying KB5012170 can provoke BitLocker Recovery (though unintentionally).
Of those affected, some have been able to get back to rights by applying the PC’s BitLocker Recovery key. Others have had to update their UEFI before that key application “takes.” In my case, I apparently dodged that bullet, because none of my production Windows 11 machines (four Lenovo laptops of various descriptions, and a Ryzen 5800X desktop) fell prey to this gotcha.
You can see the “success” report for this KB item boxed in red in the lead-in graphic for this story, in fact…
If KB5012170 Can Provoke BitLocker Recovery, Then What?
BitLocker keys can be stored in at least three ways. 1. On paper, 2. Electronically (usually on a USB drive). 3. Associated with a specific MSA (Microsoft Account). I prefer method 3 because it’s easy to set up and MS manages it automatically on your behalf.
You must log into your MSA online (I go through account.microsoft.com). Then go to Devices, and pick the affected PC. Next, click on Info & Support. There you’ll find a Bitlocker data protection item that includes a link to “Manage recovery keys.” That’s what you want. It will show you recovery keys for all the devices associated with that MSA (I show 11, of which I’m actually using 2, so I just got rid of the rest after saving a backup copy to an encrypted disk).
BTW, that means it’s essential to add all devices you might ever want to recover to your chosen MSA. Do so right away, if you haven’t already!
Drat! In jacking around with my Belkin Thunderbolt 3 Dock Plus today, I couldn’t help but notice that the wired Ethernet port wasn’t blinking. Further testing included multiple cables and connections to the same port, none of which worked. When I tried a passive Thunderbolt 3 mini-dock in the other USB-C port on the Lenovo X12, that wired Ethernet port worked immediately. Thus, I can only conclude that Thunderbolt Dock loses GbE port is the right diagnosis. Sigh.
Note: The lead-in graphic for this story shows the rear view of the aforementioned Belkin device, with its RJ-45/GbE port at the left. No blinkin’ lights, man!
If Thunderbolt Dock Loses GbE Port, Then What?
For the time being, I’m using another dock — the Thunderbolt 3 Minidock — just for its RJ-45 GbE connection. Good thing my X12 Hybrid has a spare USB-C/Thunderbolt port, eh?
Longer term, I’ve already contacted Belkin about sending me a replacement. They’ve got a nice looking Thunderbolt 4 dock for sale now, so hopefully they’ll ship one my way. I’ve also gone ahead and ordered the CalDigit TS4, reputedly one of the best Thunderbolt 4 docks on the market today.
Thunderbolt 4 Docking Brings Other Benefits
Acquiring one or more Thunderbolt 4 docks will also help with my ongoing testing of NVMe SSD enclosures. As I reported a few days ago, switching from USB-C/3.1 or 3.2 to Thunderbolt 3 makes a difference in IO performance on my fastest SSD enclosure/drive combos. I’m curious to see if a bump to Thunderbolt 4 will make any additional difference.
According to what I read, throughput doesn’t vary that much for external drives from Thunderbolt 3 to 4. I’ve also observed that synthetic IO tests (e.g. CystalDiskMark) tend to overstate the real-world speed-ups available from faster buses. Thus it will be interesting to observe exactly how much difference the bump from 3 to 4 makes.
Stay tuned! I’ll let you know what comes of that testing. Should be fun!
Today could be a red-letter day for me. I’ve finally figured out how to use an MSA (Microsoft Account) to login to RDP on certain “problem” PCs. I even now understand what made them problematic, and how to fix things. And in the process, my odd MSA RDP login issue resolved itself. Hooray!
Let me explain an odd combination of circumstances that caused this situation to show up on certain laptops. Buckle up: it’s a bit convoluted.
Here’s the deal: for RDP to be able to use an account/password combination for remote access, that hashed data must be in the target PC’s password cache. If one only logs into that PC directly using a PIN, Windows Hello (or other biometrics), or a security token, that data never hits the cache. If that data isn’t cached, the remote login can’t authenticate and you can’t get into the PC that way. The local account technique works because it does have that data available, and thus it can serve to let the remote user in.
Where Things Get Interesting…
There’s a high-security Account setting in Windows 10 and 11 that falls under Settings → Accounts → Sign-in options that reads “For improved security, only allow Windows Hello sign-in for Microsoft accounts on this device (Recommended).” If you elect this option, you cannot login to that PC using a password. If you can’t login to the PC using a password, that info can’t make it into the cache. And then, as a side-effect, you can’t use that account to login to RDP.
So I had to disable the option, and use the password to login locally for my chosen MSA. After a restart, I was indeed able to use that same MSA and its associated password to login to a remote session using RDP. Then I re-enabled the option and proceeded on my merry way. Problem FINALLY solved!
Just goes to show: if it ain’t one thing in Windows, it’s almost always something else. And this was “something else” indeed. Glad to have it fixed, and somewhat better understood…
I have to laugh. I found myself trying to save a screen capture in Windows 11 on the X390 Yoga just now. The WinKey+Shift+S sequence brought up the Snipping Tool notification header, and it let me navigate to pick rectangular or free form area, windows and so on. But the save notification didn’t open and I couldn’t find any saved files anywhere. This had me looking for a snipping tool save fail fix so I could make screenshots from that PC. The answer proves maddeningly easy, but maddening nonetheless. Let me explain…
The control would pop-up, but once a save mode was selected, nothing showed up for me to save. Decidedly odd.
OK Then, What’s the Snipping Tool Save Fail Fix?
As an app, I went to the Store to see if it needed an update first and foremost. Nope that wasn’t it. But when I entered the app name in full “Snipping Tool” I got its Store window with an Install button showing. WTF?
Of course that means, for whatever reason, Snipping Tool was NOT installed on that laptop. And indeed, as soon as I installed it, the key combo worked just like it’s supposed to. Then indeed, the notification item shows up and I was able to start saving screencaps. Easy-peasey, right? Yeah, sure, but I don’t undersand why the app went MIA in the first place.
Don’t Overlook the Obvious…
It’s just a reminder that when apps get — or in this case, seem — flaky in Windows (and this applies to both 10 and 11), it’s best to check from the ground up. Though I didn’t expect this built-in app to be MIA, I quickly ascertained that’s exactly why I couldn’t get it to work. I guess that proves it’s hard to use something, if it’s not installed. Go figure!
At least I can console myself with the understanding that visiting the app in the Store is a smart and sure check on its functionality. In this case, that check led me directly to a quick and workable fix. Sigh.
This is too cool. I’m finally starting to make sense of how to get the best performance out of external NVMe-based storage devices. As far as I can tell, bus speed is key. In fact, Thunderbolt turns up NVMe IO speeds. I apparently have only one laptop that’s new enough to show off the difference, but those results speak for themselves.
It also took me a while to lay hands on an NVMe enclosure that could deliver the performance goods. If you look at the lead-in graphic above, you’ll see two sets of CrystalDiskMark results from the same storage device and PC. The left-hand set comes from a USB-C port (USB 3.2, according to the Lenovo Yoga 7i specs). The right-hand set comes via a Belkin Thunderbolt 3 dock with the NVMe enclosure snuggled into one of its two available USB-C ports.
Showing That Thunderbolt Turns Up NVMe IO Speeds
The graphic speaks for itself. It shows speed boosts that range from ~2.5 X (Read SEQ1M Q8T1) to ~1.2X (Read RND4K Q1T1) faster for Thunderbolt versus a direct USB-C connection. I’m going to spring for the CalDigit Thunderbolt 4 dock, in the belief that it will improve speeds still further. Time will tell if that’s wishful thinking or actually worthwhile.
I can tell you this much from direct observation. Through the USB-C port on the Lenovo Yoga 7i, Macrium Reflect takes 4:03 to make an image backup (with reported read/write speeds of 7.6 and 7.2 Gb/s, respectively). Through the Thunderbolt 3 dock the same device takes 3:33 (with reported read/write speeds of 8.6 and 6.9 Gb/s). The former is what I would call “reasonably speedy;” the latter is 14% (30 seconds) faster.
I’m not sure that’s a big enough difference to count. You tell me…
Heat Can Be an Issue
Running backups back-to-back also showed me that heat can be an issue if you drive an NVMe SSD hard in an unventilated metal enclosure. So I parked the aluminum case on an ice-pack and it sailed through repeated backups with a reported temp of 13 C. Where there’s the will, there’s almost always a way! LOL