This is because the setting "Idle timeout before the system returns to a low power sleep state after waking unattended." value is set to 120 (Seconds) by default. You need to change it to '0'.
Run the following command to list the power schemes (* will show the active scheme). POWERCFG.EXE /LIST [cid:[email protected]] Then run following command to set the "Idle timeout before the system returns to a low power sleep state after waking unattended." Value to 0. POWERCFG.EXE /SETACVALUEINDEX <POWER SCHEME GUID> 238C9FA8-0AAD-41ED-83F4-97BE242C8F20 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 0 POWERCFG.EXE /SETDCVALUEINDEX <POWER SCHEME GUID> 238C9FA8-0AAD-41ED-83F4-97BE242C8F20 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 0 Thanks, Abhi From: [email protected] [mailto:[email protected]] On Behalf Of Miller, Todd Sent: Friday, September 27, 2013 10:18 PM To: [email protected] Subject: [mssms] Machine returns to sleep too fast for WOL advertisements I am waking up machines to run an advertisement at 3:00AM. On a sample machine, it wakes up at 2:57:06AM and goes back to sleep at 2:59:51AM - and so does not run the 3:00AM advertisement. I can see the proof of the WOL working in the client's system event logs. It feels like 2 minutes is just not enough time for my clients to wake from sleep, reestablish a network connection send events to the MP and then get the tasks executing. It exits the "recently resumed state" process at 2:59:12 which doesn't leave time to kick off an advertisement. In the morning when I go to check on the success/fail, I waggle the mouse and when I look in the logs, I see the missed advertisement runs when the machine is woken up by the waggle (but not at the WOL time). This is a recurring advertisement and it has happened 2 nights in a row now. I mention this because I am certain that the machine "knows" it is supposed to run an advertisement at 3:00AM. It seems like SCCM agent for some reason is failing to let the OS know it is not supposed to go to sleep because there is a pending advert - or at least it is not getting that message to the OS in time to prevent a return to sleep. I have a similar problem that could be related. I have seen clients go to sleep right in the middle of a software inventory. This happens a lot on laptops where the sleep timeout is set to 15 minutes. A user wakes up a laptop after not using it for several days, SCCM starts a software inventory because it is past due, and then the computer goes to sleep in the middle of the inventory process. I would think if SCCM is doing anything or is scheduled to do something in the next 5-10 minutes, it would prevent the OS from sleeping. Has anyone else had this problem? I am thinking of modifying the "go back to sleep from WOL" setting to be > 2 minutes, but there is no GPO or GUI for setting it so that could be messy. ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE PRIVILEGED. If this message was misdirected, BlackRock, Inc. and its subsidiaries, ("BlackRock") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of BlackRock, unless the author is authorized by BlackRock to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by BlackRock. Although BlackRock operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
<<inline: image001.png>>
