News, tips, advice, support for Windows, Office, PCs & more. Tech help. No bull. We're community supported by donations from our Plus Members, and proud of it
Home icon Home icon Home icon Email icon RSS icon
  • Win7 Enterprise clients reporting “Not Genuine”, 0xc004f200, when they’ve been working for years

    Posted on January 9th, 2019 at 16:38 woody Comment on the AskWoody Lounge

    Blame KB 971033, which shouldn’t even get installed on KMS-controlled machines.

    For some unknown reason, earlier today, Microsoft suddenly started pushing the eight-month-old KB 971033 — an “update for Windows Activation Technologies” that was released on April 17.

    I’m seeing cries of pain all over the internet. For example, torontojc reports on the Reddit sysadmin forum:

    Woke up this morning to find a few thousand Windows 7 VDI machines reporting that Windows 7 wasn’t genuine. After much troubleshooting we found that KB971033 (should not have been installed in a KMS environment in the first place) was installed on these machines. Until today having this KB installed hasn’t been an issue, it appears a change to how Microsoft’s activation servers respond to a standard KMS key being sent to them may be to blame.

    Removing the update, deleting the KMS cache and activation data from the PC’s and re-activating against KMS resolved the issue.

    Most of the responses recommend uninstalling the patch then reaming out the systems, but Nick on Microsoft’s TechNet forum says:

    I found that the only steps I required were as follows. I didn’t need to uninstall the KB971033 patch in my case, even though it was installed. Nor did I need to delete the tokens.dat or cache.dat.

    net stop sppsvc
    del %windir%\system32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-0.C7483456-A289-439d-8115-601632D005A0 /ah
    del %windir%\system32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-1.C7483456-A289-439d-8115-601632D005A0 /ah
    net start sppsvc
    slmgr /ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
    slmgr /ato

    We are currently trying to decide whether to roll out this workaround to all our clients, or to wait a day or two to see if Microsoft issue a patch for the problem. It has been widely reported on Reddit/r/sysadmin too.

    If you hit the problem, let us know how you solved it.

    UPDATE: Looks like it wasn’t a problem with this month’s patches. It’s a bug in a change MS made in the way its Activation Servers behave, that just coincided with the patch push. The bug sets off red lights if you have the old KB 971033 installed. @abbodi86 has details and a link here. Günter Born has an article here. And Martin Brinkmann has more details here.

  • AskWoody’s security certificate is back and all is well in this, the best of all possible worlds

    Posted on January 9th, 2019 at 06:35 woody Comment on the AskWoody Lounge

    … with apologies to Leibniz.

    Good news on the Plus Membership front, too. The bugs are disappearing slowly. More info shortly, I hope.

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

    Posted on January 9th, 2019 at 06:18 woody Comment on the AskWoody Lounge

    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?