When I run the following command from an administrative command prompt on the root server, it returns: [ERROR] REST API returns error: HTTP 401: Unauthorized.
My BESWoLMedic.log does not have these error, so doesn’t that mean that the credentials are correct? This just started happening in the past year. I am not sure what changed.
Command:
C:\Program Files (x86)\BigFix Enterprise\BES Server\Applications\BESWoLMedic\BESWoLMedic.exe" -besserver http://<BigFixServer_host>:<BigFixServer_port> -r https://<BigFixServer_host>:<BigFixServer_port> /api -u <master_operator_name> -p <master_operator_password> -e “IBM BigFix Server” -d
What does the -e parameter mean? I assume it is an endpoint. The documentation is not clear.
I didn’t know how this part worked and had to do a bit of archaeology to find out. Thanks for the challenge!
The “-e” parameter provides the ‘Realm’ for authentication. That has varied a bit depending on BigFix Server Version.
We can see the different values by version listed in the Fixlet “842 Enable Wake-on-LAN Medic” int he BES Support site:
if {version of main gather service >= "9.5.16"}
parameter "ApplicationParams" = "-besserver %BESHTTP% -r %RESTURL% -u %MOUSERNAME% -p %MOPASSWORD% -e "BigFix Server""
elseif {version of main gather service >= "9.2.6"}
parameter "ApplicationParams" = "-besserver %BESHTTP% -r %RESTURL% -u %MOUSERNAME% -p %MOPASSWORD% -e "IBM BigFix Server""
else
parameter "ApplicationParams" = "-besserver %BESHTTP% -r %RESTURL% -u %MOUSERNAME% -p %MOPASSWORD% -e "IBM Endpoint Manager Server""
endif
For 9.5.16 and higher, the ‘-e’ parameter should be “BigFix Server”. This format worked for me:
BESWoLMedic.exe -besserver http://bes-root.local:52311 -r https://localhost:52311/api -u <username> -p "<password>" -e "BigFix Server"
I’m not sure why we specify both ‘-besserver’ and ‘-r’ for REST URL; if I had to guess, I would think the BESWolMedic may have to lookup dashboard variables or something that would be prefixed with the deployment name (so ‘-besserver’ probably needs to match your Masthead Name), while the -r parameter is used to connect to the REST API (and might use a different name in the case of a fake-root, or 127.0.0.1:52311/api for loopback or something along those lines).
Thanks Jason! The key was “BigFix Server” vs “IBM BigFix Server” which is what is listed in the WOL troubleshooting document.
Now I need to figure out why WOL is not actually waking up machines. I notice that the BESWolMedic.xml was changed 11/7/2024. It is calling BESWoLMedic.bat rather than BESWoLMedic.exe. The bat file consists of the following.
%1 %2 %3 %4 %5
for /D %%f in (C:\Windows\Temp\p2xtmp*) do @rmdir “%%f” /Q /S
I am running Bigfix version 10.0.7.52. I have a case opened but not getting anywhere with it. CS0174491
The BESWoLMedic.log shows no errors.
Hm. The fixlets themselves were last modified in 2016.
Reading in a bit more detail, the settings snippet I included above were for Linux-based roots. For Windows-based roots, the commands it builds are
// adding realm
if {version of main gather service >= "9.5.16"}
parameter "ApplicationParams" = "-besserver %BESHTTP% -e "BigFix Server""
elseif {version of main gather service >= "9.2.6"}
parameter "ApplicationParams" = "-besserver %BESHTTP% -e "IBM BigFix Server""
else
parameter "ApplicationParams" = "-besserver %BESHTTP% -e "IBM Endpoint Manager Server""
endif
Then further down I see where it’s building the XML of the command to execute:
<Command>"{ value "EnterpriseServerFolder" of key "HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\Enterprise Server" of registry as string & "Applications\BESWoLMedic\BESWoLMedic.bat" }" "{ value "EnterpriseServerFolder" of key "HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\Enterprise Server" of registry as string & "Applications\BESWoLMedic\BESWoLMedic.exe" }" {parameter "ApplicationParams"}</Command>
So this executes the BESWolMedic.bat and sends it several parameters, which inside the batch file get interpreted as
%1 = "<path to BESWolMedic.exe>"
%2 = -besserver
%3 = <name of BES server>
%4 = -e
%5 = "BigFix Server"
So what the batch file is doing, is executing the BESWolMedic.exe with those parameters, and then deleting the TEMP files that it creates. The ‘p2xtmp’ folder names indicate this tool was original a Perl script compiled to an executable, so executing it extracts a runtime into TEMP to execute it.
When this is run in the context of the BES Server Plugin Service we don’t have to supply the credentials on the command line, I think they come in as part of the environment
I am running Wireshark with a WOL filter and I am not seeing any traffic going out when I right-click on “Send Wake on Lan Request”. This is on the root server.
For whichever client you are trying to wake, the root server determines one or more ‘Wake-on-Lan Forwarders’ attached to that clients’ subnet. Do you have WoL Forwarders deployed?
Once the server selects one or more Wake-on-LAN Forwarders to notify, the root server will send a Notification to that client. This uses the normal notification path, so it’s a TCP/52311 from the Root to top-level Relays, TCP/52311 from any Parent Relay to any Child Relay, and finally UDP/52311 from whatever Leaf Relay to the WoL Forwarder Client.
It’s only the WoL Forwarder client that will send the UDP broadcast on the target subnet with the magic packet (that Wireshark is probably looking for). That’s a broadcast (IP broadcast and, I think, Ethernet broadcast) packet with the target MAC address repeated three times. I don’t recall which UDP port is specified but it’s probably 52311 as well.
Since you may not always know which Wake-on-LAN Forwarder is going to be used (and we often recommend enabling every client as a Wake-on-LAN Forwarder), the easiest way to test is usually by running a packet sniff on the target machine, since you may not know the expected source of the WoL packet.
WoL has been working in our environment for the past 10 plus years. I do have every machine setup as a Wake-on-LAN Forwarder.
If I sniff with Wireshark, I can filter for UDP but after that I am lost. How can I filter to find the Magic packets?
Again you’ll need to sniff this on the subnet of the client but this may help
I used a WireShark Capture Filter of just udp to capture only UDP traffic, and a Display Filter to show the packets:
(ip.dst==192.168.1.255)&&(eth.dst==ff:ff:ff:ff:ff:ff)
I sent the Wake-on-LAN request several times. In the Data we can see the string starting ‘BESWol’ so we know it came from BigFix, and then the ‘magic packet’ content which is the 6 bytes of 0xFF followed by the target machine’s MAC address repeated several times. I can also see it was sent on UDP/52311; that’s a BigFix convention, but the Wake-on-LAN specification itself does not require any particular UDP port.
If you can try to capture that, then knowing whether (1) the packet is not being sent, or (2) the packet is sent but it does not wake the client cuts the problem space in half.
That is really helpful. I am seeing the BESWoL in the Wireshark data. So, it appears that the Magic package is reaching the endpoint but still not waking up machines that are shutdown. I believe the bios and the NIC are set correctly.
The only machine in our environment that was not a wake-on-lan forwarder was the root server, according to the fixlet to turn on WoL forwarder. I turned on WoL forwarder on the root server. This seemed to make a difference in the look of the Wireshark capture. Does that make sense? Is it a requirement that the root server be a WoL forwarder?
My issue with wake-on-lan is resolved. The problem was a setting in bios under power management called “Extended Idle Power States”. With this setting enabled, WoL did not work. After turning it off, WoL worked. I am using HP EliteDesk G6 and G7 machines. The problem was that power was off to far to come back on.
Dave Langridge introduced me to a nice tool called WakeOnLanMonitor.exe. It detects Magic packets reaching the endpoint. The trick with it is to use port 52311, and stop the BESClient service.
2 Likes
Thanks for posting back with your solution! Much appreciated.
