Forum Discussion
UShort Error with the Exchange Module
That seems like an Exchange bug.
ushort only pertains to Visual Basic, whereas PowerShell is aligned to C# and the Common Language specification, in which there is no ushort.
If you have premier field support (PFS) or some other channel to report it directly to Microsoft, you should probably do so.
To get by in the interim - assuming this is occurring on the latest release, you might want to try removing the version you have installed and backdate to a previous version. Conversely, if you're on an older version, try updating to the latest.
If this fails, then the issue is within the dynamic module that the installed module pulls down during the call made with Connect-ExchangeOnline, in which case perhaps there is no workaround and you just have to wait for the fix, which is why lodging a bug via PFS is important.
You might also want to ask this question in the Exchange forum, as this isn't strictly a PowerShell issue and more people there would work with Exchange (you'd hope, anyway).
Edited to add the following:
I've just given the commandlet a quick try and the bug is unfortunately in the dynamically-loaded code as evidenced below. So, you'd have to go via PFS for this one.
Perhaps a dependency was missed or something in a recent update - no idea, but there's nothing you can do to fix this one, I suspect.
Edited again to correct myself:
[ushort] exists in C# but it's correct that it's not in the CLS, and certainly not natively in PowerShell as a result.
Cheers,
Lain
Install Powershell 7.x and try again:
Source:
https://lukasz.de/powershell-microsoft-365/fehlerbehebung-bei-der-dkim-einrichtung-in-microsoft-365-clientfehler-ex43c0ac/
That's fine as an individual workaround but it doesn't absolve the need for fixing the bug. It doesn't serve as a reliable, scalable workaround as PowerShell does not ship with Windows and getting customer acceptance for mass deployments of any kind in large change-managed environments is not always trivial.
But this is missing the point. From the following article:
"All versions of the module are supported in Windows PowerShell 5.1."
ushort (and other types) are not supported by .NET Framework meaning it should not have been used if the module is indeed intended to operate under both .NET/PowerShell environments. Rather, the UInt16 type (to which ushort is mapped during compilation in the C# context) should have been used, as it is supported by both Core and Framework.
PowerShell
Windows PowerShell
This is a clear-cut bug on those two commandlets that needs fixing (and it's a very, very easy fix).
Cheers,
Lain
I've opened a bug on github for this, as it's still an issue under ExchangeOnlineManagement 3.6.0 (second post):
Either it should be fixed or the support stance should be updated to exclude Windows PowerShell. Or they could just continue to ignore the bug, I guess. Time will tell.
Cheers,
Lain