Some SCCM clients not receiving WOL packects
We are beginning to implement WOL with SCCm and we are running into problems with some clients not receiving a magic packet to wake them up prior to the advertisment. The server is on a different subnet than the client and subnet directed broadcasts are enabled. In some cases we have complete success and in others only a portion of the clients in a particular collection wake up. We have had a network monitor on the subnet in question that has failed the most and we only see three magic packets appearing for three clients. These clients do wake up so I want to see if they are actually being sent from the server itself to the entire collection. Hardware Inventory information appears to be correct for all stations in the collection and correspond to DNS and DHCP entries. Can anyone tell me which log I can use to actually view the wakeup packages being sent from the server. I have tried the wolmgr.log and wolcmgr.log but they do not show any info as to whether a particular station has had a magic packet generated for it by SCCM. I do see that it is processing jobst and that they have been attempted three times as per the wol settings on the server with a 3 minute offset.
November 25th, 2010 4:14pm

Hi, Have you tried to capture the traffic with a network monitor? It should give you the needed information.Kent Agerlund | http://scug.dk/ | The Danish community for System Center products
Free Windows Admin Tool Kit Click here and download it now
November 26th, 2010 1:07am

That's most likely caused by network components, not the ConfigMgr server. It might have something to do with ARP entries on routers.
November 26th, 2010 4:18am

That's most likely caused by network components, not the ConfigMgr server. It might have something to do with ARP entries on routers.
Free Windows Admin Tool Kit Click here and download it now
November 26th, 2010 4:18am

Hi I thought that arp caches were only relevant with Unicast and that subnet directed broadcasts do not depend on arp caches? My understanding is that a subnet directed broadcast sends out to everyone on the subnet and only those stations with the MAC address in the packet acknowledges it. I thought the server held the mac address information after an HW inventory was done and didnt need to rely on the arp cache, that being the reason to use subnet directed broadcasts instead of unicast. If the server doesnt have the information it would send out an arp request which would then indicate a problem with the stations HW inventories but the properties of each client indicates the correct MAC address as does DNS and DHCP. We have sniffed the subnet where the packects should be appearing but only three of 37 show up. I was hoping to find a log that actually shows the packets being generated from the server so I can eliminate it as a problem and look at the network with our woefully understaffed Network guys. If packets were being dropped on the network, it would be logical to me that the the wake ups would be more random with different stations recieiving them over a series of tests instead of the same 3 of 37 stations over n over, which suggests to me they are not being generated in the first place by sccm.
November 29th, 2010 4:20pm

Hi I agree with the guys that this is network related and by default CISCO (assuming CISCO) disables MAGIC packed forwarding for security reasons. We've enabled this on all switches but locked it down to a single MAC address (ConigMgr server) and port number. I've used this to troubleshoot http://www.depicus.com/wake-on-lan/wake-on-lan-gui.aspx http://www.depicus.com/wake-on-lan/wake-on-lan-monitor.aspx We do have some hardware VPN sites that do not support the MAGIC packet so we've started using 1E wake http://www.1e.com/softwareproducts/1ewakeup/index.aspx It allows you to create a WOL webpage which is used daily by Engineers to wake up desktops in remote sites. Hope this help G Gerhard (G-man)
Free Windows Admin Tool Kit Click here and download it now
November 30th, 2010 4:28am

Hi JIMDAV987 Please check WOL is properly configured on the Targeted Machines (BIOS as well as NIC settings) also check udp port 9 is not block. Gather Model number of the computers facing this problem and if Model number is same than contact to the PC vendor. I had faced a problem where vendor had provided me a patch for BIOS. Below is a link of advantages and disadvantages for both (Unicast and subnet directed broadcast) mode. http://technet.microsoft.com/en-us/library/bb632911.aspx Below are the inbuilt reports which will help you in finding that packets being generated in the first place by sccm or not. Errors received while sending wake-up packets for a defined period History of Wake On LAN activity All sites that are enabled for Wake On LAN All computers targeted for Wake On LAN activity All objects pending wake-up activity Below is the link for Troubleshooting Wake On LAN Issues might help you. http://technet.microsoft.com/en-us/library/bb932199.aspxDivakar
November 30th, 2010 5:18am

Hi and thanks for replying Forwarding of subnet directed broadcasts with an ACL list was done prior to these tests and I do not think it is a problem here as some of the stations do wake up in the subnet. Sniffing the network during the wol packages arrival in the subnet shows 3 wol packages for the three stations that do wakeup with the correct cooresponding mac addresses but the remaining 34 packages for the other 34 stations do not show up ever. The reports indicate that all these stations are targeted for a wol activity. The wolcmgr.log and wolmgr.log all indicate that the jobs were completed successfully. errors recieved while sending wake up packets for a defined period shows no errors History of WOL activity shows no errors All Sites that are enabled foe Wake on Lan shows the site is enabled All computers targeted for Wake On Lan activity is complete as is all objects pending WOL activity All stations in each subnet are Acer Veriton M670G and are able to be woken up by other means either via our Deepfreeze console or dummy WOL packets sent to the stations. Our Deepfreeze server is able to wake up all the stations with no problem using subnet directed broadcasts and thats why I do not believe it is a issue with the Lan and I am able to wake up the stations with MC-WOL within the subnet so I do not believe it is a BIOS issue since they respond to this method as well. At this point I am really running out of places to look for where the eror is occuring as it just seems to be that the WOL packages are just not being generated by SCCM
Free Windows Admin Tool Kit Click here and download it now
November 30th, 2010 3:00pm

Go through below link and see if it helps you http://blogs.technet.com/b/smsandmom/archive/2008/03/04/configmgr-2007-implementing-wake-on-lan-wol.aspx Divakar
December 1st, 2010 11:15am

Go through below link and see if it helps you http://blogs.technet.com/b/smsandmom/archive/2008/03/04/configmgr-2007-implementing-wake-on-lan-wol.aspx Divakar
Free Windows Admin Tool Kit Click here and download it now
December 1st, 2010 11:15am

Well it does appear that the error is coming from Sccm We did some port mirroring of the sccm server and noticed that for each station that was not waking up the destination address for that frame was incorrect. The destination address for the station not waking up was 169.254.255.255 so its getting dropped at the very first router. What we are trying to figure out is why for some stations that are assigned the wol enabled advertisement the subnet address is correct and for others the destination is 169.254.255.255.
December 1st, 2010 4:08pm

We have found the problem. SCCM generates the subnet address from the HW inventory of the client. The clients that experienced the issue had bad Network adapter configuration data info in the HW inventory (DHCP server = 255.255.255.255 , IP address 169.254.xxx.xxx, etc...). This is what kept generating the subnet address of 169.254.255.255. Forcing a Full HW inventory of the client resolved the issue on the server, correcting the HW inventory data and the stations are now responding to the WOL packets. SCCM only does delta HW inventory after the initial Full HW inventory scan so this info never changes on the server until a full hw inventory is done. Only a forced Full HD inventory or uninstall/reinstall of the client resolves the issue.
Free Windows Admin Tool Kit Click here and download it now
December 2nd, 2010 4:40pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics