Jump to content


  • 0
Gorilla

WOL Woes - Unicast on Strike

Question

Throwing one out there for those either successfully using Unicast Wake-Up Packets from SCCM or whom have an idea for what I'm going through.

 

SCCM 2007 R2 on Server 2008 SP2 (One MP/DP w/ Remote SQL2005 DB) is NOT sending out Unicast Wake-Up packets any longer. Subnet-Directed works. I *had* Unicast working and tested, but then there was a WSUS version upgrade snafu that wiped all the WSUS bits. Indeed it wiped them better than the MS MSI Uninstaller. Not a trace. I was forced to reinstall the WSUS SP3 bits again as stand alone and reinstall my SUP. Okie doke we're up and running again except for two bones.

 

1) The DST bug is back. My WOLMGR.DLL is the old version and that's after several successful re-installations of the Hot Fix that previously fixed it. Not a big deal since I can pad deployment times by an hour and it works until I get the new DLL to stick. But anyone whose seen this or has an idea, I'm chomping the bit here.

 

2) Unicast WOL packets haven't worked since the Great WSUS Crash of 2010. I mean they don't get sent out. No Router between. One Subnet. Sniffer shows UDP WOL packet going out from the server when I manually send a WOL packet to the client MAC. So I know it's not a switch or ARP table issue. I know the client wakes up and is compatible. I know a packet can be sent from the server. When configuring SCCM to send a wake-up packet via Unicast, the log files (WOLMGR and WOLCMGR) all fire and show the packet being sent, but the sniffer just glares back at me balefully. I switch to Subnet-Directed, update the deployment schedule by a few minutes, watch the logs fire, wait the 57 seconds or so that the log says and then BAM! Sniffer shows the packet. Clients wake up. Checked DDR's and INV. Mac's are right. IP's are correct. DHCP shows proper lease. Name resolution from server works. No errors anywhere of any kind. No Maintenance Windows assigned.

 

I'm out of bullets. WOL reports show that they are scheduled and seemingly sent, and if not for the sniffer I wouldn't know they weren't being sent and just not firing up for some reason. Anyone with any insight as to how one can tickle Unicast for WOL (I did the IT Radio Button tickle already) so that the server starts using them again might prevent me from stabbing myself in the left eye with a ball point pen.

 

Since there are not separate Server requirements I am aware of for one type of WOL transmission over the other, Subnet-Directed wouldn't be working if I didn't have my Site, Collections, and Deployments properly configured. To be clear, all I change is the WOL Packet type at the Site Properties and it works. Unicast stopped working when I had to reinstall WSUS 3.0 SP2 bits and reinstall SUP. I'm not using Out of Band Management currently so Power On packets aren't an option.

 

Thanks for any and all assistance! I'll update with solutions as I find them.

Share this post


Link to post
Share on other sites

3 answers to this question

Recommended Posts

  • 0

Okay so oddly enough, in desperation, I changed SCCM WOL Unicast UDP packets from Port 9 to a dynamic port (45k+) and bam it fired! Go figure. I haven't the foggiest idea how just Port 9 could be on strike, but I have a workaround now that doesn't require Subnet broadcasts.

 

If I figure out the Port 9 thing, because I'm damn curious, I'll post the solution.

 

I still need to figure out why my DST patch isn't working. Currently padding deployments by adding an hour.

Share this post


Link to post
Share on other sites

  • 0

funny that, i was going to ask you to try another port but you beat me to it,

 

perhaps the port has been blocked/reconfigured/broken by a new firewall gpo, or on the switch side by a port change ?

Share this post


Link to post
Share on other sites

  • 0

funny that, i was going to ask you to try another port but you beat me to it,

 

perhaps the port has been blocked/reconfigured/broken by a new firewall gpo, or on the switch side by a port change ?

 

There is no switch between the test server and client. Same subnet. And yes the port change worked. So somehow, Port 9 is broken on the server side. Strange days indeed. My spidey senses told me to try a port change hours ago, but my common sense told me that didn't make any sense. But as any good troubleshooter must do, I went back to basics and walked the tree. Alas the senseless prevails! Mr. Spock would never have cut it in this industry.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.