Endless windows key activation burning OEM keys

Joe Schmitt

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

Wayne Workman

Yeah this is really bad…

mrayzies

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

mrayzies

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.

Joe Schmitt

GitHub issue:

https://github.com/FOGProject/fog-client/issues/34

Joe Schmitt

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

mrayzies

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

Joe Schmitt

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

mrayzies

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?

Joe Schmitt

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.

Joe Schmitt

v0.9.10 has been released and addresses this issue.

jayphizzle

@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");
        }

Quazz

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.

jayphizzle

@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?

Wayne Workman

@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

jayphizzle

@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

Endless windows key activation burning OEM keys

221

11.6k

17.1k

154.6k