Tag: Windows 7

Microsoft January 2019 KB4480970 Patch – KMS Activation Errors – UPDATED

I’ve seen a few cases of this now in the wild within my organisation, where previously activated Windows 7 devices would suddenly report that they were no longer activated. On running “slmgr /dlv” I could see that the client reported as unlicenced, with the notification reason as “0xc004f200 (non-genuine)“

This appears to be another instance of the infamous KB971033 which has caused this in the past, which seems like it might have resurfaced as part of the January 2019 – KB4480970 rollup update and KB4480960 security only update

Listed under known issues is;

KMS Activation error, "Not Genuine", 0xc004f200 on Windows 7 devices.

So, it would appear that this is the cause of the activation problem in this case. The fix is as follows;

wusa /uninstall /kb:971033 /quiet
net stop sppsvc  /y 
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
del %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\tokens.dat
del %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\cache\cache.dat
net start sppsvc
cscript %windir%\system32\slmgr.vbs /ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
cscript %windir%\system32\slmgr.vbs /ato

Don’t forget the Windows 7 key in my example above is for Windows 7 Enterprise, grab the right key for your edition of Windows 7 from Microsoft’s KMS Keys Page.
This should remove the offending update and re-activate the copy of Windows against your KMS server.

UPDATE
Microsoft have confirmed that the Windows activation problem is, in fact, unrelated to the January 2019 update, and is in fact caused by a separate update to Microsoft Activation and Validation and has since been reverted by them

Cisco AnyConnect “Failed to initialize connection subsystem” Error When Connecting to VPN on Windows 7 or Windows 8

I just today I tried to connect to my work network from home using the Cisco AnyConnect client, for reference I’m using AnyConnect 3.1.05182 on Windows 8.1, and was unable to. I was immediately presented with an error before even being asked for a username and password, which said something was wrong with the client, as it hadn’t really had time to start any proper negotiations with the ASA.

A little bit of Googling revealed that the problem might have come from a recent Microsoft update, dated just a few days ago. I had noticed my machine downloading a few updates of late, and I’m nowhere near as diligent with testing updates on my personal machine as I should be, or as I am on any work related systems.

It turns out that this is indeed a bug with the latest set of Microsoft patches, and Cisco confirmed this here.

While Cisco have said ultimately the fix has to come from Microsoft, there is a workaround until a permanent fix is produced;

  • Close the AnyConnect client from the system tray
  • Navigate to the AnyConnect client install location, for example “C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\”
  • Right click on the vpnui.exe and click troubleshoot compatability
  • Pick “Try recommended settings”
  • Click “Test Program” and this will reopen the AnyConnect client
  • Repeat the same process again, but for vpnagent.exe

    • On the final test when the AnyConnect client opens again, you then find that you’re able to connect normally again. If you have Cisco support it would probably be valuable opening a TAC case and mentioning case number #115021112390273. This bug does also affect Windows 7 when IE11 is installed, and the same fix should work there too.

    Force Password Check With PDC When Login Failure Occurs

    I didn’t even know this setting existed as an option within Group Policy, but then again, Group Policy is a bit of a beast at the best of times.

    So, the PDC emulator is responsible in the domain for handling password replication to other domain controllers, a password change occurs on the PDC and this is then replicated out to all other domian controllers. But what if you have a large infrastructure and the password change hasn’t replicated out yet to the domain controller being used by a client to authenticate? Well there’s a policy setting you can apply to your domain controllers, that forces them to check with the PDC in the event they deny a logon request due to a bad password. The setting is called “Contact PDC on logon failure” and it is briefly detailed on TechNet, and within the Group Policy editor, lives at the below location;

    Computer Configuration\Policies\Administrative Templates\System\NetLogon

    Use with caution though, if used on domain controllers on slow WAN links, this will create a lot of traffic to the PDC, and in general it can create a lot of load on the PDC in large environments.

    Using Full DVD/CD Writing Capabilities in a Hyper-V VM

    See the note at the end of the post before implementing this
    Normally when you pass an optical drive through from the hyper-v server to the guest OS in a VM it can act as a read only device, even if it has writing capabilities.  This is a limitation of Hyper-V.

    However this can be worked around using iSCSI.  Microsoft now make available their own iSCSI target software, but unless I’m mistaken that cannot share optical drives.  Alcohol 52% Free Edition contains the ability to setup an iSCSI target device which you can then connect to from Windows 7 and will handle optical drives.

    Alcohol 52%

    Install Alcohol 52% on the host OS, ignoring all the crapware and reboot as required.  Then start the application and look down to the bottom towards the list of drives.  Right click on the drive you wish to share and click sharing;

    Then highlight the drive and click the new share button.

    Give the share a name and highlight “share read” and “share write” then click ok

    Back on the sharing window go to the options tab, enter a username and password and make sure the service is started and the startup type is automatic, this will ensure it still runs after a reboot.

    Finally click ok and this completes the section on the host OS.

    On the guest OS under Administrative Tools start the iSCSI initiator.  Under the discovery tab click discover portal and enter the IP address of the host OS, leaving the port the same and click ok.

    Then head back to the targets tab and click refresh.  The iSCSI device setup should show, highlight it and click connect.  Then on the next window click ok, leaving the details the same.

    Finally the iSCSI device should show connected and if you check your connected drives you should see the device listed in My Computer.

    Job done.

    Note: I salvaged this from a very old version of my blog, I know it applies to Hyper-V in Windows Server 2008 R2, but I’ve not tested this on any versions of Server 2012. This will work if you’re in a pinch and need it, but I couldn’t really suggest this for use in a production environment