Forum Discussion

wandarah's avatar
wandarah
Level 5
15 years ago
Solved

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

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. 

Best Practice
Configuring
Documentation
Enterprise Vault
Information Governance
Tip-How to
Troubleshooting
  • KarlW's avatar
    KarlW
    15 years ago

    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

7 Replies

Sort By
  • KarlW's avatar
    KarlW
    Level 6
    15 years ago

    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's avatar
    wandarah
    Level 5
    15 years ago

    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's avatar
    KarlW
    Level 6
    15 years ago

    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's avatar
    wandarah
    Level 5
    15 years ago

    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. 

  • wandarah's avatar
    wandarah
    Level 5
    15 years ago

    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's avatar
    wandarah
    Level 5
    15 years ago

    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!