Wow! It’s been a whacky week in advance of Turkeyday, with Version 1511 (Build 10586) gone over the weekend, then back again late yesterday. MS even furnished an explanation, which I reproduce from TenForums.com:
Here’s the scoop, straight from TenForums.com
I ran the new update, which is labeled KB3120677, on all of my Win10 machines last night (including both Preview PCs, and my 5 other production machines) without experiencing any difficulties. Here’s what Winver now reports in its wake:
We gain another .03 on the Windows build number, to 10586.14
More importantly, the versions of Windows now available from the Media Creation Tool are now back in synch with most other sources (the TechNet Evaluation Center, MS TechBench, and so forth, though MSDN shows no change on release date info). Looks like what diverged has already reconverged, which should be a great relief to Windows admins everwhere!
[Update added 11/25 1PM CDT -06:00 UCT] Further details on the settings mentioned in the TenForums post have come to light since I posted initially this morning. The specific details that have emerged center around the privacy options available in Windows 10: to view these, type “privacy options” into the Search box, and check out the Change privacy options that appear there. By default, all of these are turned on in Windows 10; the initial update to V.1511/Build 10586 reset all those options to the default even if the user had set one or more of them differently. Paul Thurrott‘s coverage of this topic says it best, in summing up what’s apparently been going on: “Suffice it to say, none of this matters in the slightest, which makes the pulling of 1511 and the resulting weird silence even weirder.” I concur, and in a tongue-in-cheek nod to the 1985 John Hughes movie classic, we should name this episode of the Microsoft Follies “Weird Silence!” Thanks, Paul…
There’s been a whole lotta hoopla over the past few days about the sudden disappearance of Version 1511 (Build 10586) from the Media Creation Tool late Friday, 11/21. Of the many stories published on this topic, the items from Ed Bott at ZDnet and Peter Bright from Ars Technica, are especially interesting. Current speculation on the reasoning behind this surprise move from the Colossus of Redmond seems to center around the notion that as-yet-undocumented bugs in this new release have prompted the decision to yank the images from the Media Creation Tool, and to revert to Version 1507, better known as Build 10240.
Being myself of a curious nature, I zipped on over to MSDN where Build 1511 also made its appearance on November 12, to see if it had been pulled from that subscribers-only download mecca as well. Here’s what I found:
Version 1511 remains readily available on MSDN, as of early AM Texas time 11/24.
This may just mean that MS hasn’t gotten around to pulling these files just yet, so it will be interesting to watch what happens to MSDN over the next day or two. It may also mean that the speculations about the bugginess of 1511 may be somewhat over-stated. For my own part, I’ve been running 1511 on my Technical Preview test machines for three or four weeks now without any obvious issues, and on all six of my regular Windows PCs (three desktops, a Surface Pro 3, an All-in-One, and a Lenovo X220 tablet) likewise since 11/13 or thereabouts.
While we’re all waiting for the dust to settle, I’d like describe fact and history as we know them at present. Previously, MS has only updated installers for major version changes and Service Packs, and such updates have propagated to the Media Creation Tool (let’s abbreviate this as MCT, and further observe that it is a utility of fairly new provenance, with roots only as far back as Windows 8.1, though Windows 8 did offer similar functionality under a different name) and MSDN in tandem. If the 1511 release counts as a “Service-Pack-like” update to Windows 10, then indeed it makes sense for it to be made available via the MCT and MSDN. Given that the two sources are currently divergent, I’d expect something else to pop up on the MCT front, to catch it up with MSDN. Or, we could be looking at a new regime for Windows 10, where the subscribers have access to releases not made available to the general public. Again: it should be interesting to keep watching, and see which way the mop flops next. According to neowin.net, 1511 is still supposed to be available through Windows Update, though some users have not been able to access it through that delivery mechanism (but that might be a function of a 10240 install that is less than 31 days old, and thus ineligible for WU to offer the upgrade, to give users 30 days to revert to the previous installation).
[Update: 8:45 AM CDT 11/24] Paul Thurrott points to an 11/20 System Center Configuration Manager Team Blog entitled “Issue with the Windows ADK for Windows 10, version 1511” as a possible explanation for why MS yanked the update from MCT. It affects multiple releases of the product and includes the statement “we do not recommend that Configuration Manager customers use the 1511 version of the Windows 10 ADK” (ADK stands for Assessment and Deployment Kit, a collection of tools that sysadmins can use to customize, assess and deploy Windows OSes to new computers). He may be right that this explains the current back-pedaling, and I believe he’s also right to speculate that “bringing back integrated installs will happen in the future.”
[Update: 2:30 PM CDT 11/24] Windows info site Tenforums.com cites MS MVP Greg Carmack’s reports of activation issues with V.1511/Build 10586 as possible cause for switching the MCT from 10586 back to 10240 (and possibly also for making them temporarily off-limits through Windows Update, protestations to the contrary notwithstanding). Read the whole thread for some whacky and entertaining conspiracy theories…
On 11/18, later in the day, my Win10 systems picked up a new cumulative update: KB3118754. What made this update interesting was that it led to an increment in the Windows 10 Version number suffix, as shown in this screen capture from the Winver command:
Following application of KB 3118754, the Build number went from 10586.3 to 10586.11.
After the recent application of the Threshold 2 update last week, the version number stood at 10586.3, and the software made available through MSDN and the Windows 10 Download (Media Creation Tool) was updated likewise. With the change in version number, I found myself wondering if this meant that the versions published through those outlets would also be changed to follow suit. A quick check on MSDN showed the pub date for the version available there remained fixed at 11/12 (the day before the Threshold 2/November 1511 update was pushed out through WU):
No change to the most current available MSDN version for Windows 10.
Just for grins, I downloaded another copy of Windows 10 from the afore-linked download page, and used the Media Creation Tool to build another Windows 10 installer UFD. Taking advantage of the info from my previous blog post, I used DISM to give me version info from the .esd file on that media, and saw no change in version info there, either.
I’m glad to understand that we can track versions for Windows 10 more precisely now, but that this doesn’t mean a constant need to update installer and/or repair/recovery media to track those frequent version number changes. I guess the difference between the current baseline version as defined by those items and the current actual version as defined by the most recent cumulative update will instead stand as a rough-and-ready metric for how many updates will need to be applied to the baseline version of Windows 10, should one be required to perform a refresh, reset, or in-place upgrade by way of repair.
The Windows 10 adventure continues, as we all learn the new and emerging rules of the road that are unfolding before us. Let’s hope we can keep making sense of what’s happening as those changes keep coming!
The more I dig into the DISM (Deployment Image Servicing and Management) command, the more “good stuff” I keep finding. Today’s gem comes courtesy of Sergey Tkachenko, whose excellent WinAero.com site has come in for kudos from me many times already in this blog. Earlier this week he posted an item entitled “How to see which build and edition of Windows 10 the iso file contains,” but his observations apply equally to bootable UFDs (or even optical media, for those who use them for Windows installation), and also apply to Windows versions as far back as 7 (and possibly even Vista, in which version the .wim, or Windows Image, file format was introduced). The same approach also works for compressed .esd (Electronic Software Download) files as well, like those included in the installer constructed using Microsoft’s Media Creation Tool (.esd . files are of more recent vintage, however, and go back only to Windows 8). In short, you can aim DISM at a .wim or .esd file, and use it to tell you what version of Windows it’s looking at. Here’s some syntax:
For .wim files:
where <dl> is the drive-letter for the volume you’re looking at (perhaps by mounting an ISO) and <wimfile> is the name of the Windows Image file you’re inspecting (usually this will be named install.wim or perhaps boot.wim)
This is the info from the UFD I built to upgrade the en-GB version of Win10 running on my production PC.
For .esd files:
where <dl> is the drive-letter for the volume you’re looking at (perhaps by mounting an ISO) and <wimfile> is the name of the Electronic Software Download file you’re inspecting (usually this will be named install.esd
If, like me, you’ve got numerous bootable installer and repair/recovery UFDs laying around, not all of them labeled — especially now, when we have to make sure we’re using the right version of Windows 10 to match what we want to install or repair — this little technique can come in quite handy. Give it a try!
In getting to know the new build of Windows 10 released late last week, I’m starting to notice some interesting refinements here and there. In particular, v1511 now combines location and time zone by default, so that it can reset a device’s time presentation automatically while on the move. I’ve long wondered why MS didn’t add this capability into the OS, given that Windows devices get time updates from time servers by default, and are tuned into their geographic locations ditto. And finally, it appears that MS has connected these two types of information to make that happen without requiring users to pop open the Date and Time widget from Control Panel (or to access Date & Time through Settings/Time & Language instead). Here’s what it looks like:
The Settings app lets you manage time and time zone settings automatically, and the Control Panel widget lets you override those settings.
This capability will be particularly handy for those who travel with their Windows devices. As soon as you turn off Airplane mode before getting off the plane (or cross time zones on slower modes of transport), your device should automatically reset the time zone shortly thereafter. Good stuff, if long overdue!
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.”