Endless windows key activation burning OEM keys
-
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.
-
GitHub issue:
-
I have finished the patch. Currently it is completely untested so if I could have some volunteers to test, that would be greatly appreciated.
-
Thanks for working on this so fast. I will test it out today.
-
It is not released yet. I would need to send you a build of it.
-
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?
-
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.ps1like the master branch does. I can give you a build in a little bit. -
v0.9.10 has been released and addresses this issue.
-
@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 = 0These steps repeats every few minutes,
Running slmgr.vbs /dli shows the following status:
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"); } -
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.
-
@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.
Can some mod mark the tread as unsolved?
Or should i open a new thread? -
@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
-
@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
