locked
Mailbox permissions when disabled mailbox account (resource forest) is enabled/becomes active/primary RRS feed

  • Question

  •  

    We're currently running a resource forest with Exchange 2003 installed - the mailboxes were migrated from another forest which is still used for logon and mailbox access, but mailboxes themselves are in a new forest (with mailbox accounts being disabled and Associated External Account set to accounts forest entry).

    At some point in the future the resource forest should become primary/active, so accounts will need to be enabled and used for logon and mailbox access. Looking at this now, I see an issue with mailbox permissions and delegates - these all currently resolve to accounts forest, and I don't see them automagically updating to resource forest entries as these are enabled.

    Has anyone gone through a similar exercise - we are limited in using ADMT for sIDHistory due to the requirement to have admin rights in the source domain, and as far as I can tell all mailbox permissions and delegates will become invalid once resource forest accounts are activated (surely this can't be right, resource forest being a supported configuration?).

    Thanks for any help/ideas,

    Petar

    Tuesday, February 22, 2011 3:04 PM

Answers

  • This corresponds to our experience in our environment. We have a quite large Exchange Resource Forest containing some 120 000+ mailboxes. During our consolidation migration collapsing several domains + exchange forests to one we had one domain where the mailboxes were migrated before the AD account. We ended up in the same dreaded situation like you are in now.

    We could't find a solution ourselves so we asked Microsoft for advice and were told that this wasn't a supported method. So as far as I know it isn't supported by Microsoft to first migrate mailboxes and then the AD account.

    Our solution was to re-ACL the whole lot with the help of our security team.


    Jesper Bernle | Blog: http://xchangeserver.wordpress.com
    • Proposed as answer by Gavin-Zhang Friday, February 25, 2011 7:05 AM
    • Marked as answer by petargolubovic Friday, February 25, 2011 10:43 AM
    Wednesday, February 23, 2011 10:03 AM

All replies

  • Mailbox permissions are preserved within the mailbox. You will have to use ADMT to migrate the accounts from accounts forest to the resource forest. I haven't worked with resource forests before, but have done Forest migrations. Mailbox permissions, delegates, etc are preserved when doing forest migrations, I don't see resource forest being any different. The mailbox has the permissions, as long as it can backlink the SIDS to a valid account in the resource forest will be preserved so you will have to use ADMT to migrate.

    You should be able to a test with a single account\mailbox.


    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
    Tuesday, February 22, 2011 10:30 PM
  •  

    Hi James,

    What you are saying is correct, except that it doesn't apply in this scenario.

    As I mentioned, ADMT is not an option due to admin rights requirements in the source domain, and mailbox permissions currently point to SID of the accounts forest. I did test this, and when resource account is enabled, the permissions are still kept as they were (using the accounts forest account), so essentially all customised permissions and delegate rights are lost.

    I'm not sure if you understood the scenario?

    Regards,

    Petar

    Wednesday, February 23, 2011 9:21 AM
  • This corresponds to our experience in our environment. We have a quite large Exchange Resource Forest containing some 120 000+ mailboxes. During our consolidation migration collapsing several domains + exchange forests to one we had one domain where the mailboxes were migrated before the AD account. We ended up in the same dreaded situation like you are in now.

    We could't find a solution ourselves so we asked Microsoft for advice and were told that this wasn't a supported method. So as far as I know it isn't supported by Microsoft to first migrate mailboxes and then the AD account.

    Our solution was to re-ACL the whole lot with the help of our security team.


    Jesper Bernle | Blog: http://xchangeserver.wordpress.com
    • Proposed as answer by Gavin-Zhang Friday, February 25, 2011 7:05 AM
    • Marked as answer by petargolubovic Friday, February 25, 2011 10:43 AM
    Wednesday, February 23, 2011 10:03 AM
  •  

    Many thanks Jesper - that unfortunatelly sounds like what we'll have to do as well (re-ACL all Mbxs and PFs).

    How did you handle re-ACLing in practice - was that done all at once/bing bang style, or staggered? We'd hope to be able to stagger it, but I see an issue with that since permissions will need to be updated for each enabled account on all other mailboxes, which would mean many (painful) re-runs of re-ACL process to get all permissions right at the time of account enablement. Any info on your experience 'from the trenches' much appreciated!

    Best regards,

    Petar

    Wednesday, February 23, 2011 11:53 AM
  • Ahh sorry misunderstood, I thought you meant "you are limited to using ADMT" meant third party software was not an option and not we cannot use ADMT. Your guys assessment seems right.
    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
    Wednesday, February 23, 2011 4:07 PM
  • As I said, it was the Security Team that did this re-ACLing and we are separate teams so I had no insight into this unfortunately. But from what I did manage to over hear it was a real challange so be prepared to roll up your sleeves and do some hard work.

    Good Luck to you.


    Jesper Bernle | Blog: http://xchangeserver.wordpress.com
    Thursday, February 24, 2011 8:19 AM