JRA

Cheers. Yes WoL breaking utterly slew us. Another "feature" I could have gladly karate kicked Microsoft for.

Cheers, yes I'd say a little more frequently here, maybe one or two tickets a day, then none for a day, then one or two etc. Restart, log off/on or if I'm feeling whimsical a gpupdate /force /boot sorts them.

Must admit this has been a little bit of a pickle and come in with W10; when we were mixed W7/W10 this wasn't an issue, so I'm thinking W10 has to be the culprit. If a PC is left logged on overnight it'll often need a restart to pick up the printers again. Also sometimes (though certainly not all the time) printers will just not apply and need another log off/on to appear. Is this "a thing" that's been overcome somewhere by people or is it just W10 awfulness? Printers apply through GP ofc, user policies and set in prefs. Thanks everybody for any musings.

Looks like each AP needs sticking in NPS RADIUS Clients. Each one. I have 60. Putting a tea on and getting typing...

Hi all - trying to get our EnGenius system (new and shiny) to use RADIUS authentication for one particular network/SSID. What I'd ideally like to happen is clients/guests join the "Public" wifi and then divert to a captive portal login page (so far this part works.) I'd like staff only, not students, to be able to authenticate here and get wifi, plus ONE other AD account called "public." The account "public" will have it's password changed daily and emailed to a few staff to serve as the daily public wifi password, so non-staff can get logged in for up to 1 day. For the life of me I cannot get EnGenius and RADIUS to play nice. Anyone using these two in a similar way and had any luck? Thanks all.

Hang on, would a sextant work on a flat earth? EDIT - no it wouldn't. Neither would an astrolabe. We've been using those for hundreds of years.

Mate that sounds grim. What network card have you got in the PCs and is it all PCs doing it? Sorry if you've answered already I've not read back. Drivers sorted me (amongst other things) so that's where I'd look.

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.

Actually that seems to have REALLY shifted it into gear. Goodness. Scavenging no-refresh and refresh times in DNS both set to 1hr, IP addresses looking VERY tidy, no duplicates. I wonder that that's TOO aggressive but in a perverse way I look at it and think "yeah you GET busy at that after four years of flipping slacking..." Hopefully that's not idiotic in any way. At least my problem is fixed. I need a holiday or something...

Heh, no got three of them in fact.

With my bravery hat on I went into DHCP and checked all the sensible DHCP > IPv4 > properties > DNS bits: On one of the DHCP servers the bottom tickboxes were greyed out, and "Always dynamically update..." now set on both DHCP servers, and both servers now set to these options here. Hopefully that does something. Don't think it'll make it worse at any rate.

Okay this has been the work of years. Tweaking, never right, tweak again, never right... Can anyone who's got any knowledge this way help me stop this? I just don't know what it wants from me. Multiple PCs in DNS are getting the same IP addresses and both pinging etc. This is killing me. Can anyone just let me know what the thing wants from me? Is this DNS or DHCP scvenging at all even? I'm so flipping lost...

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.

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

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.

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.

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

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

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?

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?

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?

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

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.

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.

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.