Microsoft patch problems persist: bad release sequences, CRM blocks and more

[Karlston]

Blue screens, bungled releases, stealthy .NET upgrades, CRM blocks and complex manual fixes. October is shaping up to be one heck of a patch-encumbered month.

Thinkstock

We’re sitting at PT+2 — two days after Patch Tuesday — and the problems continue to roll in. Here are the latest mug shots in a rapidly devolving rogue’s gallery.

 

If you’ve been following along, you know about the initial problems I reported on Tuesday — the Word zero-day, TPM patches that don’t patch, known and acknowledged bugs in Windows patches. You saw the late bloomers I reported on Wednesday — delayed, failed and rolled back Windows patches, a non-existent Flash update, confusingly no .NET security patches, an incorrect description of the CVE-2017-11776 fix, and more TPM follies.

 

You ain't seen the half of it yet.

Delta Updates and Cumulative Updates

On Tuesday afternoon, @mobartz reported on AskWoody:

 

For the first time, I’m seeing Delta Updates for Win 10 1607 and 1703 along with the regular Cumulative Updates. This is on our WSUS server.  I thought the deltas were only for non-WSUS environments…

Then on Wednesday morning:

The delta updates KB4041676 and KB401691 for Windows 10 version 1607 and 1703, as well as Windows Server 2016, were all expired some time after the initial release to WSUS. So it looks like it was a mistake that Microsoft corrected.

@derzeitgeist has the details, quoting a Microsoft account rep:

Somehow they [Microsoft] published both the cumulative update, and the delta (express) update to both WSUS and SCCM. This should never happen. There is no issue with the Windows 10 or 2016 Cumulative but only an issue when both the Cumulative and Delta are installed on a machine together. All customers should re-synchronise their WSUS / SCCM server and the Delta Updates Binaries will be expired.

He then says:

Even though they say SCCM should have been affected, for some reason only pure WSUS-based systems seem to have been affected here. We are migrating to a SCCM SUP, and the Automated Deployment Rule that I’ve been testing didn’t hose any of the potentially vulnerable systems. Since WSUS is used by either method, I’m not sure what the difference was. All I can say is that it behaved differently with pure WSUS vs. SCCM.

Early Thursday morning, Microsoft re-posted a mea culpa, called Windows devices may fail to boot after installing October 10 version of KB4041676 or KB4041691 that contained a publishing issue, in which the powers that be fessed up to the mayhem they created. They describe three different scenarios — depending on whether WSUS/SCCM was synced before 4 p.m. on Tuesday, and whether you can boot — with manual workarounds for each. Those of you who face hundreds or thousands of machines with blue screens and INACCESSIBLE BOOT DEVICE have a Herculean task ahead.

 

If you have to manually remove installation packages from a machine (“Scenario 3”), derzeitgeist’s final recommendation may help:

One or more of the “remove-package” commands may fail. Just move on to the next one if that happens until all 3 packages have been addressed. Reboot and wait for Windows to try to load. If some part of the packages couldn’t be removed, the system will try to complete the process. Be patient while it tries to complete, and everything should be restored to working order.

This thread on the Microsoft Answers forum contains several additional suggestions.

 

There’s a general overview of Monthly Delta Updates on Microsoft’s docs site. It lays out, in black and white, why you can’t install both the Cumulative and the Delta updates on the same machine. Pity the folks who fed WSUS didn’t read the article.

 

Think of it as the admin full employment effort.

 

It’s important to note that these problems only affect sites using WSUS or SCCM to control rollout of Windows patches. For those of you admins who let this one through, now you know why I don’t recommend setting your servers to automatically approve updates. There’s a good discussion about rollout strategies in this Reddit thread. I can’t imagine any admin trusting Microsoft after this blargefest.

 

But that’s not all. Oh, no.

.NET 4.6

If you’re trying to hold onto .NET 4.6, you’re losing the battle. Microsoft's moved your cheese, without telling you. According to @abbodi86:

Starting July 2017, all .NET 4.6/4.6.1/4.6.2/4.7 updates have been reconciled into one rollup update that is based on 4.7 binaries version — meaning, your .NET 4.6.x version is transforming into 4.7 under the hood… so [if you want to stay patched,] the best decision would be to install 4.7 itself or install .NET 4.5.2, which is still [getting updates] separately

Problems importing XLS files

If you’re seeing problems importing XLS files into your applications, you aren't alone. See this anonymous post on AskWoody:

I have to report a bug, or is it a “feature” maybe, with the 2017-10 Security Monthly Quality Rollup for Windows 7 for x64-based Systems KB4041681 and 2017-10 Security Only Quality Update for Windows 7 for x64-based Systems KB4041678.

Yesterday we got bombarded with the problem that we can not import an xls file into our application, which we have been doing since forever. It gives an error: Unexpected error from external database driver (1). We dug deeper and discovered

Provider=Microsoft.Jet.OLEDB.4.0;Data Source={0};Extended Properties=\”Excel 8.0;HDR=Yes;IMEX=1\”

Doesn’t work anymore. After we removed both updates, everything was back to normal.

Lost network connectivity

Then there’s the one about getting kicked off the network, from @AlexEiffel:

Last month after the automatic patching of Windows Server 2012 R2, my domain got unassigned from the network card and I lost all possibility to connect to the SQL database for the accounting package. This month, same thing, right after the automatic patching during the night. Nobody able to work in the morning. I don’t manage this server. I don’t know Windows Server, I don’t use it.

The trick was to simply disable the network card, then reenable it. Quickly realizing the network was public and not domain, I tried things for an hour with a consultant last time before finding that: restarted, registry tricks, manually assigning the domain to the private network…

More problems

Then there’s this report, also from an anonymous poster:

I installed KB4041689 last night — against Woody’s advice. [ahem - Ed] But I thought, last update for 1511, gonna have to do it sometime, why not now? Screwed up everything. Dialog boxes in file explorer buggered. Uninstalled it less than an hour after it finished. Back to normal. Why does MS do this to us?

Even Microsoft’s own Dynamics CRM got hit. The official CRM support site includes this post from jsrobertso:

Getting an error when using the Outlook Add-In for Outlook 2013. Retrieval of a page from a CRM server failed due to an error.

RedHermit says:

I encountered this same problem. Functionality was restored after removal of KB4011178 in my testing. Issue seen in the following environment: Outlook 2013 32bit / CRM Server 2011 / Various CU's for Outlook client testing

And flyingflea points at a different patch:

Uninstalling Security Update for Microsoft Outlook 2010 (KB4011196) fixed MS Dynamics CRM 4.0 for Outlook 2010 for us.

Ready to install the October Windows and Office updates? Blerg.

 

There's a reason why I recommended, and continue to recommend, that you hold off. Avoid the rush to patch. Wait for Microsoft to get its act together — or, at the very least, wait for folks to identify the most offensive patches so you can avoid them.

 

It’s so bad I started a new thread on the AskWoody Lounge.

 

Source: Microsoft patch problems persist: bad release sequences, CRM blocks and more (Computerworld - Woody Leonhard)

[BDX]

No problems here.

[nIGHT]

This is why we need to have the power when to download and install wup, but already block it

Need to migrate to the latest version.