Endless windows key activation burning OEM keys

[mrayzies]

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.

[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:

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