Activating Windows 10 Pro after deployment

[ckasdf]

This is cross-posted from /r/sysadmin.

I have been working on implementing FOG as a new deployment method for computers to replace the current, less capable method. I’ve successfully sysprepped a Windows 10 Pro image, created an answer file, captured and deployed that, and ended up with an image that will deploy while avoiding OOBE. I’ve also got the client working successfully to change the computer name and join it to the domain.

What I’m having difficulty with at current is activating Windows. Each computer we buy has a Product Key sticker that says “Windows 10 Pro for Refurb PCs.” My image has no Product Key given, and on a couple of my test computers, I’ve entered the Product Key into the General > Host Product Key section. After deploying, Windows is still left un-activated.

Someone else suggested that I may not have the “windowskey” plugin, so I checked on that. I activated plugins, found the list of available plugins, and installed windowskey. Once those were accomplished, I deployed again.

Again, FOG didn’t activate Windows. I looked at c:\fog.txt, and it has an error “Invalid product key provided by server.” I checked the key in FOG against the sticker, and they match perfectly. Searching that error on Google returns this github code page, with snippet:

 if (key.Length != 29)

         {
              Log.Error(Name, "Invalid product key provided by server");
              return;
          } 

My Product Key is 25 characters long, and if you add in the 4 dashes, that would equal 29. Is there something in the code not properly working with the dashes, or am I doing something incorrectly / missing a step?

[george1421]

I don’t use FOG to specifically activate since we use KMS server. But, when we were using mak keys we had something like this in our setupcomplete.cmd batch file.

Note the key was gleaned from some random page on the internet. I don't know if its real or borrowed from some place else. The key is only intended for use as an illustration.

cscript /nologo slmgr.vbs /ipk NPPR9-FWDCX-D2C8J-H872K-2YT43

So to help try to debug this issue with FOG and the key management (note the fog client is needed to activate the target computer. There is a different option if we can’t get fog to do what is needed).

What I want you to do is to open an elevated command prompt on one of these unactivated computer. Then key in the cscript command using one of your keys. See if the system activates using this method. You will note the dashes are in the example I provided which would get you to 29 characters. These computers will probably need direct or indirect (proxy’d) internet access to activate correctly.

[Sebastian Roth]

@ckasdf Let’s see if we can shed a light on this by adding a bit more output to the code. I just recompiled the Modules.dll (including the HostnameChanger code) to actually output the key to see if it’s empty (response from the FOG server wrong) or if there is some kind of extra character in the key that is causing it to be of a different length.

Download Modules.zip (19.4 KB), extract the Modules.dll, stop FOGService (Windows Services management console), rename C:\Program Files (x86)\FOG\Modules.dll and put the new Modules.dll in place. Then start the FOGService again and watch the log for Checking Product Key Activation: #NPPR9-...# (the hash tags are intended so we even notice if there is a trailing space or whatever).

I hope you have fog-client version 0.11.16 installed as it would terribly fail otherwise - service won’t properly start and you wouldn’t see anything in the log.

[ckasdf]

@Sebastian-Roth I followed your instructions, and after restarting the service, the FOG log says:

Checking Product Key Activation: #1234567890123456789012345#

No extra spaces anywhere, and also no dashes. (Obviously the 123…345 above is just 25 characters of filler.) For reference, when I performed machine inventory at the first PXE boot, I assigned the Product Key, but did not type in dashes. When viewing the key in the GUI, it has dashes, though they disappear if I click in the field. If I try typing dashes, they appear and disappear.

Perhaps the best/easiest way to manage this is to allow the user to input with or without dashes, and then store the key stripped of dashes, so that when it’s run against the length checker, it matches 25. Let me know what you think, and if you have any additional tests you’d like me to perform.

[ckasdf]

@george1421 I ran this command, substituting the NPPR9 key with the key provided with the machine, and it successfully activated. On the reddit thread linked to in the OP, someone provided a way I can automate using an Excel database and an slmgr script, but if I can avoid an extra step and just enter the key into FOG, that’d probably be easiest/best.

[Sebastian Roth]

@ckasdf Seems like it’s definitely something we can make better in FOG. I will look into this in the next days.

[ckasdf]

@Sebastian-Roth sounds good! In the meantime, is there something I can change in the FOG server’s/client’s config so that it accepts 25 characters?

[george1421]

@ckasdf So your key includes dashes but isn’t 29 characters long? Or do I understand that the FOG webgui is eating the dashes?

Cross linking active post because the conditions sound similar: https://forums.fogproject.org/topic/13069/clone-pc-and-change-product-key

[ckasdf]

@george1421 Sorry if my response wasn’t clear. The letters & numbers of my key sum to 25 characters. In the FOG log, it has the pound/hash symbol, the key, and another pound/hash. In the middle, no dashes exist. Thus, it appears that FOG is indeed “eating” the dashes. If I can modify a config somewhere for it to accept 25 characters on the input, I can test that and let you guys know, but I’m not sure where that config might be located.

[george1421]

@ckasdf Ok I want to test something.

On your fog server linux console log into mysql with
mysql -u root -p fog

Enter no password.
At the mysql prompt key in:
select hostName,hostProductKey from hosts where hostName='000000000000;

Key in exit to leave the mysql query tool.

Where 000000000000 is the name of a known computer that has the product key populated. Does that return the expect key with the dashes in place (assuming you entered the product key in the webgui with the proper dashes)?

[ckasdf]

@george1421 You missed an end-quote on that select.
Running that command, the key does indeed display with dashes.

[george1421]

@ckasdf said in Activating Windows 10 Pro after deployment:

You missed an end-quote on that select.

I had an extra floating single quote after I keyed it in. Now I know where it goes.

OK so we know the key is hitting the database correctly so the problem isn’t on the fog server side. Its on the FOG Client that’s purging those dashes. Knowing where to look is half the battle.

If Sebastian can’t find where the issue is on the client side, we still have another option with a post install script to update the unattend.xml file with the proper key. There is a bit more setup this way, but it will work too. The right answer is of course getting the fog client to behave well.

[x23piracy]

@george1421 & @ckasdf sorry guys but i don’t understand exactly whats going on here:

Afaik fog doesnt display the dashes in the webif even if you paste a 29 sign key, ajax or whatever cool technique immediately removes the dashes visible in the edit field (at that moment i don’t know if it is stored as 25 or 29 sign key into db), lets say the readback works propperly then the only problem can be the fog client or the key itself.

Have you tried to activate manually? slmgr.vbs -ipk key (store the key) followed by slmgr.vbs -ato (activate key)

Btw. afaik you don’t need the windowskey plugin, it’s used for group deployments or volume license keys, if you have unique keys for each host your good to go with the hosts key definition.

Regards X23

[Sebastian Roth]

@ckasdf @x23piracy Without having actually looked at the code I guess what’s happening is that the FOG web UI removes the dashes to be stored in the database but the client will ask for a 29 char key including the dashes.

Unfortunately there is no config for the fog-client to allow for 25 char keys right now. But I can provide a fixed DLL for you: https://ufile.io/mna63 (checks if the key is 29 long and if not it adds the dashes - this is just a quick workaround as we definitely need to address this properly)

[george1421]

@ckasdf said in Activating Windows 10 Pro after deployment:

Running that command, the key does indeed display with dashes.

If I understand this correctly the dashes ARE displayed in the database. I don’t store activation keys in FOG so I can’t confirm one way or the other. So that tells me the fog client (or its API call) is removing the dashes when it retrieves the key from the database. From the way it sounds the fog client code is expected 29 characters. So it may be the middleware between the fog client and the database.

[ckasdf]

@george1421 That’s exactly it - the database shows the key with dashes, so the total characters displayed are 29. When the client tries to apply the key though, the string length logic kicks back, saying it’s too short, because the key it’s presented with is only 25 characters (no dashes).

Somewhere between the server and the client, the dashes get lost, so it gets confused. I’m leaving for the day (and unfortunately calls pulled me away from FOG development today, boo-hoo), but I’ll try the fixed DLL tomorrow. I know it’s a work-around, but would be interesting to see what happens. I think the most simple way to handle it is for the input to store the key stripped of dashes, and all the remaining logic expect that. Perhaps AJAX in the GUI can still show it with dashes for easy reading.

Thanks for all the help so far, guys!

@Sebastian-Roth - some stuff happened both personally and at work, so I haven’t gotten to testing the fixed DLL, but hopefully I’ll be able to do that tomorrow.

[ckasdf]

@Sebastian-Roth Finally got a chance this morning to try the modified DLL, and it worked to activate the computer.

[Sebastian Roth]

@ckasdf I will still need to fix this properly in the code. Will be in the next release.

[ckasdf]

@Sebastian-Roth That sounds good! You’re doing wonderful work! Do you know about an ETA on the next release? Should I use the modified DLL till then, or do you think that’d be bad practice?

[Sebastian Roth]

@ckasdf I’d suggest using the patched DLL for now as I have a lot on my schedule and I am not sure if I get to properly fix the issue and push out a release any time soon. Although it might be a bit strange to download the file from a file sharing server it’s an officially compiled DLL.