Newsletter Archives

  • Patch Lady – That SMB issue isn’t SMB

    As a follow up to Woody’s earlier post on the issue of  KB4480970 (Monthly Rollup) and KB4480960 (Security only) causing issues with networking and discussed on the Patch Watch Podcast, an interesting factoid about the Windows 7/Server 2008 R2 bug of this week:

    It’s not due to SMB, but NTLM bug.

    Ned Pyle on twitter (and summarized here) states that:

    You will NOT have this issue if you’re using Kerberos. I.e, with a Domain user that is connecting to remote share by DNS or NB name & not IP address

    You won’t have this issue if you are NOT a local administrator on SMB host

    You will NOT have this issue if your SMB host is running Windows 8, 8.1, 10 or Windows Server 2012, 2012 R2, 2016, 2019

    Furthermore, it already looks like the issue has been resolved in a new KB https://support.microsoft.com/en-us/help/4487345 … which appears to only be released on the Microsoft catalog site at this time and not through Windows update.   Which may I point out is a bit odd since many hitting this are … cough … not in a domain and thus wouldn’t be behind WSUS and would only experience Windows update as their patching mechanism.

    If you are impacted the other workaround is showcased in https://support.microsoft.com/en-us/help/951016/description-of-user-account-control-and-remote-restrictions-in-windows that has the fixit version of the registry key workaround.

    One could argue that it’s bad running as local administrator (it is).  One could argue that one needs to ensure you are moving off sharing files on a Windows 7 or Server 2008 r2 given that it has about a year’s life left (unless you have an uber expensive premier support contract and plan to be buying extended support for Windows 7/Server 2008 R2).  But one could also argue that Microsoft is once again showcasing that it’s not testing patches across a wide range of scenarios.

    The reality is that we still have a ton of crappy line of business software that demands local administrator, and the reality that we have workhorses called Windows Server 2008 R2 and Windows 7 that until the feature release process settles down (I’m looking at you 1809 for the number of consultants I see complaining about excessive CPU, the need to constantly install updated drivers, and interactions with printers that worked fine with prior feature releases) as a reason that Windows 10 still needs to act like the adult it’s supposed to be and be dull and boring as it should be instead of annoying and petulant like it is.

    Until then, download that patch from the Microsoft catalog site and go back to keeping an eye out for any other issues on the first official “B” Patching week of the 2019 patching year.

     

     

  • I blew it again

    For the %$#@!th time in a few years, I’ve completely blown a bit of sleuthing.

    Earlier this week, I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. The cause? Win7 PCs attached to corporate networks were suddenly declaring themselves to be disingenuous. Or not genuine. Whatever.

    I looked into the problem early in the cycle and figured it was an error due to this month’s Win7 patches, KB 4480970 and KB 4480960, somehow aided and abetted by an ancient Win7 patch known as KB 971033. Looked like a duck. Projectile pooped like a penguin.

    Ends up, I was wrong. @abbodi86 pointed out — and Microsoft has confirmed — that the bug lies in its Activation update servers, which just happened to be changed at the same time the Win7 patches went out. The bug only affects Win7 activation on machines that have KB 971033 installed. Sometimes a projectile pooping penguin duck is a phantasy. Say that ten times real fast.

    I’m wrong. They’re right.

    Don’t worry. It’ll happen again.

  • January patches for Win7, KB 4480970 and KB 4480960, break networking

    Tell me if you’ve heard this one before.

    I first read about it on Günter Born’s site, but word is starting to spread:

    The KB4480970 (Monthly Rollup) and KB4480960 (Security only) updates were released by Microsoft on January 8, 2018 for Windows 7 SP1 and Windows Server 2008 R2 SP1. The updates seem to cause serious network issues for some people. Network shares can no longer be achieved via SMBv2 in certain environments.

    Details in Computerworld Woody on Windows.

    UPDATE: Martin Brinkmann has further details:

    The issue is triggered only if the user attempting to make the connection is an administrator on the machine that hosts the Share. If the user is “just” a user on the device that hosts the share, the connection should be fine.

    (Some of you ask why I quote Günter and Martin so frequently. Ends up, they’re in the right time zone — they get the bad news before it’s circulating widely in the US — and they both have excellent eyes for screw-ups. Of which there are many.)

    ANOTHER UPDATE: It’s possible that this is another manifestation of the oem<number>.inf issue that’s documented in the KB article — the same bug that’s been acknowledge by MS since April. But the descriptions I’m seeing are different. In particular, Brinkmann’s description above doesn’t sound anything like the oem<number>.inf NIC failure.

    Anybody have more details?