Get-ComputerInfo throws an error on 2008R2

[mgreenegit]

Importing module MSFT_xGroupResource failed with error - Unable to find an entry point named 'GetFirmwareType' in DLL 'kernel32.dll'.

I validated that the same error is thrown any time the Get-ComputerInfo command is invoked on 2008R2.

[RobCannon]

Any update on this? We have been using this resource on our 2008R2 computers for some time and I went to rebuild them and this bug cropped up. I think perhaps it doesn't exist in an older version.

The bug is in this file: https://github.com/PowerShell/xPSDesiredStateConfiguration/blob/master/DSCResources/CommonResourceHelper.psm1

That is where the Get-ComputerInfo call is. BTW, that is a really bad command to call as it gets a bunch of information (like Hotfixes installed). A call to a CMI namespace like Win32_OperationSystem is a much better way to get this info. I will try that out on a nanoserver container to see what it returns.

[RobCannon]

BTW, this bug would be better named 'xGroup resource broken on Windows 2008 R2'

[RobCannon]

OK, here is the fix. The Test-IsNanoServer function should be:

function Test-IsNanoServer
{
    [OutputType([Boolean])]
    [CmdletBinding()]
    param ()

    return (Get-CimInstance -ClassName 'Win32_OperatingSystem' -Property 'OperatingSystemSKU' | %{ $_.OperatingSystemSKU }) -in @(143,144,149)
}

The list of skus comes from this documentation: https://docs.microsoft.com/en-us/windows/desktop/CIMWin32Prov/win32-operatingsystem

149 is not in that list, but that is the SKU for a nano server container. The OperatingSystemSKU value also probably works correctly when the server is using a different language while looking at strings probably does not.

I'll look at what it take to do a PR for this project. I suppose it won't be available until the next release, though, which doesn't help me with my immediate problem.

[RobCannon]

The new code runs in 170ms vs 4700ms for the first run. Subsequent calls are much faster for both versions at 15ms-30ms.

[RobCannon]

This was broken with the 6.1.0.0 release with this commit: https://github.com/PowerShell/xPSDesiredStateConfiguration/commit/c17339aa17d4a3b69904886e950e67022fb5032a

The 6.0.0.0 release resolved my issue.

I will try to do a PR with my new function, but it will be a couple of days.

[johlju]

@RobCannon Would love a PR for this, thanks!

Although the evaluation in the suggested fix seems wrong 🤔 This returns $true

(@('143') | % { $_ }) -in (143,144,149)

But this does not return $true

(@('143','999') | % { $_ }) -in (143,144,149)

So if we are expecting several values in the result of property OperatingSystemSKU we should look over the evaluation? 🤔

[RobCannon]

The type of OperatingSystemSKU is an uint32, so there would never be more than one value:

uint32   NumberOfUsers;
uint32   OperatingSystemSKU;
string   Organization;
string   OSArchitecture;

[johlju]

Ah good, I was thrown by the snipped that was doing ForEach-Object (%).