Exchange Online PowerShell: plus de temps pour la migration de l'authentification

Microsoft has extended the deadline for removing the `-Credential` parameter from its Exchange Online PowerShell module, giving administrators more time to adapt their scripts and automation processes. According to the Exchange team, the removal of this parameter will now occur starting with module versions released after December 2026, rather than the previously planned July 2026 date. The affected commands include `Connect-ExchangeOnline` and `Connect-IppsSession`. Scripts and automated workflows relying on these parameters will cease to function once they are updated to a module version released after December 2026. The `-Credential` parameter allows PowerShell scripts to pass a credential object containing username and password information, typically generated using `Get-Credential`, to authenticate with Exchange Online or Security & Compliance PowerShell. This method is commonly used in automated tasks to store login credentials for administrative purposes. However, Microsoft aims to phase out this older authentication method because it does not support modern security features such as multi-factor authentication (MFA). The transition is being implemented in two stages. First, Microsoft will remove the `-Credential` parameter from new versions of the Exchange Online PowerShell module. Scripts using older module versions will continue to work initially, providing administrators with additional time to migrate their systems. However, automatic updates could disrupt scheduled tasks unexpectedly. If the module is updated to a newer version, scripts that rely on passing `-Credential` to either of the two cmdlets will fail. In a later stage, Microsoft plans to disable the underlying authentication process on the server side, rendering the `-Credential` parameter ineffective even with older module versions. While the company has not yet announced a specific date for this change, it intends to notify users beforehand. As a result, administrators cannot indefinitely remain on older module versions. Primarily affected are scripts executed automatically, such as those generating reports, managing recipients, performing permission checks, or modifying transport rules. For interactive administration sessions, the standard login method via `Connect-ExchangeOnline` remains available and supports MFA. For automations outside of Azure, Microsoft recommends using app-only authentication. This approach involves authenticating with a registered application in Microsoft Entra ID instead of a user account. The application authenticates itself using a certificate. It requires the permission `Exchange.ManageAsApp` and the necessary RBAC rights for each command. Although this method avoids storing user passwords, it necessitates careful management of certificates and permissions. If automation runs within Azure, such as in Azure Automation runbooks or on Azure virtual machines, managed identities can be utilized. Azure assigns a unique identity to the resource, allowing the script to avoid handling passwords or certificates. For example, a connection can be established using `Connect-ExchangeOnline -ManagedIdentity -Organization <Tenant>.onmicrosoft.com`. The availability of cmdlets and parameters depends on the assigned RBAC rights. Administrators should immediately review which internal scripts and third-party tools pass `-Credential` to `Connect-ExchangeOnline` or `Connect-IppsSession`. They should then select an appropriate replacement method for each automation task, assign only the required permissions, and test the migration thoroughly. However, the alternative methods do not cover all cmdlets. Particularly, there are limitations with cmdlets related to M365 groups and certain Purview cmdlets. Therefore, administrators must individually assess all affected processes. Additional details are available in the Message Center post MC1248389.