What happen with the newest KB update of Exchange Sever SE

Question

What happen with the newest KB update of Exchange Sever SE

Rachal Camp 80

Hi, Exchange Management Shell is error right after the newest KB update ? Every cmdlet going to error now. Any recognized from MS ?

0 comments

Answer accepted by question author

Hin-V 16,830 Microsoft External Staff Moderator

Hi @Rachal Camp

Thank you for posting your question in Microsoft Q&A.

Currently, I have not found any officially recognized issue from Microsoft regarding Exchange Management Shell (EMS) or cmdlets failing after the KB update. To assist you further, could you provide additional information for the following questions:

May I know the exact error message you receive when running commands in EMS?

Could you please confirm whether you are experiencing the same issue described in this thread?

This information will help narrow down the issue and check if it aligns with any known compatibility or update-related issues.

I will be waiting for your response. If you have any additional concerns, feel free to comment below. I would be more than happy to assist.

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

Rachal Camp 80 Reputation points

2026-01-05T14:50:37.3266667+00:00

Yes I have the same as the thread you proposed
Hin-V 16,830 Reputation points Microsoft External Staff Moderator

2026-01-06T12:05:56.3366667+00:00
Hi @Rachal Camp
Sorry for my delayed respond.

If possible, could you please try to check for any active Software Restriction Policies (SRP) on the server.

Run the following on the Exchange server:

gpresult /h C:\gpresult.html

Open the generated HTML file and search for “Software Restriction Policies”. Look under: Computer Settings > Security Settings > Software Restriction Policies to see whether any SRP is applied and what rules are configured.

Alternatively, open Local Security Policy (secpol.msc) and navigate to:

Security Settings > Software Restriction Policies

If the node exists but no rules are shown, SRP should not block scripts unless a default disallow rule is configured.

Additionally, you could try to check for Zone Blocking. If Exchange files were copied or downloaded (for example, during patching), they may have a Zone.Identifier marking them as internet‑sourced.

Run the following command as Administrator:

Get-Item "C:\Program Files\Microsoft\Exchange Server\V15\bin\*" -Stream *

Look for Zone.Identifier streams on .ps1 or .ps1xml files.

If present, unblock via:

Unblock-File -Path "C:\Program Files\Microsoft\Exchange Server\V15\bin\*.ps1" Unblock-File -Path "C:\Program Files\Microsoft\Exchange Server\V15\bin\*.ps1xml"

After applying allow rules and unblocking files, restart the server (or at least IIS/PowerShell sessions) and test the Exchange Management Shell again.

Any update would be appreciated. I would try my best to assist you troubleshoot it.

1 additional answer

Your answer

Rachal Camp 80 Reputation points

2026-01-05T14:50:37.3266667+00:00

Yes I have the same as the thread you proposed
Hin-V 16,830 Reputation points Microsoft External Staff Moderator

2026-01-06T12:05:56.3366667+00:00

Hi @Rachal Camp
Sorry for my delayed respond.

If possible, could you please try to check for any active Software Restriction Policies (SRP) on the server.

Run the following on the Exchange server:

gpresult /h C:\gpresult.html

Open the generated HTML file and search for “Software Restriction Policies”. Look under: Computer Settings > Security Settings > Software Restriction Policies to see whether any SRP is applied and what rules are configured.

Alternatively, open Local Security Policy (secpol.msc) and navigate to:

Security Settings > Software Restriction Policies

If the node exists but no rules are shown, SRP should not block scripts unless a default disallow rule is configured.

Additionally, you could try to check for Zone Blocking. If Exchange files were copied or downloaded (for example, during patching), they may have a Zone.Identifier marking them as internet‑sourced.

Run the following command as Administrator:

Get-Item "C:\Program Files\Microsoft\Exchange Server\V15\bin\*" -Stream *

Look for Zone.Identifier streams on .ps1 or .ps1xml files.

If present, unblock via:

Unblock-File -Path "C:\Program Files\Microsoft\Exchange Server\V15\bin\*.ps1" Unblock-File -Path "C:\Program Files\Microsoft\Exchange Server\V15\bin\*.ps1xml"

After applying allow rules and unblocking files, restart the server (or at least IIS/PowerShell sessions) and test the Exchange Management Shell again.

Any update would be appreciated. I would try my best to assist you troubleshoot it.

Answer 1

If you are experiencing errors with cmdlets in the Exchange Management Shell after a recent KB update, it may be related to issues that have been reported in similar scenarios. For example, after upgrading to Exchange Server 2010 SP3, some cmdlets may fail, and users can encounter errors indicating that operations are not valid due to the current state of the object.

To address this, a common workaround is to open a remote session to an Exchange server using specific PowerShell cmdlets at the beginning of your script. This can help restore functionality to the cmdlets that are failing.

If the issue persists, it may be beneficial to check for any updates or patches from Microsoft that specifically address these errors following the latest KB update.