I am using dgreadiness_v3.6.zip (from https://www.microsoft.com/en-us/download/confirmation.aspx?id=53337)
PS C:\Users> powershell.exe E:\Desktop\dgreadiness_v3.6\DG_Readiness_Tool_v3.6.ps1 -ready
###########################################################################
Readiness Tool Version 3.4 Release.
Tool to check if your device is capable to run Device Guard and Credential Guard.
###########################################################################
###########################################################################
OS and Hardware requirements for enabling Device Guard and Credential Guard
1. OS SKUs: Available only on these OS Skus - Enterprise, Server, Education, Enterprise IoT, Pro, and Home
2. Hardware: Recent hardware that supports virtualization extension with SLAT
To learn more please visit: https://aka.ms/dgwhcr
###########################################################################
Credential-Guard is not running.
HVCI is not running.
Config-CI is not running. (Not Enabled)
Not all services are running.
I assume that PSCompatibleVersions {1.0, 2.0, 3.0, 4.0鈥 also includes v5.
PS C:\Users> pwsh E:\Desktop\dgreadiness_v3.6\DG_Readiness_Tool_v3.6.ps1 -ready
###########################################################################
Readiness Tool Version 3.4 Release.
Tool to check if your device is capable to run Device Guard and Credential Guard.
###########################################################################
Note that this script is compatible with v5 PowerShell. YMMV.
get-wmiobject: E:\Desktop\dgreadiness_v3.6\DG_Readiness_Tool_v3.6.ps1:1013
Line |
1013 | $isRunningOnVM = (get-wmiobject win32_computersystem).model
| ~~~~~~~~~~~~~
| The term 'get-wmiobject' is not recognized as the name of a cmdlet, function, script file, or operable
| program. Check the spelling of the name, or if a path was included, verify that the path is correct
| and try again.
InvalidOperation: E:\Desktop\dgreadiness_v3.6\DG_Readiness_Tool_v3.6.ps1:1014
Line |
1014 | if($isRunningOnVM.Contains("Virtual"))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| You cannot call a method on a null-valued expression.
###########################################################################
OS and Hardware requirements for enabling Device Guard and Credential Guard
1. OS SKUs: Available only on these OS Skus - Enterprise, Server, Education, Enterprise IoT, Pro, and Home
2. Hardware: Recent hardware that supports virtualization extension with SLAT
To learn more please visit: https://aka.ms/dgwhcr
###########################################################################
Credential-Guard is not running.
HVCI is not running.
Config-CI is not running. (Not Enabled)
Not all services are running.
PS C:\Users> pwsh -version 5 E:\Desktop\dgreadiness_v3.6\DG_Readiness_Tool_v3.6.ps1 -ready
PowerShell 7.0.2
Script works out of luck
https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/starting-the-windows-powershell-2.0-engine?view=powershell-7 does not seem to trigger "v5 compatibility mode" as extrapolated.
> $PSVersionTable
Name Value
---- -----
PSVersion 7.0.2
PSEdition Core
GitCommitId 7.0.2
OS Microsoft Windows 10.0.18363
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0鈥
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Get-WmiObject was considered _deprecated_ in PowerShell version 3.
Since then, Get-CimInstance has been the replacement command. Get-WmiObject was officially dropped in v6.0. If this script hasn't been updated since v2, I wouldn't expect it to work.
I'm not sure in what capacity, if any, -Version 2 is expected to work, but I wouldn't expect it to function in pwsh myself.
What does, then, PSCompatibleVersions mean, if not _backwards compatibility with previous PS versions_?
PSCompatibleVersions is, as far as I'm aware, only referenced for the purposes of #Requires -PSVersion statements. In other words, if the stated version is not in the PSCompatibleVersions list, PowerShell won't even _try_ to run the script. Many scripts are compatible, which is why later versions will still try to run scripts written for older versions. But not all, as you've seen here. Typically adjustments needed are minor, though; for instance, there's a good chance if you simply replace the Get-WmiObject calls with Get-CimInstance instead, it will probably work.
It's more about preventing earlier versions of PS from trying to run scripts which may contain language features that were introduced later on, to the best of my knowledge. 馃檪
In any case, "in such a volatile environment", I would expect that #Requires -Version (_and not #Requires -PSVersion_), would guard both ways: against old _and_ against new features.
Or, would provide backwards-compatible interfaces.
In any case, I got what I expected by this thread. Thank you for the prompt responses.
This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.