OK, then. I think I’m at the end of a long, long road. I remember buying my Surface Pro 3 in 2014. It was the first in a long series of tablet PCs I’ve bought over the years. Included were models from MS (Surface), Dell (Latitude), Fujitsu (Stylistic) and Lenovo (ThinkPad). But now, it’s time for me to say: “So long Surface Pro 3.” Please: let me explain what’s going on…
Why It’s Time for So Long Surface Pro 3
This morning when I logged into my network, I noticed the SP3 had switched over from the wired GbE port in the dock to its wireless interface. It’s been dropping this wired connection for months now. As (almost) always, a reboot brought the wired interface back up. But I can tell the dock is starting to fail.
I just spent US$19 last week to replace the power supply brick for the dock. But I hesitate at replacing the dock outright (costs about US$100 for a refurb unit). It’s time to quit futzing around with this old beast, and unload it into proper disposal channels.
Where to Take This Aging Beast
For years, I’ve given my older PCs to Reglue, a charity that placed them in the hands of under-served students and their families to confer low-cost/no-cost Internet access. But alas, the founder of that organization has retired and is no longer accepting donations.
For about the same period of time, I’ve recommended Goodwill as a safe, responsible drop-off for used PC electronics of all kinds. Thus, I’m glad to see that the Austin Reuse Directory likewise recommends Goodwill for such purposes. I’ve already got a Goodwill bag going with some old hard disks, memory modules, cables and interfaces ready for drop-off.
I’ll need another bag for the SP3 and its accoutrement, though. I’ve accumulated a major mound of stuff for this unit over the years. This includes:
- an MS keyboard with fingerprint reader
- the dock, with its external power brick
- the original power brick shipped with the SP3
- a Brydge aluminum keyboard that turns the SP3 into a clamshell style laptop
Another thing to take care of this weekend, when out running errands and shopping. Good thing my nearest Goodwill location is only 3.2 miles away!
In surveying my PCs this morning, I learned it was time to update the Intel PROSet software. This remains an entirely routine matter. It’s easy if a bit time-consuming to accomplish. Hence, I’m pleased to find Intel PROSet still ticking along. I have an admittedly small population of PCs (11 in total right now). Of those 6 show Intel interfaces in Advanced IP Scanner. I’m aware of at least 3 more Intel interfaces that don’t register on its scans. (Example: my Asrock Z170 motherboard has two Intel GbE interfaces: an I-211 and an I-219V.)
If Intel ProSet Still Ticking Along, Then What?
The download/install routine is pretty straightforward. Search Intel Downloads/Drivers&Software for the string “Intel Ethernet Adapter Complete Driver Pack” (for wired Ethernet). or for “PROSet wireless” (for Wi-Fi connections). Either way, you’ll get a ZIP file out of the download. Unpack it to a folder of its own, and you can use the autorun.exe file therein to perform installations for drivers (if applicable) and the latest PROSet software version (22.214.171.124 for wired; 22.190.0 for wireless).
Note: Don’t ask me why the window shown above reads “intel Network Connections.” It’s been that way for a long, long time. If memory serves — and this goes back far enough that it may not serve very well — this used to be the general description for intel network drivers and software before PROSet came along. But that’s what it says, no matter if my recollection is correct or not.
The lead-in graphic shows the wired package, as you can see from the version number at the lower right of that image. The whole update process took less than 5 minutes on each of the affected machines. If you unzip the contents of the download to a shared drive, it works like a charm for all PCs on an accessible network.
It’s Easy to Get Lost in the Weeds
There are tons of advanced settings for Ethernet (especially wired GbE or higher speeds) available. PROSet provides access to such things pretty directly, or you can go through the Advanced Properties tab for the target interface in Device Manager under the Network Adapters heading. All-in-all, PROSet is a bit less unwieldy to use than DevMgr (where it is available).
So if one needs to monkey around with such things, I find PROSet preferable for such shenanigans. If you’re not already using this tool and you’ve got Intel interfaces to manage, give it a try.
I remember the networking wars of the late 1980s. That was when Token Ring, ARCnet, LocalTalk and other physical media vied with Ethernet for market- and mindshare. Indeed, I’ve worked with versions of Ethernet all the way back to 10Base2 and 10Base5. Thus, I successfully upgraded the Wi-Fi drivers on my 2018 vintage Lenovo ThinkPad X1 Extreme (running Windows 11) with bemusement and appreciation minutes ago. Based on how earlier Windows versions worked, there was surely some remote Wi-Fi driver update magic involved.
The lead-in graphic is the Intel installer pane that announces a successful Wi-Fi driver install. What’s interesting about this? It’s inside a Wi-Fi based RDP session. I’m working on my production PC via Remote Desktop Connection to the X1 Extreme. It restored itself automatically once the driver install finished. It came back up, even though the connection dropped as that update occurred. No working driver means no Wi-Fi during the switchover from old to new.
What Makes Remote Wi-Fi Driver Update Magic Happen?
Good question! RDP apparently recognizes enough about the dropped session to bring it back to life. And FWIW, that occurs during the first “retry” — by default, RDP attempts resuscitation up to 5 times — without undue muss or fuss.
What makes this noteworthy? I can remember that even Windows 7 could not restore RDP sessions dropped during driver updates. Windows 8 (and 8.1) were hit or miss. It’s only since Windows 10 came along in 2015 (General Availability: 7/29/2015) that this capability has been both mainstream and dependable.
Once upon a time, Wi-Fi driver updates meant the end of open RDP sessions. Recovery was impossible: the only way back in was to fire Remote Desktop Connection up, and start afresh. It’s a small thing, really, but one I’ve learned to appreciate in modern Windows versions.
Modern Wi-Fi testifies to robust and practiced driver design. Indeed, it keeps working in the face of many predictable difficulties. Replacing drivers is a case in point, but Wi-Fi just keeps on chugging along. And that’s despite various source of interference, occasional hiccups with power, wireless gateways, and more. Having followed the technology as it’s grown and sped up I’m grateful it works well.
For years now, I’ve been a huge fan of Nir Sofer’s software tools. Along the way, I’ve often used his NetBIOS Scanner (NetBScanner). It shows me which IP addresses Windows PCs occupy. Two weeks ago, I noticed PatchMyPC supports a tool named Advanced IP Scanner. I’ve now tried it out. I can say I totally find Advanced IP Scanner worth using. It appears as this story’s lead graphic, in fact.
This NetBScanner output shows only Windows and other devices with NetBIOS names; Advanced IP Scanner (top) shows EVERYTHING IP.
If Advanced IP Scanner Worth Using, What About NetBScanner?
Once I started using the former, I immediately saw the limitations of the latter. Simply put, NetBScanner shows only 8 entries; Advanced IP scanner shows 18. It even includes devices that lack NetBIOS names but participate in the LAN (e.g. my ASUS WAP, my thermostats, and my TV). Better still, it shows the IP addresses that some of my PCs (laptops, mostly) use for Wi-Fi and GbE, along with which one is live at present and which one is unused (e.g. X380).
There’s more: as I was troubleshooting my PING and RDP issues earlier this week, I learned to make use of the right-click tools it offers for devices whose IP addresses it shows. You can access its maker’s own Radmin utility to jump directly into its version of remote administration of anything showing.
To me, though, the right-click Tools menu is both interesting and helpful. Shown above this paragraph, it lets you run a variety of commands in a cmd.exe window against the highlighted item. I used it to run PING tests point-to-point on my LAN and eventually got everything working. It also turns out to be a handy way to launch RDP as well.
Remember: Cools Tools Rule
I’ve come to like this free, informative and easy-to-use utility enough to add it to my top tier Windows tools collection. I call these “Cool Tools.” For me, they are essential items in my administration and troubleshooting toolbox. If you try Advanced IP Scanner out, I predict you’ll want to add it to your lineup, too.
Apocryphally, PING stands for “Packet InterNet Groper” (or perhaps, “Packet Inter-Network Groper”). Actually, I think it comes from submarine-speak. There, a PING denotes the return sound that sonar makes when reflected. I’ve been troubleshooting a persistent RDP issue with the Lenovo P360 Ultra SFF PC. En route, I just fixed an inability to PING that node. Changing Advanced Sharing All fixes PING, as far as I can tell. Deets follow…along with an RDP fix.
Why Say: Advanced Sharing All Fixes PING?
First off, I relaxed all entries under the “All Networks” heading in Advanced sharing settings (Control Panel). Then, PING started working on the P360 Ultra. Easy-peasey, but not terribly safe.
Interestingly, I then went back and changed the settings to their defaults. That’s “the other option” in all thee cases shown. PING kept working, but the sharing was tightened back up.
Comparing P16 and P360 Ultra
What’s even more interesting is that the other “new machine” here does RDP and PING just fine. That’s the latest Lenovo Loaner here at Chez Tittel: the P16 Mobile Workstation. I’ve had no issues with networking and RDP on that other machine. But I was still unable to remote into the P360 Ultra.
I switched to the Remote Desktop app, and got a more informative error code: 0x4. In researching possible fixes, I found a reghack under that heading at TechDirectArchive. Since I’d already tried everything else recommended in that story, I tried that too.
Here’s the Remote Desktop app with the P360 Ultra under its wired IP address: 192.168.1.192. Problem solved!
It had me create a new Regkey named MaxOutstandingConnections in HKLM\CurrentControlSet\Control\Terminal Server. As suggested, I set its value to 0x10000. And guess what? Both the Remote Desktop Connection application (mstsc.exe) and the Remote Desktop app (show above) now work!
Go figure. All I can say is “What a relief!” It’s been driving me bananas…
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.
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…
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!
OK, then. Yesterday, we spent a small fortune packing up and shipping out a tower PC and 27″ monitor to my son’s college address. In the aftermath, I moved the other B550 tower with Ryzen 5800X upstairs to his room. But alas, because I left the high-end, PCIe WiFi card in the shipped-out unit, I couldn’t get any of my plug-in (or built-in) WiFi devices to connect to the Spectrum router. Hence my claim that signal strength impedes swapped PC WiFi access.
Overcoming Signal Strength Impedes Swapped PC WiFi Access
There’s a whole litany of checks I ran through to see if I could get such WiFi devices as were at my disposal working. The PC could “see” the Spectrum router. Alas, it just couldn’t connect, not using any of the following:
- A 5-year old Asus 802.11ac USB 3 (USB-AC 56) device with external antenna
- A similar vintage NetGear 802.11 ac USB 3 (AC 600) device with no external antenna
- The built-in M.2 slot with a non-Intel 802.11ax mini-card (but no external antenna)
I worked through all of the following checks, too, just to cover all the bases:
1. Reboot PC to reset startup network settings
2. Ran the network troubleshooter
3. Enable/disable device drivers in Device Manager
4. Reset Network Settings as per ElevenForum Reset Network Adapters in Windows 11 tutorial
No joy on any of these, though. Sigh.
An Alexandrine Solution?
Eventually, I installed a switch at the RJ-45 wall jack upstairs, then ran a long cable from that switch into my son’s bedroom to give him a direct, wired Internet connection. Of course, that worked right away once I’d gotten all the pieces and parts plugged in properly.
The story does have a happy ending, though. Check out the Fast.com speed test results I obtained after setting up the wired link into that PC. This is the fastest I’ve ever seen on my LAN.
I didn’t realize the Spectrum router could exceed 1 Gbps on its end. This PC has a 2.5 GbE interface, so it’s capable enough. But given a GbE LAN exceeding the speed limit makes me wonder…
Earlier this week, MS released Build 25158 into the Dev Channel. Among the many notes in this build’s announcements, you’ll find an item that starts off “DNS over TLS testing is now available for Windows DNS client query protection.” Thus, when Build 25158 gains DNS over TLS support, that means improved security for DNS traffic on networks everywhere. Given that DNS is a constant focus for direct and indirect attack, this is a good thing. So, how can you try this new feature out?
Putting Build 25158 Gains DNS Over TLS Support to Work
For brevity and convenience, DNS over TLS is usually abbreviated as DoT. Two ingredients are needed to take DoT for a spin:
1. You need to point your IP stack at a DoT DNS server. You’ll find a list of same at the DNS Privacy Project. It provided the lead-in graphic for this story, in fact. For the nonce, I’m using Google’s 126.96.36.199 and 188.8.131.52 addresses (and associated domain names for certificate authentication). There are several other options available.
2. A series of configuration tweaks, including Settings changes, and netsh and ipconfig commands, are required to set this up and make it work. Fortunately, all those details are covered in an MS Networking Blog post entitled “DNS over TLS available to Windows Insiders.” Therein, Tommy Jensen provides nicely illustrated step-by-step instructions to get you through the process.
More to Follow After Additional Try-Outs
I have two (2) test machines running Build 25158. I’ll try DoT on both of them, and let you know what happens. Mr. Jensen’s post on setting things up includes a potentially scary phrase. That is “This may result in a small performance improvement depending on the network environment at the cost of the flexibility HTTPS-based protocols can provide” (italic emphasis mine).
I’m afraid I know what this means. Indeed, I’ll be curious to see what’s still working — and what’s not — after experimenting with these changes. Given an upcoming out of office adventure, I might wait until week after next to put this to a real test. Stay tuned! In the meantime, you might find this Wikipedia article about DoT worth a quick read-through (good discussion and lots of good additional references there).