Understanding WakeUp Status
When you are reading WakeUp reports, using the WakeUp Console, or otherwise working with WakeUp, you will often see details about the results of wakeup requests.
WakeUp request stages
Requests go through four stages:
Origination
Server-level processing
Subnet-level processing
Response.
These stages will have various results depending on the stage and the circumstances.
Origination
The wakeup request is originated. This can be from a variety of sources, such as WakeUp Server for ConfigMgr deployments or ConfigMgr console requests, the NightWatchman console, the NightWatchman service for NightWatchman maintenance windows, or Web WakeUp.
Server-level processing
The requests are queued on the NightWatchman and WakeUp servers.
The servers determine:
The client computers that should be targeted
The subnets those computers are likely to be on
The WakeUp servers that are responsible for those subnets
The primary or alternate WakeUp agents on the subnets.
The servers then send the requests to the primary or alternate agents on the subnets.
Subnet-level processing
Magic packets are sent for individual client computers and responses are recorded.
Response
The computers respond if possible. They might already be awake or they might wake up. In some cases WakeUp can determine the computer is now awake but does not know whether that was due to the wakeup request.
How WakeUp status is reported
WakeUp status is reported:
WakeUp stage | Status | Explanation |
|---|---|---|
Origination | Jobs | The WakeUp jobs for the requests. |
Server-level processing | Queued | The number of network interface card (NIC) addresses that will be tried altogether (all relevant subnets). This is more than the number of client computers because some computers have more than one NIC. It also includes retries. |
Skipped | The subnet of the client is not a known subnet (or boundary), or a previous wakeup request was sent and the minimum "rewakeup" time has not expired (15 minutes by default). | |
Subnet-level processing | Sent | The number of network interface card (NIC) addresses that will be tried on the subnet. This is more than the number of client computers because some computers have more than one NIC. It also includes retries. |
Not sent | No primary or alternate agent was available on the subnet. This is also a NIC address count, including retries. | |
Response | Awake | Was already awake when the request was sent to the clients. |
Woke up | Woke up due to the magic packet. | |
No agent | Is awake but WakeUp cannot determine if it was already awake or woke up due to the magic packet. | |
Failed | Cannot be verified as awake. It could be awake but does not have the WakeUp agent, and it doesn't respond to pings. It may not be present at all on the expected subnet, and thus impossible to wake up, or it could be misconfigured so that it doesn't respond to magic packets when it should. |
If you look at the WakeUp client logs or use a network packet sniffer, you will see that the primary or alternate agent on each subnet will broadcast a HELLOWAK packet to query the state of the clients. Those that were woken up by the request will respond with JUSTWOKE. Those that were already awake respond with WASAWAKE. Other clients that are awake but don't respond to the HELLOWAK request are pinged to determine if they are available.
Those that respond to the ping are recorded as "No agent", meaning that a WakeUp agent is not installed or not working on that client (otherwise it would have responded with one of the other two messages). So they are online and ready to be used but WakeUp doesn't know why they are currently awake. All other computers are recorded as "Failed".
Note
Although WakeUp should automatically manage each WakeUp stage, we recommend occasionally reviewing WakeUp status at each stage to see if you can improve the process.
For example, the primary and alternate agents might occasionally become unavailable on some subnets, but WakeUp will continually try to reestablish primary and alternate agents. As a result WakeUp might be less successful at times and then improve without intervention. Or, you might have to intervene when for example, computers might not be successfully configured to received magic packets, or subnets or clients might be configured to reject ping requests.