11 Replies Latest reply on Jul 11, 2016 11:36 AM by phoffmann

    WOL takes the weekend off!

    GaryH Apprentice

      I got WOL working finally in Landesk.  Biggest problem was some Dell OptiPlex’s and the need to disable S4/5 deep sleep in addition to turning on WOL in bios. Tested WOL a number of times after pushing out bios update using Dell CCTK.

      One of my test boxes sits here in my office.  Last week, I could power it down and bring it back up via console repeatedly. 

      I come in this morning, and I see the Nic lights on for that box. As I would expect.  Box is turned off.  I initiate WOL from console . . . . .nothing.  I try again. Nothing. I try a third time. Nothing.

      So I power up that box and then shut it down.  10 Minutes later, I right click and WOL in console.  Machine powers right up via WOL from console.

      What gives?  The only difference I know of is that I waited over the weekend to WOL this time. Its almost like the longer I let the machine set, the less likely WOL will work.  I have seen this several times.

      Am I still missing something?



        • 1. Re: WOL takes the weekend off!
          marcel Specialist

          Which OS do you have installed? If you have Windows 10, Microsoft have changed the shutdown process and you have to do something special.

          • 2. Re: WOL takes the weekend off!
            GaryH Apprentice

            Windows 7 Enterprise.  And, like I said, it seems to work most of the time but APPEARS to stop working after machine has been powered off extended persiods of time.  This is all on a test box here I can verfy that everything looks right.

            • 3. Re: WOL takes the weekend off!

              Hi Gary,


              I am experiencing the same issue with machines not powering up after they have been switched off for a prelonged time. I've had a look at the problem and noticed that I don't experience the problem with machines that have reserved IP addresses (or static IP's). I thought LANDesk WOL used the MAC address to wake up machines. I was wondering if anyone has a fix for this issue as I've run ou of ideas...


              Did you manage to fix the issue?

              • 4. Re: WOL takes the weekend off!
                rmeyer SupportEmployee

                WOL is not LANDESK's. You have to make sure the BIOS for the computers is set correctly for WOL to work. There are utilities you can use to send the magic packet to a MAC address to test the computer to make sure it is configured correctly. Google it to find a magic packet utility so you can test it to make sure the computer is configured correctly. If you need help with configuring WOL properly on the device, you will need to contact your computer vendor for help with it.

                • 5. Re: WOL takes the weekend off!
                  phoffmann SupportEmployee

                  All WOL uses MAC-addresses - the magic packet is 16x (IIRC) the MAC-address. You don't use IP's at all (since "at the time" of being off, a NIC doesn't have an IP address as such).


                  If you can see the WOL packet being sent on the relevant network segment (there's not much to it, and you can grab a specific WOL tool to test the WOL yourself), then that's about all there is from our side to do (i.e. - step 1 - identify the right network / step 2 - get a client to send a WOK packet out). Tools like Wireshark help here to ensure that what is supposed to happen is happening (and you don't have weird things like switches or whatnot blocking you, for instance).


                  If the WOL packet makes it on to the network, the rest is down to the machine / hardware.

                  • 6. Re: WOL takes the weekend off!

                    I am able to WOL using a script without any issues, so there is no issues with the device configuration.

                    The problem I have is that when I right-click the device and select WakeUp=>WakeUp On LAN in LANDesk the machine doesn't wakeup if it has been switched off for a prolonged time. However if the machine is on, I can switch it off/on using the same WOL option.


                    Any ideas.

                    • 7. Re: WOL takes the weekend off!
                      phoffmann SupportEmployee

                      OK - that makes more sense.


                      My initial suspicion here then is going to be down to network configuration - not so much in a "your routers are borked" but in a "LD can only WOL on what it has in the database - and that may be outdated?" type situation. So we have to check that the network (specifically - subnet) information is (still) correct on the device. If a device "changes subnets" while it's powered off (for instance), we're going to be sending the WOL packets to the wrong network.


                      Here's a few articles to help you along:

                      - Wake on LAN troubleshooting flowcharts

                      - How To: Test Wake on LAN/ Wake on WAN

                      - How To: Change Wake on LAN / Wake on WAN Port


                      The last article is "just in case" that a certain port simply gets blocked on the network level somewhere down the line. Chances are you'll need to start Wiresharking / sniffing the network to find out at what point the network comms that should happen - don't ... and go from there.


                      If need be, the support folks can help you with that, as well - but the above articles should help you along considerably, I hope.


                      The "fixed IP" stuff *should* be a red herring by and large, but if there's a lot of "network segment switcharoo" type stuff happening, that could explain it - broadcast domains are very significant for WOL to work - if we send the WOL packet in the wrong subnet, the client is never going to hear the magic packet, if that makes sense.

                      • 8. Re: WOL takes the weekend off!

                        Hi, Okay it looks like there maybe an issue with the database being outdated as the problem only exists when we try and WOL machines using LANDesk, other methods work fine.


                        Can you let me know how we can update the database and keep it updated so we can get WOL working via LANDesk, thanks.

                        • 9. Re: WOL takes the weekend off!
                          MarXtar ITSMMVPGroup

                          You say you are using Wake-On-LAN, have you tried using the Wake-On-WAN option?


                          A while back LANDESK changed WoL so it would try an IP directed WoL as well as a subnet directed broadcast. Subnet directed broadcast is generally blocked whereas the directed message would be allowed through as long as the MAC address of the device was still in the cache of the devices that needed to route the information. This is probably why you find it works but then doesn't if the device is left offline for a while.


                          Wake-On-WAN should still use this but should also attempt to use another device within the local subnet to wake the target device. It's slower overall but should have a higher success rate.


                          Mark McGinn

                          MarXtar Ltd/MarXtar Corporation


                          LANDESK One Development Partner


                          Try MarXtar State Management for LANDESK to Better Understand and Manage your Assets

                          • 10. Re: WOL takes the weekend off!

                            I have tried both but no joy.


                            Why would LANDesk use the ip? Surely it makes sense to use the MAC address of hosts. I currently use a WOL script which uses the MAC address of machines at it works realily well.


                            I need to get LANDesk to wake up machines, is there any way of doing this as I'm out of ideas.

                            • 11. Re: WOL takes the weekend off!
                              phoffmann SupportEmployee

                              It doesn't use the IP as such. The rest of the networking information is relevant though.


                              OK - so quick crash-course in networking fundamentals around WOL.


                              • You have broadcast domains - often misnamed subnets - which are pretty important with WOL, as WOL is a UDP broadcast & thus doesn't go beyond its broadcast domain (usually a router, but doesn't have to be).


                              • Therefor, the Core needs to know what broadcast domain a client is on that you're trying to wake up, so that it can throw a request into the relevant network so that a broadcast-domain local device (any LD client) can send the magic packet


                              • ... does that explain why knowing the network information is relevant? It's not about the IP-address - it's about the rest, in essence.


                              In terms of "what's happening" - have you looked at/through the logs / used Wireshark at all? "It doesn't work" doesn't really help much in terms of pointing you in the right direction. The place to look at, is the "console.exe.log" - that's usually in "C:\Program Files\LANDesk\ManagementSuite\log\"


                              You should have entries like the following one:

                              07/11/2016 18:26:23 INFO  1520:Main Thread RollingLog : WakeOnLan.Wakeup(): Sending Packet - ipAddress =, subnetAddress =, macAddress = 000C294EE571, port = 0


                              This gives you a starting point, to ensure / check against your expected network setup (it's a lazier option than unpacking Wireshark right off the bat).


                              Have you looked through the troubleshooting articles I've linked above? It's a pretty low-tech affair (there's not much to a magic packet) so it usually comes down to network information in the DB side being incorrect (because - say - a laptop changed location from where it last scanned) or stuff gets blocked on the network somewhere down the line (for whatever reason). Unlikely the magic packet itself gets blocked (as you tested this & that works & there's not much to it), but it could be the comms leading up to it (for instance).


                              Hope this helps?

                              1 of 1 people found this helpful