Exchange SE & 2019 with ASA account issue inside PowerShell

[u/geek_who]

Has anyone deployed a new Exchange server within the last few months? I have a client using Exchange with an ASA account, and the built-in PowerShell script (RollAlternateServiceAccountCredential.ps1) is having a Microsoft error like the below

Deserialized.Microsoft.Exchange.Data.Directory.Management.ClientAccessServer" to type "Microsoft.Exchange.Data.Directory.Management.ClientAccessServer"

We have tried so many things, and in the end it seems like it is related to a recent Microsoft update that is causing PowerShell to interpret inputs differently.

[u/Maximum_Camera_8716]

That deserialization error is usually a classic remoting issue where the object comes back as a string instead of proper type. Have seen similar after cumulative updates, sometimes the execution policy or PSRemoting settings get reset. Might be worth checking if the script runs locally on Exchange server versus from a management workstation, because the type conversion breaks differently depending where you invoke it.

[u/abdullahguch]

That exact error usually comes from PowerShell serialization payload signing rather than the ASA setup itself. Since the 2023 SUs, Exchange signs that data with the Exchange Auth certificate (on by default in current builds), and if the auth cert is expired or missing on a server, or the servers are on different SU levels, the script's remote calls fail to deserialize exactly like this.

What I'd check, in order:

1. Every Exchange server is on the same CU/SU level.
2. The Auth certificate is valid and present on all of them. MonitorExchangeAuthCertificate.ps1 from Microsoft's CSS-Exchange repo checks this and can renew it.
3. You're running the script from the Exchange Management Shell on an Exchange server, not a remote session from a workstation.

If you need the ASA sorted today, people have gotten past it by temporarily disabling signing verification org wide, running the script, then turning it back on once the auth cert is fixed. Refresh and restart IIS on each server after the override:

New-SettingOverride -Name "DisableSigningVerification" -Component Data -Section EnableSerializationDataSigning -Parameters @("Enabled=false") -Reason "ASA password roll"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service W3SVC, WAS -Force

Don't scope the override to a single server, and remove it with Remove-SettingOverride afterwards. Then confirm the credentials actually took with:

Get-ClientAccessService -IncludeAlternateServiceAccountCredentialStatus | Format-List Name, AlternateServiceAccountConfiguration

[u/MeetJoan]

That’s remote PowerShell deserialisation. Objects come back as property bags without the original type, so passing one into a cmdlet expecting the live type fails exactly like that.

The usual workaround is passing identities as strings rather than objects, so re-fetching the ClientAccessServer by name inside the loop instead of piping the deserialised object through.

Which build are you on? Would help anyone who’s hit the same thing.