It is sometimes a little disconcerting to the new customer when installing the 1E WakeUp Server component, opening the WakeUp Console for the first time, browsing to the AGENTS node and finding little or nothing there! This document is going to provide a basic overview of the process, and the communications required to make it all happen.
We assume here that the WakeUp Server component is properly installed, and that several agents (at least) are deployed to remote subnets (“remote” is defined here as being other than the same subnet that the WakeUp Server is installed on). We also assume that those agents have had time to send up to the server their basic inventory (specifically, IP info), that ends up in the server-side file ..\docs&settings\all users\Application Data\1e\WakeUpSvr\AgentList.dat
So, how do we list the subnets in the WakeUp Console/Agents node in the first place? It all begins with the initial WakeUp request for a machine on a given subnet. To see as much detail as possible in the logs, increase the DEBUG level to the max:
hklm/software/1e/WakeUpSrv (or WakeUpAgt)
REG_DWORD name DEBUG
Value: 255
1) WakeUp Server receives a WAKE_NAME action, for instance to wake a machine by name from SMS/CfgMgr or the NightWatchman Console
2) The Name is resolved to a ResourceID
a. This comes from machine discovery data from WMI
b. This information will be detailed in the WakeUpSvr.log
c. For a collection or group we resolve to a list of ResourceIDs, so from this point on the process is the same
3) We retrieve a list of that machine’s mac address, ipaddress and subnet
a. These are retrieved from the hardware inventory which needs to be up to date from WMI
b. we often have multiple ip addresses, subnets, and mac addresses
c. This information will be detailed in the WakeUpSvr.log
d. We look in the AgentList.dat currently loaded into memory (memory mapped file) for all the subnets
4) If we currently do not have an entry for the subnet or there isn’t a primary or alternate agent registered we start the agent finder process, seen in the WakeUpSvr.log file as:
“ Could not find subnet in agent list. Creating a new entry...”
“ AgentFinder Rescan 10.205.17.0”
“ Finding agent(s) subnet - 10.205.17.0 [255.255.255.0]”
5) The agent finder process queries the database (SMS/CfgMgr or NWMMgmtCtr) for all machines in that target subnet and return a list of ip addresses
a. This appears in the log as a ping list
b. Each machine is pinged in turn
c. On a successful ping the following appears in the log
“Found 10.205.17.44”
6) If the machine is pingable (ICMP PING and ECHO must be open to/from the client) we attempt a TCP/IP connection to that machine on the WakeUpAgent port (port 1776)
7) If the Agent is not running, or we cannot connect to it, we get the following error:
“Failed to connect to WakeUp agent on 10.205.17.44”
8) This can occur because the machine is off, the connection was blocked, the agent is not installed or running, or the port is configured incorrectly
9) If the machine is on but the WakeUp agent is not running you see the following error
“ GetTCPconn connect failed No connection could be made because the target machine actively refused it. 10.138.191.105:1777”
10) We carry on trying machines until we find one we can connect to, when the following appear in log (agent is able to respond to the server via port 1777):
“Found 10.205.17.41” “New Agent found 10.205.17.41 for subnet 10.205.17.0”
d. Note well: this agent is not in the agent list yet
11) To validate the bidirectional communications that are required, we send a register message to the agent (again, via port 1776)
12) The agent then responds and registers with the server (and as before, on port 1777)
“ Agent 'IBFFTCMW39217, 0, 0,mask=255.255.255.0' registering for subnet 10.205.17”
13) At this point, the agent appears in the WakeUp Console on its respective subnet. You now have a primary agent. The same process occurs with a second agent, registering itself as the alternate agent on the subnet
14) The wakeup request is queued for that initial send request, and sent to the primary agent on the remote subnet
15) The primary agent receives the wakeup request and proceeds to issue the magic packet to the requested machine’s MAC address
Things that can go BUMP in the night!
So what can cause any or all of the above to fail, and you see A) no subnets at all (other than 0.0.0.0 with “Local Agent”; and, the WakeUp Server’s local subnet with “YourServerName” listed); or, B) Subnets listed but no agents registered on them?
· In the WakeUp Server’s registry, the following key is set incorrectly (this is documented in KB article Q10789):
hklm/software/1E/WakeUpSvr
REG_SZ name AGENTMANAGER
Value: ON
· see 1E WakeUp Installation Guide, Section 6.2 Common Problems for a summary of issues at either or both the client and/or server firewall
o Firewalls are blocking communications on either or both ports 1776 and 1777 (the latter is currently not documented in this section)
o ICMP PING and/or ECHO are blocked at either or both the client and/or server firewall
· Secure (encrypted) communications are specified on one side and not the other
o Server is using encryption, but client is not
o Client is using encryption, but the server is not
Hopefully this information will better explain the process that is followed, and give some ideas or insight into what may be causing the process to fail.