This is just a theory, but it's possible that the management controller is powered off, if the machine is powered off. The default "power package" set by Configuration Manager SP1 is whatever index "5" refers to. Depending on the device model, and the corresponding AMT firmware version, it's possible that, in this power state, the ME is shutdown when the computer is turned off. I guess my first question would be: can you connect to the affected machine(s) using the OOB Console, while they are powered off?
The power package functionality has changed in service pack 2 for ConfigMgr, and it will allow you to force AMT to always be active.
Additionally, have you examined the wake-on-LAN log file(s) on the site server that holds the Out-of-Band Service Point role? I'm not sure if this is the correct log to examine or not, however from the Technet documentation, it would appear that these logs would be the most logical place to start looking.
Sounds like you have configured the site server appropriately. Can you try and create another package with the system shutoff (and ensure as Trevor stated your power policies are set to AMT always on - you can manually set this in the MEBx until SP2 comes out and natively supports this feature) and make an mandatory advertisement. Select "run as soon as possible" and see if AMT wakes the system. Let me know these results.
Sorry to take so long to respond, but I'm currently having some issues with one of my SCCM site servers.
I am able to contact the management engine when the system is powered off and I've checked the BIOS and as far as I can tell everything is set as it should be.
One thing I had not done was properly configure Wake On LAN to "Use power on commands if the computers support this technology; otherwise, use wake-up packets." I have since configured the site to do this and it still doesn't work. I tried re-creating the whole advertisement with a new mandatory assignment also.
I'm thinking about next installing a sniffer to ensure UDP packets are making it through our network (the SCCM server and the workstation are on different vlans/subnets). I've been told they're not being blocked but it looks like it's worth checking out.
Power-on commands using Intel vPro / ConfigMgr will not be sniffable, as they are not UDP packets. Intel vPro uses TCP-based, TLS-secured conversations to send commands, and retrieve information from remote devices.
Did you examine the log files I recommended in my previous post?
Yes, I did. Here's entries from the latest attempt:
STATMSG: ID=6510 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_WAKEONLAN_MANAGER" SYS=TSS-SCCMSQL01 SITE=OSL PID=15560 TID=15976 GMTDATE=Wed Jul 29 16:50:01.451 2009 ISTR0="OSL200BF" ISTR1="1" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=2 AID0=421 AVAL0="1" AID1=415 AVAL1="OSL200BF"
WOLCManager executing job id='179d207d' in state 'STATE_PROCESSDATA'.
WOLCManager processing data for job id='179d207d'.
Failed to create the IPV6 writer (8007273f), IPV6 may not be installed
WOLCManager waiting 5 seconds for work.
WOLCManager retry for job id='179d207d' has completed (3 retries).
STATMSG: ID=6505 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_WAKEONLAN_COMMUNICATION_MANAGER" SYS=<systemname> SITE=<sitecode> PID=15560 TID=15912 GMTDATE=Wed Jul 29 16:52:01.579 2009 ISTR0="<sitecode>200BF" ISTR1="1" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=3 AID0=422 AVAL0="179d207d" AID1=421 AVAL1="1" AID2=415 AVAL2="<sitecode>200BF"
I'm trying to wake up a Vista system (SP2, I believe) so IP v6 should be installed. I don't see anything else interesting but let me know it there's anything else to look for. I'm not ever sure what a successful attempt is supposed to look like.
Well, I'm not absolutely sure that the wake-up logs were the right place to look. I just thought it would be the most logical place to start looking. Since vPro doesn't support IPv6 yet, I'm guessing the IPv6 messages in the log are proabably referring to Wake-on-LAN over IPv6? Just a guess. I'm not an IPv6 guru either
Just so you know, the target operating system of the device that you're trying to wake up shouldn't matter either. Since vPro is an out-of-band technology (operates independently of the OS), there should be zero software requirements, on the client, once it has been provisioned.
Sorry I can't be more helpful ... I need to play around with this stuff a little more.
Hi, bgushue. There is two other areas to check,did you turned OFF WOL in the standard BIOS, the LAN PHY can only support one WOL feature. The other area to check is that the LAN driver does not have WOL feature enabled in the Advanced features section - this will also wreck havoc with WOL. Let us know if that helps.
Thank you Sean for replying, as I am still struggling with this.
To be clear: Is WOL supposed to be enabled on one, but not the other (ie., I'll enable it on the network adapter properties in the OS but disable it in the BIOS)? How about if it was enabled in the BIOS, but not on the network adapter properties?
If you really want to test Legacy WOL you enable WOL in the BIOS, you Set WOL to enable in the advanced features of the LAN driver and you pick what method to wake up the machine, either with a generic IP ping or with a Magic packet (magic packet is preferred method). You may need to get the latest LAN driver from Intel or your OEM to see the advanced features that have WOL available.
To use the secure environments of ME WOL, Turin OFF WOL in the BIOS. you don't have to do anything about the LAN driver - ME runs on its own and the LAN driver will not be involved. the Key is turn off WOL in the BIOS. Then enter MEBx and enter AMT -> power policy's and setup S1,S3,4-5 WOL. I am assuming you have installed the OOB console to SCCM, Provisioned the platforms for OOB management. If you have not done this, ME WOL will not be available. There are plenty of documents on setting up SCCM with OOB console here in Expert center, that is your first step, once you can remotely connect thru the OOB console then ME WOL is available and you can remotely push at any time securely