Been there on this one!! What we have done it take the NIC out of the boot order. By excluding this, it resolved it for us. For some reason it tries to network boot first when woke up over the network. That obviously cause headaches. So give that a shot.
From: [email protected] [mailto:[email protected]] On Behalf Of Murray, Mike Sent: Friday, March 11, 2016 10:27 AM To: [email protected] Subject: RE: [mssms] RE: ConfigMgr wake-up proxy and port-security Ouch! From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Krueger, Jeff Sent: Friday, March 11, 2016 6:47 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: ConfigMgr wake-up proxy and port-security Does anyone have experience implementing this in an environment which is BitLocker encrypted? Doing some initial testing and it looks like on our HP machines when it gets turned on by the wake up process it causes the machine to go into recovery mode because it sees it as a change in boot order. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Phil Wilcock Sent: Friday, March 11, 2016 3:09 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: ConfigMgr wake-up proxy and port-security Yeah works fine, We did a session on this very subject at the last MS – MMS in 2013 so researched it quite a bit, including the original MS Research project. Neat way of implementing WoL Phil From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: 11 March 2016 01:35 To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] RE: ConfigMgr wake-up proxy and port-security Not useless at all. It works quite well. The MAC spoofing is well documented and the TechNet documentation explicitly calls out that you need to discuss enabling this feature with your network team before enabling it. Don’t blame the product or design for a click-happy; fire, aim, ready; shoot from the hip admin. J From: <[email protected]<mailto:[email protected]>> on behalf of "Marcum, John" <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Thursday, March 10, 2016 at 2:51 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [mssms] RE: ConfigMgr wake-up proxy and port-security I seem to recall a lot of conversations about this when that feature was introduced. Another Useless Feature. ________________________________ John Marcum MCITP, MCTS, MCSA Desktop Architect Bradley Arant Boult Cummings LLP ________________________________ [MVP] <https://mvp.microsoft.com/en-us/overview> [MMS] <https://urldefense.proofpoint.com/v2/url?u=http-3A__mmsmoa.com_&d=CwMGaQ&c=aLnS6P8Ng0zSNhCF04OWImQ_He2L69sNWG3PbxeyieE&r=pQGVi_ygWZb0EWR_EeMFzgKJCQ8AFTQI7Ck6iiIPItI&m=abIGPtgono7VQhRyjW2nRi1eIzVgN5bTiSGXjmUVXRE&s=f80lByUmVwMzTB9MIV9Jh8CvNKx8PDo85lYO3xp2C9I&e=> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Murray, Mike Sent: Thursday, March 10, 2016 11:14 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] ConfigMgr wake-up proxy and port-security FYI, got this message from one of our network guys. This involved another campus. ~~~~~~~~~~~~~~~~~ We ran into a really “interesting” issue this week. The SCCM guys decided to implement the SCCM “wake-proxy” feature on the SCCM. Not quite the normal magic packet WOL procedure. This has the SCCM server hit specific machines, which then go and hit the machines in their vlan. However, these “manager machines” also spoof the mac addresses of the machines that go to sleep in their vlan in order to keep the MAC alive in the switch tables. This is quite fun when you have port-security turned on that limits the number of mac addresses on the ports! We had random machines dropping off the network, DHCP issues, etc. It was quite fun to chase down what exactly was going on. The only indication that we saw was that ports were showing multiple MAC addresses when we knew that there was only one device connected to it and it was not running a VM. Wasn’t even logged into. Fortunately, something ticked the back of my mind about a feature they were thinking about implementing on the SCCM and we were able to put the pieces together. Otherwise, we would still be scratching our heads over this. Bottom line? DO NOT implement SCCM wake-proxy with any sort of port-security enabled. Better yet, just don’t implement wake-proxy at all. Here is a discussion we found afterwards, once we knew what to look for. https://supportforums.cisco.com/discussion/11835361/mac-address-flapping-and-sccm-wake-proxy<https://urldefense.proofpoint.com/v2/url?u=https-3A__supportforums.cisco.com_discussion_11835361_mac-2Daddress-2Dflapping-2Dand-2Dsccm-2Dwake-2Dproxy&d=CwMGaQ&c=aLnS6P8Ng0zSNhCF04OWImQ_He2L69sNWG3PbxeyieE&r=pQGVi_ygWZb0EWR_EeMFzgKJCQ8AFTQI7Ck6iiIPItI&m=abIGPtgono7VQhRyjW2nRi1eIzVgN5bTiSGXjmUVXRE&s=ae1Bq02jMxkiGTWcc5uIczDbSpTQXt9XS0KumXpxuiU&e=> I worked with ALU TAC all afternoon on this. The only weirdness that we could see was that the packet capture showed that the computer was sending out replies to ARP packets that were not for his MAC address. I sent them the above link, so hopefully, they can add it to their internal database and be prepared if they see it again. Just letting you all know! ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. ________________________________ CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy & Security page on www.henryford.com<http://www.henryford.com> for more detailed information as well as information concerning MyChart, our new patient portal. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us.
