In perusing my usual newsfeeds this morning, I saw what looked like an interesting story. It says something like “Use the MCT to Get Win10 May 2019 Update without Insider signup.” (Check that link to get the full title, please.) But the story promises more than it actually delivers. Yes, it turns out there’s a download link to a file named MediaCreationTool1903.exe. But if you actually grab that file, and start looking at what’s inside, you’ll see that MS hasn’t yet made the right behind-the-scenes connections. It’s actually the same ISO you’ll get if you visit the Download Windows 10 page at Microsoft (17763.379, to be more precise).
The filename looks tantalizing, but there’s nothing new under that hood . . . yet!
Why Say MCT1903 Misnomer Not Available?
More than mildly curious, I downloaded the MediaCreationTool1903.exe file. I took the option of saving the files it proffers in ISO form. I named that ISO Windows1903MCT.iso just to make it easy to identify. But after mounting that ISO to drive N:, I ran DISM against the install.esd it includes in its /Sources folder. Index 6 covers Windows 10 Pro, and here’s what I got in response to the DISM command shown:
The MCT may be labeled 1903, but the contents are indisputably 1809. Sigh.
Is this a Put-up Job?
I imagine some enterprising Windows-head found this file by presuming it existed, supplying the URL (the same one linked in paragraph 1), and grabbing same. But MS has obviously not yet made the right connections for this tool to grab the 1903 release. The obvious reason why is because it’s not released yet, so those connections haven’t yet been made. So no, it’s not a put-up job. It’s just not ready for prime-time/real use just yet. The existence of the file is simply indicative that someday in the near future (before the end of May) it will actually work the way it’s should. But in the meantime, steer clear.
A funny thing happened when I upgraded my Surface Pro 3 to the latest Release Preview. I’m talking Build 18362.53, otherwise known as 1903 aka May 2019 Update. Before the upgrade, the PC saw its SDXC card and contents without issue. After the upgrade, nada. Before the upgrade, DevMgr saw something named “Richoh SD Disk Device.” After the upgrade only a generic “SD Disk Device” appears there, and it doesn’t work. I didn’t see this myself though. I got a private message from TenForums user StanP50 that asked if I could access my SDXC card under the latest build. His wasn’t working. So I checked mine, and sure enough: it wasn’t working either. And that’s what led me to the immortal question “Dude, where is my SDXC drive?”
Before the upgrade, SDXC worked fine; after the upgrade, its was invisible in Explorer and inaccessible in Disk Management.
Where is my SDXC drive, and how do I get it back?
Looks like we’ve got a specific issue here on my Surface Pro 3 (SP3). My other Release Preview laptop, a Lenovo X220 Tablet, also upgraded to 18362.53, sees its SDXC card just fine. I rolled back to the preceding version 17763.404 on the SP3, and presto! Now it sees and accesses its SDXC media correctly, too. Sigh.
I’ve reported this to the Feedback Hub as “1903 knocks out SDXC card.” If you’ve got a Surface Pro 3 with an SDXC card installed that’s running 1903, you might want to check to see if you have the same problem, too. If so, please upvote that thread.
Demonstrating the Value of Release Preview
This is just the kind of thing that a Release Preview is supposed to flush out of the woodwork. And with the actual, full-blown public release still perhaps as many as seven weeks out, MS has time to find and fix what testers report. Though it’s vexing to lose access to a device, it’s better that people who volunteer to test the software prior to public release do it, instead of the unwashed masses. Most of us testers expect a few rough spots to show themselves, and know how to report and deal with them. I have a feeling this is just one glitch among many that will be found and fixed before the end of May comes around. Relax! The system is working as intended. To me, that’s actually reassuring.
Last Friday, a couple of Lenovo loaner laptops showed up at my office. Both include 8th Generation (formerly, Coffee Lake) CPUs and Samsung OEM NVMe SSDs. As I was perusing the TenForums threads yesterday, I noticed a new version of the Samsung NVMe drivers. But my drive’s model number is MZVLB1T0HALR. It doesn’t appear in the list of supported drives on the Samsung site, either (see screencap below). That raised this very interesting question: are Samsung consumer drivers OEM friendly? I decided to find out.
Lots of familiar product names here, but they’re all consumer/retail products. Will they work for my OEM products, too?
[Click image for full-sized view; Source.]
The drives named on the preceding snip from the Samsung SSD downloads page are NVMe 970 Pro, 970 EVO, 970 EVO Plus, 960 Pro, 960 EVO and 950 Pro. My OEM NMVe SSDs are best described as “recent vintage, but none of the preceding.” This adds a certain air of mystery, or perhaps confusion, to finding out if they’ll work on those new Lenovo laptops I’ve recently been loaned.
Finding Out if Samsung Consumer Drivers OEM Friendly
Given that on both machines, I was monkeying with device drivers for their boot/system disks, I decided to take some precautions. Fortunately they turned out to be unnecessary. But here’s what I did to prepare for possible trouble, up to and including a non-bootable system:
1. I made an image backup on an external USB drive using Macrium Reflect (MR).
2. I used MR to create “Rescue Media” for each PC (a standalone bootable WinPE runtime that can read and restore MR backups).
3. I made sure I could boot to the Rescue Media on each machine, and was able to “see” the image backup device in its MR runtime.
3. I installed the new driver on my first loaner (X1 Carbon Extreme), crossed my fingers, and rebooted.
If the machine had failed to boot, I would have resorted to the Rescue Media and used it to put things back the way they were before I started messing with them. Fortunately for me (and for others who may have laptops with newish Samsung OEM drives) it worked like a champ. Here’s what I see in DevMgr on the X380 (the X1 Carbon has two NVMe drives, so it has two driver entries instead of just one as shown here):
I was mighty relieved when the X1 Carbon rebooted successfully.
Alas because there are so many (and poorly documented) Samsung NVMe SSDs out there, you can’t know if this driver will work for you unless you try. And if you do, you’d better take precautions beforehand, just like I did. That way, if you get bitten, you will still be able to restore your PC to working condition. Note also, the 950 Pro released in September 2015 (equivalent OEM model SM951). I wouldn’t try installing this driver on anything older than that, either, if I were you. ‘Nuff said!
With the release of 1903, aka Windows 10 May 2019 Update, coming soon the Insider Preview program is going through some changes. A bit of “special maneuvering” lies ahead. That is, upcoming Insider Preview changes 2020 release access methods . Those who want to stick with a true Fast Ring release — which becomes 19H2 as soon as the Windows 10 May 2019 Update arrrives — should switch to the Slow ring this week. (That means sometime between today, April 8, and Friday, April 12.) Those who want to stay one additional increment in the release cycle — namely, 20H1 — should stay in the Fast or Skipahead rings. These will merge into a single group once the next feature update becomes available.
For the next couple of weeks, and possibly longer, the Slow Ring is for checking the Release Preview, and the Fast and Skip ahead Rings are for target 20H1 builds.
Why Make Upcoming Insider Preview Changes 2020 Release Access Anyway?
I guess this is how Microsoft is reintroducing a meaningful Release Preview mechanism just before the May 2019 Update builds a full head of steam. This strategy does seem to ensure that lots of Insiders will be giving that release a serious once-over before it starts trickling into wider distribution. Given the results of skipping this phase for 1809 and the troubles that followed, I’d say MS is working diligently to implement hard lessons learned. They’re definitely NOT skipping Release Preview for this next Feature Upgrade, and this temporary changeover appears designed to make sure that the near-final bits get a maximum once-over.
FWIW, I’ve set those test machines I want to keep on leading/bleeding edge builds to Skip, and those on which I want to check the Release Preview and then go back to Fast Ring later, to Slow. You can do as you please, but hopefully, you now have some idea what that might be!
Those who want to see what Brandon LeBlanc had to say on this topic last Friday (April 5) should check out this Windows Insider blog post. According to that same post, MS “will begin releasing 19H2 bits to Insiders later this spring.” That means the Fast Ring is taking a bit of a break for a while, and will probably start back up sometime after the May 2019 Update gets going. That’s my best guess right now anyway. So, for the time being, staying Fast means going slow. And staying Fast, really means Skipahead. But this is just temporary until the dust settles from the upcoming Feature upgrade. Stay tuned and I’ll tell you when Fast really means Fast, Slow means Slow, and a difference between Fast and Skipahead is re-established. Got that? I sure hope so!
The last two Win10 feature updates (1803 and 1809) have had problems. There’s been lots of grousing from business users about updates, too. Finally, Microsoft is changing its stance on pushing updates. Hooray! In a post to Windows Blogs today (April 4), Mike Fortin (Corporate VP, Windows) announced a new approach. I take from this material the idea that MS backs off forcing updates through WU. Here’s the relevant paragraph, in all its glory:
In previous Windows 10 feature update rollouts, the update installation was automatically initiated on a device once our data gave us confidence that device would have a great update experience. Beginning with the Windows 10 May 2019 Update, users will be more in control of initiating the feature OS update. We will provide notification that an update is available and recommended based on our data, but it will be largely up to the user to initiate when the update occurs. When Windows 10 devices are at, or will soon reach, end of service, Windows update will continue to automatically initiate a feature update; keeping machines supported and receiving monthly updates is critical to device security and ecosystem health. We are adding new features that will empower users with control and transparency around when updates are installed. In fact, all customers will now have the ability to explicitly choose if they want to update their device when they “check for updates” or to pause updates for up to 35 days.
Separate controls for Feature Updates may help those who want security and quality updates, but no upgrade yet, get what they want.
[Click image for full-sized view. Source: Fortin Blog post.]
Why Say: MS Backs Off Forcing Updates?
One single line above gets my attention. It reads: “We will provide notification that an update is available and recommended based on our data, but it will be largely up to the user to initiate when the update occurs.” Two other items are also noteworthy. First, there’s a statement that “all customers” can explicitly choose to update or not. Second, they can pause updates for up to 35 days. According to Paul Thurrott, 35 days means deferring updates 7 days at a time, 5 times in a row.
What About the Next Feature Update?
It’s been renamed to the May 2019 Update in Mr. Fortin’s post. He also asserts that MS “will increase the amount of time the May 2019 Update spends in the Release Preview phase. . .” MS plans to “proactively obtain more early feedback about this release.” Good idea, especially after they skipped this step with the much-maligned 1809 Feature Update. Those in the Insider Preview/Release Preview group will get an advance look at this release starting next week. Others will be able to use “check for updates” in WU to request the new release sooner. Interestingly, customers running Windows versions at or near end of support will also get the new release pushed to them.
More Update Controls, Yes Sir!
When the new release hits it will have new and improved update controls. A new “Download and install now” option for Feature Updates will appear in versions 1803 and 1809. No doubt, that change will come through a cumulative update or a servicing stack update by late May as well. The screen cap for this blog post (clipped from the original MS post) shows what this will look like. Users will be able to use “Check for updates” without causing the Feature Update to be forced upon them. Good move, MS.
Just yesterday, MS released a new cumulative update (CU) — namely, KB4490481. For the first time in my experience, Win10 KB4490481 leaves 6 reclaimable packages behind. What does this mean? After you install this update, run
DISM /online /cleanup-image /analyzecomponentstore You’ll see something that looks like this (captured inside a PowerShell administrator session):
Notice the line in the command output near the bottom that reads “Number of reclaimable packages: 6.” In my experience, this sets a new record for detritus in the wake of a Windows 10 CU.
Win10 KB4490481 Leaves 6 Reclaimable Packages Behind. So What?
As I recite in my previous blog post, cleanup using
DISM /online /cleanup-image /startcomponentcleanup after this CU can pay big dividends. Notice the size of the item in the preceding screen capture: Backups and Disable Features. At 8.94 GB, all that goes bye-bye after the cleanup. My typical cleanup results came in around 9.5 GB, so there’s another 0.54 GB that gets whisked away from other component store nooks and crannies, too.
As post-CU clean-ups go, this one’s a biggie. In fact, it’s the biggest one I can ever remember seeing. Especially for those running Win10 1809 on small-footprint devices (tablets or laptops with limited storage of 32 or 64 GB) this maneuver seems more mandatory than optional. But even for those with system/boot SSDs of 512 GB or larger, a 9+ GB cleanup still remains significant. And, should you run into the same error I encountered when working this through on the Release Preview before it hit general distribution, my previous blog post explains how to fix that, too. Alas, though, if you’re updating only from 17763.379 to 17763.404, you’ll find only 1 reclaimable package when you run /AnalyzeComponentStore. This will recover upwards of 1.6 GB instead (because there are many fewer packages involved). YMMV, as they say on the Internet.
If all this talk about component store cleanup piques your interest — and I hope it does — here’s a great resource for further exploration. Shawn Brink over at TenForums offers a great tutorial on this stuff. Prosaically enough, it’s entitled “Clean Up Component Store (WinSxS folder) in Windows 10.” It goes into and illustrates all the relevant DISM commands in detail. It’s worth a read-through. You can even use it as a step-by-step guide to work through these commands on your own Win10 PCs. Check it out!
Generally speaking, whenever one installs a Win10 cumulative update (CU), it raises the possibility that component store cleanup should follow. How do you find out if cleanup is needed? The command
DISM /Online /Cleanup-Image /AnalyzeComponentStore when run, will recommend for or against cleanup. Lately, I’ve observed that trying to run that cleanup immediately after the restart that CU install requires doesn’t always work. Generally, a second reboot fixes DISM StartComponentCleanup nicely.
In fact, I’ll show a sequence of PowerShell screencaps that show this in action. [WARNING! Completing this cleanup often takes a long time — over a half hour on my Surface Pro 3, for example.]
How to Tell If a Second Reboot Fixes DISM StartComponentCleanup
You’ll know if you need to try a second reboot because of the error message that DISM produces for that particular command. It appears in the following screenshot:
Notice the 6824 error at bottom: “The operation cannot be performed because another transaction is depending on that fact that this property will not change.”
[Click image for full-sized view.]
Apparently, a Reboot Clears the Pending Mystery Transaction
MS Docs labels the 6824 error code as ERROR_CANT_BREAK_TRANSACTIONAL_DEPENDENCY. As far as I can tell, it means that some other OS transaction is pending. Before DISM StartComponentCleanup can do its thing, that transaction must complete. I can’t yet identify that other pending transaction. But it’s pretty clear that a second reboot handles and clears it. The second reboot lets the previously failed DISM command run unimpeded.
If you ever find yourself in this boat after installing a CU, try another reboot. It’s worked for me every time I’ve gotten the 6824 error code instead of package cleanup. It should probably work for you, too.
Here’s where I wound up with my successful cleanup, after the second reboot. Please note that after the DISM command ran for 30 minutes it got stuck on 94% complete. So I closed the PowerShell window, opened it again, and re-ran the same command. What you see below shows the strange results that ended in success almost immediately. I ran another /AnalyzeComponentStore command to get “post-cleanup” sizes. The component store dropped from 15.93 GB to 6.52 GB (HUGE: 9.42 GB), with attendant size reductions in actual size, primarily from backups and disabled features. It’s pretty unusual to see six (6) reclaimable packages after a CU, so I expected — and got — significant cleanup. Good stuff!
[Click image for full-sized view.]
Sometimes, accidental uses of software outstrip intended uses. Let me explain: my son’s PC is up in his bedroom. It’s about as far from my office as you can get in my house. Because I’m always tinkering with the PCs at home, I like to remote into them. But he’s away at school most weekdays, and out and about on weekends. So we’ve got his machine configured to go into deep sleep (S3/S5) while he’s not using it. Thus, I found myself learning how to enable the Magic Packet for Wake-On-LAN (WOL) so I can start that machine up from my office, and then get an RDP session going. In researching the topic, I stumbled across Nir Sofer/Nirsoft’s excellent WakeMeOnLan utility. In using that utility I realized it shows a list of all active IP addresses on the LAN, which makes it superior as a simple LAN scanner as well. Not only will it let me do what I want, WakeMeOnLan provides quick compact net survey. Here’s what that looks like:
Not only does it offer remote wake-up/shutdown, it also shows every device on the LAN (including our Alexa, printers, and even my otherwise unlabeled WAP). Good stuff!
[Click image for full-sized view.]
Why WakeMeOnLan Provides Quick Compact Net Survey Is a Good Thing
I’ve tried plenty of other LAN survey tools. But most of them list the entire address range from 0 to 254 with a bunch of empty entries when no device is mapped to an open IP address. WakeMeOnLan shows only occupied addresses, and thus also, shows me only what I want to see. Because I use DHCP device addresses will occasionally change. That makes this tool especially helpful when that happens to one or more of my network-attached printers, because that means I have to use the new IP address to resolve driver issues.
Others may find this tool likewise helpful and informative. Like most of Sofer’s utilties, it’s quick, capable, and easy to use. Check it out!
Man, I have to laugh! Just yesterday (March 28), John Wilcox in the MS Windows IT Pro Blog posted that “version 1809 has transitioned to broad deployment.” This occurs, just as the buzz about 1903 is starting to escalate. In fact, people are speculating that it could show up as early as next month (April 2019). Of course, we know that MS has designated this next release as 19H1. This means that it could show up as late as June 30, and still hit its stated mark. Indeed, I have to believe that with Win10 1809 designated for broad deployment, a later date now seems more likely than an earlier one. This could buy MS some apparently much-needed time, because the latest Slow Ring release (Build 18362) has been withdrawn from circulation. The latest release is waiting on pending bugfixes related to updates for Build 18356.16.
This cheerfully ominous connected cloud graphic adorns Mr. Wilcox’s proclamation of “broad deployment” for 1809.
What Does Win10 Designated for Broad Deployment Really Mean?
In the afore-linked blog post, Mr. Wilcox explains that 1809 transitions to this state “based on the data and feedback we’ve received from consumers, OEMs, ISVs, partners, and commercial customers.” My interpretation is that recent telemetry has showed fewer issues. I’d guess, too, that the volume of complaints or issues reported from those constituencies has dropped to normal levels. Thus, MS has put 1809 into full general release, 5.5 months after its initial foray. It emerged on a Tuesday; the following Friday, it disappeared (11/13 and 16, respectively).
Wilcox goes on to report that “Windows 10 Enterprise and Windows 10 Education, version 1809 will be serviced for 30 months from its November 13th release date.” Given that my last blog post featured speculation that MS is hopeful that users might skip from 1803 directly to 19H1/1903, I wonder how many Enterprise and Education users will adopt the 1809 feature update anyway. That same post also reported shockingly low uptake of 1809 at this point in the release cycle. I wonder if the transition to “broad deployment” changes that current and painfully slow uptick at all. We’ll see!
The March 2019 AdDuplex Report is out, and it tells and interesting and possibly depressing story about Windows 10 1809. The 1809 rollout has been bumpy, to say the least. As 1903 looms ahead, only 26.4% of PCs under the AdDuplex purview are running 1809. Compare this to 1803, which runs on 66.3% of that population. This leads AdDuplex to assert that “Microsoft seems to be giving up on  … in favor of upgrading users straight to the next version.” I agree. It’s also why I say that AdDuplex tells interesting 1809 story.
Note that 1803 still outweighs 1809 by a 2.5:1 ratio, almost six months after its initial release and subsequent withdrawal.
[Source: AdDuplex. Click image for full-sized view.]
The Data that Drives AdDuplex Tells Interesting 1809 Story
Lots of people, including Paul Thurrott, have raised issues with AdDuplex’s numbers. They rightly observe that those numbers don’t really represent the complete population of Windows users. As AdDuplex itself states “This report is based on data collected from around 5,000 Windows Store apps running AdDuplex SDK v.2 (and higher). The raw data analyzed was collected over the day of March 26th, 2019 (UTC time) unless otherwise stated.” They also note the total PCs involved in this sample is “more than 100,000.” That’s only a tiny fraction of the 800 M copies of Windows 10 in active use right now (0.0125 %).
Normally, I’d quibble with AdDuplex numbers for those selfsame reasons. But this time, I think they may be onto something valid. That’s because it’s the proportions that matter most, not the absolute numbers. If a majority of Windows 10 users is running 1803, with just over a quarter of them on 1809, this is interesting. It also follows logically that MS would try to upgrade those users to 1903. This lets them skip the apparently still problematic 1809 release along the way.
I’ve been following Windows professionally since 3.11 was released in 1992. Over the past 26 years, I can’t remember too many other Windows releases with a similar slow and unwanted uptake profile. Only Windows ME, Vista, and the original Windows 8.0 release are in this hunt. In my opinion, only Windows ME has had more bad press and more bad cess. This shows an unexpected benefit of the twice-yearly feature upgrade cycle, I guess. That is, no matter how bad or problem-ridden a feature upgrade may be, we don’t have to live with it longer than six months unless we choose to do so.
[Here’s a shout-out to Shawn Brink at TenForums, whose post “AdDuplex Windows 10 Report for March 2019 now available” brought this to my attention. Thanks, guy!]