Posts made by ckasdf

@george1421 You weren’t kidding about the 10 minutes, that was easy! There was another article on DNSMASQ that I had looked at before putting up this post, which looked mega complicated. Likely it was intended to do more than just PXE stuff. I haven’t deployed anything, but I registered a computer successfully after booting to PXE, so now I just have to migrate from laptop to server. w00t!

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

So to make sure I understand, essentially have the two options 66 & 67 turned back off that I had turned on the other day, then set up dnsmasq? Anything else I need to change on the router?

@george1421 The DHCP server is running on a Cisco router. I have confirmed the router is on the same subnet as the FOG server and target computers.

Thanks for the info, George.

My PXE deployment environment is going to be completely UEFI, so no need for dual capability DHCP. I had a guy in the networking side of things add options 66 (FOG IP address) & 67 (ipxe.efi), and progressed a little further, but then got stuck again.

>>Start PXE over IPv4..
  Station IP address is [laptop's IP]

  Server IP address is [DHCP gateway's IP]
  NBP filename is ipxe.efi
  NBP filesize is 0 BytesPXE-E18: Server response timeout.

Thoughts on how to proceed from here? I’m guessing that it is expecting the FOG server’s IP on that 3rd line, rather than the DHCP server.

I installed CentOS + FOG onto a laptop and enabled the DHCP server during the install, and have been using that for testing. It worked well, though I ran into complications with that, as the network’s actual DHCP+DNS server were conflicting with the laptop.

I got some server space for a CentOS VM, so I’m working on moving from the laptop to the server. I fresh-installed FOG, and chose not to accept any of the DHCP settings. FOG is up and running, I can log into the web interface, but now I can’t PXE boot. What’s the best way forward? I didn’t find much in the way of documentation.

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

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

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

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?