Thanks again, Codeplug. I tried everything I could on my Windows 7 and here's the results:
(All concerning local service application)

1. One can get global power policy settings via a call to GetCurrentPowerPolicies().

2. To apply or change a policy setting (for either AC or DC) one needs to have a policy ID (which is an integer ID in an older version of API and a GUID since Vista.) To get that ID one needs to call an API such as GetActivePwrScheme() or PowerGetActiveScheme() for newer APIs, both of which return FALSE when called from a service. (Confirmed that.) My next idea was to enumerate all available power schemes by calling EnumPwrSchemes() or newer version PowerEnumerate() but both again failed without producing any results.

3. I can't try setting a power scheme because I can't get an ID of an existing scheme to do that.

4. The above might work from a local service running on Windows XP, since services used to run in a user session 0. But it obviously has to work under later OS as well, so I didn't try that approach ...


So we arrive at a classic catch-22: To get a power scheme ID someone's code has to run from a user-mode code (not even elevated), but to set it, one's code has to run elevated (and possibly OK from a local service.)

My next thought was go an extra mile and spawn a user-mode process from my local service, that will do all the power scheme changes (however complex and unnecessary this move can be) but then what would I do if there're no users logged on to the workstation at the time (when the service starts up)?

So obviously someone at Microsoft didn't think all this through. If you look at the documentation to the new (Vista) power schemes, it is very scarce and some parameters don't even have links or further explanation to how to get to them.

So my god-send solution was the CallNtPowerInformation API that seemed to solve the issue of reading/writing a power setting without affecting global power schemes (which is an added bonus -- or in other words -- it was not persistent), but evidently not every computer supports it. Again, the error code I quoted above came from a client's computer that I don't have access to. I ran several tests on that machine (through his help) and all confirmed that error code that is not even documented...

So I'm leaving it at that. There's nothing else I can do. (Which is OK for Windows.)