Exchange 2013 KB5008631 eDiscovery Deserialization of type Microsoft.Exchange.Data.PropertyBag+Value

[MarcAEC]

After KB5008631 was installed, in-place eDiscovery & Hold in ECP stopped working.  When going to the page, an error is displayed "Deserialization of type Microsoft.Exchange.Data.PropertyBag+ValuePair blocked due to NotInAllow at location MailboxDataStore."  After the user clicks off the error message, the list of searches is left blank.  If I uninstall KB5008631, the error stops occurring.

[#2]

I am seeing the same issue. Installed KB5008631 over the weekend.

[#3]

I had opened a support case.  I was recently informed that it is a known issue in KB5008631 and that it is already fixed in the code to be included in the next update.

[#4]

Support had told me it was fixed in the "February update", but it's March now and no update has been released.  I'm now working on a migration to Exchange 2019 and am not seeing the same problem there.  I suspect that I'll be done with that before support informs me that the Exchange 2013 update is ready.

[#5]

Seeing the same thing after installing the March 2022 SU as well. We skipped the Jan 2022 SU.

[#6]

Support is telling me the fix has been scheduled for "the next CU".  Since there are no more CUs planned for Exchange 2013, I guess that means the fix is scheduled for never.  This is really poor of the Exchange team.  They have the issue diagnosed and a code fix ready, and are choosing not to release it.

[#7]

I wonder if they used a branch of code that didn't have the fix to create the March SU.

Uninstalling the SU did resolve our issues. It was the mailbox servers and the ecp web.config file specifically since that is the only one that was modified by the update.

Maybe they can get it right the next time. Hoping support meant the next SU and not CU since 2013 isn't getting any more.

[#8]

No, support has been very clear of CU vs SU. I even mentioned there are no more CUs and they still insist their documentation says it will be included in the next CU. I'm in the middle of a migration to Exchange 2019 and found the issue is not there. This may be a case of the Exchange team just showing disdain for customers that are on an old version.

[#9]

Support has now acknowledged that another CU is not coming, and since the fix is marked for the next CU, they can't say that it'll ever be released. They're trying to close the case and telling me to upgrade to Exchange 2019.

It's unacceptable for Microsoft to break something that was working when a product entered extended support, then say "sorry, we're not gonna fix that because the product is in extended support."

[#10]

@Marc K Looks like they released another SU. Has anyone with this issue tried installing that to see if it still breaks Exchange 2013?

[#11]

@BrianGrell83I'm no longer able to test this.  I completed an upgrade to Exchange 2019 a while back.  I asked support if the new SU includes a fix for this issue and they said there is no indication that it does.  I also found out that since I opened the case via software assurance, the service level is very poor.  This team has no ability to contact the product team to express my dissatisfaction that a fix was coded and is being withheld from customers.  They said if I wanted better service, I'd need to open a ticket under premier support.  This team considers the case resolved once the issue is confirmed as a known bug.