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.

1. The servers determine:

   1. The client computers that should be targeted.

   2. The subnets those computers are likely to be on.

   3. The WakeUp servers that are responsible for those subnets.

   4. The primary or alternate WakeUp agents on the subnets.

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