Dealing with Laptop Standby Power Mode – Part 2
This is a continuation of Part 1 where i discussed a script to configure the network adapters to allow for WOL while in stand-by mode or hibernation mode.
Is this post we’ll address Issue #2
Once you have resolved the issue of being able to bring the devices out of stand-by mode, then you ideally want to keep those machines up indefinitely or at least until the application installs complete. So then you need to either have a group policy or “something” that configures the laptop to stay on after being imaged. I’ll cover this issue in Part 2.
Well here we are in Part 2, so lets address keeping the machines on. It’s great that we have a way to at least wake up the machines from stand-by mode, but it would be even better if we could keep them from going into stand-by to begin with.
I was able to address this issue in our environment by creating a SMS package that configured the laptop power scheme to be “Always On”. Now once a user logs in and changes the power scheme, they could override my setting, but that is fine, my primary concern is dealing with the laptops after they are deployed or refreshed. So once i’m done with what i need to do, the users can adjust the power settings as needed.
I simply created a new package called “Power Config” that has a program called “Always On” that is configured to run unattended. My command line for my program is:
C:\WINDOWS\system32\powercfg.exe /SETACTIVE "Always On"
So, by running it this way, i don’t need to have files on the distribution point for the package to work, right? Well yes and no :) If you are simply deploying this program through the normal software distribution process, then yes, correct you do not need to have files on the distribution point since it’s simply calling a command line that calls a local file.
However, there seems to be a small bug if you are deploying this package through MDT/SMS and are calling the package as part of the OSD process, in my case through customsettings.ini again. So i now have a Packages002=ABC0001:Always On.
However, without any package files actually on the DP, the customsettings.ini process gets a little cranky and you will see the following result in osdswdprogramexec.log
Basically stating that it can’t find the distribution point for the package. Now i’ve seen this before if you don’t have your OSDMP and OSDSiteCode properties configured in customsettings.ini however, i know that i do and that they are correct.
So i simply added a small batch file so the DP has something, and then set the source directory for the package to a folder with that batch file and then updated the DP’s. Once that had been completed, i ran the process again and my install went through just fine. So installing as a package through SMS, worked great without any source files. However, when i tried to call the package through customsettings.ini then i needed to have some files in the DP in order for the package to complete successfully. For whatever reason.
Now that i’ve got this package working through customsettings.ini, it’s again part of the tail end of my imaging process and now not only can i power on my machines if they do go into stand-by mode, but i have been able to configure them to not go into stand-by mode by default after being imaged so hopefully i won’t have to wake them up to begin with.
And that’s it! Hope this helps.