-
Notifications
You must be signed in to change notification settings - Fork 8
Frequently Asked Questions (FAQ)
YES! As of January 2018, PowerShell Core 6.0 is now GA. Minor code changes were required mostly to deal with the parameter differences in Invoke-WebRequest between Desktop and Core editions and the way TLS settings are handled. All OS platforms supported by PowerShell Core are supported by the module.
The underlying connection was closed: Cloud not establish trust relationship for the SSL/TLS secure channel.
Your Infoblox is either still using a self-signed SSL certificate or the custom certificate it's using is no longer valid. You can ignore certificate validation using the -SkipCertificateCheck parameter on most functions or set it in your connection profile using Set-IBConfig.
Your Infoblox is either still using a self-signed SSL certificate or the custom certificate it's using is no longer valid. You can ignore certificate validation using the -SkipCertificateCheck parameter on most functions or set it in your connection profile using Set-IBConfig.
There's a -Depth parameter that "specifies how many levels of contained objects are included in the JSON representation". The default is 2 which is insufficient for some Infoblox objects. I usually set it to 5 just to be safe.
There is unfortunately no native support in Invoke-RestMethod (or any related cmdlet) for per-call disabling of certificate validation. Validation logic is controlled globally at the .NET level on a per-session basis in System.Net.ServicePointManager. In order to mimic a per-call disable flag, we're essentially disabling cert validation globally just long enough to make our call to Invoke-RestMethod and then setting it back to the default functionality. But our ServicePointManager tweaks seem to sometimes conflict with whatever VMware is doing with PowerCLI to disable certificate validation.
The current recommendation is to just let PowerCLI take care of disabling validation and skip using the option in Posh-IBWAPI.
UPDATE: The version of Invoke-RestMethod included in Powershell Core 6.0 includes a -SkipCertificateCheck parameter which should resolve this issue at least for Core edition users. Hopefully Microsoft will back port those changes into Desktop edition eventually.
As of PowerShell Core 6.0, some security related native still cmdlets such as ConvertTo-SecureString still depend on Windows Data Protection API (DPAPI) which has no equivalent on non-Windows OSes. But instead of throwing a nice'ish error about not being supported, it currently throws this error about not being able to load a Windows-specific DLL. See also PowerShell issue #1654.
This module tries to work around those limitations on non-Windows platforms. But doing so makes the posh-ibwapi.json incompatible between systems. So if you have copied the config from Windows to non-Windows, you'll get this error.
The error should no longer occur in PowerShell Core 6.2+. But the configs are still not portable between OSes.
This happens when you try to copy a posh-ibwapi.json config file to a different Windows computer or a different user's profile on the same computer. The underlying APIs used to encrypt the password in the file are tied to both the current computer and user and are not portable. The rest of the config values should still be valid. You will just need to set new -Credential value with Set-IBConfig.