Here is the problem description:
A migration of user, group, contact, etc. took place by migrating these objects with ADMT 3.0 from one Forest (W2K03 Native) to a new Forest (also W2K03 Native), including SidHistory.
Directly after that, the mailboxes of the users were migrated from Exchange 2003 in the old Forest to Exchange 2007 in the new Forest using the Move-Mailbox CmdLet.
Everything seemed fine.... until an admin tried to remove some mailbox permissions from a mailbox using the Remove-Mailboxpermission CmdLet. He got the following error message:
"Remove-MailboxPermission : Cannot remove ACE on object "CN=Migrated Mailbox
Hmmm... when looking at the permissions on the migrated mailbox (Get-Mailboxpermission) it clearly stated that the user that was specified in the Remove-Mailboxpermission CmdLet has rights. The user was displayed in the following format: New Domain
First we thought a type-o was made or someting in the CmLets, but after some investigation all seemed to be fine with that. So what was happening here then?
The Solution:
What is happening here is the following. The name that is displayed when doing a Get-Mailboxpermission is actually not correct. The reason why it states "New Domain
When performing the Get-Mailboxpermission, Exchange translates this OLD Domain Sid to the "NEW Domain\Username" based on the SidHistory value in AD of the migrated user.
To test this we removed the SidHistory of the migrated user in the NEW Domain. Because at that moment the Trust between the Forests was still active, when doing a Get-Mailboxpermission you would now see the permissions in the form of "OLD Domain\Username"
Now when performing the Remove-Mailboxpermission on the mailbox for the same user based on the syntax of "OLD Domain
Because removing SidHistory could have a big impact, a call was logged with MS. After sending a lot of info about this to MS we ended up in a conference call with Redmond discussing this issue. Basically MS told us that this is by design, and if you would migrate between Forests using SidHistory, you would first need to "clean up" all mailbox permissions before doing a Move-Mailbox....... right.
To me a simple option to just add another parameter to the Move-Mailbox Cmdlet that would enable you to just choose if you want to translate the mailboxpermissions to the
Basically the only option to solve this issue after a migration, is to clean up SidHistory. Yes, I know, you should always do this to finish a migration clean. In small migrations this is maybe not a real issue, but in large scale, phased migrations this in general is an issue. Maybe not after all objects have been migrated, but you still have that time in between the start of the migration and the end, in which you will not be able to remove mailbox permissions. A not so nice alternative is to grant explicit Deny permissions to the user if the user should not have rights on the mailbox at all anymore. But if you just want to change the permissions, you will not be able to.
Wim.
Posts
