I've been reading all over the net about this issue, but can't seem to come up with any solutions. For something that is supposed to be simple, it sure is frustrating!Environment:Windows 2003 R2 SP2 ServersWindows XP ClientsSCCM 2007 SP1 Server3Com switchesSame Subnet, no routers in the way.Using a few different tools, I can use WOL to wake a PC successfully. It's functional. When I try to do a WOL from a Mandatory advertisement within SCCM, it's intermittent. We are configured to use Unicast from SCCM. In reading, the ARP cache needs to be populated in order to work. According todocumentation, the SCCM Server is supposed to use the hardware inventory to grab the MAC address, which would then populate the ARP cache. I can watch the ARP cache as it tries to send out a packet. The IP address will show up, with the MAC address of all 00's for all of about 3 seconds, then disappears. when that happens, the PC does not wake up. If I configure a static entry for the ARP cache, it works every time.I have seen talk in the Forums about getting the router's ARP Cache populated, but that doesn't seem to fit our problem. The breakpoint seems to be within SCCM itself. It doesn't seem to be grabbing the MAC address properly, or at least putting it in the ARP cache. BTW, we have made sure the Hardware Inventories are done on a daily basis, which should be more than ample time to have correct information.Please Help.Matthew Williams

I would call PSS.John Marcum, Systems Management Architect - www.TrueSec.com

If all your clients are in the same subnet, I would use broadcast WoL. It works much better in one subnet compared to unicast WoL.With unicast WoL in your scenario the site server should keep the MAC addresses in its ARP cache longer. By default, Windows Server 2003 has2 minute time-to-live for unused ARP cache entries and 10 minute TTL for used entries. You can change the default TTL value by increasing ARPCacheLifevalue in the registry. See:http://technet.microsoft.com/en-us/library/cc739819.aspxWindows Server 2008 has differnet ARP cache parameters, so the following article is only for Windows Server 2003.If your clients would be in the different subnet from the site server, the router's ARP cache TTL needs to be increased. By default, e.g. Cisco's routers have 4 hour TTL. Panu

Thanks for your replies, John and Panu. While I understand the ARP cache time-to-live is not all that long, I don't think that's the problem. As I had mentioned,I have seen talk in the Forums about getting the router's ARP Cache populated, but that doesn't seem to fit our problem. The breakpoint seems to be within SCCM itself. It doesn't seem to be grabbing the MAC address properly, or at least putting it in the ARP cache.If you could help me with that, it would be wonderful. I'm trying to avoid a call to PSS if at all possible, but it is on the table.Matthew Williams

Because your target clients are in the same subnet, the router plays no part in your situation.ConfigMgr is actually getting ONLY the IP address (not the MAC address) of your target machines from ConfigMgr database. If the corresponding MAC address in unknown, the site server will broadcast ARP query. Because the target machine is not online, nobody will answer for this ARP query --> ConfigMgr cannot transmit the correct WoL packet, because it doesn't know the MAC address.You can confirm this with Network monitor. Or with ARP -a command you'll see what machines are in site server's ARP cache.In theory, ConfigMgr could create an ARP cache entry before transmitting a WoL packet, because it knows the target machine's IP and MAC address. However, it doesn't do that!It is much easier to use broadcast WoL if all your target machines are in the same subnet with the site server.

So in effect, the Unicast WOL through SCCM is useless? If I have to wake machines up daily, I know the ARP cache is going to time out after just a few minutes, let alone hours. What I'm reading is that ifSCCM does not have a static ARP Cache, it does not do Unicast WOL. Is that correct? If so, Microsoft should look at removing that portion.Matthew Williams

I've confirmed with Microsoft that SCCM relies on the ARP cache, making Unicast with WOL through SCCM pointless. SCCM will not use the MAC address for the machine that it already knows about! If you can keep the ARP cache loaded with Static entries, it will work. Keep in mind the ARP cache static entries are cleared upon reboot, causing you to recreate it. And to keep up with the changes as new machines are added or removed. Hence, we are going with the Subnet broadcast. Hopefully, this discussion can help out someone else.Thanks for your help, guys.Matthew Williams

I have been testing the Unicast Wake On LAN method, and found some great challenges. Solutions exists, but at a price. Even though this is an old post I think it will help people understand the issues they are facing when using Wake On LAN. I found the Microsoft documentation on the subject inadequate at best. It does not tuch any of the real world issue concurning WOL (http://technet.microsoft.com/en-us/library/bb632911.aspx) There is a reason why WOL is not implemented successfully in every company around the world. Both WOL solutions supported by SCCM (Unicast vs. SubnetDirectedBroadCast) have their pros and cons. No solution is superior, or an obvious choice. Neither of the solutions are limited by the way they are implemented in SCCM, but by limitations (restrictions) found in the TCP/IP-protocol and network equipment. In short I have found the following while working on an companywide WOL-solution: Unicast WOL: Requires ARP Offload support to be fully functional companywide. Not all network adapters do support this feature. Some of the older computer models do not support ARP Offload. See the detailed description of the problem further down in this document. Furthermore ARP offload is only available in standby and while the system is hibernated (S3 and S4 power states), not when the systems is completely powered off (S5 state). Subnet Directed Broadcast WOL: Requires all network routers to be re-configured to allow broadcast from the central SCCM server. This exposes the network infrastructure to SMURF-attacks that in worst case, if exploited, will disrupt the hole network. In best case render the central SCCM server incapacitated. Using a network sniffer it would be relative easy to reveal this exploit. Will wake systems from S5 (completely powered off) Unicast WOL in DETAIL: The main challenges while dealing with the unicast method is to wake systems that have been shut down for a longer period of time. This is due to the very nature of Unicast WOL. The magic package is not broadcasted to all systems on a subnet (like the SubnetDirectedBroadcast-model), but the magic package is targeted to a specific IP-address. Delivering a single TCP/IP-packages to a computer is not a problem. However sending a single package to a system which is shut down, and not fully operational and present on the network is another story! What most people experience while testing Unicast WOL for the first time: it works perfectly as long as the target system has not been shut down for too long! If the target system is shut down for too long it will not wake even though the SCCM Wake On LAN and the network equipment is working just fine. What too long is depends on your network equipment, and how short the ARP-cache timeout is on your particular hardware. It can be anything from 30sec to 4 hours. Even longer. All in all these challenges render the out-of-the-box Unicast WOL solution, found in Configuration Manager, useless. Unless we take other measures into the equation! ARP-request and ARP-response is the sole key to the issue. Neither have anything to do with WOL or SCCM, but basic TCP/IP-transmissions. The following WOL example explains what happens when a target computer is powered off for too long, so its ARP-cache entry expiries from the network equipment: The central SCCM server will send out the magic package targeted to a single IP-address (e.g. 10.2.3.155) As the IP-address is not on the same subnet as the central SCCM server, it is handed to the router (the default gateway of the central SCCM server). It is now the router who is responsible for delivering the Magic package, and not the central SCCM server. You can add as many static ARP-entries on the central SCCM server, but it is not going to change a thing. The router then determines which route the package must be send. In most cases this will be through several other routers on a cooperate network. When the Magic package reaches the final router that is connected to the IP-subnet 10.2.3.x through a switch. The router is now responsible for the delivery of the magic package to the target computer with the IP-address of 10.2.3.155 connected to the switch . This means that the router must find which MAC-address (network adapter) holds the target IP-address (10.2.3.155). This can be done in 2 ways: Either using the ARP-cache or using an ARP-request. The router will always check its ARP-cache first, as this is far quicker than a ARP-request . The ARP-cache is basically a list of IP-addresses and their associated MAC-address. If a match is found the router will know which MAC-address (network adapter) to deliver the unicast magic package to. If no match is found in the ARP-cache (because the timeout is reached), the router will make an ARP-request (broadcast) to all computer connected to the switch, and basically ask; Who holds the IP-address of 10.2.3.155? Normally the target computer (10.2.3.155) would immediately reply to the ARP-request, after it has been process by the Windows OS. This would also add the computers MAC-address to the routers ARP-cache. However when the computer is in a powered off state (S3, S4 and S5) no Windows OS will process the ARP-request package. The router will not receive an answer, and believe that computer is not present on the network, resulting in the a dropped magic package. So in short: When a computer is not powered on, it will not respond to ARP-request. The router will not deliver the Magic package to the computer (network adapter) as it is not present on the network. The Unicast WOL magic package will never reach its target network adapter. The result is no system will Wake/Power On! The Solution: The answer to our prayers is a hardware feature called ARP Offload! This hardware dependent feature enables the network adapter to stay present on the network and answer ARP-request while the system is in standby or hibernated. While Windows enters a power saving state, it will tell the network adapter to answer any ARP requests it receives. The feature does not work if the system shutdowns completely, or AC power is lost at some point after ARP Offload (standby or hibernation) is initiated. If our target system (10.2.3.155) in the example above, did support ARP Offload, it would in step 7 be able to reply to the ARP request from the router. Successfully enabling the router to send the Magic package to the desired computer, and powering on the system. ARP Offload requirements: The network adapter hardware must natively support ARP Offload, and the network driver must also incorporate the support for the feature and be NDIS v6.2 or higher. My experience tells me that the ARP Offload feature is present on most network adapter chipsets designed around 2009-2010 and after. More on the subject found here: http://technet.microsoft.com/en-us/library/ee617165%28WS.10%29.aspx Other solutions for powering on systems are Intel AMT og 3rd party solutions like 1E or custom made solution based on WOL broadcasts, that are send from other computers on the same subnet as the target. Hope this post will make people understand the challenges they face when implementing Wake On LAN.

Excellent post Thorbjrn. I have one thing to add and one question. For those of you above who talk about ConfigMgr and the MAC address in the database, you are confusing what ConfigMgr uses the MAC address for (it does use it) and how TCP/IP works. Thorbjrn explains the TCP/IP side of very things well. In the unicast scenario, to deliver the magic packet to the client standard TCP/IP is used and if the MAC address is not in the appropriate ARP cache or the machine doesn't respond to an ARP request then the packet will not be delivered. Nothing wrong with ConfigMgr, this is how TCP/IP works. ConfigMgr nor Windows will use the MAC address in the database to deliver the magic packet. Where ConfigMgr does use the MAC address from its database is in constructing the contents of the magic packet. The payload of the magic packet does contain the MAC address (16 times in fact) and that will be the MAC from the database. See here for full details: ConfigMgr 2007: Implementing Wake-on-LAN (WoL) My question ... perhaps you can help Thorbjrn? Can anyone find a reference about ARP Offload and a machine that has been powered down (ie. S5)? I don't think ARP Offload gives me a solution because our user population turns off their machines each night. 50K users is a bit difficult to re-educate. I found this thread looking for the answer to this question because when I found out about ARP Offload I got excited and hoped I wouldn't need subnet-directed broadcasts. Unfortunately the little evidence I can find seems to say Thorbjrn is right and machines that have been powered down will not respond to ARP requests and the benefit I was hoping that provided. Finally, here is a good article on Windows 7 and network adaptor power management (relevent to this thread): Power Management for Network Devices in Windows 7