none
WOL working on some PC's even though UDP broadcasts not enabled on switches.

    Question

  • In our environment we want to enable WOL through SCCM using Unicast.  This has been enabled in SCCM but UDP forwarding has not been enabled on any switches.

    The network team is hesitant to start doing this since we have over 200 switches in our environment so we were asked to test after enabling in SCCM but not making any changes to switches.  The expecation was that the WOL would not work, but we are finding that even though the switch settings haven't been changed WOL sometimes works.  It's a low success rate but the fact that any PC's are waking up is causing a bit of confusion and our network team doesn't want to proceed with making changes to the switches until we know why some machines are waking up when we try WOL.  Again the expectation is that none would wake up.

    Does anyone know why some PC's are waking up with Unicast WOL through SCCM even though we haven't made changes to the switches?

    Wednesday, December 5, 2018 3:52 PM

Answers

  • The wording there is misleading as they aren't really "forwarding" UDP, they are simply delivering it like any other network traffic. The implication is that if you blocked UDP traffic, then you'd have an issue. I have no idea why anyone would block UDP outright, but it's technically possible.

    Also, the supposed MAC Flapping isn't an issue if you are prepared for it. It doesn't break anything and is perfectly acceptable if you understand what's happening -- that's for discussion with your network team though.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by legion991 Thursday, December 6, 2018 10:19 PM
    Thursday, December 6, 2018 10:15 PM

All replies

  • hello, which version of configmgr are you using? if the transmission method you choose is Subnet-Directed Broadcast, then maybe you "No switch reconfiguration is required." reference: https://docs.microsoft.com/en-us/sccm/core/clients/deploy/plan/plan-wake-up-clients#choose-between-unicast-and-subnet-directed-broadcast-for-wake-on-lan
    • Edited by ken.lc Thursday, December 6, 2018 7:49 AM
    Thursday, December 6, 2018 7:47 AM
  • It's version 1806, we have WOL configured for Unicast not subnet-directed broadcasts.  
    Thursday, December 6, 2018 2:38 PM
  • Unicast doesn't use broadcasts -- that's the whole point and why it's called "unicast" -- there's nothing to actually configure network-wise for it to work.

    Unicast is problematic though because of ARP and CAM cache timeouts though.

    You should upgrade to 1810 so that you can take advantage of a new peer-based wake-up capability.

    From https://docs.microsoft.com/en-us/sccm/core/plan-design/changes/whats-new-in-version-1810:

    New client notification action to wake up device

    You can now wake up clients from the Configuration Manager console, even if the client isn't on the same subnet as the site server. If you need to do maintenance or query devices, you're not limited by remote clients that are asleep. The site server uses the client notification channel to identify another client that's awake on the same remote subnet. The awake client then sends a wake on LAN request (magic packet).

    As a complete side-note, this is a forum for ConfigMgr/SCCM 2012 though and not Current Branch which is what you are running.


    Jason | https://home.configmgrftw.com | @jasonsandys



    Thursday, December 6, 2018 4:42 PM
  • Right, Unicast doesn't use broadcast but as per Microsoft "switches may need to be enabled to forward UDP packets".  Our switches are not configured that way and our network team won't enable them untill they know why some PC's are waking up and some aren't without the switch changes.  Are you saying that without this change it should still work?  Any idea how I can explain that to our network team? Because they are insisting that Unicast shouldn't work at all without the switch change.

    I'm aware of the new Wake Up action in version 1810 however as far as I know that's a process that's triggered manually.  The Unicast WOL in SCCM can be triggered at the time of a scheduled deployment so we can schedule deployments after hours and wake up the neceessary machines at that time automatically, we aren't expecting a %100 success rate with WOL but the more we can wake up automatically the better.

    Sorry for posting in the wrong forum,  I guess I'll start a new post in the correct one.  Thanks.

      

    Thursday, December 6, 2018 5:01 PM
  • but as per Microsoft "switches may need to be enabled to forward UDP packets"

    Not sure where that's coming from, but it's incorrect for Unicast.

    Are you saying that without this change it should still work? 

    Yes, absolutely.

    > Any idea how I can explain that to our network team?

    Simple, it's Unicast from the site server directly to the device being woken up. No forwarding of anything involved just like all other unicast traffic on the network.

    I'm aware of the new Wake Up action in version 1810 however as far as I know that's a process that's triggered manually.

    Hmmm, I thought it was for all WoL but I could be wrong the wording above is a bit ambiguous. I will see if I can get an answer to that.

    On a parallel note, there is another peer/proxy wake on LAN technology built-in as well that helps avoid the ARP and CAM cache timeout issues: https://docs.microsoft.com/en-us/sccm/core/clients/deploy/plan/plan-wake-up-clients


    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, December 6, 2018 9:00 PM
  • Great, thanks for the info.  We did look at that other peer/proxy WOL technology but our network team didn't want us to use it because of the MAC flapping.

    The part about "switches may need to be enabled to forward UDP packets" is from this page from Microsoft.

    https://docs.microsoft.com/en-us/sccm/core/clients/deploy/plan/plan-wake-up-clients#choose-between-unicast-and-subnet-directed-broadcast-for-wake-on-lan

    It's listed near the bottom of the page as a disadvantage for Unicast.

    From what I've seen the new Wake Up action is manually initiated from the "Client Notification" option when right-clicking a device or collection.  If it works with automation that would be great but from what I've seen scheduled deployments would still use Unicast. 

    There is also at least one limitation with the new Wake Up Action that a machine on the same subnet as the target machine needs to be on to send the WOL packet, but it would still result in a higher success rate for WOL than what we get now.

    Again, thanks for the info.


    Thursday, December 6, 2018 10:07 PM
  • The wording there is misleading as they aren't really "forwarding" UDP, they are simply delivering it like any other network traffic. The implication is that if you blocked UDP traffic, then you'd have an issue. I have no idea why anyone would block UDP outright, but it's technically possible.

    Also, the supposed MAC Flapping isn't an issue if you are prepared for it. It doesn't break anything and is perfectly acceptable if you understand what's happening -- that's for discussion with your network team though.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by legion991 Thursday, December 6, 2018 10:19 PM
    Thursday, December 6, 2018 10:15 PM
  • I also just confirmed that only the manual action takes advantage of client notification to a peer.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, December 6, 2018 11:14 PM