FOG - How to WOL?

[JRA]

Hello all, anyone good with FOG?

 

We had an old FOG server that I retired (seemed way too long in the tooth to update it) and got a shiny new one in.

 

The old one could WOL boot the whole domain no problem, however the new one just won't do it.

 

Anyone know how to get this working right?

 

Thanks muchly all.

Edited August 31, 2020 by JRA

[Steve21]

When you say whole domain does that mean some work and some don’t? If so is it across vlans and did you update iphelpers on router etc?

 

Steve

[JRA]

When you say whole domain does that mean some work and some don’t? If so is it across vlans and did you update iphelpers on router etc?

 

Steve

 

Ah, sorry wasn't clear - nothing on the domain will PXE boot from FOG.

 

Yes do have multiple VLANs for client PCs too. IP helpers on the core switch are still as they always were; set to addresses of both DHCP servers.

Edited August 31, 2020 by JRA

[3s-gtech]

The DHCP options between old (e.g. 0.32) and new FOG are very different. You’ll need to change the boot file location.

[JRA]

The DHCP options between old (e.g. 0.32) and new FOG are very different. You’ll need to change the boot file location.

Thanks for that - would this be DHPC option 67? Set to undionly.kpxe which does seem to behave in a general sense. I think I did change this previously from something else however.

 

That look right or do I need to look again?

 

Also would that stop a magic packet going out even?

 

Thanks again too.

[3s-gtech]

That’s the right setting already (yes - option 067) so that’s not the issue. Do the PCs just wait then fail if set to network boot only?

[JRA]

That’s the right setting already (yes - option 067) so that’s not the issue. Do the PCs just wait then fail if set to network boot only?

Hi - they'll image fine...

 

...

 

...I just realised I meant to write WOL in the title and NOT strictly won't PXE boot.

 

FOG won't wake them up rather than imaging. Images them fine.

 

[JRA]

(At this point I'd take any old method to WOL the domain. Anyone know anything good/work-y?)

[Steve21]

I mean if you know the MACs etc, you could just pipe them into a BAT with wol.exe

 

https://www.gammadyne.com/cmdline.htm#wol

 

Was what we used previously to SCCM

 

Steve

[JRA]

I mean if you know the MACs etc, you could just pipe them into a BAT with wol.exe

 

https://www.gammadyne.com/cmdline.htm#wol

 

Was what we used previously to SCCM

 

Steve

 

 

Thanks Steve! Gave that a try, and also the Nirsoft one here: https://www.nirsoft.net/utils/wake_on_lan.html

 

Still no joy, tried on things in the same subnet/VLAN and out of it too. Very odd that the previous FOG server could wake the domain just fine.

 

Looking like something switch-ey?

[Steve21]

A few options I guess, Did the old Fog server use a different port? There's 7 and 9 normally, you can do a switch in the one I linked to try a specific one, as it might be it's using the wrong one

 

Switch wise should only block it if it's set to a different IP etc than the old Fog server, and if it's on the same VLAN etc shouldn't be a problem, unless you have a specific MAC based ACL etc?

 

Steve

[JRA]

A few options I guess, Did the old Fog server use a different port? There's 7 and 9 normally, you can do a switch in the one I linked to try a specific one, as it might be it's using the wrong one

 

Switch wise should only block it if it's set to a different IP etc than the old Fog server, and if it's on the same VLAN etc shouldn't be a problem, unless you have a specific MAC based ACL etc?

 

Steve

Ah, now, yes it is on a different IP address.

 

Think it's worth binning the old fog server totally, giving the new fog server the original one's IP address?

 

That likely to upset anything as far as fog is concerned, regarding clients and imaging etc or should be ok to try would you think?

[Steve21]

It might just be if you have it set to only allow from certain IPs on your switch access etc, normally it shouldn't matter as it just requests a response on the VLAN (or equivalent IPHelper/DHCP options)

 

Steve

[JRA]

It might just be if you have it set to only allow from certain IPs on your switch access etc, normally it shouldn't matter as it just requests a response on the VLAN (or equivalent IPHelper/DHCP options)

 

Steve

 

Thanks Steve. Only place I can think of that happening would be core switch. Looks to be ok. Pasted a bit of the config (UDP port 9 related) which just "looks" to be ok:

 

ip forward-protocol udp 10.108.10.255 9 ip forward-protocol udp 10.108.5.255 9 ip forward-protocol udp 10.108.4.255 9 ip forward-protocol udp 10.108.7.255 9 ip forward-protocol udp 10.108.9.255 9 ip forward-protocol udp 10.108.10.63 9 ip forward-protocol udp 10.108.10.127 9

 

Really can't understand why it won't have it. Can you think of anything else to try?

[JRA]

Funnily enough this does seem to have happened with W10 deployment.

 

Can W10 "do" something to the BIOS settings?

 

Another clue is, in a PC nearby (again also different subnet/VLAN to the FOG server) I've looked in the BIOS and changed the option "Power on by Ring" to enabled. And, although FOG itself can't WOL that, the wakeonlan program itself CAN, and it WILL wake up for that with:

 

# wakeonlan ma:ca:dd:re:ss

 

 

However, that PC was on a very old test image, not my "final" one. I'm imaging that PC now with the up-to-date W10 image to see if that breaks it.

Weird that I made that change in the BIOS because I didn't have that there before and the domain used to WOL from the old FOG server perfectly.

 

I don't fully understand what this is pointing at atm

Edited September 1, 2020 by JRA

[JRA]

Actually at this point I'll take anything, Windows or Linux that'll just get me WoL back across the network again.

[computer_expert]

Do you have fast startup enabled in windows 10? I think fast startup breaks WOL.

[JRA]

Do you have fast startup enabled in windows 10? I think fast startup breaks WOL.

Not sure, I'll disable in GP and have an experiment.

 

Thank you thank you. <3

 

EDIT - did both bits, the policy and the second reg key: https://serverfault.com/questions/793295/how-to-disable-fast-startup-using-a-group-policy

 

Still no joy. Also that seem to make it boot very fast and I don't see my group policies applying at startup anymore.

Edited September 1, 2020 by JRA

[JRA]

Just posted the following in the FOG forums - they're helping a treat also. I have clues so posting it here also:

 

Okay, it did twice, and so did wakeonlan from the FOG server.

 

However, it won't do it or not do it consistently BUT I have clues...

 

It seems to be when it's allowed to boot as far as the BIOS (with keypress and actually enter the BIOS,) or into POST when it's looking for DHCP.

 

If I power it off there then it'll WoL from FOG every time after that. If I let it boot into W10 though and turn it off with a momentary power button press it'll not WoL until I remove the power cable whilst it's off, count to 20, put the cable back in and then go into the BIOS or wait for that part in POST just once more.This works the same across different subnets/VLANs too, happily!This does also seem a LITTLE dependent on the amount of time it's just in a "pre-Windows" state.

 

As in, for a test, I turned on 4 machines. Two of them I just left to boot as far as the searching for a DHCP server and then turned them off, the other two I actually went into the BIOS - didn't change anything but exited and turned them off. The "BIOS pair" would WoL but the "DHCP off" pair did not. I then went to the next two and got them to the DHCP polling bit and then paused them for thirty seconds - again not letting W10 boot - then turned them off and these two ALSO would WoL after that.

 

It seems like if they spend around 40 seconds in a "non-Windows10-but-powered-on" state they then become receptive to WoL packets, but if you let Windows boot up you'll need to power them off at the wall/pull the power cables out for 30 seconds before you can try again, and get another chance to "prime" them in this way. I'm sure there's a clue in there... hope that long old story is some help!

 

Thanks much again for sticking with me also.

Edited September 1, 2020 by JRA

[Katy]

I recently spent ages trying to get as much of my network to WoL as possible - if it's not doing anything at all I tend to stick network monitor on, send some wake up packets and see if they appear on the machine in question within network monitor - to prove if it's the network or the PC. Besides that there's a few things like turning off "hiberboot" (or fast startup where it never shuts down properly) and making sure they are using the right NIC drivers. I wrote a blog post on this a few weeks back with everything I tried: https://katystech.blog/2020/08/wake-on-lan-revisited

[JRA]

Damn, this is bad. Any more of us getting this too?

 

How are we supposed to deploy software etc when we can't WoL anymore?

 

Thanks Microsoft that absolutely stinks...

[JRA]

Okay now having put on that disable fast startup policy all my workstations are stuck on fast startup and nothing I can do (remove or reapply that policy) is getting them back to the "regular" startup where I could see all the policies etc applying as they did.

 

This truly has spiralled.

[JRA]

Well today things getting back to "normal" and gpupdate /force makes them take the regular startup again. Phew.

 

Now just back to the problem itself. Have another NM coming for a look and a joint ponder next week so we'll see what we see.

 

Thanks everyone for all the patient help so far. This sucks so bad.

 

Have good weekends all.