Exchange archive folders loosing permissions

[Marcde]

Hello, 

a customer is having the problem that sometimes some of the exchange archives are loosing the inherited folder permissions from exchange. Synchronization takes place at 12 am and 12 pm. From what I understand the folder hierarchy and permissions should be synchronized on an exchange mailbox archiving task Run which is scheduled between 3 and 7 am. Am I right here? 

So the normal synchronization at 12 am and 12 pm should not be respsonsible for the loose of the permissions. 

We tried tracing the archiving task and it shows:

{CFolderHelper::GetFolderSettings:#1192} Synchronising folder permissions for folder [Posteingang]

....

{CSynchHelper::SynchroniseFolderPermissions:#1054} (Posteingang) - add permissions to dacl

....

CSynchHelper::APTEVD(Posteingang) - Adding SID [<SID>] to Security Descriptor, Grant Mask = 0x0000007F, Deny Mask = 0x0000000

....

{CSynchHelper::SynchroniseFolderPermissions:#1094} (Posteingang) - Set the dacl in the security descriptor

{CSynchHelper::SynchroniseFolderPermissions:#1106} (Posteingang) - Calling UpdateArchive as it has changed from the copy stored in the database

Does this mean that the archiving tasks detects that permissions have changed? 

If this is the case - What could have changed the permissions on the folders in the archive? Nothing has changed on exchange side. 

Is this a common problem or does anyone know how to investigate further on this? 

Enterprise Vault version is 11.0.1.3474

Regards

Marc 

[Ben_Watts]

You are right that the perms are synced during the Archiving run but you can also sync perms on a manual Sync of the mailbox via the properties of the Task - Sync tab.

How often do the perms get stripped?

Is it all mailboxes when it does happen or just some?

Do you have a NLB in the mix anywhere? (Reason I ask is that it has been seen where NLB have helped to cause issues like this in the past at times)

[Marcde]

It's varying. Sometimes there weren't any permission problems for days and sometimes it was one after the other day. 

Customer uses a single multirole exchange 2010 system without a nlb. 

[Ben_Watts · Accepted solution]

I would hazard a guess and say that it is connectivity being broken during the operation somewhere along the line, being that unpredictable points along that path to me.

Try hardcoding a GC into the mix on the EV Server to see if that helps.

[Marcde]

I've checked the environment again. GC is not hardcoded in VAC and DS Server or Closest GC are not set in the registry. 

I will give it a try and enter the GC in der Vault Admin Console. 

[Marcde]

Hello Ben,

I just want to give you an update on this. Since hardcoding the gc in vac everything is fine.

[Marcde]

Hello Ben, 

after some weeks without problems the error now reoccured. 

Do you have further ideas or other troubleshooting steps? 

[Marcde · Accepted solution]

Just to close this. 

Not sure which step exactly solved this but we hardcoded the gc in the vac as mentioned by Ben and entered the exchange 2013 (my fault, I thought it was 2010) connection point.

The problem reoccured a few weeks after we entered the gc so we added the exchange 2013 connection point also. 

We made these last changes about 3 months ago and it didn't reoccur. 

[JimmyNeutron]

What does your Mailbox policy - Advanced setting - Inherited Permissions show? Is it set to inherit permissions from Exchange?

You also might want to start off by using PermissionBrowser.exe to begin analysing the permissions inherited on all your archvies.

[Ben_Watts]

I would mark this/your answer as the solution personally, sounds like it was a mixture of things but basically down to communication to the GC at the end of the day.

Thanks for updating us Marc, could be handy for others in the future.

[Marcde]

I don't have access to the environment any longer.

We used PermissionBrowser to analyze this. 

As I said I think this one is solved. 

[JimmyNeutron]

Kindly mark the solution