ExchangeOnlineManagement 3.8.0: "Unable to find type [Microsoft.Exchange.Management.ExoPowershellSnapin.JsonTypedConverter]" when running cmdlets

Question

ExchangeOnlineManagement 3.8.0: "Unable to find type [Microsoft.Exchange.Management.ExoPowershellSnapin.JsonTypedConverter]" when running cmdlets

kesavan 0

We are running Exchange Online cmdlets using powershell through the ExchangeOnlineManagement PowerShell module, and on some machines the call fails with the following error:

Method: executeExchangeModuleCommandAsync
ERROR: Unable to find type [Microsoft.Exchange.Management.ExoPowershellSnapin.JsonTypedConverter].
CATEGORY: NotSpecified
FQID: Microsoft.PowerShell.Commands.WriteErrorException

Observations so far:

The error occurs with module version 3.8.0.
On the same machine, the same operation works correctly with version 3.10.1.
Other environments running the same 3.8.0 version do not hit the issue at all.
On one affected machine the error stopped occurring on its own, without any change on our side.
In some environments the issue is still unresolved.

Questions:

What causes the JsonTypedConverter type to be unavailable, given that the same module version works on other machines?
Is this a known defect in 3.8.0 that was fixed in a later release, or is it an environment/runtime dependency issue?
What is the recommended resolution — upgrading the module, or is there a supported fix for 3.8.0?

0 comments

2 answers

Your answer

Answer 1

kesavan 0

@Hendrix , thank you for the response.

Our main concern is that this issue has suddenly appeared across more than 5 environments at roughly the same time, even though nothing was changed on our side. All of these environments are identically configured and were running the same module version without any problem previously.

We understand that upgrading to the latest version resolves the error — we have verified that it works fine after upgrading. However, we are not able to roll out the version upgrade across all environments immediately, and more importantly we need to understand why this started happening.

Could you please help us with:

Root cause — what changed that caused the JsonTypedConverter type to become unresolvable on version 3.8.0, when the same version was working earlier in the same environments? Was there any service-side change on the Exchange Online side that affects older module versions?
Why the failure appeared suddenly and simultaneously across multiple environments rather than gradually.
Whether there is a supported workaround or fix for 3.8.0, apart from upgrading the module.

We are looking for the root cause and a permanent solution, not just a version upgrade as a workaround.

Hendrix 990 Reputation points Independent Advisor

2026-08-18T22:36:55.97+00:00

Hi kesavan,

Thank you for your update.

In this case, for you to receive the best possible assistance, I greatly recommend reaching out to your IT administrator to open a support ticket with Microsoft Support. A technical support engineer can then initiate a remote session, review backend settings, and run diagnostics. If needed, they can escalate the case to specialized engineering teams who are well-equipped to perform advanced troubleshooting and provide targeted solutions for your situation.

For guidance on how to request support in the admin center, please share this link with your IT admin: Get support - Microsoft 365 admin. 

If you are unsure who your IT administrator is, you can refer to this official Microsoft guide for assistance: How do I find my Microsoft 365 admin? - Microsoft Support.

Thank you for your understanding and I truly hope your concern would get resolved swiftly.

Kind regards.

Answer 2

Hi kesavan,

Regarding your concern, let me assist you by answering each question one by one based on what I have researched

1/ Why is JsonTypedConverter unavailable?

The error means the PowerShell runspace is executing generated Exchange module code that references that type, but the assembly/type that defines it is not loaded or not resolved in that runspace. This is most likely caused by a client-side module loading or runtime state issue, not by Exchange Online permissions or tenant configuration.

Exchange Online PowerShell V3 cmdlets are REST-backed and rely on local module files, supporting dependencies, and generated/imported module content during connection. The reason it can happen on some machines but not others, even with the same 3.8.0 module version, is that the local environment can differ in ways such as:

Multiple ExchangeOnlineManagement versions installed side by side
Stale or partially generated temporary EXO module files
Different PowerShell host or runspace behavior
Profile/session state differences
Local module cache regeneration, which may explain why the issue stopped occurring on one machine without an intentional change
Etc.

That said, I suspect that this is more likely a local module/runtime resolution problem exposed by version 3.8.0, not a server-side Exchange Online issue.

2/ Is this a known defect in 3.8.0?

I cannot find any official announcement or article clearly state/confirm whether this is a known behavior and also there is no documented resolutions. However, in your situation, the behavior strongly suggests that 3.8.0 has a module-loading/runtime fragility that can surface only in certain environments.

3/ The recommended solution

The recommended resolution is to upgrade ExchangeOnlineManagement to the latest GA version, currently 3.10.1 or later. Since the same operation works on the same affected machine with 3.10.1, upgrading is the most reliable and supportable fix.

Hope this information is useful for your concern. If you have any other questions, please feel free to reach out in the comments of this post. I'll be happy to assist you further.

Thank you for your patience and understanding. Hope to hear from you soon.

If the answer is helpful, please click "Yes" and kindly upvote it.

Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.