Environment
Novell ZENworks 10 Configuration Management with Support Pack 2 - 10.2
Novell ZENworks 10 Configuration Management with Support Pack 3 - 10.3
Novell ZENworks 11 Configuration Management
Situation
Understanding and troubleshooting ZCM's role in WOL.
Resolution
ZCM's role in WOL is for the Server to generate and transmit an industry standard WOL packet.
Once the packet is created and transmitted, it is up to the network devices to deliver the packet to the target workstation.
The target workstation must then accept and respond to the WOL packet.
The ZCM Agent does not play any role in responding to the WOL packet.
ZCM stores each device's last known IP address and Subnet mask and uses that to send a WOL packet to the broadcast address of that computer's subnet.
For Class "C" Network such as 192.168.1 with the default 255.255.255 subnet mask, the Broadcast address would be 192.168.1.255.
To determine the broadcast address of other Class Networks with other subnet masks, you can use a "Subnet Calculator" to determine the proper broadcast subnet.
An example of such a resource is the following: http://www.subnet-calculator.com/.
The WOL Packet itself will contain the MAC address of the target device repeated 16 times.
An actual WOL packet is displayed below:
Key parts of the packet to note are the following:
Destination: 192.168.1.255 which is the broadcast address for the device's subnet.
Protocal: WOL. Ethereal identifies the packet as a WOL packet which helps indicate the packet is properly formed.
Packet Contents: The MAC address of the device is repeated precisely 16 times.
Along with using a packet capture tool to verify what is actually hitting the wire, you can enable debug logging on your ZCM server.
The loader-messages.log file will contain the details about the WOL packet activity.
A snippet of the logs will clearly show what it believes to be the IP address, SubnetMask, and MACAddress of the target device.
This should correspond to the actual packet that is transmitted above.
-----------------------------------------------------------------------------------------------------------
[DEBUG] [10/21/09 2:07:38 PM] [] [WakeOnLANHandler : Sending packet for retry count : 0]
[DEBUG] [10/21/09 2:07:38 PM] [] [IPaddress = 192.168.1.77 SubnetMask = 255.255.255.0MACAddress = 000c29e960d1]
[DEBUG] [10/21/09 2:07:38 PM] [] [IPaddress = 192.168.1.77 SubnetMask = 255.255.255.0MACAddress = 000c29e960d1]
Currently there are not any known issues where the incorrect information is used to generate a WOL packet or the WOL packet is not generated properly.
When reporting any WOL issues to Novell, please be sure to include both the log file and packet capture and indicate whether the logs shows the wrong information being supplied to generate the WOL packet or the capture demonstrating the WOL packet does not match the information that was supplied.
Additional Information
The overwhelming majority of WOL issues are traced to either the network infrastructure or workstation configuration.
If the WOL packet has been confirmed to have been transmitted properly by the server, but the target workstation does not appear to respond the next step in troubleshooting would be to confirm the packet arrives at the workstation. To do this, turn on a packet capture utility on any device on the PC's subnet and take a trace while issuing a WOL command. If the packet is not received by the device on the target workstation's subnet, then there is a configuration issue with the routers and/or switches which are blocking WOL subnet broadcasts.
Either reconfigure the routers and/or switches to permit WOL Subnet broadcasts or configure a WOL Proxy.
Please see TID#7001764 to learn how to configure a WOL Proxy.
If the packet reaches the target device, but the workstation is still not waking up, ensure the WOL is enabled in the BIOS of the computer.
Also, the NIC Driver in Windows may contain WOL settings that control if the device will respond to WOL packets.
In rare cases, updating or backdating drivers in Windows seems to effect whether or not the computer will respond to WOL packets.
The reason that a Windows Driver can effect WOL even when the PC is powered off and Windows is not running is that the Driver can actually configure settings on the NIC that will persist even when the computer is powered down.
To Allow WOL to Bring a device out of a Hibernate State, Perform the following Steps which may vary slightly depending on the Version of Windows:
1. On the target computer in Device Manager or in the network settings select the network card.
2. Click on: Properties
3. Click on the configure button of the network card.
4. Select the tab: Power management
5. Set a check mark at: Allow this device to bring the computer out of standby
6. Click on: OK
7. Continue to close all property pages.
2. Click on: Properties
3. Click on the configure button of the network card.
4. Select the tab: Power management
5. Set a check mark at: Allow this device to bring the computer out of standby
6. Click on: OK
7. Continue to close all property pages.
(Note: The BIOS must support this feature as well and not all devices may support WOL in a hibernate state.)