none
one KMS client suddenly cannot activate - Non authentic message, that is not true RRS feed

  • Question

  • Hi,

    2 KMS servers in place in large environment.

    Functioning flawlessly.

    Today got a request for one W7 machine that is on network for at least couple of years.

    The problem is that it cannot activate from KMS, with falce visual message that it is not authentic.

    After some basic diagnostics I have to ask forum. There are similar topics on web, but I have my MGADiag output.

    Prior to ask... checked that the machine properly see KMS servers populated by DNS.

    Telnet connection is fine.

    So, see plz MGADiag... I never saw this thingy, so would like to have a solution in case there will be more machines with the same symptom.

    I can try to enter MAK address tomorrow, now not sure if it will help in case of KMS client corruption or else...

     Diagnostic Report (1.9.0027.0):
    -----------------------------------------
    Windows Validation Data-->

    Validation Code: 50
    Cached Online Validation Code: 0xc004c4a2
    Windows Product Key: *****-*****-J8D7P-XQJJ2-GPDD4
    Windows Product Key Hash: xgsndMkYdJsYmUng0qIJ/thx+HI=
    Windows Product ID: 00371-868-0000007-85570
    Windows Product ID Type: 1
    Windows License Type: KMS Client
    Windows OS version: 6.1.7601.2.00010100.1.0.048
    ID: {234352AF-9C25-4791-9609-9DC91D989E5A}(1)
    Is Admin: Yes
    TestCab: 0x0
    LegitcheckControl ActiveX: N/A, hr = 0x80070002
    Signed By: N/A, hr = 0x80070002
    Product Name: Windows 7 Professional
    Architecture: 0x00000009
    Build lab: 7601.win7sp1_ldr.181111-0600
    TTS Error: 
    Validation Diagnostic: 
    Resolution Status: N/A

    Vista WgaER Data-->
    ThreatID(s): N/A, hr = 0x80070002
    Version: N/A, hr = 0x80070002

    Windows XP Notifications Data-->
    Cached Result: N/A, hr = 0x80070002
    File Exists: No
    Version: N/A, hr = 0x80070002
    WgaTray.exe Signed By: N/A, hr = 0x80070002
    WgaLogon.dll Signed By: N/A, hr = 0x80070002

    OGA Notifications Data-->
    Cached Result: N/A, hr = 0x80070002
    Version: N/A, hr = 0x80070002
    OGAExec.exe Signed By: N/A, hr = 0x80070002
    OGAAddin.dll Signed By: N/A, hr = 0x80070002

    OGA Data-->
    Office Status: 109 N/A
    OGA Version: N/A, 0x80070002
    Signed By: N/A, hr = 0x80070002
    Office Diagnostics: 025D1FF3-364-80041010_025D1FF3-229-80041010_025D1FF3-230-1_025D1FF3-517-80040154_025D1FF3-237-80040154_025D1FF3-238-2_025D1FF3-244-80070002_025D1FF3-258-3

    Browser Data-->
    Proxy settings: 
    User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
    Default Browser: C:\Program Files\Internet Explorer\iexplore.exe
    Download signed ActiveX controls: Prompt
    Download unsigned ActiveX controls: Disabled
    Run ActiveX controls and plug-ins: Allowed
    Initialize and script ActiveX controls not marked as safe: Disabled
    Allow scripting of Internet Explorer Webbrowser control: Disabled
    Active scripting: Allowed
    Script ActiveX controls marked as safe for scripting: Allowed

    File Scan Data-->

    Other data-->
    Office Details: <GenuineResults><MachineData><UGUID>{234352AF-9C25-4791-9609-9DC91D989E5A}</UGUID><Version>1.9.0027.0</Version><OS>6.1.7601.2.00010100.1.0.048</OS><Architecture>x64</Architecture><PKey>*****-*****-*****-*****-GPDD4</PKey><PID>00371-868-0000007-85570</PID><PIDType>1</PIDType><SID>S-1-5-21-2746169226-2174554052-403190442</SID><SYSTEM><Manufacturer>Hewlett-Packard</Manufacturer><Model>HP Compaq Elite 8300 SFF</Model></SYSTEM><BIOS><Manufacturer>Hewlett-Packard</Manufacturer><Version>K01 v02.05</Version><SMBIOSVersion major="2" minor="7"/><Date>20120507000000.000000+000</Date></BIOS><HWID>F0693307018400FE</HWID><UserLCID>0C0C</UserLCID><SystemLCID>040C</SystemLCID><TimeZone>Est(GMT-05:00)</TimeZone><iJoin>1</iJoin><SBID><stat>3</stat><msppid></msppid><name></name><model></model></SBID><OEM><OEMID>HPQOEM</OEMID><OEMTableID>SLIC-BPC</OEMTableID></OEM><GANotification/></MachineData><Software><Office><Result>109</Result><Products/><Applications/></Office></Software></GenuineResults>  

    Spsys.log Content: 0x80070002

    Licensing Data-->
    Version du service de licences logicielles : 6.1.7601.17514

    Nom : Windows(R) 7, Professional edition
    Description : Windows Operating System - Windows(R) 7, VOLUME_KMSCLIENT channel
    ID d’activation : b92e9980-b9d5-4821-9c94-140f632f6312
    ID d’application : 55c92734-d682-4d71-983e-d6ec3f16059f
    PID étendu : 00371-00170-868-000000-03-3084-7601.0000-0082019
    Identificateur d’installation : 002206180062226935007631966903565173031974676454729006
    Clé de produit partielle : GPDD4
    Statut de la licence : notification
    Raison de la notification : 0xC004F200 (non authentique).
    Nombre de réinitialisations de Windows restant : 2
    Heure approuvée : 2019-01-08 18:20:13
    Utilisez slmgr.vbs /ato pour activer et mettre à jour les informations sur le client KMS afin de mettre à jour les valeurs.

    Windows Activation Technologies-->
    HrOffline: 0x00000000
    HrOnline: 0xC004C4A2
    HealthStatus: 0x0000000000000000
    Event Time Stamp: 1:8:2019 12:55
    ActiveX: Registered, Version: 7.1.7600.16395
    Admin Service: Registered, Version: 7.1.7600.16395
    HealthStatus Bitmask Output:


    HWID Data-->
    HWID Hash Current: LgAAAAEAAgABAAIAAAABAAAAAQABAAEA6GEmRvaZEsL4uVpbeIQUrY7/lBiWYw==

    OEM Activation 1.0 Data-->
    N/A

    OEM Activation 2.0 Data-->
    BIOS valid for OA 2.0: yes
    Windows marker version: 0x20001
    OEMID and OEMTableID Consistent: yes
    BIOS Information: 
      ACPI Table Name OEMID Value OEMTableID Value
      APIC HPQOEM SLIC-BPC
      FACP HPQOEM SLIC-BPC
      HPET HPQOEM SLIC-BPC
      MCFG HPQOEM SLIC-BPC
      SSDT SataRe SataTabl
      SSDT SataRe SataTabl
      SLIC HPQOEM SLIC-BPC
      SSDT SataRe SataTabl
      SSDT SataRe SataTabl
      TCPA APTIO4 NAPAASF
      ASF! INTEL HCG
      BGRT HPQOEM SLIC-BPC


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Tuesday, January 8, 2019 11:40 PM

Answers

All replies

  • When KB971033 is installed on a Windows 7 Volume Activated client you are expected to receive Not-Genuine errors as volume licence keys are not stored in the validtaion servers. The fix for this issue is to remove KB971033, restart and attempt to activate again.

    Detailed step-by-step guide here:

    1.             Uninstall KB971033.
    2.             If the machine doesn’t have KB971033 installed please follow the below steps.
    3.              Reboot
    4.             Run Command Prompt as administrator manually or via a PowerShell script from https://support.microsoft.com/en-us/help/4032981/powershell-script-for-windows-7-non-genuine-issue-is-available/. 
    5.             Type: net stop sppsvc 
    6.             Type: del %windir%\system32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-0.C7483456-A289-439d-8115-601632D005A0 /ah 
    7.             Type: del %windir%\system32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-1.C7483456-A289-439d-8115-601632D005A0 /ah 
    8.             Type: del %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\tokens.dat 
    9.             Type: del %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\cache\cache.dat 
    10.              Type: net start sppsvc 
    11.             Type: slmgr /ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH 

    Note: The 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH key is for Windows 7 Enterprise. If the OS is different, find the corresponding KMS client key from https://docs.microsoft.com/en-us/windows-server/get-started/kmsclientkeys and use it instead.

    1.             Type: slmgr /ato 

    Regards


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.



    Wednesday, January 9, 2019 3:18 AM
    Moderator
  • 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.

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

    Wednesday, January 9, 2019 10:34 AM
  • Same here, all of a sudden some of our Windows 7 Enterprise Clients report "Not Genuine", 0xc004f200 !

    KMS Host is on Server 2019 (1809) with Windows Server 2019 CSVLK (Windows Server 2019 Datacenter & Standard). All Windows Versions from Windows 7 Enterprise to Windows Server 2019 Datacenter are activated, but some of our Windows 7 Enterprise Computers are showing "Not Genuine"...



    • Edited by J. Juergen Thursday, January 10, 2019 7:26 AM
    Wednesday, January 9, 2019 2:52 PM
  • Same here.

    Several hours of troubleshooting and testing and no solution till now.

    The only workaround was to slmgr.vbs /rearm. But this is a temporary solution...

    Additional information will be very apreciated. This is causing caos...

    Wednesday, January 9, 2019 3:40 PM
  • Same problem here.

    We have the same error.

    This looks like a MS problem!

    Wednesday, January 9, 2019 8:11 PM
  • Same issue - started yesterday morning for us. We've been chasing our tails trying to identify the cause.
    Wednesday, January 9, 2019 8:38 PM
  • I was able to fix the this issue by using flowing steps:

    1-     1-  C:\windows\system32\cscript slmgr.vbs /rearm

    2-      2- Reboot the computer

    3-      3- C:\windows\system32\cscript slmgr.vbs /ato

    is rearming windows going to cause any problem in the future?

    Wednesday, January 9, 2019 8:44 PM
  • We're seeing this too.  (Seriously Microsoft?)

    For us, at least for now, doing the below gets the computer running, but we're not sure if it will come back next time our workstations check in with the KMS server or not.

    1. slmgr.vbs -rearm
    2. reboot workstation
    3. slmgr.vbs -ato

    Wednesday, January 9, 2019 8:56 PM
  • It will expire in 180 days- you'd have to do it again.
    Wednesday, January 9, 2019 9:29 PM
  • We've learned that all of our systems impacted by this have been flagged as "non-genuine" by the WAT validation scheduled task installed as part of KB971033.  Re-running the task or executing its action from the command line seems to resolve the issue:

    c:\windows\system32\wat\watadminsvc.exe /run

    My colleagues and I are still trying to determine what caused the failure in the first place.
    • Proposed as answer by jamesaf Thursday, January 10, 2019 12:32 PM
    Wednesday, January 9, 2019 10:38 PM
  • KB 971033: Description of the update for Windows Activation Technologies' contains the following text:

    Note:  For an Enterprise customer who uses Key Management Service (KMS) or Multiple Activation Key (MAK) volume activation, we generally recommend to NOT install this update in their reference image or already deployed computers.  This update is targeted at consumer installs of Windows using RETAIL activation.

    Uninstalling KB 971033 should resolve the activation / "non genuine" errors.  However, in some instances it has been reported that the removal of KB 971033 can cause token store corruption.  If the issue persists after removing KB 971033, OR if token store corruption occurs, then follow the steps below to rebuild the token store.

    For Windows 7 enterprise clients only:

    net stop sppuinotify

    sc config sppuinotify start= disabled

    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

    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 c:\windows\system32\slmgr.vbs /ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH

    cscript c:\windows\system32\slmgr.vbs /ato

    sc config sppuinotify start= demand

    For Windows 7 Professional clients:

    net stop sppuinotify

    sc config sppuinotify start= disabled

    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

    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 c:\windows\system32\slmgr.vbs /ipk <product key>

    cscript c:\windows\system32\slmgr.vbs /ato

    sc config sppuinotify start= demand

    NOTE:  Replace the text "<product key" with the proper KMS client product key that can be obtained from:  Windows 7 KMS Client Keys (GVLK)


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, January 10, 2019 1:29 AM
    Moderator
  • A very similar issue is described at https://support.microsoft.com/en-us/help/4032981/powershell-script-for-windows-7-non-genuine-issue-is-available from back in 2017.

    Our understanding is that KB971033 added the ValidationTask scheduled task that would use WAT to check against Microsoft Servers to confirm that Windows is Genuine. This is only required if you are not using KMS, but has been installed in a lot of institutions using KMS.

    It seems that yesterday something went wrong with the Microsoft Servers and rather than responding Genuine for KMS machines, they were flagging them as non-genuine.

    It appears Microsoft have fixed/changed something on their activation servers now so in theory it shouldn't happen to any more machines. But best practice would be to remove KB971033 in case it occurs again.

    • Proposed as answer by jamesaf Thursday, January 10, 2019 12:23 PM
    Thursday, January 10, 2019 9:58 AM
  • It´s documented now:

    https://support.microsoft.com/en-us/help/4480970

    https://support.microsoft.com/en-us/help/4480960

    BUT:

    We didn´t install one of those Patches/Rollups above either. Our Windows 7 Clients started complaining around 3 to 5 p.m. (GMT+1) on January 8th





    • Proposed as answer by J. Juergen Thursday, January 10, 2019 11:39 AM
    • Unproposed as answer by J. Juergen Thursday, January 10, 2019 3:18 PM
    • Edited by J. Juergen Thursday, January 10, 2019 3:41 PM
    Thursday, January 10, 2019 11:37 AM
  • It´s documented now:

    https://support.microsoft.com/en-us/help/4480970

    https://support.microsoft.com/en-us/help/4480960

    Thanks!

    I thought that KB971033 (NOT part of the January 2019 update, but previously released) caused the issue in combination with a change on the Microsoft online activation servers on 8-Jan-2019.

    How is this issue being attributed to the January 2019 4480960 update ? Was a faulty version of KB971033 re-released as part of the January 2019 update ?

    Thanks,

    Mario

    Thursday, January 10, 2019 12:13 PM
  • It don't think it can be directly connected to those patches - they were only just released and I expect very few Enterprise clients will have deployed them yet as there are usually testing and change control processes to follow which delay patch deployment by a week or more.

    None of the machines I'm seeing affected by this have received the patches for January yet. We first started getting reports of this early afternoon (GMT) on the 8th, a few hours before patches would have been released.

    Something else has prompted this to happen now.

    Is there anything that would cause an activated Windows 7 machine to jump straight from successful KMS activation one day to Non-Genuine notification the next? Or does this only happen after 180 days of not activating? In which case did the problem happen back in July?

    Thursday, January 10, 2019 12:21 PM
  • jamessaf - Agreed. None of our VDI machines that exhibited the issue had the Jan 2019 updates installed.

    Here's my understanding: If a Windows 7 computer in a KMS environment did NOT have KB971033 installed, then it did not experience the 'Windows not genuine' issue.

    If a Windows 7 computer in a KMS environment did have KB971033 installed - This results in the KMS key being sent to the online Microsoft activation servers for validation. Prior to 8-Jan-2019, KMS keys were identified as valid by Microsoft. Post 8-Jan-2019, the KMS keys were identified as not genuine by Microsoft.

    This leads one to conclude that a change in the Microsoft activation servers on 8-Jan-2019 triggered the issue.

    Yes, KB971033 should not be installed on Windows 7 computers in a KMS environment, but since this KB is advertised via Microsoft update, it can potentially sneak back in, and a change in the Microsoft activation servers could cause the issue to reoccur.

    Hopefully, someone from Microsoft can shed more light on this.


    Thursday, January 10, 2019 12:43 PM
  • I have to say the report of KB4480970, KB4480960, or even KB971033 as the cause of this are somewhat confusing to me.

    I just checked one of the workstations (Windows 7 Pro) that had this problem occur for us yesterday and it does not have any of these 3 updates installed.  This is good information to learn about, but I have to think there is still something else going on that can cause this problem.

    Thursday, January 10, 2019 1:55 PM
  • Each of our Windows 7 computers with the activation issue ran the "ValidatationTask" just prior to the losing their activation.  The "ValidatationTask" task reaches out to co2.sls.microsoft.com.  If you enter https://co2.sls.microsoft.com into a browser and view the certificate, the certificate is assigned to "activation.sls.microsoft.com".  Microsoft probably soon realized something was messed up and corrected it.  So when you run the task now, Windows 7 will activate.  Can someone from Microsoft explain what happened?



    Thursday, January 10, 2019 5:57 PM
  • I am the initial poster...

    the issue is very weird but the instructions of Teemo helped.

    First I tried to run the script that failed.

    Then just entered commands provided. The scary part is... if large environment of W7 relying on 2 KMSs will do that (for now I had one machine failed to activate), what we will do?

    I cross fingers...

    I checked the thread just to say Thanks to Teemo and didn't expected to see so many declaring the issue.

    So, the problem is "sleeping" somewhere...

    I guess MS is aware already... Should be some "antidote" KB.

    What is interesting I don't have patch KB971033 on WSUS servers. I didn't find it on failed workstation.

    Logically, it should not be distributed to corporate environment and should not be applied VLK installations since it was considered for retail versions of W7.

    Moderator, could you please bring us some solid news on issue.

    Probably, new patch needed.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Thursday, January 10, 2019 7:33 PM
  • See this:

    This was posted today Activation failures and "not genuine" notifications around January 8, 2019, on volume-licensed Windows 7 KMS clients

    https://support.microsoft.com/en-us/help/4487266/activation-failures-and-not-genuine-notifications-on-vl-win-7-kms-clie



    Paul




    • Edited by J. Juergen Friday, January 11, 2019 7:28 AM
    • Marked as answer by pob579 Friday, January 11, 2019 1:02 PM
    Friday, January 11, 2019 7:27 AM
  • Thx. Let's hope ...

    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Friday, January 11, 2019 1:07 PM
  • just wondering if there is a real fix from MS.

    Kind of KB, that will remove KB971033 and will do other cleanup for fixing activation problem.

    My WSUSs don't have this update for distribution. Yes it could be that this KB971033 was in some deployed images.

    It means that it was downloaded from MS when I prepared a reference image.

    In the article from the link in above posts, MS mentions that it is NOT Recommended to install this update.

    How one could know what KB is recommended and what not. I didn't install it forcibly.

    If it came from MS during Windows 7 update, it came... If it is not recommended it should not be distributed to VLK OS (W7).

    The question how to roll it back in large environment... There are machines that possibly have this update for more than a year and KMS activation was not affected.

    There are many people that declared the same activation problem. Looks like something was done "centrally" and probably should be fixed.

    For now, I had 2 machines. If it will come to 10 I will call to MS.

    Any clarification on one to all fix...

    Thx.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis

    Monday, January 14, 2019 2:31 PM
  • Note:  For an Enterprise customer who uses Key Management Service (KMS) or Multiple Activation Key (MAK) volume activation, we generally recommend to NOT install this update in their reference image or already deployed computers.

    Any hope for Multiple Activation Key (MAK) users, as recalling KMS servers as above scripts doesn't seem to work for MAK subscribers?

    We managed to take KB971033 update on time off most of our clients machines, but still got few machines being out of premises for beginning of January and they all got "not-genuine" notification now?


    Monday, January 21, 2019 4:46 PM
  • Interesting... I started getting issues last week with the odd machine, then quite a few yesterday... Just Windows 7 on KMS with the issue. A slmgr /rearm and slmgr /ato fixes it..

    Don't have any of those updates applied and has been running fine for years.

    Something is going on!

    We have Windows 10, 8.1, and Office and none of them seem to have the issues, just 7!

    • Marked as answer by pob579 Wednesday, February 13, 2019 1:05 PM
    Wednesday, February 13, 2019 10:23 AM
  • > A slmgr /rearm and slmgr /ato fixes it..

    I am an original poster.

    I got one more yesterday...

    When I saw first 3 machines in January I was panicking... 

    THanks for letting know that just slmgr /rearm should fix the issue. It would be a great solution if couple of more will appear.

    I think MS pushed some KB in January, kind of antidote for fixing this thingy. Or adjusted on their side. There are no "storms" that supposed to come if all W7 were affected.


    --- When you hit a wrong note its the next note that makes it good or bad. --- Miles Davis





    • Edited by pob579 Wednesday, February 13, 2019 1:16 PM
    Wednesday, February 13, 2019 1:05 PM
  • Ok not aware of a KB to fix it. I have just used the VAMT tool and am working through putting MAK keys on the Windows 7 clients, plan to get rid of Windows 7 completely in the summer anyway with support ending in January.
    Wednesday, February 13, 2019 3:24 PM