Which table to check in db to see if there are pending wakeup entrys
-
Hi,
i have a strange problem that a lot of my computers turn on automatically after they have been shutted down.
I could find out that FOG server is causing this because when i shutdown the fog server the problem does not happen.All the hosts that have this problem has been deleted from fog ( @Tom-Elliott told me that fog only send wol to registered hosts)
I also uninstalled fog service from some of the hosts to check if this is the cause but even then the computers wake up.When they turn on by them selfs i can see that they not only receive a wol, they boot from the network and that happens when fog server is waking them in normal.
Then when i shutdown the fog server und shutdown the problematic computers they do not turn on again. So this is an evidence for me that the FOG Server is waking them up, but i don’t know what to check on the server while the tasklist is empty, is there anything in the fog db i could check for pending wakeups?
Could this be a broken task? Maybe FOG thinks i should turn on the computer and has never received that i really has been booted and therefore it sends this wol again and again?
I really need help with this please. @Joe-Schmitt
FYI: I am on RC6 but this happened also with the RC’s before and younger Trunk Versions, FOG Client is 11.4.
Regards X23
-
This was not a WOL problem. It wasn’t, technically, a FOG problem either.
The issue was with Windows 10. Though I suspect similar things would’ve happened with Windows 8.
Basically, fast boot was on. This left the system in what appears to be turned off, but the nic will still respond to commands like ping, wol, etc…
The idea of Fast boot is to make booting faster (duh). However, the FOGPingHosts service was just sending a simple ping to the 445 port on windows. The device would see this and think it needed to turn on.
-
powerManagementandtasksare both capable of doing it I think, unless Tom has moved all power stuff to power management. -
-
Powermanagement has never been a “task”, it’s always been it’s own thing.
WOL, only happens to registered hosts.
I’m not saying what you’re seeing isn’t happening, I just don’t see how FOG (itself) is the one doing it.
WOL for tasks is handled when the Task is created. That’s the purpose of the “Wake On LAN” checkbox that’s there when you are creating the task.
Powermanagement can tell a host to wake on lan as well, but again, all of the Wake on lan stuff that FOG performs is handled only if the host is registered.
Through this whole time, is it possible there is the FOG Scheduler service that’s still running old items to wake them up? What’s in the /opt/fog/lob/fogscheduler.log file?
-
This was not a WOL problem. It wasn’t, technically, a FOG problem either.
The issue was with Windows 10. Though I suspect similar things would’ve happened with Windows 8.
Basically, fast boot was on. This left the system in what appears to be turned off, but the nic will still respond to commands like ping, wol, etc…
The idea of Fast boot is to make booting faster (duh). However, the FOGPingHosts service was just sending a simple ping to the 445 port on windows. The device would see this and think it needed to turn on.
-
@Tom-Elliott facepalms in Microsoft’s general direction
-
@Quazz said in Which table to check in db to see if there are pending wakeup entrys:
@Tom-Elliott facepalms in Microsoft’s general direction
ACK! was a bad day for me
-
So Microsoft would let me send just a ping to… you know… the broadcast address of a mega-company in their internal network from… say a wifi connection outside the building, and I can literally wake up every single computer in the entire network, whether WOL is enabled or not, as long as Fast Startup is turned on? I guess that’d make port scanning and ‘penetration testing’ all the easier, right? I hope microsoft reads this.
-
@Wayne-Workman I suppose I should add more information to how I derived at this idea then, just in case they do read it.
So, as @x23piracy stated, Systems were turning on even after he removed them. However this wasn’t in the case of the host not existing. Ping and WOL only happen on “registered” hosts. However, in the case of Ping, the pinging would operate on “Pending” hosts as well. Removing the host from both register and pending hosts, and the problem would go away.
So we ran a few tests to figure out exactly what was causing it. First, we stopped fogscheduler service. He also has another node, so we also stopped fogscheduler on the node. I know the other node had nothing to do with it, as turning off the fog server itself the issues went away. This didn’t help. Well that blows the “WOL” theory right out the window because only taskings and FOGScheduler do any WOL stuff. To be exact, FOGScheduler only performs WOL on schedules of Powermanagement and taskings awaiting that are WOL enabled. Seeing as there was no Powermanagement items in the DB and there were no tasks waiting to be performed, that was enough proof that this was not a WOL problem at all. Add to that, stopping the FOGScheduler service didn’t fix the “hosts waking up randomly”.
So @x23piracy decided to see about FOGPingHosts. He stopped the service, shutdown one of the “problem” systems, waited some period of time and nothing at all happened. So we started FOGPingHosts and immediately the system that was shutdown started.
So, I added a quick test by only allowing FOGPingHosts to ping hosts that were approved. Initially I only had it checking of the value of the pending state was set to 0, but when fog approves a host, the value might be an empty string, or 0. I was initially searching for 0, and stopped and started the FOGPingHosts service. Nothing happened. In our case, it wasn’t returning any hosts , so I extended the “approved” host search to search empty strings and 0 as the value. At this point we restarted FOGPingHosts again, and immediately approved systems that were shutdown started turning on.
There was no real indication as to what or why, but now I had a theory to try. So I had @x23piracy hard poweroff one of the problem systems. Once again, I restarted PingHosts and nothing happened. So we loaded into the windows system and ran
powercfg -h offand shutdown the system. Now restarting the FOGPingHosts service also had no impact. Thus leading me to the conclusion it must be something with the ping. Remember, Pings don’t happen in the same way as normal with fog. We aren’t simply sending a ping command, we’re essentially scanning a port (# 445 by default) and getting the information from the socket opened so we can be more verbose about that systems status. -
@Tom-Elliott said in Which table to check in db to see if there are pending wakeup entrys:
We aren’t simply sending a ping command, we’re essentially scanning a port (# 445 by default) and getting the information from the socket opened so we can be more verbose about that systems status.
I suppose a ‘penetration tester’ could easily leverage this new feature that Microsoft has implemented. Computers - whether fast startup or not, when they are ‘off’ (or whatever you want to call it) should only turn on if WOL is enabled in firmware, and by a WOL packet only. This is not FOG’s fault, it’s Microsoft’s fault.
-
I just found this…
https://communities.intel.com/thread/29566I’m trying to refrain from celebrating until it’s been a few days with no wakes, but I think I FINALLY found the answer. I’ll document it in case some other poor soul has this problem and googles it.
In the BIOS menu there’s an option to display the Intel ME prompt during boot. It’s together with the options to display F2 to enter setup, F10 to enter boot menu, and so on. I enabled it just to see what it was. Upon restart, sure enough, right at the end of the POST there’s a prompt to press CTRL+P to enter Intel ME. I did. Apparently it’s kind of an extension to the BIOS menus. Among the few items inside, there was a “remote wake up” thing which was set to Enabled. I set it to Disabled. Now the computer doesn’t reply to pings when it’s sleeping. As I said, it will be a couple of days until I can be sure that I’ve solved the problem, but it does look promising.
I have to say, this Intel ME thing (I think it’s Management Engine) is not documented anywhere, nobody seems to know about it, and why Intel put those options there instead of in the BIOS menus with the rest, is beyond me. Even the prompt to enter Intel ME is disabled by default, I was lucky to stumble upon it after trying everything.
Anyway, I hope it works permanently. I would like to thank everyone for your suggestions, especially rseiler. I may have ended solving the problem by myself (hopefully!), but I appreciate the time you took to contribute. I’ll let you know if there are any news, or I’ll mark the question as answered in a couple of days.
I need to sleep now but the solution sounds interesting and the problematic pcs have intel nics.
Will try this on monday!
Regards X23
-
@x23piracy Just for some background information here, I can say that the ME (or actually vPro) is only on select model of computers. Its intended to be a software version of the light-out / RSA / iLo / DRAC / remote management adapter that you find in servers. When vPro is setup you can actually remote into a computer (via the Management Engine) and power it on/off change bios setting, reinstall an OS outside of what ever OS is running on the target computer. It is a really cool, and some what of a PITA to setup - technology. Typically if its not activated the software lays dormant and does not interact with or cause pain to the target OS. It is not part of the bios actually it has its own firmware and kind of runs outside of the traditional bios/firmware. This vPro is actually an add in to the CPU and not anything really to do with the network adapter or its interface. The reason why your network adapter remains operational even of the computer is powered down, is because of vPro is running on the computer in the background on the motherboard.
-
@george1421 look at this, found on the Computers that made Trouble (Intel nics)
The text means in englisch: Activate on pattern match!i will now also check Intel ME…
Regards X23
-
no need to disable hibernating (powercfg -h off) The intel I219 NIC’s support wakeup by pattern match (ping) that can de bisabled within the driver look to my post before with the screenshot.
The question is howto integrate that setting into the image, i think this is registry saved but howto import this before sysprepping? afaik the path in the registry can be different when it detects the nic lan-connection#2 #3 #4 etc.
Any idea?
Regards X23
-
@x23piracy Because what you’re referencing (from what I can tell) is individual device properties, I don’t think you’ll find a viable fix for imaging using that method. This is because even if every system has identical model of nic’s in them, the device between is different.
I’d still recommend using the powercfg -h off option as it’s a sure fire way to ensure it will work across the board.
-
@Tom-Elliott sure i will stick with -h off because we don’t do hibernating but i would like to share information about that behaviour maybe someone can use it
Regards X23
-
@x23piracy Of course, sharing information is always good, but a “here’s how to do it always all the time” is likely not possible doing the method you show below. (Unless you go one by one to every system lol).
-
@Tom-Elliott Wouldn’t it be possible with the postdownload driver install script if you modify the associated config files for those drivers?
-
@Quazz Sure, I suppose, but not quite easily. You have to know exactly where the file is. I’m not 100% sure the file actually exposes the firmware configuration in that manner though.
-
Should be possible to use windows scripting host (WSH) to check with number your NIC is and set the registry key. Have you found out about the registry key yet?
