A while back we came across a nice "hidden feature" of Exchange that occurs after migrating mailboxes cross Forest. Again, its been a while, but I thought I would blog about it anyway.
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
,OU=....." for account "New Domain\migrated user" because it is not present"
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\Username.
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\Username" is SidHistory. Under the hood, the "OLD Domain\Username" still has permissions. To be more specific, the permissions are still pointing to the OLD Domain Sid of the user.
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". If the Trust would be gone, this would state the old Domain Sid of the user because it would not be able to resolve the account name anymore.
Now when performing the Remove-Mailboxpermission on the mailbox for the same user based on the syntax of "OLD Domain\Username", it worked without issues. Without a trust you could even use the old Domain Sid of the user to remove the permissions, same thing.
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 value or not, could just do it. But MS thought differently.....
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
