New-WebBinding: Cannot retrieve the dynamic parameters for the cmdlet New-WebBinding: Cannot retrieve the dynamic parameters for the cmdlet powershell powershell

New-WebBinding: Cannot retrieve the dynamic parameters for the cmdlet


That part of your question:

I've googled, some mentioning something about 32bit vs 64bit powershell

is already half of an answer. Some commands do not run properly if bitness of PowerShell process does not match bitness of operation system. So, you need to run powershell.exe, which located in this %windir%\System32\WindowsPowerShell\v1.0\ directory. But there is a little problem described in this documentation topic:

In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64.

Thus, if 32-bit program on 64-bit OS invoke %windir%\System32\WindowsPowerShell\v1.0\powershell.exe, it will actually invoke 32-bit version of PowerShell from here %windir%\SysWOW64\WindowsPowerShell\v1.0\ instead of 64-bit one. To actually invoke 64-bit PowerShell from 32-bit application you need to use this trick:

32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access.


I've got the same error when running the following cmdlet:

PS> Remove-WebAppPool -Name 'Test'Remove-WebAppPool : Cannot retrieve the dynamic parameters for the cmdlet. Retrieving the COM class factory forcomponent with CLSID {688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error: 80040154 Class notregistered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).At line:1 char:1+ Remove-WebAppPool -Name 'Test'+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    + CategoryInfo          : InvalidArgument: (:) [Remove-WebAppPool], ParameterBindingException    + FullyQualifiedErrorId : GetDynamicParametersException,Microsoft.IIs.PowerShell.Provider.RemoveAppPoolCommand

The reason was because I ran it using Windows PowerShell (x86) on my Windows 10 x64 machine.

When I tried the same but using Windows PowerShell, which is 64 bit version, it worked just fine.


I think your $guid is the issue. The GUID needs to be the GUID of the program to bind the cert to. For your example port 443 is only bound to a random GUID, and not your program's GUID. IIS and other apps have a static GUID that you will want to use. If the GUID for a powershell script then Get-host is the powershell host executing code so that's the GUID you need. It changes for every powershell session and the netsh binding needs to as well.

$appid = "appid={"+(get-host).InstanceId.guid+"}"

$certhash = ls Cert:\LocalMachine\my | where {$.EnhancedKeyUsageList -Match 'Server' -and $.subject -match (hostname)}|sort-object $_.NotAfter|select -expand Thumbprint -last 1

$cmdline='netsh http add sslcert ipport=0.0.0.0:443 certhash=' + $certhash + ' "' + $appid + '"'

netsh http delete sslcert ipport=0.0.0.0:443

Invoke-Expression $cmdline