While perusing the postings over at the Windows 10 Forums earlier, I caught an item there entitled “Trimming down Win10TP” that taught me a new way to use the Deployment Image Servicing and Management tool (aka DISM). According to the DISM reference on TechNet, it involves adding a couple of different switches to the by-now-familiar DISM /online /cleanup-image sequence.
Lots of building blocks go into Windows images, so lots of blocks can be (occasionally) cleaned-up.
[Image Credit: Shutterstock 223942717 © IndianSummer]
Those two switches are
1. /StartComponentCleanup, which TechNet explains as intended “to clean up the superseded components and reduce the size of the component store” (WinSXS).
2. /ResetBase, which TechNet explains as intended “to reset the base of superseded components, which can further reduce the component store size.”
Nothing loath, I tried them both! I’ve already cleaned up my driver store, and gotten rid of leftover update detritus and Windows.old installations on all these machines, but I did get from just under 1 GB to 2.1 GB back on the various machines I tried it on, including both Windows 8.1 and 10 (Build 10122) installations. Here’s a short table of results:
|Results of running DISM to clean Component Store (WinSXS)|
|Machine||Brief stats||OS||B4 C: size (GB)||After C: size|
|Dell Venue 11 Pro||i5/8GB RAM/256GB SSD||Win10||36.9||34.8|
|i7-4770K Desktop||i7/32GB RAM/256GB SSD||Win10||69.9||68.3|
|Production desktop||i7/32GB RAM/500GB SSD||Win8.1||98.7||97.9|
|Surface Pro 3||i7/8GB RAM/256GB SSD||Win8.1||60.4||59.9|
I wouldn’t call these earth-shattering space savings, but any time you can save another gig (sometimes more) of space, and tidy up Windows at the same time, I’m inclined to endorse the activity involved. I can also say it took a great deal longer for Windows 8.1 to crank its way through the work involved in this clean-up as compared to Windows 10. On the Win10 PCs it took under two minutes to finish up, on each of the Windows 8.1 PCs it took between 5 and 10 minutes to complete.
There’s a caveat to keep in mind, too: If you run the /ResetBase switch, you will thenceforth be unable to roll back any Windows Updates installed on that PC. This has yet to bite me on the hindquarters, but it is worth remembering, especially in corporate environments, where updates are carefully and cautiously applied anyway.
When I wrote a blog post on May 11 entitled “The Importance of DriverStore Cleanup,” little did I know the post would turn out to be both useful and prophetic. But after investigating the disk layout for the recently-released Build 10122 of Windows 10, I was struck by the difference in size for the RecoveryImage folder on my two test machines. The Dell Venue 11 Pro showed that folder with a size of 2.4 GB, while the same folder for the i7-4770K desktop weighed in at a hefty 20.4 GB instead. “Hmmmmm” I found myself wondering, “could drivers somehow be involved in this difference?”
After the upgrade on the desktop PC, I found only 14 drivers in the DriverStore for Build 10122.
A bit of spelunking into the causes for such a difference revealed that the RecoveryImage folder includes a sub-folder named Drivers. Further spelunking showed me that this folder is 1.7 MB on the Dell, and 18.1 GB on the desktop. That sure seems to suggest that drivers can occupy a LOT of space when the Windows installer uses a current image to generate a recovery image during the installation process, don’t it?
Further investigation shows over 120 sub-folders in the /Drivers/Regular directory tree on the desktop PC, where many (80%) of those folders include duplicate content with anywhere from 2 to 40 other such folders. Alas, the names of the entries therein appear to be auto-generated, and aren’t easy to puzzle out completely, though an inspection of their contents will help point seriously interested investigators at the relevant drivers represented therein. By comparing those names to other images of the same drive and a backup from the DriverBackup utility, I was able to determine that my duplicates came primarily from two sources: the Nvidia graphics card in that PC, and the RealTek audio circuitry on its MSI motherboard.
I take three lessons from this encounter:
1. It’s a good idea to check your driver store before any Windows 10 (or other Windows) upgrade to see how big it has grown. If it’s over 5 GB in size, you’ll want to prune it to reduce the size of the RecoveryImage that Windows 10 builds automatically during the install process.
2. It looks very much as if when Windows supplies drivers via Windows Update, multiple copies of the same driver often wind up in the driver store. Any time you get a driver from WU, it’s probably worth checking the store to see what new inventory has showed up on its shelves, so to speak. The CodePlex RAPR.EXE utility is just what you need for this task.
3. It’s probably a good to best Windows maintenance practice to check your driver store anywhere from 2 to 4 times a year, to eliminate clutter therein. Those who, like me, enjoy fooling with drivers and obsess about keeping them up-to-date will need to check at the higher frequency; those who avoid drivers except under duress can check at the lower frequency.
The urgency of these tasks (especially item 1 above) will be inversely proportional to the size of the boot/system drive where the upgrades occur. Those with tablets that have only 64 or 128 GB of storage will find this effort quite rewarding, but the payback for the work diminishes for those with 500 GB or more in their boot/system volume. I want to keep monitoring the driver store to see if my theories about WU driver delivery have any merit, and I’ve already proven to myself that item 3 is worth doing, if only because I tinker so much with drivers that I tend to load my driver store down pretty heavily over time. YMMV on that last item, as the old acronym goes!
The last couple of days have been exciting in my part of the world, mostly as a consequence of downloading, installing, and absorbing the latest Windows 10 build, 10122, which made its debut two days ago. As per current usual practice, Gabe Aul documented its release at Blogging Windows, in a post entitled “Announcing Windows 10 Insider Preview Build 10122 for PCs.” Dealing with the necessary steps of installation, driver tweaking, and familiarization, 10122 has been something of a “good-news, bad-news” scenario as is not atypical for a late-stage Windows OS beta release.
The Winver output for build 10122 shows an expiration date in October, 2015.
The good news about this release is pretty good indeed, on the whole. Whereas my Dell Venue 11 Pro has experienced install issues with the last three previous builds (a cold restart after the initial reboot screen ultimately proved to be the fix for this issue, but I learned that only after a countless number of other, failed possible workarounds), the Fast Ring “update install” worked fine this time. Ditto for my homebrew i7-4770K desktop test machine (which had no problems with any of those previous installs, either). The weird touchpad insensitivity issue I’ve been wrestling since MS released a new Synaptics driver version last week (version 188.8.131.52, straight from the manufacturer via MS itself) turns out to have been related to sensitivity settings easily addressed using the Mouse Properties widget available in the Control Panel.
Some cleanup following the install of Build 10122 is probably a good idea: I shed 20+GB on the Venue 11 and 19+GB on the desktop following the install, using the “Old Windows installation” checkbox item that makes itself visible in CCleaner (always grab “slim” version), or by clicking the “Clean up system files” button in Disk Cleanup available directly from Windows 10 itself, via drive properties. The old build is big enough to be worth removing if the upgrade works, particularly on tablets or PCs with smaller boot/system storage volumes at their disposal.
The bad news about this release has been documented online as consisting of difficulties installing on Surface Pro 2 and 3 models (see this NeoWin story for a workaround hitherto unknown to me that cleans up drivers and DLLs). Also, users who have non-Nvidia/non-Intel graphics adapters on their test machines have also reported difficulties in using the new build as well, particularly with the new Edge browser (see this NeoWin “known issues” story for more info). I’ve run into something that has popped up in other prior releases — namely, that program entries in the Start menu appear as they should, but don’t respond to mouse clicks or touches by launching the related executable. The workaround is to jump into the Program Files or Program Files (x86) folder hierarchy, then find the executable, and double-click the .exe file to fire it off. OTOH, the high-priced Windows 10 version of Stardock’s former Start8 , now called Start10, continues to work just fine, so perhaps that item isn’t as nugatory as I had previously thought: and perhaps Stardock paid attention to my qvetching and moaning when buying an Object Desktop subscription was the only way to get that software, because you can now download and use a 30-day trial for free, or pay $4.99 to buy only Start10 by itself. Good on you, guys!
I’ve also noticed that Build 10122 will freeze or hang on me for as long as a minute at a time upon occasion, particularly when the CPU load shows “maxed out” 100% utilization on all available threads, but also when jumping into or out of a Remote Desktop session (I often remote into my Win10 test machines from my primary production Windows 8.1 desktop, when writing articles or blog posts, testing various OS features and functions, or fooling around to look for potholes and gotchas). I’ve experienced a couple of blue screens when mucking around with drivers, particularly on the Dell Venue 11 Pro when trying to clear the “Out-of-date” flag on its Bluetooth driver with which DriverAgent presents me on that machine. I did notice that the new build does not apparently draw on up-to-date drivers from its predecessor during the install process, which set me to wondering why that isn’t a primary source for driver data when upgrading from one related Windows OS version to another. On the other hand, the desktop machine upgrade experienced no similar loss of “driver smarts” upon its completion, so it could just be a function of the age of the gear involved: the Dell is less than 6 months old, while the test desktop includes no components less than 18 months old.
On the whole, Build 10122 seems quite solid and is working well for me. I can only hope other beta testers fare as well, and have an equally enjoyable overall experience.
[Note added 5/25: I’ve now discovered that the issue with clicking entries in the Win10 Start menu relates to search index issues. If you visit Indexing Options in Control Panel, then click the Advanced button, then click Rebuild (for Rebuild index), the menus return to normal working order. This fix restored proper behavior on both of my Windows 10 test machines in under a minute (rebuilding the index comes with dire warnings about time required to rebuild them on machines with lots of storage and things to index; warnings notwithstanding, the rebuild process was quick, even on my desktop test PC with over 5 TB of storage). Thanks to this article at WinBeta.org that set me haring off on this trail: “How to: Rebuilding your search index in Windows 1o,” I was able to confirm that menu access issues apparently stem from search stuff.]
I’m using a Dell Venue 11 Pro 7139 as one of my two primary Windows 10 test machines at the moment, and it has become a recent focus for some interesting driver issues. Late last week, MS unleashed a new Synaptics HID TouchPad driver through Windows Update for Windows 10. As soon as I applied the driver, the touchpad stopped working properly (the cursor appears on screen and the touchpad buttons work, but the cursor does not move in response to motions on the touchpad once the system finishes booting up; interestingly it works fine during boot-up, but not afterward, once I establish a log-in). A quick trip to Device Manager, where I go to the driver Properties, Driver tab, and clicking the Roll Back Driver button takes care of the problem, and things go back to normal.
Until MS, or Synaptics, or Dell, fixes the standard driver not working problem on the 7139, I’m going to see this in WU.
Why is this a problem? The reason is that Windows Update in Win10 doesn’t give me the option to hide driver updates, so I can’t tell WU not to apply this update. Every time the system reboots, it checks for updates, applies the new (non-working) Synaptics driver, and bang! there goes my touchpad into “out of order” mode. I can, of course, use an external mouse (I have both Bluetooth and Unifying receiver-based meese at my disposal) or I can zip back into Device Manager and roll back the driver each time WU re-applies it for me. Just for grins, I decided to give Dell Tech Support a call to see if they knew anything I didn’t. Once they found out I was running Windows 10, they punted in Microsoft’s direction and urged me to post my issue to the Windows 10 Insider Hub/Windows Feedback (I have already done so) but were unable to offer any other solutions that might fix the problem once and for all. I spoke to a very nice service technician, and her boss, both of whom agreed that the issue essentially boils down to a lack of means or functions to selectively refuse driver updates from Windows Update in Windows 10. I hope that Microsoft will address this kind of general functionality in the RTM and/or GA releases, perhaps by making such drivers optional (which gives users the ability to refuse them, and hide them to prevent further auto-installation attempts).
[Note added 5/25: Last Friday (May 22), I visited the Synaptics widget in Control Panel, and by increasing the touch sensitivity of the touch panel, I was able to restore it to proper working operation. Something about the driver update caused the settings to be massively decreased, to the point where the touchpad really couldn’t function. Monkeying with those settings, and getting them to an apparently more normal range, allowed me to regain use of the device. Go Figure!]
In my last post here, I observed the number and frequency of updates for Windows 10 arriving via an unthrottled and untrammeled Windows Update. By far, the biggest number of items in the 15-day list concerned Windows Defender, with well over half the individual events resulting in an update of some kind targeting that application. And in fact, Defender was the only application to regularly receive multiple updates in one day, and as many as three updates on some days.
“If at first you don’t succeed…” may be a mantra for overcoming difficulties; that said, it shouldn’t apply to a one-or-more-times-a-day update like that for Windows Defender.
This morning, I discovered that both of my test systems were failing to apply Updates related to Defender. Further investigation revealed that in cases where Windows Update delivers more than one Defender update at the same time (as was the case with Update Versions 1.197.2868.0 and 1.197.2856.0) queued up at the same time), an interesting pattern manifested itself. The first such update would succeed, but the second would fail producing a variety of different error codes along the way. The fix was bone-headed and time-consuming but it worked: although Defender doesn’t require a reboot following its updates (nor should a set of routine security and antimalware additions), a reboot after each update when more than one Defender update is queued up for application was the only way I could get them to apply themselves successfully.
Looking back through my update history through early May on both machines, I see 9 failures on the homebrew PC and 7 failures on the Dell Venu 11 Pro: all of them involve Windows Defender. There are no other update failures in either record, in fact, which suggests to me that Defender is a culprit (or perhaps, a victim) for some kind of update problem. I’ve reported this to MS through the Windows Feedback app, and see that this has been reported many times over the past three months or more. I hope this is something they’ll fix prior to the upcoming RTM release: it’s bad enough that some updates require reboots to complete their successful application; it’s worse when updates that shouldn’t require reboots end up demanding them to work around as -yet-unknown bugs in their normal application process.
[Note added 5/25: Since recording these observations a week ago, I’ve been able to reconfirm them on several occasions for both of my test machines. I’m not sure that constitutes a sufficiently large pool to make a quorum, but from my perspective this now looks less like an interesting anomaly and more like a bug, and I’m reporting it as such to Microsoft through the Windows Feedback widget.]
In the brave new world of Windows 10, updates are no longer batched, but pop up when and as they appear. I decided to take a look at what that means by examining the Update Histories for my two current Windows 10 PCs, in terms of types and frequencies of updates involved. But first, of course, some caveats:
1. Windows 10 is a beta OS so it’s probably more subject to updates in general than a stable production OS would be.
2. Furthermore, Windows 10 is a beta OS that’s in the headlong rush to RTM sometime in the next 2-4 weeks or so, so perhaps what we see is waaaay outside the realm of what’s likely after GA comes and goes.
3. By way of comparison, the last Update Tuesday (May 12) deposited from 40 to 48 updates on my half-dozen or so Windows 8.1 PCs and tablets here at Chez Tittel. That works out to a daily frequency of roughly 1.3 to 1.5 updates, not including Windows Defender.
On Windows 10, Windows Update is handled through the Update & Security widget in the Settings app.
With all this in mind, take a look at what showed up on my two test PCs for the period from May 1 to 15 (I ran Windows Update just after logging into both machines on the 15th, but that day is far from over it still being early morning as I write this blog post):
|Windows 10 Updates May 1-15, 2015|
|Date||Dell Venue 11 Pro||Homebrew i7-4770K|
|5/3||Defender (3)||Defender (3)|
|5/5||Update KB2062095||Update KB3062095|
|5/6||Defender (2)||Defender (2)|
|5/9||Synaptics driver update||Defender|
|Realtek HiDef Audio driver update|
|5/11||Defender (3)||Realtek HiDef Audio driver update|
|Malicious SW Removal Tool||Malicious SW Removal Tool|
|5/14||Feature on Demand for X64 (.NET 3.5)||Feature on Demand for X64 (.NET 3.5)|
|Intel HD Graphics driver||Security Update KB 3051768|
|Security Update KB3066002|
|5/15||Security Update KB 3051768|
|Security Update KB3066002|
The data suggest some interesting take-aways from a new and upcoming Windows Update regime. First, I find it interesting that on some days Windows Defender gets as many as three distinct updates (the rhythm for other endpoint security solutions varies, but this is not unheard of in enterprise environments, either, and is usually separate from the normal controlled update deployment regimes in place). Second, it was fascinating to see device drivers arriving more or less at random: though the Windows qualification scheme is reasonably well-managed for drivers that pass through WU, I can’t imagine enterprises passing them onto clients without prior testing, because driver failures are as likely, if not more likely, to cause blue screens than any other kind of botched update. Third, it was interesting to see the monthly Malicious Software Removal tool show up solo on my Windows 10 machines — in fact, that’s what clued me into checking up for updates on my Windows 8.1 PCs.
The total number of updates for May so far, not including Defender (which I don’t consider to fall under the normal aegis of update management and deployment, anti-malware updates being of a somewhat different nature) was 7 for the Dell, and 6 for the homebrew PC, of which 3 for the Dell and 1 for the homebrew PC were drivers, the rest security and other Windows updates for each machine. This is not an insane number, but their irregular and unpredictable frequency and composition (drivers versus other updates, for example) means that enterprise IT pros will still be collecting them as they show up, passing certain critical items through on a high-priority basis (these might have been identified as “critical out-of-band security updates” in the old, pre-Win10 WU world; it will be interesting to see how they get labelled and handled in the new, post-Win10 WU world), and working and testing the remainder to see which ones make the cut for the next scheduled update deployment time slot. Given what I see here, I don’t believe that the recently-announced Windows Update for Business is going to have much of an impact. It should be interesting to wait and watch to see how it all plays out!
Realizing that yesterday was “Update Tuesday,” I opened up my update history on a production Windows 8.1 PC this morning, and found 40 (!) updates of varying shapes and sizes had been installed thereupon. You can read all about what hit yesterday in the MS Security Bulletin Summary for May 2015 if you like, but you’d best set aside at least half an hour to chew your way through its formidable contents. Suffice it to say here that you’ll find two critical items (MS15-043 and MS15-044) that could permit remote code execution, one that provides a cumulative security update for IE, the other that patches TrueType font driver related issues for Windows, .NET, MS Office, MS Lync, and Silverlight.
The big bulletins for May pose interesting vulnerabilities for IE and “TrueType fonts everywhere.”
Just for grins, I jumped over to my Windows 10 test machines and found a single common update from the herd of Windows 7/8 items had propagated over to the new desktop OS — namely, the usual monthly update to the Windows Malicious Software Removal Tool (KB890830). I’m not sure how many of the other updates released for earlier desktop OSes yesterday had already been applied to Windows 10, nor how many common elements may still be forthcoming. It seems fairly obvious, however, that ongoing streaming of updates instead of batching them up for monthly release will definitely lower the Wow! factor for those who have updates applied automatically when they log in the day after “Patch Tuesday” — err, rather, “Update Tuesday,” as Microsoft’s new nomenclature would have it.
The upcoming delivery of Windows Update for Business (see my May 6 blog post for details) means that enterprise admins will be able to permit some updates to propagate to end-users if they so choose, while holding back others for testing and safety/compatibility checks. My best guess is that enterprises will stick to their current approaches and toolsets, trusting to their own tried-and-true update handling techniques for some time to come, as they work with and try out WU4B to see if it does them any better than their own methods already do. The jury will be out on that question for some time to come, because it all hinges on large-scale, wholesale upgrades to Win10, which often don’t happen until 1-2 years after initial release to the general public. I’m wondering if Win10 will bring enough compelling new features to the party to accelerate things a bit, or if the impending retirement of Windows 7 and the lackluster response to Windows 8 might not prove a more telling impetus in the long run. We’ll see!
I’ve blogged repeatedly here about a great little free software tool called DriverStore Explorer (RAPR.EXE). In Windows environments all the way up to and including Windows 10, any drivers that have been loaded and installed on the current Windows OS (or prior OSes that have been upgraded) reside in a directory named %windir%\System32\DriverStore. As an experiment, I’ve been cleaning up that directory on one Windows 10 installation (on my Dell Venue 11 Pro 7130) and leaving that directory alone on another installation (on my i7-4770K homebrew desktop). Upon reading an observation from one Windows 10 beta tester over on the Windows 10 Forums this morning about a Windows install over 50 GB in size (!) I found myself wondering if DriverStore might not be playing a role in that burgeoning disk consumption.
So I decided to compare the size of those two directories on my cleaned-up versus untouched versions. On the untouched version the size of that folder is a whopping 26.1 GB; on the cleaned-up version, it consumes just 1.4 GB. Here’s what those folders look like in WinDirStat, just for a quick visual comparison:
Dell above, homebrew below: you can fit the smaller box into the bigger one more than 18 times!
(I reduced pixel count by 50% on both images to better fit most WordPress displays)
In case the moral of the story isn’t already clear, especially for those who want to run Windows on a smaller SSD or hard disk, you really can recover a lot of storage space by keeping your DriverStore cleaned up. If you need further proof, following a quick cleanup with RAPR on that directory, it consumed only 1.3 GB. I found over a dozen duplicate Nvidia drivers therein, but it was the 120-plus copies of the RealTek sound chip drivers that really sucked up the space, as the subsequent reclamation of 24.8 GB of disk space unequivocally illustrates. All I can say is “Zounds!”
In the wake of recent MS conferences like Build 2015 and Ignite, the pundits and prognosticators seem surprisingly unanimous with two short-term predictions. First, Windows 10 seems bound for general availability (GA release) by the end of July; and second, a new, improved and fanless Surface Pro 4 (SP4) model seems destined to hit markets at around the same time. Sean Cameron at WinBeta, Mary Jo Foley at ZDNet, and Brian P. Rubin at readwrite, among many others — including yours truly — have all recently opined about what it’s gonna take to turn the already formidable Surface Pro 3 into a market-leading monster upon its impending release.
What’s missing from the Surface Pro accessory collection is a plug-in keyboard with hinge like this one, to turn it into a clamshell PC.
I think I’ve got the answer (with which Sean Cameron concurs, as his afore-linked WinBeta story will attest): a clamshell style keyboard dock. The Type cover is fine, but I am continually frustrated by the kickstand with floppy keyboard whenever I try to work away from a desk or tabletop. Though MS delights in proclaiming the kickstand-plus-Type-cover as “lappable” ( or is that “lapable?”) I do not find the device to be such, nor terribly workable away from a hard, flat surface upon which to park it.
So far, I’ve owned two tablets that included clamshell keyboard plug-ins, both with added batteries to improve the runtime of the devices that plug into them. One, I got rid of — the Fujitsu Stylistic Q704 — primarily because its Haswell-era i7 processor produced enough heat to overwhelm the tiny unit’s built-in cooling capacity, and kept having to be throttled back to keep it from overheating. Its clamshell keyboard dock was great, if a bit heavy, and really made the unit much more useful (and thus also, likely to be used) over time. The other is my Dell Venue 11 Pro 7130, which includes a Broadwell M i5-4210Y CPU, and doesn’t need active cooling to operate. It too, has a nifty clamshell keyboard dock (which appears in the preceding photo), and I use it all the time both as a light-duty traveling machine and as a book reader/media player. Even with the keyboard attached, it’s light enough that I have recently traveled with a Lenovo T520 for work, an iPad to read on the plane with, and the Venue 11 Pro for personal use and entertainment, all in the same old beat-up but still serviceable Targus computer briefcase I’ve carried for over a decade now.
If MS doesn’t already have something like this in the pipeline, we won’t see such an accessory when the newest Surface Pro model ships in the next few months. But I sincerely hope MS decides to build something like this for the Surface Pro models, because it would make the difference between me watching my wife and son use the Surface as our household’s go-to mobile PC at home, and me turning that unit into my road machine and primary desktop replacement at home. Are you listening, Microsoft? I sure hope so…
One of the most interesting tidbits to emerge from the Ignite conference so far has been Microsoft’s announcement of its “Windows Update for Business” service. Terry Myerson himself, Microsoft’s EVP for Operating Systems, made this announcement — and offers an equivalent Blogging Windows post on the topic — which shows that the company really gets how important handling updates at the enterprise level truly is, and has put some serious thought into accommodating a very different set of needs and priorities when it comes to staging and deploying such updates in a business environment.
With Windows 10, MS will finally offer a different kind of Windows Update for business users, emphasis on enterprise-class deployments.
[Click image for full-size view, if the “fine print” is too challenging.]
What does Windows Update for Business involve? There’s a lot of hoopla in the announcement about matters related to protection, for devices, identity, applications, and information, but I’ll let the announcement handle those details. What I — and most enterprise IT organizations — care about even more is support for how updates get managed and deployed. Historically, the consumer-grade version of Windows Update has been totally at odds with business needs in that it’s endpoint driven, automatic, and more or less involuntary. In enterprise environments, the first concern about change management is to ensure that introducing change does not also introduce unwanted side effects, particularly those that might affect the proper operation of mission-critical line of business and custom applications. Perforce, there’s no way for MS to test against such things before unleashing updates on the world, so enterprise IT organizations have no choice but to test such things themselves, and only to permit updates that don’t create negative impacts to be deployed in their production environments. In addition, most enterprise IT organizations have only short intervals during which update deployment is scheduled to occur (usually on a monthly or quarterly basis) and they must be able to stage and deploy safe updates within the time windows available to them, or roll back problem or incomplete updates before the update time window closes, so as to leave their production environments in a stable, working state for employees, contractors, and partners to use when production work resumes immediately thereafter.
The MS announcement takes strong cognizance of these needs and the enterprise update situation. To that end, it includes the following capabilities:
1. Distribution rings: a means whereby IT can specify which devices go first in an update wave, and which devices will come later (this provides an opportunity to pilot new or changed elements to power users, developers, and the like, to enable issues to manifest and be solved, before rolling updates out to the entire world of production).
2. Maintenance windows: enables IT departments to establish the dates and times when updates may occur, and — more important — when they may not occur.
3. Peer-to-peer delivery: permits IT to deliver updates to branch offices and remote sites only once, after which they can fan out to individual nodes and devices at the edge of the network. This is essential to conserving bandwidth across private or high-cost WAN links from central, highly-connected corporate sites to the network edge.
4. Integration with existing tools: permits management tools and environments (e.g. System Center or Enterprise Mobility Suite) to continue to function as the “single pane of glass” through which to manage update deployment along with the myriad of other functions needed to care for and troubleshoot enterprise IT environments. I’m curious to see how well this will play in enterprises that use non-MS tools to perform such functions (where connectors may need to be built before full-scale integration is possible), though MS platforms already seem to be covered.
As somebody who’s witnessed a few holiday weekend exercises in update deployment, with a battery of experts on tap to escalate and shoot the inevitable trouble that often pops up as the time window expires, I’m delighted to see that Microsoft is getting with the program that has been in place in enterprise IT environments since the beginning. All I can say is “About time!” And again, it will be fascinating to see how the elements described above play out in actual high-volume deployments once Windows 10 has been deployed in sufficient numbers to make it suitable to put Windows Update for Business to work in the real world.