A little over two weeks ago, I found myself dealing with a suddenly non-functional Caldigit TS4 dock. This morning, I finally figured out what I’d been doing wrong. There’s one and only one high-wattage USB-C connector on the TS4. And there’s one and only one USB-C connector on most of my Lenovo laptops that will accept power and signals. The short explanation is: I hooked the wrong “gozouta” into the wrong “gozinta.” Net result: signals, but not enough power to make things work. Doh! Thus, this gets my recent CalDigit Hiatus finally illuminated.

Caldigit Hiatus Finally Illuminated, Literally

If you look at the lead-in graphic, you’ll see that the leftmost USB-C port on the back of the CalDigit is labeled “Computer.” It’s the port that delivers up to 98W of power to a PC, along with TB4/USB4 capability. I had somehow gotten my ports wrong, and used the middle one instead. Not paying sufficient attention? Guilty as charged. The red-boxed USB-C is the proper gozouta for the Caldigit hub.

Likewise on my Lenovo Yoga 7 14ITL5 (specs are PDF formatted), the left-hand USB-C port is also the only one that accepts TB4/USB4 and power together. Thus it’s the proper gozinta for the laptop in question.

Sigh. Put the right ports together and everything works just fine. Put the wrong ones together, and the PC doesn’t get enough power to run properly, nor for the TS4 dock connections to work as expected. Sigh again: it’s not hard to get the obvious wrong, but it can be challenging to recognize the obvious if one’s wits aren’t entirely engaged.

For This, I  Contacted Tech Support?

Yes, I admit it: I did that. And we all assumed I was using the right ports. Thus, they were as baffled as I was by what the lack of a power light really meant. Now I know: the light comes on when you use the high-wattage USB-C port to run power into a PC or laptop. And when you set the connections up as they should be, everything works likewise. Go ahead: laugh! Once I got over my astonishment at missing the obvious, that’s what I did too.

Last week, I ran an experiment Monday through Friday. Each day, I made sure to use winget upgrade and Software Update Monitor (aka SUMo) to check updates on 9 PCs here at Chez Tittel. I kept track of how many updates each tool found in tabular form. In each daily data cell, the first value counts updates winget found, and the second value counts updates SUMo found. It was interesting and unexpectedly time-consuming (averaged 75 minutes each day). It does give me a better sense of Windows application update rhythms, though.

Checking Windows Application Update Rhythms

The  9 machines in my sample included 1 4th-Gen CPU and 1 6th-gen Intel CPU (both perforce running Windows 10). All but one of the other machines run Windows 11, and all but one are 8th Gen Intel CPUs or higher (the hold-out runs a Ryzen 7 5800X). Each machine runs anywhere from 24 applications listed in SUMo to as many as 62. In the results table, an “at sign” (@) means that either Winget or SUMo recommended an update that I couldn’t install (winget) or find (SUMo). That latter one proved time consuming indeed.

Table of Results

A total of 131 updates were put forward by one or the other tool last week, for an average of about 14.5 for the week for each PC. The range of values went from a low of 8 to a high of 24.

What this tells me is that tracking updates could be a constant effort, were one minded to invest the time and energy. It also shows that the pace of updates is pretty brisk, and somewhat relentless. This makes it very clear why, except for emergency security patches, most organizations of any size prefer to limit updates to scheduled windows of fixed duration.

Otherwise, it’s the kind of rabbit hole into which admins could disappear, never to be seen again!

In early January, I wrote about Intel’s Unison app as a possible “killer app” for Windows 11. Why? Because it provides an app that (sort of) integrates the iPhone with a Windows PC. Now, MS is jumping into the game. Tuesday’s “Moment 2” announcement includes mention of a new connection for iPhones into the previously Android-only Phone Link app. And wouldn’t you know it? MS phases iPhone support into Phone Link for Dev Channel Insiders, and I’m not among those to whom this capability is currently extended.

Waiting as MS Phases iPhone Support into Phone Link

If you check the lead-in graphic, you’ll see that iPhone is now mentioned in an early Phone Link setup screen. But unless your PC is offered that functionality, that entry reads “iPhone® – Coming soon” in greyed-out text (see red box at lower right). Indeed, that means I’m waiting for one or both of my Dev Channel test machines to get the offer, so I can try things out.

Like Intel Unison, what I read about this capability is that it uses a Bluetooth link (and works only on Windows 11). Thus I make the same plea to MS I made to Intel: “Fix the app communications stack so it can use a wired connection — e.g. Lightning or USB-C cable — as well as Bluetooth.” To my dismay, I observed that Unison would quit working as soon as I plugged into my iPhone 12 by wire.

Other limitations include no support for MMS or SMS attachments. Those, I guess I can live with. I can always move stuff over after the fact for such things if I plug in a cable, right? LOL

Tick … Tock … Tick … Tock

But for now I’m waiting for the offer to hit my test PCs. It’s welcome news in a Windows-iPhone household like the one here at Chez Tittel. Soon, I hope to be able to see how well it works. Stay tuned!

I’m flummoxed. As part of my production PC repairs the other day, I ran an in-place upgrade install. It didn’t fix my problem, but it ran to reportedly successful completion. Here’s the thing: I used a Windows 10 Pro image for build 19045.2546 (from UUPdump.net) to make those repairs. I’m surprised it worked!

Why Say: Win10 Enterprise Image Repair Mismatch?

As you can see in the lead-in Winver graphic, this PC is clearly running Windows 10 Enterprise (2nd text block). Yet the filename and download info at UUP Dump clearly identifies the Windows version as Pro:

19045.2546.230118-0641.22H2_RELEASE_SVC_PROD3_CLIENTPRO_OEMRET_X64FRE_EN-US.ISO

Targeting install.wim from the Sources directory, DISM unambiguously identifies the Windows version as Windows 10 Pro.

Yep: it definitely says the image is Windows 10 Pro.

IDKYCDT

IDKYCDT = “I didn’t know you could do that.” But apparently, you can. Indeed the MS Answers advice on this technique says only that one must

download the latest .ISO file available for Windows 11 or Windows 10.

It says nothing about version. Likewise, the TenForums tutorial on this topic simply says

• If you have a 32-bit Windows 10, then you must use a 32-bit ISO or USB.
• If you have a 64-bit Windows 10, then you must use a 64-bit ISO or USB.

Again, there’s nothing here about version, simply that a valid ISO is required. I don’t where I got the idea that the version and kind of ISO used for repair had to match the repair target. But it does NOT have to match. I got explicit evidence to the contrary earlier this week with my own eyeballs, on this very PC.

Thus, I learned something useful and can pass it on to you, dear reader. Any valid Windows 10 ISO works for Windows 10; ditto for Windows 11. Cool!

This is actually pretty handy because you can use UUPdump.net to cobble together an image for the current build number for Windows (10 or 11) including all recent updates and CUs. Then, when you repair the image it should work for Home, Pro, Education and Enterprise even if you — as I did — download the Pro-only ISO. No further updates will be required, when that repair completes.