@wayne-workman Just noticed I put those settings on a different scope.

Everything is working now.

Thanks!

@george1421 Thank you very much for your time George. I’ll try today and back to you asap

@dpotesta50 said in Question About Windows Licensing:

I see the area you’re referring to but wouldn’t that be the product key just for THAT particular one machine? The same key won’t activate every machine I pull that image to, correct?

Correct, and if all you have are individual licenses for individual machines, this is the ONLY legal way you have. If you had a MAK key, you could use groups to apply that to many hosts at once - but you don’t unfortunately, you just have Pro keys.

Here’s what I did for 100+ laptops, you need two people for this. One good at typing and listening, one good at reading and speaking clearly. One reads keys, the other one types them in. Yes, it will suck, better to get it over sooner than later. Also you’ll definitely want to backup your database when you’re done so you don’t have to do it again!

@fox134 Well lets hope you don’t have an ipxe.exe in there…

The client gets its booting information from (the) dhcp responsible for assigning an ip address to the target computer. So if you want the target computer to use a different boot file then you might update dhcp options 67.

Now with that said, from your OP you say that FOG is giving out the IP addresses on a dedicated imaging network. So if you want to change the boot file, you will need to edit the dhcp config file on your FOG server.

To see what you config file looks like, you can review this example: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1

You will see for arch 7 and 9 it calls out ipxe.efi. You can replace that with maybe snponly.efi or any of the other efi files. Then you must restart your dns server. On ubuntu you would issue the command sudo systemctl restart isc-dhcp-server to restart the service.

@jfulton Try putting a dumb switch (unmanaged mini-switch) between the target host you’re working with and the rest of the network, see if it makes a difference or not. If there’s a difference, we have additional steps for you on how to fix it.

The problem seams to have self resolved. This can be closed. FYI, nobody changed any settings. It just started pulling from the correct node on its own.

One GB. Is small because in this partition is the WINPE.

/dev/sda4 : start= 102758400, size= 2095104, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EDED91DC-7BDE-4F7B-B502-B57A6C90EF 30, name="Basic data partition"```

@wayne-workman Thanks alot guys that fix the issue, now I just have this issue when opening the fog via the webpage I see that no storage is attached.

0_1521139121302_Fog Image.PNG

Ok thanks.

@tom-elliott

Still me, I just redo a test and here are the multicast logs

[03-15-18 10:24:37 am] | Task (15) Multi-Cast Task is new!
[03-15-18 10:24:37 am] | Task (15) /images/SalleC11-01 image file found.
[03-15-18 10:24:37 am] | Task (15) Multi-Cast Task 2 clients found.
[03-15-18 10:24:37 am] | Task (15) Multi-Cast Task sending on base port: 54210.
[03-15-18 10:24:37 am] | Command: /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 600 --portbase 54210 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/SalleC11-01/d1p1.img;/usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 10 --portbase 54210 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/SalleC11-01/d1p2.img;/usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 10 --portbase 54210 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/SalleC11-01/d1p3.img;/usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 10 --portbase 54210 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/SalleC11-01/d1p4.img;
[03-15-18 10:24:37 am] | Task (15) Multi-Cast Task has started!
[03-15-18 10:24:47 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:24:57 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:25:07 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:25:17 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:25:27 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:25:37 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:25:47 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:25:57 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:26:07 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:26:17 am] | Task (15) Multi-Cast Task is already running with pid: 43102.
[03-15-18 10:26:27 am] | Task (15) Multi-Cast Task is already running with pid: 43102.

@doludizgin If you are keen you can surely compile your own iPXE binary with an embedded script asking for a static IP to enter. Take a a look at the wiki on how to do that.

But I suggest you better run a DHCP server just as George and Wayne said…

@wayne-workman @Tom-Elliott
Thanks for the help guys! I was able to get it re-installed although I have one issue, I will open another thread for that.
Thanks again!

@george1421 Yes, if i change password of one user into FOG_Admin, It change immediatly for connect to FOG WEBUI. 🙂

@itcc correct

@itcc Two ways.

Manually: https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address With a tool: https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

I remoted in with teamviewer and helped the OP get things working correctly. We had to ensure that the dhcp server only bound to the imaging lan NIC adapter and not both. We also found a nuance with ubuntu where it only wanted one interface up at a time by default. Once we had both interfaces up, fog installed correctly and like the OP needed it. Solving this case.

@george1421 In that case, the issue resolved. Thank you for all the help.
Tom

TY guys, I solved it, the path in tftp options was wrong. I saw other post with same issues. many tks for help

@Greg-Plamondon The new video is interesting as is seems to show that it finds the interface eth0 but is not able to bring it up within 35 seconds. What kind of client model is this? Are you able to FOS boot this very same machine at a different location? I kind of doubt but what do I know. 😉

Tom,
Thanks for your help! I reapplied (what seemed to be the already) correct permissions, rebooted the server and now it works!