Sure, there’s a lot that’s new about Windows 10, and there have been a lot of changes introduced with the new OS. While some are positive, and some negative, nearly everyone has been unhappy about the lack of information on Windows Updates that MS has provided since Windows 10 went into full rotation in July 2015. Until yesterday, the most anyone could get out of MS about updates was boilerplate language along the lines of “Changes made to add stability…,”quality improvements, security fixes, and so forth.
Starting with the latest “Patch Tuesday” (2/9/16), MS has introduced a new Web page entitled “Windows 10 Update History,” that goes back to the old changelog approach of documenting new updates. Not coincidentally, yesterday’s updates also included a new Cumulative Update — namely, KB3135173. Here’s what that page has to say about it, as an illustration of the kind of information once again being made available:
This update includes quality improvements and security fixes. No new operating system features are being introduced this month. Key changes in this update include:
Improved installation time of updates.
Fixed issue with Microsoft Edge browser caching visited URLs while using InPrivate browsing.
Improved Silverlight performance.
Fixed issue that didn’t allow a Windows 10 PC to remotely configure a server.
Fixed issue with pictures and tables not displaying in Windows Journal.
Fixed security issues that could allow remote code execution when malware is run on a target system.
Fixed security issues in Microsoft Edge and Internet Explorer 11 that could allow code from a malicious website to be installed and run on a device.
Fixed additional issues with Input Method Editors (IMEs), Direct Access, assigned access, peripheral device detection, barcode scanning, Windows Explorer, Internet Explorer 11, Microsoft Edge, and scripting.
Fixed additional security issues with .NET Framework, PDF library, Windows Journal, kernel-mode drivers, Remote Desktop, and WebDAV.
For more info about the security fixes in this update and a complete list of affected files, see KB3135174.
For an audience that’s been half-frustrated, and half-appalled with the lack of information about Windows Updates for Windows 10 until now, this comes as very welcome relief. I must say I liked it better when you could simply click on entries in the Update History on a specific PC and get this kind of information, but the new approach is much, much better than the total lack of detail provided up until now. For the incurably curious, the information available within Update History remains pretty generic, though. Here’s the “detail” provided for the foregoing KB3135174 therein:
A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.
My best guess as to why MS has made this change, and introduced the Web page instead of returning to detail in Update History is that with multiple release branches now in place, it’s easier for them to manage all the data online. They don’t have to package that information for distribution with the updates any more, either.
As of the latest figures from NetMarketShare.com, Windows 10’s desktop operating system marketshare has just surpassed that for Windows XP, that venerable, creaky and insecure OS whose support went bye-bye when it hit end-of-life status on April 8, 2014. Almost two years later, it’s still kicking after a fashion, with various arms of governments world-wide (including branches of the US military) still paying for extended support contracts into 2016.
In fact, XP’s 11.42% marketshare still beats that for everything except Windows 7 (52.47%) and 10 (11.85%), including
- Windows 8.1: 10.4%
- Mac OS X 10.11 3.44%
- Windows 8: 2.68%
- Mac OS X 10.10: 2.33%
- Everything else: 5.4%
On the one hand, I’m amazed that XP has persisted as long as it has in “zombie status” (still in use after end-of-life has been reached). It’s a testament to various aspects of human organizational behavior, including inertia, parsimony, and sheer cussedness, none of which are especially flattering, but all of which are too apt to be denied.
On the other hand, it’s cool that Windows 10 has now jumped into second place overall. Now, it can start whittling away at Windows 7’s still unbeatable majority market share of 52.47%. Shawn Brink of TenForums.com observes that XP has been losing a fairly steady 0.5% in marketshare over the past year, which would indicate that it could vanish as soon as two years from now, or fade into the “other” category (less than 2.5%) in as little as eighteen months. We’ll see!
What I’m interested in watching going forward, is how well the dip in Windows 7 usage corresponds to the rise in Windows 10 usage. My guess is that Windows 10 will grow mostly by stealing from Windows 7 marketshare. I’ll keep an eye on this and report back in a few months.
NetMarketShare.com Desktop Operating System Market Share for 2/8/16 shows Windows 10 finally ahead of Windows XP. ‘Bout time!
There’s an interesting tool available in the Hardware Dev Center portion of MSDN: it’s called the Windows Imaging and Configuration Designer, aka Windows ICD. It’s designed to streamline the process of customizing and provisioning a Windows image. The home page for this tool states that it is designed to handle these tasks:
- View all of the configurable settings and policies for a Windows 10 image or provisioning package.
- Create Windows provisioning answer files.
- Add third-party drivers, apps, or other assets to an answer file.
- Create variants and specify the settings that apply to each variant.
- Build and flash a Windows image.
- Build a provisioning package.
Here’s the Table of Contents for digging further into this documentation (and the related tool). Note that you must first install the Windows ADK for Windows 10 before you can use this facility, and elect a specific set of options (all of which is covered in details in the “Getting Started” item below).
ICD uses a tile-based interface, and is both powerful and easy to use.
[Click image to see larger version]
|Getting started with Windows ICD||Read this topic to find out how to install and run the Windows ICD. Once you have Windows ICD running, check out the supported Windows ICD project workflows to learn about some of the things you can do using the tool.|
|Supported platforms for Windows ICD||Provides information about:
|Build and apply a provisioning package||You can use Windows ICD to create a provisioning package (.ppkg), which contains customizations that you can include for a particular Windows image. You can either apply the provisioning package to an image or share it as a standalone package that can be applied to a running system using the Provisioning Engine. For more information about PPKGs and how they are generated and applied, seeProvisioning packages.|
|Build a provisioning package with classic Windows applications||Create a provisioning package that includes Classic Windows applications and other files with your Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) devices. Uses:|
|Export a provisioning package||Export a provisioning package if you want to reuse the customizations already configured in a different project or to share it as a standalone package that can be applied to a running system during initial device setup or later.|
|Create a provisioning package with multivariant settings||Multivariant provides a generic mechanism for creating a single image that can work for multiple markets and reduce the number of images that OEMs need to create and test. It enables OEMs to dynamically configure language, branding, apps, and network settings during runtime based on the mobile operator and locale/country.
Windows 10 provisioning is an updated and enriched version of the runtime configuration or multivariant feature supported in Windows Phone 8.1. In Windows 10, multivariant is available for all Windows editions.
To provision multivariant settings, you must create a provisioning package with defined Conditions and Settings that are tied to these conditions. When you install this package on a Windows 10 device, the provisioning engine applies the matching condition settings at every event and triggers provisioning.
|Build and deploy an image for Windows 10 Desktop||You can use Windows ICD to create a new Windows 10 for desktop editions image and customize it by adding drivers, apps, language packs, settings, and more. You can also build the deployment media either to a folder or to a USB key.|
|Build and deploy an image for Windows 10 Mobile||You can use Windows ICD to create a new Windows 10 Mobile image and customize it by adding settings and some assets.|
|Build and deploy a Windows 10 IoT Core image||You can use Windows ICD to customize and create a new Windows 10 IoT Core (IoT Core) image.|
|Configure customizations using Windows ICD||You can use Windows ICD to configure the Windows device UI, connectivity settings, and user experience to better reflect your brand, to meet mobile network requirements, to comply with IT department security requirements, or to fit market segments or regions where the device will ship.|
|Use the Windows ICD command-line interface||You can use the Windows ICD command-line interface (CLI) to automate the building of provisioning packages and Windows 10 for desktop editions and Windows 10 Mobile or IoT Core images.
|Use the package splitter tool||Enterprise IT professionals who want to use a barcode to provision mobile devices during OOBE can use the package splitter tool, ppkgtobase64.exe, which is a command-line tool to split the provisioning package into smaller files.|
Just when I thought I’d seen just about everything Microsoft could do with Windows updates, the company pulled a fascinating rabbit out of its hat. I’m talking about KB3136562, a purportedly Cumulative Update to Windows 10 that bumps the build number from 10586.71 to 10586.79 but that shows up in Update History only as “Update for Windows (KB3136562). Here’s what’s interesting about this item:
- It is not yet available through normal Windows Update automatic download
- It requires manual download and installation, via the Windows Update Standalone Installer (x86 download/x64 download). This explains why those files end with the .msu file extension.
- There’s been no official word from MS about this update just yet, though numerous sources have provided coverage, including my personal fave TenForums.com and reddit.
- Most everyone who’s tried this update has reported successful installation, and it’s succeeded on 2 of the three systems I’ve tried it out on. It took some digging, but found the 0x80070BC9 error code for both failed install attempts on the affected machine.
At first, I believed that the affected machine’s use of the [en-GB] (British English) language pack, instead of [en-US] (American English) might have been at fault, but a question and reply sequence to fellow community members at TenForums disabused me of that notion. Now, I’m just scratching my head to figure out why it worked on most of my targeted PCs, but not on one of them. I’ll keep working it, of course, but such mysteries are what make working with Windows both extremely interesting and occasionally frustrating as well.
When the update installs, here’s the latest resulting WinVer output.
The big questions about KB3136562 can be stated as follows:
1. Why hasn’t MS released it through normal Windows Update channels?
2. Why is there no document page for KB3136562? (A search at Microsoft.com turns up zilch right now).
3. Why are the manual downloads available with no MS fanfare nor explanation?
If, like me, you’re incurably curious and just want to see what KB3136562 does, go ahead and use the download links provided in the bulleted list above. I’d suggest installing it only on a test machine, however, as it’s by no means a given that this update will ever be released through formal channels. Have fun!
I’ve been a big fan of Secunia’s (now part of Flexera) Personal Software Inspector (PSI) and Corporate Software Inspector (CSI) for half-a-dozen years or longer. The engine that makes both versions work scans PCs for installed software, and compares them to its sizable and comprehensive database of applications to see what’s up-to-date and what’s in need of patching or updating. But since the release of Windows 8, the software scanner engine has had a tendency to present an inert or perhaps comatose appearance to the OS long enough for it to register as unresponsive and to provoke errors that get picked up in the Windows Reliability Monitor on Windows 10.
That’s why I was glad to see the engine get an update in late January (to version 184.108.40.20604 for PSI, CSI uses the same agent on the PC clients it serves) that seems to have fixed this problem. I’m not sure what caused the lag between the software release and the OSes it serves, but it’s nice to have a good monitoring tool NOT act as a source of errors when it appears, to all intents and purposes, to be functioning properly and providing useful information and system guidance.
As far as scanning tools go, both PSI and CSI are worth checking out — and using, should your personal or corporate needs incline in their direction. This goes double, now that the latest release of the client-side engine (PSIA.exe) that works for both the personal and corporate versions of the software is no longer throwing potentially spurious “Stopped Working” errors on Windows 8.* and 10 PCs. At the UI level, the PSI scanner shows a (Not Responding) error while this situation works itself out in the background.
Note the APPCRASH error thrown by PSIA.exe on 1/2/2016: the latest release no longer does this.
Before the latest cumulative update for Windows 10 (KB3124262) appeared on 12/27, I’d already run into a problem with theKB3119142 “Update for Microsoft Visual C++ 2012 Update 4 Redistributable Package” on a couple of my PCs. I’d also fixed it fairly easily, having discovered numerous reports of this problem in various self-help repositories on the Web, most notably Answers.Microsoft.com and TenForums.com. As the repeated entries from the snippet of Update History from an affected machine shows below, the update keeps reinstalling and reinstalling though each installation is reported as “successfully installed.”
The fix, as it happens, is pretty straightforward, so I’ll provide step-by-step instructions:
- Open Control Panel
- Open Programs and Features
- Scroll down and right-click the entry that reads “Microsoft Visual C++ 2012 Redistributable (x64) – 11.0.61030
- Select “Repair” from the resulting pop-up menu
- Once the repair completes, reboot your PC if requested to do so
I haven’t yet found an explanation as to why this is happening, but it stops the endless cycle of repeated reinstallations cold. Given that 3 of my 7 current PCs experienced this issue, and that I see hundreds of reports from others suffering likewise, I have to believe this is a reasonably widespread phenomenon. Thus, I’m hopeful that an understanding that this problem, while vexing, is not terribly serious, along with a recipe to bring it to a screeching halt, will be helpful to those legions of Windows administrators out there. Given access to a decent automation facility such as PowerShell, AutoIt, WinAutomation, or something else in the same vein, one could easily script a quick utility to execute this repair on any and all affected machines during the next scheduled data cycle using your normal deployment tools.
The following screen capture makes it crystal clear as to the obvious symptoms that manifest when this issue is present on a Windows 10 PC (I count 10 recurrences in a 5-day period). If you start seeing something like this, now you know what to do!
Though successfully installed, KB3119142 keeps going like the Energizer Bunny.
On January 19, Microsoft released a System Firmware Update for the Surface Pro 3 that included an item related to Pen settings for the Surface Pro 4 Pen. In the wake of numerous subsequent reports of crashes and blue screens resulting from this item, MS has removed it from that firmware update (details appear under a “January 2016” heading on the Surface Pro 3 update history page). Alas, however, many people — including yours truly — had already updated their firmware with the original package that included the now-missing Surface Pro 4 Pen settings element.
Here’s how you can tell if your Surface Pro 3 is affected. In Device Manager, open the Human Interface Device entry, and check the version number for the driver associated with the Surface Pen Settings element. If your driver version is numbered 10.0.302.0, dated 10/22/2015, you’ve got the version associated with the Surface Pro 4 Pen installed; the most up-to-date version for the Surface Pro 3 Pen Settings is actually numbered 220.127.116.11, dated 3/20/2015.
The easiest fix for this potential gotcha is to simply click the “Roll Back Driver” button in the Surface Pen Settings Properties window on the Driver tab. This will automatically de-activate the 10.0.302.0 driver, and re-activate the 18.104.22.168 driver that preceded its installation. I followed a set of instructions from Liam Tung at ZDnet that had me uninstall the 10.0.302.0 driver, then restart the Surface Pro 3, which was supposed to automatically re-install the 22.214.171.124 driver by itself. Instead, I wound up with an Unknown Device in Device manager, which I was able to fix by pointing its Update Driver function at my local copy of the 126.96.36.199 driver already resident in my DriverStore folder.
I have to believe that the rollback fix is easier than digging into device designations (it took a while) to find the right one for the Surface Pen Settings item. But, all’s well that ends well, and now my Surface Pro 3 is humming happily along with no signs of crashes or blue screens in sight. Just another day in Windows-World, eh?
OK, now that’s more like it: proper driver now replaces improper SP4-only version.
The Technical Preview version of Microsoft’s System Center Configuration Manager (SCCM) offers some pretty tasty capabilities, including up-to-date support for Windows 10, handling for Windows in-place upgrades, a sped-up update cycle to track the more rapid Windows 10 update cadence, and on-premises mobile device management (MDM). There’s a lot to like about it, but also a lot to do with it, too.
That’s what makes the System Center Configuration Management Cmdlet Library worth digging into, for those who work with any of the latest SCCM releases. After you download that library, it will receive the ongoing updates that MS publishes for this environment automatically. It’s based on the Windows PowerShell module for SCCM, and brings all kinds of interesting automation capabilities into the SCCM environment, and is designed to help manage a Configuration Manager hierarchy using PowerShell Cmdlets and scripts. The only requirements to grab and use this toolset are access to Windows PowerShell 3.0 or newer, and a current SCCM console (2012 or newer).
To help you dig further into the subject matter, here are some relevant technical references and information:
Technical reference for SCCM (TechNet, 12/8/2015)
How to build a lab environment to evaluate SCCM (TechNet, 12/15/2015)
Documentation for SCCM (TechNet, 12/15/2015)
Find the most advanced features for SCCM in the ongoing Technical Preview (60-day eval, including Endpoint Protection) or Technical Preview2 (180-day eval, SCCM only)
Using Windows PowerShell (TechNet, 10/17/2013)
The System Center Configuration Manager Cmdlet Library (Developer Network/PowerShell Docs); see also the Technical Preview version, though currently only Operations Manager items are available.
SCCM Cmdlet Reference (TechNet, 2/7/2014)
For those just getting into PowerShell, the MSDN PowerShell pages are also worth digging into. There is a plethora of books available on this topic — as this Amazon Search shows clearly — though you’ll want to concentrate on versions 3.0 and 4.0 (the latest releases as I write this post).
The latest SSCM offers terrific deployment and management capabilities that include Windows 10 on the desktop, plus in-place upgrades.
Be sure to check all this out!
VDI has always faced an uphill slog. Implementation is time-consuming and expensive. The technology only fits certain use cases, and with so many moving parts and people to please, a lot of problems can crop up.
If your higher-ups are on board with doing VDI and you get the infrastructure right, one of the last hang ups you might encounter is user acceptance. If workers don’t want to use their virtual desktops, your project is as good as dead. Virtual desktops and applications must work when users need them, and they need to work well. They should be fast, responsive, and easy to access.
When employees use graphically intensive applications, such as CAD or architecture apps, they press a particularly sharp thorn into your VDI deployment’s side: Graphics are resource hungry, and when they don’t get what they need, they get laggy and slow. When applications are laggy and slow, workers aren’t happy, and anyone who’s ever handled a help desk ticket knows what unhappy workers can be like.
Fortunately, graphics processing unit (GPU) cards, emulation and virtualization are all viable options to improve performance.
GPU emulation is cheap, but it won’t help much with very needy applications. GPU cards can get pricey if you have to support many people, but a dedicated GPU is a power user’s dream come true. If you can’t afford to match one GPU to every one of your users, you can virtualize it or share it among users.
No matter how many users need graphics support, it’s likely there’s a GPU option that fits, and our new handbook, GPUs Bring Lightning-Fast Apps to Virtual Desktops, has the information you need to make an informed decision.
In case you missed the news, MS has issued a recall on the power cords from all Surface Pro, Surface Pro 2, and Surface Pro 3 models sold before March 15, 2015. As the owner of a Surface Pro 3 purchased on 3/14/2014 — according to my online warranty info for the device — I’m entitled to claim a replacement, as are others who own Surface Pro machines of the proper vintage.
Always glad to avoid potential hardware troubles or failure, I visited the “Microsoft AC power cord recall…” web page to request my replacement unit. To complete that process, I had to first sign into my Microsoft account, verify my ship-to information, select my Surface Pro 3 device by serial number, and then submit the replacement request. The whole shebang took less than a minute to complete, and didn’t require me to jump through any unduly unpleasant hoops. One must, of course, have registered all Surface Pro units beforehand to make it this simple, or register all such units before requested cord replacements. For those who must do this for multiple Surface Pro units, as in many businesses where IT will request them en masse, it’s a good idea to print out a list of their serial numbers in advance, because that’s the identifier that MS uses to distinguish among such units. And alas, AFAIK, a separate replacement request must be submitted for each affected Surface Pro unit on a one-off basis.
Here’s the culprit, which apparently suffers from shorting potential if the cord itself is tightly wound or sharply kinked.
I hadn’t noticed any signs of trouble with my power cord, but then again, I mostly use the AC cord that plugs into the Sruface Pro 3’s dock enclosure anyway. It is not subject to the same recall (nor would one need to mess with its power cord much anyway, under ordinary circumstances). That said, it’s nice to benefit from Microsoft doing things right, and making it easy for its affected customers to participate in a recall.