Activating Windows 10 Pro after deployment



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


  • Developer


  • Senior Developer

    @Borega did you try downloading the file and placing it in the proper location? It seems this was already done.



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



  • @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!


  • Developer

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


  • Developer

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



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



  • @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.


  • Moderator

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


  • Developer

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


  • Moderator

    @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 You missed an end-quote on that select. ;)
    Running that command, the key does indeed display with dashes.


  • Moderator

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



  • @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.


  • Moderator

    @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



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


  • Developer

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


Log in to reply
 

499
Online

6.4k
Users

13.8k
Topics

130.1k
Posts