Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

WOL

solarwinds-admin

I have some problems with the WOl.

i've downloaded the pdf and did everything accordingly. i've send the request to a test machine but it did not wake up.

If i check the task history, i can see that the job was succesfully.

I've check with the network guy and upd broadcast is limited to the local domain.

A reboot is working job is working fine.

the 3 update has been installed already. does someone have an idea.

thanx in advanced.

Find more posts tagged with

Accepted answers

All comments

solarwinds-admin

First, love the avatar.

OK, on the WOL, there are several things to consider.

First and foremost is ensuring that you have run a discovery on the subnets that contain the computers that you wish to wake up with WOL.

You can verify the EminentWare has the required information (MAC address, etc) by running the MAC addresses report under the Discovery category.

If in fact you have verified this, then the next item to look at is ensuring that the computers that you are waking up have WOL enabled in the BIOS AND the network adapter has WOL enabled (we use the magic packet technique).

Assuming this is true, the next thing to verify is that either

1) The computer that you are sending the WOL request to is on the same subnet as the EminentWare server.

2) You have installed a second EminentWare automation server in the subnet that has the computers in it that you want to wake up. BTW, in this scenario the Primary EminentWare server forwards this request to the EminentWare automation server in the subnet and that server sends the WOL magic packet.

3) You have created a exception in your routers that enables the UDP port 9 broadcast to be forwarded to the subnet that has the computer(s) that you are trying to wake up.

If all of these things are effectively done, then I would wakeup the machine manually, grab and install wireshark on that computer and take a sniff on the computer when re-running the WOL task in EminentWare. This will tell us whether the packet is actually getting to the machine (and subnet) in question.

cruggeri

and if none of the above work?... i have used wireshark with TechSprt....got one working...tried the same on the next problem machine...and the same fix doesn't work.
Using Wireshark is great for a couple of machines....but when you are dealing with a number of machines throughout a campus-like area...that becomes a bit inefficient?

Any other ideas on troubleshooting?

LGarvin

In a general sense, issues with WOL come down to one of two areas of investigation.

1. Was the device successfully enumerated in a Patch Manager discovery task? By running an IP Addresses report in the Discovery report category and inspecting the IP Address of the client -- note whether a MAC Address is identified for that client. If there is no stored MAC Address for the client, the WOL will fail. Also, keep in mind the potential impact of short DHCP leases -- which may cause the Patch Manager discovery results to become stale if another device picks up an IP Address previously 'discovered', as now the stored MAC address will be incorrect and the WOL will be delivered to the wrong target. You should run regular discovery events consistent with your DHCP lease times to ensure that the Patch Manager database has correct MAC addressing information.

2. The second part is about network pathways from the Patch Manager server to the target client. If a client works on an IP subnet, then the pathways can generally be assumed to be good to that subnet, but it doesn't necessarily mean that the pathways are good to other subnets. As noted in the original thread, you can also work around the UDP Port 9 router concern by implementing a Patch Manager Automation Role server in the subnet, and defining an Automation Server Routing Rule that routes all traffic for that IP Subnet to that Automation Role server exclusively.