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 18.104.22.168, 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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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.
Wow! Has there been a lot of Windows 10 action at the enterprise lately, or what? The Internet has been abuzz with everything from rants to raves for enterprises interested in — or already piloting or deploying — Windows 10. In fact, I can’t help but see something of a “stick and carrot” approach emerging from Microsoft in making the case for Windows 10 to its all-important enterprise user base.
On the carrot side, there’s been some interesting coverage of enterprise adoptions of Windows 10 that are worth researching further for interested parties. On January 12, Terry Myerson, MS’s EVP for the company’s Windows and Devices Group posted an item entitled “Windows 10 Embracing Silicon Innovation” to the Windows Experience blog. It actually speaks to both sides of a carrot-and-stick dynamic where enterprise adoption of Windows 10 is concerned.
Walk Softly, But Carry a Big…
There’s little difficulty seeing the stick side of things in this statement regarding upcoming chips and chipsets:
Going forward, as new silicon generations are introduced, they will require the latest Windows platform at that time for support. This enables us to focus on deep integration between Windows and the silicon, while maintaining maximum reliability and compatibility with previous generations of platform and silicon. For example, Windows 10 will be the only supported Windows platform on Intel’s upcoming “Kaby Lake” silicon, Qualcomm’s upcoming “8996” silicon, and AMD’s upcoming “Bristol Ridge” silicon.
I don’t think it’s unfair to characterize this statement as equivalent to “If you want the latest and greatest new circuitry, you’re going to have to run Windows 10 thereupon.” I can’t help but see this as a way for Microsoft to limit its need to develop multiple versions of device drivers — particularly at the device class level, where it often takes the lead in creating driver frameworks that manufacturers can then customize and optimize for their particular device offerings — or at least to test those device drivers on “current” (i.e. mainstream supported) operating systems. I have no trouble understanding why they want to do this, but I also have no trouble understanding why I surely won’t be the only one to see the stick in this statement, particularly amidst the enterprise audience. Ditto for Myerson’s later statement in the same blog post that Skylake support for Windows 8.1 and 7 will apply to “devices on the supported list” until July, 2017, after which only the most critical security updates will be addressed for those configurations…
If you read carefully here, both carrot and stick are evident in this MS slide.
Carrots Help One See Better in the Dark
In the same blog post, Myerson also reports on Windows 10 action in its enterprise customer base, “with more than 76% of our enterprise customers in active pilots and over 22 million devices running Windows 10 across enterprise and education customers.” Quotes from Kimberly-Clark, the Australian Government’s Department of Human Services, and NASCAR Information services touting improved security, speedy deployment, and identity management follow. MS is doing everything it can do position Windows 10 as a useful and productive desktop OS for business use, and pulling out all the stops in getting its message out.
In the end, it’s sometimes hard to tell which of the carrot and the stick proves the most powerful inducement to change. It’s clear that MS understands it must use all the means at its disposal to move enterprises forward onto Windows 10, whether lured by anticipation of improved security and capability, or forced by the inexorable forward move onto the latest silicon platforms.
Thanks to a recent story on WinSuperSite, a positive and powerful benefit of Windows 10’s new “Windows as a Service” posture is now evident. Because the Windows Update stream includes regular Cumulative Updates –they’ve occurred once or twice monthly, since the release of Build 10240 in July, 2015 — the process of catching Windows up from a clean install involves much, much less time and effort than for either Windows 7 or Windows 8.1.
In his 1/18/16 story entitled “Windows Updates versus Cumulative Updates,” Richard Hay explains what he observed in updating all of the virtual machines he uses for testing, which currently includes VMs for Windows 10, Windows 8.1, Windows 7, and even Windows XP. Omitting the totally obsolete outlier (XP), here’s what he observed after creating new VMs for each of those (newer) operating systems:
- The Windows 7 VM needed over 50 items from Windows Update to be installed to achieve currency, for VM with a “freshness date” of July 2015 (the same time that Windows 10 was released).
- The Windows 8.1 VM needed over 170 items from WU to do likewise.
- The Windows 10 VM only needed the latest Cumulative Update (released last Tuesday, 1/12) plus other updates from that day to achieve currency (under half-a-dozen)
Extrapolating from Hays’ observations, and my own understanding of how WU works, in general this means that catching up a clean install of Windows 10 at any given moment will require applying only the most recent CU plus whatever other updates were released along with it, and any that have been released since that date. My best guess is that because CUs are released at least monthly these days, that the total number of updates for Windows 10 that would be required under any circumstances would seldom top one dozen. That’s a nice improvement over the 50-plus updates that Windows 7 requires for an image current as of July 2015, and a massive improvement over the 170-plus required for Windows 8.1.
Windows as a Service offers at least one powerful benefit: faster clean installs.
[Image Source: Supersite for Windows, 7/17/15.]
Who knows: maybe there really is something positive to the whole “Windows as a Service” thing, after all? IMO, this is a pure and unalloyed benefit of the new streaming updates approach inherent in that implementation. Even for business users, who probably won’t be on the Current Branch version of the OS, this benefit still adheres, because their branch (“Current Branch for Business”) will also be easy to make current as of its most recent Cumulative Update as well. Ditto for Long-Term Servicing Branch, too, in fact.
As part of the most recent “Patch Tuesday,” MS pushed Cumulative Update KB3124263 out to all Current Branch users for Windows 10. As sometimes happens, this caused some settings in the runtime environment to be reset. Perforce, this meant reaching out to restore such tweaks as I find useful or necessary and in so doing, I was reminded of a tip I wanted to add to this blog a while back, but forgot to document.
The only way this shows up on the Windows desktop is if you tell File Explorer to show hidden files.
While I like to see hidden items in the Windows file system in the vast majority of instances — especially as they pertain to system files and other normally obscured aspects of the OS — I don’t like my desktop cluttered up with irrelevant icons, either. Selecting the “Show hidden files, folders, and drives” option in the File Explorer Options widget in Control Panel applies that policy everywhere, which means the display shown above here (with two instances of “desktop.ini” on my personal desktop) is what happens when that selection is made.
But for those who’d like to tidy those items away, including me, there’s a quick and simple trick to hide them from view. In File Explorer, navigate to the Desktop (I simply select the Desktop entry in the left-hand pane beneath the “This PC” entry), then click the View tab at the upper left. If you simply uncheck the “Hidden items” checkbox in the “Show/hide” area of the ribbon UI at the top, desktop.ini will no longer appear on the desktop.
I’d also wondered for some time why I kept seeing two instances of desktop.ini appear. Checking the Details tab data after right-clicking the icons, then selecting Properties, I learned that one of those items belongs to the current logged-in user account, while the other comes from the Public folder that applies to all user accounts. Using this technique happily hides both of those entries.
When I started working on SearchEnterpriseDesktop, I thought it would be easy. I was wrong.
The information that IT administrators need about Windows isn’t always easy to find—and it’s often difficult to digest. There are so many versions and editions of the OS, each with its own quirks, and every organization’s deployment is unique. As a result, Windows admins have some really important questions, especially when it comes to Windows 10: Is it really free? How do I get it? Should I upgrade? What do I need to know before I migrate? And how the heck do I get off Windows XP?
For starters, only some versions of Windows 7 and 8.1 are eligible for the free upgrade, and there are a few steps in the download process that might seem a little foreign. Getting continued updates from Microsoft is different in Windows 10, too. Instead of the monthly Patch Tuesdays of the past, smaller and more frequent fixes and feature updates will come down the pike. And as for the question of getting off Windows XP, the answer is simple, but it’s not one admins will necessarily want to hear: Get ready for a clean install.
Download this three-part handbook to get even more answers and learn about the shiny new Windows 10 operating system.
Reading over the recent forum posts at Spiceworks this morning, a thread entitled “Windows 10 reinstalls after July 2016?” caught my eye. Inquiring readers want to know when the automatic key recognition from an earlier Windows 7 or Windows 8 installation on revamped Windows 10 hardware will quit working. In other words, how much does the hardware in a system have to change before it is no longer recognized as the same computer that was upgraded? In post 17 in the thread, an MS employee named Chris Le Texier provides a pretty definitive answer.
Anything up to, but not including, a motherboard change should still permit Windows 10 to be reinstalled on an upgrade key.
Le Texier goes on to cite a passage from the Windows OEM licensing FAQ to support his position, including the kind of argument someone will have to make with Microsoft (namely, that the mobo was replaced to repair a defect if it is not identical to the original, as provided in the manufacturer’s warranty) to re-activate that key, if necessary. Interestingly enough, this appears to indicate that when the warranty period ends, subsequent motherboard replacement will indeed require obtaining a new license, or burning another license from an organization’s supply under some kind of volume licensing agreement.
Now we know!