cancel
Showing results for 
Search instead for 
Did you mean: 

Migrating Mailboxes X Forest - not moving AD object, or EV Data

wandarah
Level 5
Partner Accredited

Hi Folks, 

 

Huge migration project. 

Moving mailboxes from mulitple exchange environments, to an Exchange 2010 in a new domain using linked-mailboxes. However we want the original user in Domain A, to retain permissions on thier archive. At the moment, the migration of the mailbox works fine - but only the 'new' user in Domain B (i.e the disabled linked mailbox AD user) gets permissions - after a mailbox synch. The permissions to the legacy domain account have to be manually added. 

 

Synchinmigrationmode is on, etc. 

 

Is there anyway to ensure that the permissions for the legacy domain account, are not replaced by those of the 'new' domain account once a mailbox synch is complete?

 

Scripting per user permissions would be a nightmare, besides, EVPM doesn't like creating MAPI sessions through a CAS server (yes, I have added default DS server reg edit). 

 

All suggestions gladly welcomed! Can't find much from Symantec for Linked Mailboxes at all. 

1 ACCEPTED SOLUTION

Accepted Solutions

KarlW
Level 6
Employee

Using ADSIEdit.msc validate that the new user account in Domain B contains the property msExchMasterAccountSid (this should contain the SID of the linked account in Domain A).   If this is present then EV should be synchronizing this to the Archive permissions.

If it does please can you run a synchronize against a user where the permissions are not correct and trace AgentClientBroker.exe and post here.  If during synchronization we come across an associated account without the required permissions it gets logged in the trace.

Additionally run get-mailboxpermission for the user on the Exchange server and validate the associated account has full mailbox access (FullAccess) as this is what EV requires.

Regards

Karl

View solution in original post

7 REPLIES 7

KarlW
Level 6
Employee

Using ADSIEdit.msc validate that the new user account in Domain B contains the property msExchMasterAccountSid (this should contain the SID of the linked account in Domain A).   If this is present then EV should be synchronizing this to the Archive permissions.

If it does please can you run a synchronize against a user where the permissions are not correct and trace AgentClientBroker.exe and post here.  If during synchronization we come across an associated account without the required permissions it gets logged in the trace.

Additionally run get-mailboxpermission for the user on the Exchange server and validate the associated account has full mailbox access (FullAccess) as this is what EV requires.

Regards

Karl

wandarah
Level 5
Partner Accredited

Thanks Karl. 

 

We've now got the permissions to 'migrate' with the mailbox - and in EV permissions for both domain users are correct. Users can open archived items via Outlook - but:

Unfortunately - the user cannot access Archive Explorer - it gets to the actual page, but is unable to populate the windows. 

 

Any ideas?

KarlW
Level 6
Employee

Hi - I'm not sure what you mean by populate any windows?  Do you mean you get an empty frame of the left (tree view pane) and on the right (message view pane) with the divider in the middle?  AE is pretty heavy at caching and I believe Storage/Indexing has a permissions cache so to rule these issues out restart the Storage and Indexing service, then clear the browser cache and try again.

Have you tried search.asp to validate the user can search the archives that way?

Thanks

Karl

wandarah
Level 5
Partner Accredited

Hi Karl, 


Sorry yes - that is what I meant. 

 

The issue for one test user now seems to be resolved. 

 

Ironically EV now isn't letting us enable more mailboxes, go figure. 

mooncalf
Not applicable
Partner

What was the solution?

 

thanks

wandarah
Level 5
Partner Accredited

The solution was, as Karl implied - making sure the SID moves when migrating the mailbox to a new exchange server in a new forest. It seems to work pretty flawlessly - we had actually come up with the idea ourselves and Karl validated it. As far as I can tell, you dont even need to disable the user - just migrate the mailbox, and re-provision on the other side. 

 

This isn't covered in *any* documentation that I can find, and what I can find that is relevant makes the process sound very daunting indeed. Symantec Support were also unsure one way or the other when I spoke to them - and suggested following the a doc which talks about editing SQL tables, etc, or scripting the permissions manually. 

wandarah
Level 5
Partner Accredited

Actually, I say 'we' - but it wasn't. It was client resources that thought of it. Though it does seem exceptionally obvious from an Exchange perspective now, it's always hard to be sure if EV will like it (people keep trying to sell me Quest). 

It's such a simple way to to do it - I might be missing it, but this is not documented anywhere....it is *so* simple, it should be!