Activating Windows 10 Pro after deployment
-
@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.
-
@ckasdf Ok I want to test something.
On your fog server linux console log into mysql with
mysql -u root -p fogEnter no password.
At the mysql prompt key in:
select hostName,hostProductKey from hosts where hostName='000000000000;Key in
exitto leave the mysql query tool.Where
000000000000is 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)? -
@george1421 You missed an end-quote on that select.
Running that command, the key does indeed display with dashes. -
@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.
-
@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
-
@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)
-
@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.
-
@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.
-
@Sebastian-Roth Finally got a chance this morning to try the modified DLL, and it worked to activate the computer.
-
@ckasdf I will still need to fix this properly in the code. Will be in the next release.
-
@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?
-
@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.
-
@Sebastian-Roth Yeah, I did think it odd that you didn’t put it somewhere on github along with the rest of the code. Anyway, I’ll use that for now. Thanks!
-
@Sebastian-Roth said in Activating Windows 10 Pro after deployment:
@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)
Can someone reup this dll so that I can get my activation to work as well please?
-
@Borega did you try downloading the file and placing it in the proper location? It seems this was already done.
-
@Borega Try this file: https://github.com/FOGProject/fog-client/releases/download/0.11.16/Modules_SnapinPack_empty_dirs.dll
Should have the fix in it as well.
