Endless windows key activation burning OEM keys



  • Using FOG build 5688 and FOG client v0.9.9.

    TL;DR – Fog seems to repeatedly activate whatever key is associated with the host, even if it already has, ultimately burning the keys.

    Details:
    Been imaging a few test machines for a few days now, one machine has been imaged maybe 4 times, the others, only twice. Each machine completes the imaging process fine; however, after imaging, they no longer activate their keys.

    At every logon, the user is told that Windows needs to be activated (accompanied with the “You may be a victim of software counterfeiting” message) and if you try to activate it online, Windows refuses to activate the key.

    FOG client in this state continues to log this message during this period “XX/XX/XXXX XX:XX AM/PM HostnameChanger Activing host with product key” and looking at the code (https://github.com/FOGProject/fog-client/blob/0.9.9/Modules/HostnameChanger/HostnameChanger.cs), it seems like the hostname changer module is always activating the key. This repeated activation is likely what is burning these keys and making them worthless.

    I am imaging a fresh host to test this - I will image it, let it sit for several hours, maybe a day, and then try to reimage and see if it can activate.

    In the old legacy client, we had a script that activated the clients and in that script, we checked before we attempted to activate the windows key. The check used “slmgr.vbs /dli” to compare the current key to what the key ought to have been and activated only if the two differed.



  • @Wayne-Workman said:

    @jayphizzle said:

    Can some mod mark the tread as unsolved?
    Or should i open a new thread?

    I’d say open a new thread, I’d call this a bug as it doesn’t work right if a different language is being used by the system.

    @Jbob

    Ok ‘new’ Bug reported here: https://forums.fogproject.org/topic/6934/endless-windows-key-activation-burning-oem-keys


  • Moderator

    @jayphizzle said:

    Can some mod mark the tread as unsolved?
    Or should i open a new thread?

    I’d say open a new thread, I’d call this a bug as it doesn’t work right if a different language is being used by the system.

    @Jbob



  • @Quazz said:

    Might be safer to have the opposite check (check for unlicensed and only then try to activate rather than check for licensed and try to activate when that doesn’t match) to prevent keys from burning. I think people would prefer their computers not activating because of language issues rather than keys burning.

    :+1:

    Can some mod mark the tread as unsolved?
    Or should i open a new thread?


  • Moderator

    Might be safer to have the opposite check (check for unlicensed and only then try to activate rather than check for licensed and try to activate when that doesn’t match) to prevent keys from burning. I think people would prefer their computers not activating because of language issues rather than keys burning.



  • @Jbob said:

    v0.9.10 has been released and addresses this issue.

    I updated to v.0.9.11 on a test client today.
    Looking at the log file i found the following lines:

     15.03.2016 11:55 HostnameChanger Checking Product Key Activation
     15.03.2016 11:55 Bus Registering ParseBus in channel Power
     15.03.2016 11:55 Bus Became bus client
     15.03.2016 11:55 Bus Registering OnNotification in channel Notification
     15.03.2016 11:55 Bus Registering OnUpdate in channel Update
     15.03.2016 11:55 HostnameChanger Windows has correct key but is not licensed
     15.03.2016 11:55 WinActivation Installing Product key
     15.03.2016 11:56 Process --> Exit Code = 0
     15.03.2016 11:56 WinActivation Activating Product key
     15.03.2016 11:56 Process --> Exit Code = 0
    

    These steps repeats every few minutes,

    Running slmgr.vbs /dli shows the following status:

    alt text

    Does the following lines in https://github.com/FOGProject/fog-client/blob/master/Modules/HostnameChanger/Windows/WinActivation.cs need to be changed so the german “lizenziert” will be recognized?

     public static bool IsActivated()
            {
                var info = GetSLMGROutput("/dli");
                var flattenedInfo = string.Join(" ", info);
    
                return flattenedInfo.Contains("Licensed");
            }
    

  • Senior Developer

    v0.9.10 has been released and addresses this issue.


  • Senior Developer

    Your build is failing because you are missing WiX toolset. See https://github.com/FOGProject/fog-client/blob/master/README.md#environment . Note that the 0.9.X branch has no build.ps1 like the master branch does. I can give you a build in a little bit.



  • I was trying to build it from Visual Studio myself; however, I kept getting errors, like:

    This version of Visual Studio is unable to open the following projects. The project types may not be installed or this version of Visual Studio may not support them. 
    For more information on enabling these project types or otherwise migrating your assets, please see the details in the "Migration Report" displayed after clicking OK.
    	 - Installer, "C:\Users\Administrator\Desktop\fog-client\Installer\Installer.wixproj"
    
    
    No changes required
    These projects can be opened in Visual Studio 2015, Visual Studio 2013, Visual Studio 2012, and Visual Studio 2010 SP1 without changing them.
    	 - Service, "C:\Users\Administrator\Desktop\fog-client\Service\Service.csproj"
    	 - PipeClient, "C:\Users\Administrator\Desktop\fog-client\PipeClient\PipeClient.csproj"
    	 - Tray, "C:\Users\Administrator\Desktop\fog-client\Tray\Tray.csproj"
    	 - UserService, "C:\Users\Administrator\Desktop\fog-client\UserService\UserService.csproj"
    	 - UpdateWaiter, "C:\Users\Administrator\Desktop\fog-client\UpdateWaiter\UpdateWaiter.csproj"
    	 - UpdateHelper, "C:\Users\Administrator\Desktop\fog-client\UpdateHelper\UpdateHelper.csproj"
    	 - Debugger, "C:\Users\Administrator\Desktop\fog-client\Debugger\Debugger.csproj"
    	 - PipeServer, "C:\Users\Administrator\Desktop\fog-client\PipeServer\PipeServer.csproj"
    	 - Handlers, "C:\Users\Administrator\Desktop\fog-client\Handlers\Handlers.csproj"
    	 - Modules, "C:\Users\Administrator\Desktop\fog-client\Modules\Modules.csproj"
    	 - .nuget, ".nuget"
    	 - FOGService.Tests, "C:\Users\Administrator\Desktop\fog-client\FOGService.Tests\FOGService.Tests.csproj"
    	 - AbstractService, "C:\Users\Administrator\Desktop\fog-client\AbstractService\AbstractService.csproj"
    	 - SetupHelper, "C:\Users\Administrator\Desktop\fog-client\SetupHelper\SetupHelper.csproj"
    	 - PowerCLI, "C:\Users\Administrator\Desktop\fog-client\PowerCLI\PowerCLI.csproj"
    	 - PrinterManagerHelper, "C:\Users\Administrator\Desktop\fog-client\PrinterManagerHelper\PrinterManagerHelper.csproj"
    	 - ShutdownGUI, "C:\Users\Administrator\Desktop\fog-client\ShutdownGUI\ShutdownGUI.csproj"
    	 - FOGService, "C:\Users\Administrator\Desktop\fog-client\FOGService.sln"
    

    But it sounds like you might not be surprised by that. Could you send me a build please?


  • Senior Developer

    It is not released yet. I would need to send you a build of it.



  • Thanks for working on this so fast. I will test it out today.


  • Senior Developer

    I have finished the patch. Currently it is completely untested so if I could have some volunteers to test, that would be greatly appreciated.


  • Senior Developer



  • As an update for the test I promised – the newly imaged host imaged properly the first time; however, on subsequent imaging attempts, windows fails to activate, but it is not activating the key shown in the web interface, but is trying to activate the MAK key (the key that was present in the unattend.xml) – this step is failing because that MAK key has been burned out. I have tried renaming the host, and even though the client recognizes that change, it does not grab the updated key. Interestingly, it will notice that the key is malformed if I remove some of its contents; restoring the full key only gets it back into trying the MAK key.



  • Given my discovery today that MAK keys are also getting activated and burned, not just OEM keys (https://forums.fogproject.org/topic/6365/order-of-operations-product-key-activation-client-product-key-updater/9). Would it be possible to change the code such that it only attempts to activate if the key matches what is set in the web interface and if it hasn’t successfully activated before?


    To expand upon my above request, I think you could do/use the following:

    • check if the partial local key (slmgr.vbs /dli) matches some part of the key listed in the database/FOG web interface
    • if false, update local key to match web interface (and then either rebooting or restarting the checks to verify it was set properly)
    • check if the local key has already been activated; slmgr.vbs /dli, check for “License Status: Licensed” – if it reads “License Status: Notification”, then it has not successfully activated (i.e. it’s prompting the user to activate)
    • if it has not yet been activated, try to activate

  • Moderator

    Yeah this is really bad…


  • Senior Developer

    @mrayzies I’ll push out a patch when I get a chance.


Log in to reply
 

473
Online

38746
Users

10573
Topics

100072
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.