Operations that change non-concurrent collections must have exclusive access.

[sumeet]

Hi All,

As part of working on case 07605497 where in I do not get email notifications for Archive and Exchange backup jobs after updating to 8.1, I was asked to updated to 8.1.0.331

I'm usually not so keen on going to latest updates (95% of our VBM365 deployment is still on 7.x).

Since the 8.1.0.331 patch, the archive and exchange backup fail with below error with the first 1min of starting. Even the retries have the same behavior.
Last night I tried stopping and starting the services (even tried nats service by renaming the streams folder - which would then not start the proxy service, so had to revert the streams folder back).

I have updated the case 07605497 with screenshots. Have the logs collected, waiting for support to confirm if we can use the same case to debug (I already have many cases, do not want a new one), then will upload the logs.

18/02/2025 9:00:21 PM :: Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection's state is no longer correct.

I understand 8.1.0.331 update is primarily for proxy pool scenario - which is not applicable to my case as I do not have any additoinal proxy setup.

Anyone else facing this issue??

-Sumeet.

[Mildur]

Hi Sumeet

I have done a short lookup and couldn't find others with the same error message.
Please continue the investigation for now with our customer support.

Best,
Fabian

[sumeet]

Hi Fabian,

Will appreciate if you can assist with this case 07611532.
The RCA provided isn't helpful. This is what I got -- I have submitted an internal request to have the reccomended steps for an upgrade to include a system restart to ensure that this does not happen. In the meantime I would suggest that allowances be made to ensure that a restart is able to be performed after an upgrade to avoid future occurances of this error

-Sumeet.

[Mildur]

Hi Sumeet,

My understanding from the case notes is that this is a one-time issue occurring right after the upgrade. Are you saying that this issue persists even after reboots of the upgraded server?

If it’s indeed a one-time occurrence, I believe the suggested one-time reboot right after the backup server upgrade should be sufficient for now. If not, I would like to understand why such a reboot may not be advisable.

However, if it's happening multiple times in the same environment after the update, we need to identify the root cause. I can ask the next tier in our support team to take a second look at the case.

Best,
Fabian

[sumeet]

Hi Fabian,

After upgrade, I usually start one of the smaller jobs to see if it is progressing well and there are green ticks for few mailboxes or onedrive.

In this scenario, after the upgrade, I created a new temp job for a specific mailbox (a different case for which support asked me to do these steps), ran that job, it failed, so informed support that the latest patch did not resolve the issue (again different case)

Later in the night, while working on something different, I checked this env and saw the backups had failed.
When the issue occured, to resolve it, I did try restarting the services, but the issue occurred even after that.
The same error happened when the jobs were started manually. I did not reboot the server though (from what I remember).
I just gave up and went to sleep and then the retries automatically ran fine (all of this is in the case notes).

Post that have not seen this occur again.

What I need to understand is do the one-time reboot be done after every upgrade? The steps that we currently perform to run a job post upgrade to verify if there are few green ticks isn't sufficient?
The reboot is not advisable if it is required for each and every patch and for long long do we continue - is it for every release going forward from here? Do you think this is ok - when we have 25+ VBM deployments?

-Sumeet.