Release v1.0.26

🎯 What's New in v1.0.26

🚨 Critical Fix — Sign-in restored after HPE's auth-flow change

Upgrading to v1.0.26 is required to keep connecting to HPE GreenLake.

HPE switched their GreenLake sign-in to a new authentication workflow (v1alpha1 → v1alpha2), which broke Connect-HPEGL for everyone — both federated (SSO) and standard accounts. This release reworks the login flow to detect and follow the new HPE broker, so authentication works again with no script changes. If you stay on an older version, Connect-HPEGL will continue to fail. Full details in the Bug Fixes section below.

⭐ Headline Feature — Password-Based SSO Authentication

The biggest change in this release — and by far the largest single engineering effort the library has taken on — is that Connect-HPEGL now supports password-based SSO authentication for federated identity providers, alongside the existing passwordless flow.

This was a significant engineering effort. Each identity provider (Okta, Microsoft Entra ID, PingIdentity) drives its own multi-step, browser-based sign-in sequence, and there is no public API to perform these logins headlessly. Delivering this feature meant reproducing each provider's full authentication and MFA step-up flow — entirely without an interactive browser — so that a single Connect-HPEGL -Credential call "just works" no matter which IdP a workspace is federated with.

Connect-HPEGL -Credential — Password-based SSO for Okta, Microsoft Entra ID, and PingIdentity

You can now sign in to an SSO-federated workspace using -Credential with your federated email address. When the email domain is configured for SAML SSO in HPE GreenLake, authentication is automatically routed to the appropriate Identity Provider (Okta, Microsoft Entra ID, or PingIdentity), where the password is validated. Federation is detected automatically — no additional parameters are required.

Supported scenarios:

• Okta: Password only, or password + Okta Verify MFA step-up (push or TOTP)
• Microsoft Entra ID: Password only, or password + Microsoft Authenticator MFA step-up (push with number matching)
• PingIdentity: Password only, or password + PingID MFA step-up (push or TOTP)

# Automatically routes to Okta, Entra ID, or PingID based on email domain federation
$cred = Get-Credential -UserName "user@company.com"
Connect-HPEGL -Credential $cred -Workspace "Production"

-PasswordlessSSOEmail parameter (replaces -SSOEmail)

To clearly distinguish the fully passwordless flow (push notifications, TOTP codes) from the new password-based SSO flow, the -SSOEmail parameter has been renamed to -PasswordlessSSOEmail. The original -SSOEmail name is retained as a backward-compatible alias — existing scripts continue to work without any changes.

# Passwordless flow (push notification or TOTP — no password)
Connect-HPEGL -PasswordlessSSOEmail "user@company.com" -Workspace "Production"

Clear handling when password requirements differ from the parameter used

• -PasswordlessSSOEmail but the IdP requires a password: the cmdlet returns a clear error instructing you to use -Credential instead. It never prompts interactively, so automation scripts do not hang waiting for input.
• -Credential but the IdP account is passwordless-only: the supplied password is ignored and the normal push/TOTP flow proceeds, with a warning so you know the password was not used.

Under the hood — why this was hard: what looks like a single -Credential parameter hides three completely different provider implementations. Each of Okta, Microsoft Entra ID, and PingIdentity uses its own sequence of redirects, hidden form fields, state tokens, and MFA challenges (push with number-matching, TOTP, polling for approval), none of which is documented for programmatic use. Every flow had to be traced, understood, and re-implemented by hand — and kept resilient to the providers' frequent changes. In total this is ~2,200 new lines of authentication code in Connect-HPEGL, the result of months of reverse-engineering and testing, all so the complexity stays invisible to you.

Telemetry & Privacy

Connect-HPEGL — Anonymous usage telemetry

Why this was added: the module is maintained as a community project with no direct visibility into how it is used in the field. Without data, decisions about which platforms, PowerShell versions, and authentication methods to prioritise — and which problems are actually hurting users — are guesswork. This lightweight, anonymous telemetry exists solely to guide that work: to focus testing on the operating systems and PowerShell versions people really run, to measure adoption of features like SSO, to detect connection problems early, and to gauge demand for currently-unsupported scenarios so they can be prioritised objectively.

Anonymous data only: no personally identifiable information is ever collected — no usernames, email addresses, passwords, tokens, IP addresses, workspace names, or server names. Nothing collected can be traced back to you or your organisation. Telemetry is OFF by default (opt-in) — nothing is collected or sent unless you explicitly opt in by running Enable-HPECOMDataCollection.

When opted in, Connect-HPEGL sends a single anonymous event each time a successful connection is established. The information collected includes: module version; PowerShell version, host, and edition; operating system and version; authentication method; number of workspaces; whether the workspace has COM configured; active COM regions; connection duration; time zone; language; target environment (Production or Pavo); and whether the session is running in a CI/CD pipeline.

On the first Connect-HPEGL calls on a new machine (until you make a choice), a short invitation notice is displayed explaining that telemetry is off by default and how to opt in. It is shown at most three times, then no longer; opting in or out stops it immediately.

Beyond successful connections, the telemetry also records — anonymously and without any usernames, host, tenant, or organisation details — when an SSO sign-in is rejected or fails (e.g. an unsupported federation type, a wrong password, or a denied/timed-out MFA challenge), and which identity provider is involved when a workspace uses an unsupported OpenID Connect (OIDC) federation instead of SAML 2.0. This helps prioritise fixes and future native-support work for the providers driving demand.

To opt in permanently, run Enable-HPECOMDataCollection. To opt in for the current session only, set $env:HPE_COM_ENABLE_TELEMETRY = '1'. To opt back out at any time, run Disable-HPECOMDataCollection. For more information, see the Telemetry section in the README.

New Cmdlets

Remove-HPEGLDevice — Permanently remove devices from HPE GreenLake

New cmdlet that permanently removes (unclaims) one or more devices from the HPE GreenLake workspace.

The cmdlet warns the user about the irreversible impact of the action before proceeding and prompts for confirmation. Use the -Force switch to suppress the confirmation prompt for automation scenarios.

Supports pipeline input from Get-HPEGLDevice and accepts serial numbers directly or as pipeline strings.

Examples:

# Remove a single device with confirmation prompt
Remove-HPEGLDevice -SerialNumber CN70490RXR

# Remove a device without confirmation prompt (for automation)
Remove-HPEGLDevice -SerialNumber CN70490RXR -Force

# Remove a device using pipeline input from Get-HPEGLDevice
Get-HPEGLDevice -Name CN70490RXR | Remove-HPEGLDevice

# Remove multiple devices by piping serial numbers
'CN70490RXR', 'CZ12312333' | Remove-HPEGLDevice -Force

# Remove all server devices (use with caution!)
Get-HPEGLDevice -FilterByDeviceType SERVER | Remove-HPEGLDevice

Invoke-HPECOMSecureGatewayServerDiscovery / Get-HPECOMSecureGatewayServerDiscovery — Discover servers behind a Secure Gateway

Two new cmdlets to discover and retrieve servers reachable through an HPE Secure Gateway appliance.

Invoke-HPECOMSecureGatewayServerDiscovery runs a network discovery from the Secure Gateway to detect HPE iLO devices on the appliance's local subnet that are not yet connected to Compute Ops Management. Because the discovery performs an active network scan, the cmdlet warns about the scan and prompts for confirmation before proceeding (use -Force to suppress the prompt). It supports immediate execution (and waits for the result), -Async to return the job immediately, and -ScheduleTime (optionally with -Interval) to schedule a one-time or recurring discovery.

Get-HPECOMSecureGatewayServerDiscovery returns the servers found by the most recent discovery. If no discovery has ever been run on the Secure Gateway, it returns a warning recommending that you run Invoke-HPECOMSecureGatewayServerDiscovery first; if a discovery has been run but no servers were found, it returns nothing.

Both cmdlets report, for each discovered server, the IP address, iLO generation, iLO firmware version, whether an iLO firmware update is required before the server can be connected to Compute Ops Management, and the iLO certificate fingerprint. The results can be piped directly to Connect-HPEGLDeviceComputeiLOtoCOM to onboard the discovered iLOs through the Secure Gateway.

Examples:

# Run a discovery on a Secure Gateway and return the discovered servers
Invoke-HPECOMSecureGatewayServerDiscovery -Region eu-central -SecureGateway "sg01.lab"

# Retrieve the servers found by the most recent discovery
Get-HPECOMSecureGatewayServerDiscovery -Region eu-central -SecureGateway "sg01.lab"

# Onboard the discovered iLOs that do not require a firmware update
$iLO_credential = Get-Credential
Get-HPECOMSecureGatewayServerDiscovery -Region eu-central -SecureGateway "sg01.lab" |
    Where-Object iLOUpdateRequired -eq 'No' |
    Connect-HPEGLDeviceComputeiLOtoCOM -IloCredential $iLO_credential

Connect-HPECOMSecureGatewayDiscoveredServer — Onboard discovered servers through a Secure Gateway

New cmdlet that onboards one or more servers discovered behind an HPE Secure Gateway appliance to Compute Ops Management — the automated, gateway-driven equivalent of the "add multiple servers via Secure Gateway" wizard in the Compute Ops Management UI.

Unlike Connect-HPEGLDeviceComputeiLOtoCOM (which connects a single iLO directly and requires a pre-generated activation key), this cmdlet submits a single batch request per Secure Gateway, and Compute Ops Management then orchestrates the whole onboarding through the gateway:

• generates the Secure Gateway activation key automatically (no activation key needs to be provided);
• updates the iLO firmware on each server whose discovery reports iLOUpdateRequired = Yes (an iLO below the minimum version — iLO 5 v3.09, iLO 6 v1.64, iLO 7 v1.12.00 — cannot connect to Compute Ops Management). Servers reported as No are onboarded without a firmware update;
• skips servers whose discovery reports iLOUpdateRequired = Unknown (firmware compliance could not be determined) with a warning, so an undetermined server is never onboarded blindly;
• optionally configures DNS and NTP on the iLO, and assigns a subscription, location, service delivery contact and tags.

The discovered server objects are piped straight from Get-HPECOMSecureGatewayServerDiscovery — their IP, certificate fingerprint, Secure Gateway and appliance ID are reused automatically. Two iLO-credential modes are supported, matching the UI: pass -IloCredential once to apply the same credential to every server, or attach an IloCredential property (a PSCredential) to each piped server to use a different credential per iLO. By default the cmdlet waits for the onboarding job to complete; use -Async to return the job immediately.

Examples:

$iLO_credential  = Get-Credential
$SubscriptionKey = Get-HPEGLSubscription -ShowDeviceSubscriptions -ShowWithAvailableQuantity -ShowValid |
    Where-Object tier -eq "ENHANCED_PROLIANT" | Select-Object -First 1 -ExpandProperty Key

# Onboard every discovered server using one shared iLO credential
Get-HPECOMSecureGatewayServerDiscovery -Region eu-central -SecureGateway "sg01.lab" |
    Connect-HPECOMSecureGatewayDiscoveredServer -IloCredential $iLO_credential -SubscriptionKey $SubscriptionKey

# Onboard with full configuration (DNS, NTP, location, contact and tags)
Get-HPECOMSecureGatewayServerDiscovery -Region eu-central -SecureGateway "sg01.lab" |
    Connect-HPECOMSecureGatewayDiscoveredServer -IloCredential $iLO_credential -SubscriptionKey $SubscriptionKey `
        -Dns 192.168.2.1 -Ntp 1.1.1.1 -LocationName "Houston" -ServiceDeliveryContact "support@example.com" `
        -Tags "Country=US, Apps=VMware ESX"

Enable-HPECOMServerMaintenanceMode / Disable-HPECOMServerMaintenanceMode — Suspend support automation during planned maintenance

Two new cmdlets to turn a server's maintenance mode on and off. While maintenance mode is enabled, Compute Ops Management suspends automatic support case creation, ServiceNow incident creation, and email notifications for the server — avoiding noise and unwanted tickets during planned maintenance windows.

Both cmdlets accept a server by name or serial number (including from the pipeline via Get-HPECOMServer), support -WhatIf, and run the operation immediately (waiting for completion) or return the job right away with -Async. They also support -ScheduleTime (optionally with a recurring -Interval) to schedule the change for later. When run immediately, each cmdlet skips with a warning if the server is already in the requested state.

The current maintenance mode state of a server is exposed by the maintenanceMode property returned by Get-HPECOMServer (visible with Format-List or Select-Object). Get-HPECOMServer also gains a new -InMaintenanceMode switch to list only the servers that are currently in maintenance mode.

Examples:

# Enable maintenance mode before starting work on a server
Enable-HPECOMServerMaintenanceMode -Region eu-central -Name CZ12312312

# Enable maintenance mode on all directly managed servers, returning the jobs immediately
Get-HPECOMServer -Region eu-central -ConnectionType Direct |
    Enable-HPECOMServerMaintenanceMode -Async

# Schedule maintenance mode to be enabled in 6 hours
Enable-HPECOMServerMaintenanceMode -Region eu-central -Name CZ12312312 -ScheduleTime (Get-Date).AddHours(6)

# Disable maintenance mode once the work is complete
Disable-HPECOMServerMaintenanceMode -Region eu-central -Name CZ12312312

# List servers currently in maintenance mode
Get-HPECOMServer -Region eu-central -InMaintenanceMode

# Disable maintenance mode on all servers currently in maintenance mode
Get-HPECOMServer -Region eu-central -InMaintenanceMode | Disable-HPECOMServerMaintenanceMode

Disable-HPECOMDataCollection — Opt out of anonymous usage telemetry

New cmdlet that records an explicit opt-out of anonymous usage data collection (telemetry is OFF by default, so this also suppresses the one-time invitation notice, or turns collection back off after opting in). Running this cmdlet creates a persistent opt-out marker file (~/.config/HPECOMCmdlets/telemetry-disabled) and sets $env:HPE_COM_NO_TELEMETRY = '1' for the current session. Once disabled, no telemetry is sent even after restarting PowerShell.

Example:

Disable-HPECOMDataCollection

Enable-HPECOMDataCollection — Opt in to anonymous usage telemetry

New cmdlet that opts in to the anonymous usage data collection introduced in v1.0.26 (telemetry is OFF by default). Running this cmdlet creates a persistent opt-in marker file (~/.config/HPECOMCmdlets/telemetry-enabled) and sets $env:HPE_COM_ENABLE_TELEMETRY = '1' for the current session. Once enabled, anonymous telemetry is sent on each successful connection, even after restarting PowerShell.

Example:

Enable-HPECOMDataCollection

Bug Fixes

Connect-HPEGL (sign-in) — support for HPE's new authentication flow 🚨

Critical fix. HPE switched their GreenLake sign-in to a new authentication workflow (v1alpha1 → v1alpha2), changing the broker used by all account types. With the previous logic, Connect-HPEGL broke for everyone — both federated SSO accounts (Microsoft Entra ID, Okta, PingIdentity) and standard accounts could fail to sign in.

Connect-HPEGL now detects and follows HPE's new authentication broker automatically, while remaining compatible with the previous one. Sign-in works again for all account types — federated SSO (with both -PasswordlessSSOEmail and -Credential) and standard accounts — with no script changes required. Upgrading to v1.0.26 is required to keep connecting.

Set-HPEGLUserAccountPassword — requires a workspace session (regression)

Set-HPEGLUserAccountPassword was incorrectly requiring an active workspace session to be established before it could run, even though the cmdlet is designed to work immediately after Connect-HPEGL without selecting a workspace.

Set-HPEGLUserAccountPassword now works correctly without an active workspace session, as originally intended.

Set-HPEGLUserAccountPassword — exposes plaintext passwords in verbose output

When running Set-HPEGLUserAccountPassword with -Verbose, password values were exposed in plaintext in the verbose output.

Password values are now fully redacted in verbose output.

GLP-Organizations.psm1 — Get-HPEGLOrganization -ShowCurrent returns no result for member workspaces

Get-HPEGLOrganization -ShowCurrent (and the organization detection run by Connect-HPEGL) returned no result when the connected workspace was a member workspace of an organization rather than its management workspace.

The current organization is now correctly identified in all cases, and the Current column is properly set to True in Get-HPEGLOrganization output.

$HPECOMLastJobResult not populated after running job cmdlets

After running any job-related cmdlet such as Set-HPECOMServerUIDIndicator, Start-HPECOMServer, Stop-HPECOMServer, Restart-HPECOMServer, Update-HPECOMServerFirmware, Update-HPECOMServeriLOFirmware, and others, the $HPECOMLastJobResult global variable remained $null even when the job completed successfully.

This also affected job cmdlets that return a custom status object, including Restart-HPECOMAppliance, Invoke-HPECOMApplianceRefreshSettings, Invoke-HPECOMExternalServiceVCenterFirmwareBaselineSync, and the AI Insights report cmdlets.

$HPECOMLastJobResult is now correctly populated after every job cmdlet across all modules.

Improvements

Module import welcome banner

Importing the module now displays a short, one-time welcome banner pointing to the first step (Connect-HPEGL), the getting-started help topic (Get-Help about_HPECOMCmdlets), and the project documentation. The banner is shown only in interactive PowerShell hosts — it is automatically suppressed in CI/CD pipelines and non-interactive/scripted sessions so it never pollutes automation output. To hide it permanently, set $env:HPECOMCMDLETS_NO_BANNER = '1'.

A new about_HPECOMCmdlets help topic is also included, providing a concise getting-started overview accessible via Get-Help about_HPECOMCmdlets.

Country list now fetched dynamically from HPE GreenLake

The country list used by New-HPEGLLocation, Set-HPEGLLocation, New-HPEGLWorkspace, Set-HPEGLWorkspace, and Set-HPEGLUserAccountDetails is now fetched directly from HPE GreenLake instead of being hardcoded in the module. This ensures country names always match what the API expects, eliminating errors caused by name mismatches (e.g., "South Korea" vs "Korea, Republic of", "Czech Republic" vs "Czechia", "Vietnam" vs "Viet Nam").

The list is refreshed automatically on every connection and works correctly across all environments.

Connect-HPEGL — automatically retries on transient rate-limit errors

When connecting to HPE GreenLake, a 429 Too Many Requests response from the OAuth2 token endpoint could cause the connection to fail immediately with an error, even though the issue is transient.

Connect-HPEGL now automatically retries the token exchange up to 3 times with increasing delays (2 s, 5 s, 10 s) when a 429 response is received. Any other error still fails immediately without retrying.

Connect-HPEGLDeviceComputeiLOtoCOM — new -WhatIf support

Connect-HPEGLDeviceComputeiLOtoCOM now supports -WhatIf. When used, the cmdlet contacts the iLO read-only to gather its model, firmware version, serial number, current proxy state and external manager status, runs all validation checks, then returns a step-by-step report — without making any change to the iLO. The report has two sections:

• Validation — iLO reachability (ping), authentication/session, iLO identity, current proxy state, whether the iLO is currently managed by HPE OneView, and either the iLO firmware compatibility with the activation key (when -ActivationKeyfromCOM is used) or the device's workspace, COM-region and subscription state (when connecting to the assigned instance).
• Planned operations — proxy or Secure Gateway configuration, HPE OneView handling, an existing Compute Ops Management disconnect when -Force is used, and the Compute Ops Management connection target.

The report also surfaces actionable warnings when a blocker is detected — for example a leftover proxy on a direct connection (pointing to -RemoveExistingiLOProxySettings) or an iLO currently managed by HPE OneView (pointing to -DisconnectiLOfromOneView). This makes it easy to preview a connection or migration (including bulk pipeline operations) and confirm every prerequisite before running it for real.

$iLO_credential = Get-Credential
Connect-HPEGLDeviceComputeiLOtoCOM -IloIP "192.168.0.21" -IloCredential $iLO_credential -WhatIf

Sample output:

WARNING: iLO '192.168.0.21' [iLO 5 v3.10 - SN: MXQ73301YK] - WhatIf report:
  Validation
    - iLO network connectivity (ping) : Reachable
    - iLO authentication / session    : Succeeded
    - iLO identity                    : iLO 5 v3.10 (SN: MXQ73301YK)
    - Current iLO proxy               : Disabled
    - Managed by HPE OneView          : No
    - Device present in workspace     : Yes
    - Device assigned to a COM region : Yes ('eu-central')
    - Device subscription attached    : Yes (key: 'KY767YTUE2JHJ')

  Planned operations
    - Proxy configuration             : None (direct connection)
    - HPE OneView                     : Leave unchanged (not managed by HPE OneView)
    - COM connection                  : Connect to the 'eu-central' COM instance using the workspace ID

When a blocker is present, the report calls it out explicitly. For example, a direct connection requested on an iLO that is still managed by HPE OneView and has a leftover proxy:

  Planned operations
    - Proxy configuration             : None (direct connection) - WARNING: a proxy is currently configured on the iLO (ProxyServer: 'oldproxy.lab', ProxyPort: '8080'). Use -RemoveExistingiLOProxySettings to clear it, otherwise the direct connection to Compute Ops Management may fail.
    - HPE OneView                     : WARNING: the iLO is currently managed by HPE OneView. The connection to Compute Ops Management will fail unless you use -DisconnectiLOfromOneView to override the existing manager.
    - COM connection                  : Connect to the 'eu-central' COM instance using the workspace ID

Connect-HPEGLDeviceComputeiLOtoCOM — automatic Secure Gateway routing from the pipeline

Connect-HPEGLDeviceComputeiLOtoCOM now accepts a SecureGateway value from the pipeline. When the output of Get-HPECOMSecureGatewayServerDiscovery is piped to it, each iLO connection is automatically routed through the Secure Gateway the server was discovered behind, using the default Secure Gateway port (8080). You no longer need to specify -IloProxyServer / -IloProxyPort for this scenario. -SecureGateway has its own parameter set and cannot be combined with -IloProxyServer / -IloProxyPort; to route through a web proxy or to use a custom port, use -IloProxyServer / -IloProxyPort instead.

$iLO_credential = Get-Credential
$COM_Activation_Key = New-HPECOMServerActivationKey -Region eu-central -SecureGateway "sg01.lab"

# Onboard every discovered server that is ready to connect, automatically routed through its Secure Gateway
Get-HPECOMSecureGatewayServerDiscovery -Region eu-central -SecureGateway "sg01.lab" -ReadyForConnection |
    Connect-HPEGLDeviceComputeiLOtoCOM -IloCredential $iLO_credential -ActivationKeyfromCOM $COM_Activation_Key -SkipCertificateValidation

Note: Password-based SSO authentication — the headline feature of this release — is described in the Password-Based SSO Authentication section at the top of these notes.

Installation

Install-Module -Name HPECOMCmdlets -RequiredVersion 1.0.26

Or update from a previous version:

Update-Module -Name HPECOMCmdlets