MSFT_xPowerPlan should use power plan guid

[SGobeil]

On non-english Windows, power plans names are localized. Using power plan's GUID instead would make it work as they all seem to be the same across all Windows platforms for standard plans.

[johlju]

I can see that this becomes a problem if the same configuration file is used for different OS languages.
It is easy to list the GUIDs by running

powercfg /list

Option 1

We could enhance the schema with a Guid parameter that will override the Name parameter. If Guid is set, the power plan will be set using the Guid, and ignore the Name. The name will still need to be set since it is required, but could be set to anything meaningful for the user managing the configuration.
If we would set Name to Write as well, then configuration would allow using neither Name or Guid, which would not be good.

[ClassVersion("1.0.0.0"), FriendlyName("xPowerPlan")]
class MSFT_xPowerPlan : OMI_BaseResource
{
    [Key, Description("Specifies the resource is a single instance, the value must be 'Yes'"), ValueMap{"Yes"}, Values{"Yes"}] String IsSingleInstance;
    [Required, Description("The name of the power plan to activate.")] String Name;
    [Write, Description("The GUID of the power plan to activate. When this parameter is set, then Name parameter is ignored")] String Guid;
};

Option 2

We could replace the Name parameter with the Guid parameter. We can provide information in the documentation (README.md) how the user finds the GUID. Although, for the user managing the configuration file it will not be obvious what power plan it is configured to use (unless adding a comment). Neither will it be obvious when running Get-DscConfiguration. So in that sense option 1 would be more preferred.

[ClassVersion("1.0.0.0"), FriendlyName("xPowerPlan")]
class MSFT_xPowerPlan : OMI_BaseResource
{
    [Key, Description("Specifies the resource is a single instance, the value must be 'Yes'"), ValueMap{"Yes"}, Values{"Yes"}] String IsSingleInstance;
    [Required, Description("The GUID of the power plan to activate.")] String Guid;
};

@TravisEz13 Do you have a moment to weigh in on this?

[J0F3]

You may have a look at my resouce, which is doing basically the same thing:
https://github.com/J0F3/cPowerPlan

I have just resolved the issue with the GUID and also an other issue where the resouce did not work on core and nano server because of the missing "Win32_PowerPlan" WMI class.

Maybe we can merge my changes also to the MSFT_xPowerPlan resouce. What do you think?

[TravisEz13]

If it is to set the active power plan, @J0F3's schema looks good.

[J0F3]

I just want you know that I updated my module again so also the get and test mechanism does use the GUIDs instead of the names.

[marcinbojko]

@J0F3 Great work! Just found that issue trying some Polish/Danish language machines.
Using GUID (or NAME) should be the best option

[PlagueHO]

Hi @J0F3 , @marcinbojko - are either of you working on a fix for this one or is it still outstanding?

[johlju]

I just hit this error on a Swedish server. So I could give this a shoot to fix this if nobody else is working on it. But I do need help getting the solution we want.

I don't think @J0F3's resource is entirely optimal because it does not allow the user to set the power plan to the power plan the user created them self, at least it doesn't look so from the code. Let me know if I'm mistaken.
The user must be able to specify the guid they want to to use. And for this to not be a breaking change I would suggest option 1 that I mention above. That will allow the user to specify either.

But there is also an option 3. But this would be a breaking change.

[ClassVersion("1.0.0.0"), FriendlyName("xPowerPlan")]
class MSFT_xPowerPlan : OMI_BaseResource
{
    [Key, Description("Specifies the resource is a single instance, the value must be 'Yes'"), ValueMap{"Yes"}, Values{"Yes"}] String IsSingleInstance;
    [Required, Description("The identifier to use to evaluate the power plan. This can be set to either 'Name' or 'Guid'."),ValueMap{"Name","Guid"}, Values{"Name","Guid"}] String Identifier;
    [Required, Description("The GUID or the name, depending on the value of Identifier, of the power plan to activate.")] String PowerPlan;
};

[iainbrighton]

Can we not just just try and parse the Name parameter as a System.Guid? If it parses correctly, use the Guid and if not, use it as-is? For example:

[ClassVersion("1.0.0.0"), FriendlyName("xPowerPlan")]
class MSFT_xPowerPlan : OMI_BaseResource
{
    [Key, Description("Specifies the resource is a single instance, the value must be 'Yes'"), ValueMap{"Yes"}, Values{"Yes"}] String IsSingleInstance;
    [Required, Description("The name or GUID of the power plan to activate.")] String Name;
};

If that's not seen as "clean", we can add a boolean IsGuid parameter to indicate that the provided name is a Guid, like so:

[ClassVersion("1.0.0.0"), FriendlyName("xPowerPlan")]
class MSFT_xPowerPlan : OMI_BaseResource
{
    [Key, Description("Specifies the resource is a single instance, the value must be 'Yes'"), ValueMap{"Yes"}, Values{"Yes"}] String IsSingleInstance;
    [Required, Description("The name or GUID of the power plan to activate.")] String Name;
    [Write, Description("Specifies the name provided is the GUID of the power plan to activate.")] Boolean IsGuid;
};

Thoughts?

[PlagueHO]

@iainbrighton - I do like your first pattern there. I even have a function and unit tests for testing if a string is a GUID (from another project I work on):

<#
    .SYNOPSIS
    Checks that a Guid is valid.

    .PARAMETER Guid
    The Guid to validate.

    .OUTPUTS
    Returns true if the Guid is valid.
#>
function Test-Guid
{
    [CmdletBinding()]
    [OutputType([Boolean])]
    param
    (
        [Parameter(Mandatory = $True)]
        [String] $Guid
    )

    $newGuid = [Guid]::Empty
    [Guid]::TryParse($Guid, [ref]$newGuid)
}

I can try and get to this one at some point as I'm doing lots of work trying to get this repo up to HQRM. But no idea when.

[J0F3]

@johlju is right. My resource does not allow to set a custom power plan. This is mainly because I hade never a need for that. ;-) But it makes absolutely sense that it is possible to set a custom power plan.

I also like the first option from the idea of @iainbrighton

[johlju]

This is the error message for this issue. Caught it on a Spanish Windows Server 2012 R2 server while doing some other work.

VERBOSE: [SQLTEST21]: LCM:  [ FinalizarProbar   ]  [[xPowerPlan]SetPlanHighPerformance]  en 1.1570 segundos.
El recurso de DSC de PowerShell MSFT_xPowerPlan no pudo ejecutar la funcionalidad de Test-TargetResource con el mensaje de error: Unable to find the power plan 'Balanced'.
    + CategoryInfo          : InvalidOperation: (:) [], CimException
    + FullyQualifiedErrorId : ProviderOperationExecutionFailure
    + PSComputerName        : sqltest21.shamn.se

Default power plans on the server for reference.

PS >     $arguments = @{
>>         Name = 'root\cimv2\power'
>>         Class = 'Win32_PowerPlan'
>>         #Filter = "ElementName = '$Name'"
>>     }
>>
PS > $plan = Get-CimInstance @arguments
PS > $plan

Caption        :
Description    : Equilibra automáticamente el rendimiento con el consumo de energía en el hardware que lo permita.
ElementName    : Equilibrado
InstanceID     : Microsoft:PowerPlan\{381b4222-f694-41f0-9685-ff5bb260df2e}
IsActive       : True
PSComputerName :

Caption        :
Description    : Mejora el rendimiento, pero puede utilizar más energía.
ElementName    : Alto rendimiento
InstanceID     : Microsoft:PowerPlan\{8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c}
IsActive       : False
PSComputerName :

Caption        :
Description    : Reduce el rendimiento del equipo cuando sea posible para ahorrar energía.
ElementName    : Economizador
InstanceID     : Microsoft:PowerPlan\{a1841308-3541-4fab-bc81-f71556f20b4a}
IsActive       : False
PSComputerName :

[PlagueHO]

Awesome info thanks @johlju - I better get to looking at this one next. It does seem like these GUIDs do align:

! Dan@PLAGUE02 : ~\Source\GitHub :> $arguments = @{
>>          Name = 'root\cimv2\power'
>>          Class = 'Win32_PowerPlan'
>>      }

! Dan@PLAGUE02 : ~\Source\GitHub :> $plan = Get-CimInstance @arguments

! Dan@PLAGUE02 : ~\Source\GitHub :> $plan


Caption        :
Description    : Automatically balances performance with energy consumption on capable hardware.
ElementName    : Balanced
InstanceID     : Microsoft:PowerPlan\{381b4222-f694-41f0-9685-ff5bb260df2e}
IsActive       : False
PSComputerName :

Caption        :
Description    : Power4Gear High Performance
ElementName    : Power4Gear High Performance
InstanceID     : Microsoft:PowerPlan\{512a6ac6-efc1-4441-85c9-cccf29b69cd2}
IsActive       : True
PSComputerName :

Caption        :
Description    : Favors performance, but may use more energy.
ElementName    : High performance
InstanceID     : Microsoft:PowerPlan\{8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c}
IsActive       : False
PSComputerName :

Caption        :
Description    : Saves energy by reducing your computer’s performance where possible.
ElementName    : Power saver
InstanceID     : Microsoft:PowerPlan\{a1841308-3541-4fab-bc81-f71556f20b4a}
IsActive       : False
PSComputerName :

Caption        :
Description    : Power4Gear Power Saving
ElementName    : Power4Gear Power Saving
InstanceID     : Microsoft:PowerPlan\{df011ed9-9131-49b9-8090-46963cfb65ce}
IsActive       : False
PSComputerName :

[J0F3]

I finally got some time to look into that again. Just made a PR with changes to accept a name or a Guid as value for the Name parameter.
Furthermore as I noticed that the resource works on Windows Server 2019 not correctly besause of the absent "Activate" method on the WMI class I changes it to use powercfg.exe instead the WMI methods. This would then also fix Issue #155 and #65 (even though the later is probably not that important anymore)

Let me know what you think. 😊

[marcinbojko]

That would be great, as I've noticed that's one of not many resources not working properly on 2019.

[PlagueHO]

Hi @marcinbojko - can you put any info in here about what you're seeing on 2019 so that we can make sure there are some integration tests that will cover/validate the new version that @J0F3 is working on resolves it?

I've only just moved my lab over to WS2019 so haven't had a chance to start validating on it (and AppVeyor doesn't provide it).

[marcinbojko]

Hi @marcinbojko - can you put any info in here about what you're seeing on 2019 so that we can make sure there are some integration tests that will cover/validate the new version that @J0F3 is working on resolves it?

Of course. My resource for setting 'high power' is here: https://gist.github.com/marcinbojko/4de797ff36d66e4b7b6c6a6ddef77284
as I am using puppetlabs-dsc for everything.

The reponse is:

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = Resourceset,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = roo
t/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer HV-PUPPET-EV19 with user sid S-1-5-21-2614790921-100213042-3806504391-1103.
VERBOSE: [HV-PUPPET-EV19]: LCM:  [ Start  Set      ]  [[xPowerPlan]DirectResourceAccess]
VERBOSE: [HV-PUPPET-EV19]:                            [[xPowerPlan]DirectResourceAccess] Activating power plan 'High performance'.
VERBOSE: [HV-PUPPET-EV19]:                            [[xPowerPlan]DirectResourceAccess] Perform operation 'Query CimInstances' with following parameters, ''queryExpressi
on' = SELECT * FROM Win32_PowerPlan WHERE ElementName = 'High performance','queryDialect' = WQL,'namespaceName' = root\cimv2\power'.
VERBOSE: [HV-PUPPET-EV19]:                            [[xPowerPlan]DirectResourceAccess] Operation 'Query CimInstances' complete.
VERBOSE: [HV-PUPPET-EV19]:                            [[xPowerPlan]DirectResourceAccess] Perform operation 'Invoke CimMethod' with following parameters, ''instance' = Win
32_PowerPlan (InstanceID = "Microsoft:PowerPlan\{8c5e7fda-e8bf-4a96...),'methodName' = Activate,'namespaceName' = root/cimv2/power'.
This method is not implemented in any class 
    + CategoryInfo          : MetadataError: (Win32_PowerPlan...a-e8bf-4a96...):) [], CimException
    + FullyQualifiedErrorId : HRESULT 0x80041055,Microsoft.Management.Infrastructure.CimCmdlets.InvokeCimMethodCommand
    + PSComputerName        : localhost
 
VERBOSE: [HV-PUPPET-EV19]:                            [[xPowerPlan]DirectResourceAccess] Operation 'Invoke CimMethod' complete.
VERBOSE: [HV-PUPPET-EV19]: LCM:  [ End    Set      ]  [[xPowerPlan]DirectResourceAccess]  in 0.2180 seconds.
The PowerShell DSC resource '[xPowerPlan]DirectResourceAccess' with SourceInfo '' threw one or more non-terminating errors while running the Set-TargetResource 
functionality. These errors are logged to the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
    + CategoryInfo          : InvalidOperation: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : NonTerminatingErrorFromProvider
    + PSComputerName        : localhost

[J0F3]

Yea, it is exactly what I also notices on Windows Server 2019 with the PowerPlan resource. Actually it is the same as issue #155. Meaning the 'Activate' method is somehow not there anymore...

[PlagueHO]

I actually wonder if this is a bug. Might raise it with the Windows Server team to see if it was intentional and what the new method should be for setting this stuff.