Early yesterday morning (11/12), some of my Build 10240 Windows 10 PCs began offering access to the 10586/1511 Build. Throughout the course of the day, I was slowly but surely able to get most of my 10240 PCs upgraded to the latest Windows 10 version. Along the way, as is so often the case with things related to Windows, I learned a few things: some came with relative ease, others required a bit of elbow grease to work my way through. Here is my report, prefaced with the new OS information that shows up in Settings/System/About:
The new OS shows 1511 as the version, with 10586.3 as the Build number.
The information that came relatively easily on the upgrade/update path was as follows:
For those machines that were offered the upgrade through Windows Update, download and application went fairly quickly (10-15 minutes, on average) for each machine. I encountered no significant problems on any of those machine, though my Surface Pro 3 did come up with Airplane Mode turned on after the first post-install boot into the new OS, a minor hiccup that was quickly remedied by turning it off immediately. No device driver issues cropped up on any of the half-dozen machines I’ve upgraded so far.
Some machines did not show the 1511 upgrade notice (depiction follows) quickly enough to suit me — I’ve since learned that for machines more recently upgraded to Windows 10 10240, the 30-day rollback period must first expire before this upgrade will be offered via WU — so I jumped over to MSDN to download the ISO file for the latest x64 build (the same versions are now available through the Media Creation Tool page as well). I used Rufus 2.5 to create a bootable UFD that will also serve for repair/clean install, and ran the setup.exe program to successfully perform in-place upgrades for all the machines that didn’t get offered the update through WU.
Here’s what the upgrade item looks like in Settings, if/when it’s offered.
Some Things We Learn Unwillingly, Because We Have No Choice!
On one of my PCs — my production PC, in fact, as fate would have it — I encountered an install error I’d never seen before. The Windows installer refused to let me perform an in-place upgrade (keep files and apps) because there was a language mismatch between the installer I’d built and the version running on the target PC. Further investigation showed me that I could use the DISM command to obtain that information, as follows:
I learned that the default UI language for my production PC installation is en-GB (British English) and that, by implication, I couldn’t use the en-US (American English) installer to perform an in-place upgrade. Furthermore, I also learned (see error information in second DISM command above) that you can’t reset the default UI language on an online image, only on an offline one. Rather than learning how to take my current installed image offline to perform the necessary alteration (my research shows me this can be done using a repair install boot, then running the necessary DISM command through a Command Line Prompt from the Advanced Options section in Repair), I simply jumped back up to MSDN, grabbed the UK version of the installer, and built myself a second UFD using Rufus to perform the in-place upgrade. This went without a hitch, and my production machine is now humming along on Version 1511 (I’m writing this blog post on that very machine right now).
All’s Well That Ends Well
Now that I’m mostly finished with the upgrade process (I’m planning to upgrade my wife’s and son’s computers over the weekend) I can report a high degree of success and satisfaction with the new 1511 OS version on all machines. The only real snag I hit was of my own making (having apparently run the wrong installer for en-GB on the production PC at some time in the past, probably for Windows 8 or 8.1 some time ago), and even that was easy to overcome as soon as I figured out what was amiss. “So far, so good,” is my current assessment, as I start digging more deeply into the ins and outs of this latest version, outside the two test machines — my i7 2600K desktop, and my Dell Venue Pro 11 7139 — where I’ve been running something very close to this image for a couple of weeks now.
Looking at my update history on my Windows 10 production PC this morning, I see a whole slew of updates hit the wire yesterday for that OS, but so far there’s no sign of a Threshold 2 release showing up on PCs running Build 10240. In fact, all of my 10240 PCs still show that Build in their Winver data after all those updates are applied:
Sure, it’s rude’n’crude, but the old “Date” command shows 11/11 against the 10240 build in Winver
Methinks MS is still working on the “cody bits” (as a friend of mine, the inimitable Esther Schindler, quoted a layperson’s characterization of binary code in particularly apt fashion last week on Facebook) to get Build 10586 ready for worldwide distribution and delivery. In the meantime, here’s what showed up on my production PC in the form of updates released yesterday:
- Cumulative update for Windows 10 x64-based Systems (KB3105213)
- Malicious Software Removal Tool – November 2015 (KB890830)
- 18 miscellaneous updates for MS Office 2013, plus related Components (Word, Excel, PPT, …) and Skype
- An update to the Explorer Flash Player for Windows 10 x64-based Systems (KB3103688)
- An update for MS OneDrive for Business (KB3101505) 32-bit edition
Lots of stuff, in other words, but no version upgrade for Windows 10 Build 10240. And that means the watch for delivery of Build 10586/V1511 is now underway. When it will hit WU is now anybody’s guess. Will it be sooner or later? We’ll see! What I see on the wire instead is that MS has pushed 10586 out to the Slow Ring users in the Windows Insider program. Looks like MS has, perhaps wisely, opted to give this build wider exposure to its captive circle of willing guinea pigs first, before inflicting it on the entire Win10 user base…
[Note added 11/11 late afternoon: Several reports have cropped up today, including this “rumor” item at Windows Central entitled “Windows 10 Fall refresh for desktop and mobile aiming for Nov 12 release,” that make it look like we’ll still get the Threshold 2 stuff before the week is over. Stay tuned: I’ll cover it Friday if and when it hits.]
If you take a look at the Winver information from the latest Fast Ring build for Windows Insiders, aka Build 10586, you’ll see some additional information in the second line of text therein, just below Microsoft Windows:
Whereas old Win10 simply shows “Version 10.0 (Build 10240)” in this position, new Win10 includes “Version 1511”
As it happens, there’s some method to this apparent madness, and I came across this information thanks to an illuminating pair of blog posts from Paul Thurrott (“Windows 10 Fall Update is Set for November Release” 10/21/15 and “Here’s What’s New in the Windows 10 Fall Update” 11/8/2015).
The 1511 that comprises the Version number represents a release in 2015 (the first two digits of the version number), and the 11 represents the month of November, so that one can decode this number as “Windows 10 release for November 2015.” For those interested in applying this nomenclature to the initial release of Windows 10 on July 29, 2015 for Build 10240, that means its version number is 1507 (July 2015, in other terms) even though it lacks that designation explicitly.
But there are some other interesting implications that should be gleaned from this information as well:
- Going forward, Release 1511 becomes the official baseline for Windows 10. That means MSDN will make this version available to those who wish to download and install Windows 10, and that the Media Creation Tool that Microsoft makes available to “Download Windows 10,” will supply that version as well. [Link: https://www.microsoft.com/en-us/software-download/windows10]
- 1511 will remain the current version until the next official release comes out, which Thurrott speculates — a speculation with which I concur, FWIW — will occur on a quarterly to semi-annual basis. (Even though he says “biannual” which means every two years, I’m pretty sure he really meant to set a six-month upper bound on such update frequencies).
- Restore and repair activities will default to the latest current build for Windows 10, whatever that may be. That obviates the need to install an original release and then to apply multiple waves of updates to “catch up” with current updates and fixes. This should work well for consumer-grade users, but I find myself wondering what this means to enterprises and business-class users. Will they be able to keep up with the frequency of official versions and be able to apply the vetting and testing that goes along with their adoption and use in production environments? Will they have the option of trailing behind by a release, to add some slack into the system to give them time for testing and vetting? This will be an extremely interesting question to see answered in everyday practice.
But indeed, it looks like the old Windows paradigm of a major new release, punctuated by Service Pack like addenda at annual intervals, is about to change into something new and different. Time will tell if this model works better or worse than the old regime, and if enterprise/business-class users will be able to mold it to fit their deployment and maintenance models.
If the rumor mill is correct, the current Win10 fast ring build represents the upcoming Threshold 2 release for Windows 10, and will be pushed out to the entire population of Windows 10 users next Tuesday. Wondering about what this might mean for installation and license management for those who may now choose to upgrade from Windows 7 or 8.1 to Windows 10, I took a peek at the Windows Activation pane in Settings for Build 10240 (the current released version, in use on my production PC) versus the same info for 10586 (the pretender to the status of current released version). What I found is depicted below, with 10586 to the left, and 10240 to the right:
Windows 10 10586 can tell if the current install is an upgrade, and reports “digital entitlement.”
[Build 10586 left, 10240 right; click on image to see full-size version.]
It’s long been asserted that once the Threshold 2 release is out, users will be able to supply their Windows 7 or 8.1 keys to perform a clean install of Windows 10, in addition to a more conventional upgrade. I’d have to say that the new language in the Activation pane pretty much proves that point! And it seems pretty clear that Microsoft views the ability to perform the free upgrade however you may choose on or before July 29, 2016 — the date the one-year free upgrade deal expires — as a form of entitlement. Very interesting…
In my continuing efforts to maintain the health and well-being of my Windows 10 installations, I’ve continued messing about with the built-in deployment image servicing and management tool otherwise known as DISM. When I ran into a problem with targeting the windows image (.wim) and/or electronic software download (.esd) files that can be used to provide the full panoply of Windows files and component store elements (found in the often-mysterious %windir%\WinSXS folder), I turned to the Windows Ten Forums to search for other potential sources to replace corrupted component store elements.
Understanding the Symptoms
Despite targeting the install.esd file in the sources folder on my install/recovery UFD, DISM kept coming up with a “file not found” error in its attempts to replace the single corrupt file that a /scanhealth pass over my target system identified. Understanding that this meant the tool could not find the component store element it needed, I quickly pounced on the following “trick” to point the tool at an alternative, but equally valid source for the missing materials. It seems that if you copy the %windir%\WinSXS from a running Windows 10 system that comes up clean for the following commands, you can use it as your source for DISM successfully, too:
- sfc /scannow
- dism /online /cleanup-image /checkhealth
As long as cmd.exe gives you output that looks like this, you can copy the entire WinSXS folder to a UFD or other drive onto the target system, and then use that as the attribute value for the /source directive in the DISM command string that also includes the /restorehealth directive as well.
A Word of Warning
It takes a while to run the afore-cited commands, so it’s probably wise to fire them off in a window that you can cheerfully ignore for a few minutes. This sequence is entirely necessary, because the last thing you want to do is to provide one corrupt WinSXS folder as the source for repairing another corrupt WinSXS folder. Likewise, even when you succeed, it will also take some time (about 28 minutes for a USB 2.0 UFD, and 15 minutes for a USB 3.0 UFD, as per my own observations) to create the copy of that folder where and when you need it. But this technique works, as the foregoing screen capture shows, because I used it to repair the component store on the very system upon which this “component store OK” command sequence was issued.
For another discussion of working with the DISM command, please see my October 19 blog post entitled “Simple Trick Fixes DISM /source Syntax Issues.”
Goody, Goody: one of the things I liked least about Build 10565 in the Windows 10 lead-up to the Threshold 2 Build scheduled for later this month (November 2015) has apparently been fixed in Build 10576. Whereas Gadgets had more or less quit working in that preceding build (10565), they are once again working properly in the latest build (10576). Here’s a screen shot to show them in action alongside Windows version info:
MS claims that apps are worthy replacements for gadgets, and that they can “do many of the same things and much more,” where “some apps are better versions of the gadgets you love, and many of them are free” (quotes come from the “discontinued” page linked in the screenshot caption above). Alas, I must demur, because my primary use of gadgets is for real-time system monitoring, particularly using the excellent Network Meter and All CPU Meter gadgets from AddGadgets.com. I’ve yet to find an app that can match their compact capability to report on what my PC is doing with its compute capabilities (CPU Usage) or networking connections (Network Meter). In fact, I’ve grown dependent enough on these gadgets that I now feel just a little bit hamstrung when I have to run a Windows system without having them at my disposal.
So of course I’m delighted to discover the return of gadget capability via 8GadgetPack in Build 10576 of Windows 10. I’m hopeful this means gadgets will continue to carry on in future releases of Windows 10 going forward, including the upcoming Threshold 2 release scheduled for later this month. In fact, the rumor mill appears to be reaching consensus that this will occur on November 10 or thereabouts, that being “Update Tuesday” for this month, when MS normally used to release its updates and patches on the old once-or-twice-a-month only schedule — though this may or may not be true, it at least sounds plausible on that basis. We’ll find out soon enough, I reckon!
Between a couple of interesting stories reported at NeoWin.net and WinBeta.org recently, the rapid rise of Windows 10 installs appears to be slowing down from its initial explosive rate. Although the current level of 120 million installs reflects a daily rate of 1.33 M installs per day, that number has gone up from 110 million reported on October 6 to 120 million on October 29. For the past 24 days, that puts the daily rate at only 0.42 million per day, or 31.5% of the overall average. While many sources write gushingly about how well Win10 is doing, and how MS may indeed be able to reach its billion-install milestone in 2 or 3 years, I am not quite so encouraged by this recent and apparently massive slowdown in the daily install rate. Here’s a graph I put together to show what’s going on using a non-representative time scale:
There’s been a considerable flattening of the uptake curve since the beginning of October for Win10 installs.
The data points shown are as follows:
1. 14 million, 24 hours after initial release on July 29, 2015
2. 53 million, three weeks into the cycle on August 19, 2015
3. 110 million on October 6
4. 120 million on October 29
I can’t help but see a trend where the curve is losing upward momentum (sharper slope) in favor of slowing installations (flatter slope). Of course, a small number of data points makes it difficult to predict a trend accurately, but this looks like a phenomenon that’s reached its peak in terms of momentum and is slowing sharply. On the other hand, the upcoming release of Threshold 2 in November, and the switchover of Xbox consoles to a Windows 10 code base, may inject some further increases in the overall curve — we’ll just have to wait and see what happens. But based on the numbers at hand, it looks like MS may have been a tad over-optimistic in projecting the line out to 1 billion overall installs, even a full 36 months out from the initial release date for Build 10240 on July 29, 2015. Even at 1.33 M installs per day, it will take over 20 months to get to 1 billion total installs for the remaining 880 million left to go; at 0.42 M per day, that timeline stretches out to over 5 years!
Among my various desktops, laptops, and tablets, I’ve got an 16-month-old Surface Pro 3 purchased in August 2014. In working with the boot/sys drive recently I noticed I still had a windows.old folder hanging around, courtesy of my September upgrade to Windows 10 on that machine. “Hmmmm,” thought I to myself “that’s interesting: I thought I’d run CCleaner on that drive, and I *always* check the ‘Old Windows installation folder cleaning’ option therein when it shows up.” So I ran CCleaner again, and observed that the Windows.old folder on the Surface only included 400-odd MB of files (normally, for Windows 10, it runs somewhere above the 12-14 GB mark). Sure enough, although the program claimed to have cleaned-up Windows.old, it persisted past its supposed deletion size unchanged.
To make a long and somewhat tedious story as short and to the point as possible, I was also unable to remove Windows.old from the Surface using either the built-in Disk Clean-up utility, nor did the usually capable Unlocker program prove equal to the task of deleting the folder, either. Somewhat unpleasantly, I also observed that the latest Unlocker version comes chock-full of “bundleware,” including a search engine and home page replacement to some site that Norton disallows because of the presence of spyware and potential malware at that address. That’s why I’m no longer recommending the program to readers, and will have to find some more benign program to take over its role of resetting Windows file locks and overriding the strongest of read-only permissions.
Rd is the abbreviated form of the built-in “Remove directory” command at the Windows command line.
Once I cleaned up the small messes that Unlocker left behind on the Surface, I turned to the Windows 10 forums (TenForums.com) to their Tutorial entitled “Windows.old Folder — Delete in Windows 10.” That’s where I was reminded that, if all else fails, you can boot to a recovery/repair drive (which I always keep handy on a clearly labeled 8 GB USB 3.0 flash drive) and get rid of persistent files and folders at the command line. Here’s what I did to make that happen:
1. Shut down the Surface
2. Inserted the recovery/repair UFD into the USB port
3. Push the Volume Down button, briefly press the power on button, and hold Volume Down until the Surface logo appears on-screen
4. When the device boots into the recovery/repair disk, click through the first install screen, then elect repair on the second screen, and make your way into Troubleshoot, Advanced, and ultimately, Command Line Prompt
5. At the command line, run diskpart list volume to get the drive letter for your boot/sys drive (it won’t always stay the same when you boot into the WinPE image on a recovery/repair UFD, though mine did
6. Enter the following command to remove the persistent folder: rd /s /q C:\windows.old (substitute the correct drive letter to match your boot/sys drive as shown in the preceding diskpart command)
That’s all there is to it! Just goes to show that where there’s a will, there’s almost always a way to get things done in Windows, but also that getting there may not be as simple and straightforward as you might like. Such is life in Windows-Land!
If there are some distinctions to which Window10 testers should not aspire to attain, I’d have to say falling prey to the boot/system failures now widely associated with the recent KB3105208 cumulative update is one of them. The update appears to proceed normally, and then asks for a reboot (also a normal consequence of installing updates). But once a reboot has occurred, instead of the usual subsequent reboot start-up, what many sources are calling a “blue screen” or BSDO occurs instead. I will actually quibble with this terminology and observe that a normal start-up fails, and the built-in recovery screen pops up instead. What makes this update particularly insidious is that normal recovery techniques don’t work: you can’t perform a start-up repair, you can’t run a restore, and apparently, you can’t do much of anything at all, except perhaps for a clean reinstall of the OS.
How do I know all of this? My Dell Venue Pro 11 fell prey to this malaise, and I dithered around with it for a while before turning to the Internet for such flashes of wit and wisdom as might be available. Fortunately for me, turns out there is no shortage of insight on this particular failed update, much to my benefit and to the benefit of others who might have found themselves in that boat. This potential gotcha is no longer a threat, because in the wake of widespread yelling about problems with KB3105208, MS yanked the update and has promised to re-release it without the errant fix that brought affected systems down.
This snippet from the BIOS Configuration section of the VP 11 7139 User’s Guide gets to the heart of this matter.
As it happens, the only systems affected are those with Secure Boot enabled, which make tweaks to a UEFI BIOS to secure the boot-up sequences from unwanted tampering. The trick to the fix is to disable Secure Boot in the UEFI after which the system will return to what passes for normal with Windows 10 preview builds. My VP11 is now back on the job, awaiting the repair to KB3105208 that will let me turn Secure Boot back on, or the next Fast Ring release, which will hopefully do likewise.
Just another day in the sometimes exciting, at other times frustrating, round of the preview OS victim … err … tester. One more thing: you will also have to visit http://windows.microsoft.com/recoverykey to retrieve your BitLocker recovery key so that the next reboot can decrypt your boot partition (this is what protects it from tampering when Secure Boot is enabled) to permit a non-Secure Boot restart. Entering a 42-digit numeric string is not without its unique delights but if you’re careful you can get it right the first time!
There has been plenty of heated discussion about the way MS has handled updates in Windows 10. Much of that discussion has centered around Windows 10’s update push behavior, which forces updates on Windows 10 PCs whether the recipients want them or not (see one workaround for this in my 7/27/15 post on the MS “Show or hide updates” tool). One additional consequence of this behavior is that, following the application of some updates, Windows 10 will automatically reboot itself within 24 hours at some scheduled time or day or night — I’ve got my time window set for 3:30 AM, for example, since I’m pretty much never up and at the PC at that particular time myself. Alas, however, sometimes we don’t want Windows to reboot for awhile, usually to preserve machine state because of something we’re working on, watching, or otherwise engaged with that would be derailed thereby. That’s why I was pleased to see a Registry hack made public over at Sergey Tkachenko’s excellent Winaero.com site yesterday, in a blog post entitled “How to prevent Windows 10 from automatically rebooting for update installations.” In that post, he also shows the somewhat tyrannical warning message that Win10 displays when the scheduled boot time is nigh:
No choice but to close all apps and batten down the hatches when this message appears.
Here’s the registry hack involved, for those comfortable with mucking about therein:
- Launch the registry editor (e.g., type “regedit” in the Search box).
- Navigate to this registry key:
\WindowsUpdate\AU (all on one line of text, please)
If the key does not exist create it.
- Within the key create a DWORD value named NoAutoRebootWithLoggedOnUsers and set its value to 1.
- You must restart your PC (in a cruel twist of irony) for this change to take effect.
That’s all there is to it. Enjoy!