Overview
One of the things which Archive Shuttle must do for a migration is to determine the owner of a mailbox archive. This article explains how this takes place.
Details
Archive Shuttle takes the owner information of a mailbox archive from the Auto Security Descriptor field within the Enterprise Vault Directory database. The first entry for an archive will be the owner. Take the following three examples:
Simple1
-> Bill usage to: somedomain\simple1
-> Permissions tab: somedomain\simple with inherited read, write and delete permissions
Archive Shuttle will see the owner of this archive as ‘simple1’.
Simple 2
-> Bill usage to: somedomain\simple2
-> Manually grant an additional user read, and delete permissions on the archive
-> Permissions tab: somedomain\simple2 with inherited read, write and delete permissions. somedomain\someotheruser with manually set read, and delete permissions
Archive Shuttle will see the owner of this archive as ‘simple2’.
Simple 3
-> Bill usage to: somedomain\simple3
-> Grant full mailbox access via Exchange Management Console or Exchange Management Shell
-> Permissions tab: somedomain\simple3 with inherited read, write and delete permissions. somedomain\someotheruser also with inherited read, write and delete permissions
Archive Shuttle will see the owner of this archive as ‘simple3’.
Note: The order which the archives are listed in the permissions tab in Enterprise Vault does not reflect the order that the accounts are described in the Auto Security Descriptor field. The permissions tab shows the archive permissions in alphabetical order.
In Detail
Archive Shuttle resolves the “Owner” of an Archive as follows:
In the EnterpriseVaultDirectory Database the following SQL is used:
select ADMbxDN, LegacyMbxDN from ExchangeMailboxEntry where DefaultVaultId=@VAULTID
Archive Shuttle then does a lookup for the ADMbxDN in Active Directory to get the SID:
LDAP Query:   (ADMbxDN=<DN>)
If we do not find the AD object the Archive will be marked as Ownerless and move next option.
Archive Shuttle then does a lookup for the LegacyMbxDN in Active Directory to get the SID:
LDAP Query:   (LegacyMbxDN=<DN>)
If we do not find the AD object the Archive will be marked as Ownerless and move next option.
We then compare the SID’s we got from ADMbxDN and from LegacyMbxDN, if both of them match, we have an Owner.
If they do not match will be marked as Ownerless and move next option.
If we do not find an entry in ExchangeMailboxEntry, we resolve using the BillingOwner or the AutoSecurityDesc:
select SID from Root inner join trustee on OwningTrusteeIdentity = TrusteeIdentity where VaultEntryId=@ARCHIVEID
Note about OwnerUserSID versus SID:
As for OwnerUserSid versus SID fields in the EVArchive Table on in the Archive Shuttle Directory Database:
–          SID is always filled out with the SID which is retrieved from the above steps
–          OwnerUserSid has a foreign key constraint on the [User] Table. So Archive Shuttle only fill this out if the SID obtained from EV is actually contained in the Archive Shuttle Directory Database (i.e. has been synced from AD)
The last step is UserSidHistory table
In this table is stored Sid history for each user when they were migrated from AD1 to AD2, this SidHistory attribute is part of AD so we´re collecting this from AD directly.
Example
User1 was migrated from AD1 to AD2, SidHistory attribute was populated to AD and when AD sync is performed table UserSidHistory is populated as well. User1 was migrated to another AD so it´s supposed to be the same user and therefore in owner resolution logic is UserSidHistory as the last step. Sometimes even migrated user from AD1 to AD2 is not supposed to be the same user as samAccountNames are different in both ADs. In this case, owner resolution will take AD2 user as the owner which could be wrong in some special situations.
Workaround
As a workaround you can:

  • remove SidHistory parameter from AD and let AS to synchronize AD entries (recommended option), run EV collection to assign correct users in ContainerToUser table
  • use the SQL to assign HistoryUserSid instead of actual Sid, example of such script is below:
--udpate ContainerToUser, take UserHistorySid and assign to Container type 1 (EV containers only)
SET NOCOUNT OFF;
declare @sid varchar(128)
DECLARE ITEM_CURSOR CURSOR FOR
Select UserSid From ContainerToUser a
inner join [dbo].[Container] b on a.ContainerId = b.ContainerId and ContainerTypeId = 1
OPEN ITEM_CURSOR;
FETCH NEXT FROM ITEM_CURSOR INTO @sid
WHILE @@FETCH_STATUS = 0
BEGIN
update x set UserSid = (SELECT UserHistorySid FROM [dbo].[UserSidHistory] where UserSid = @sid)
from [dbo].[ContainerToUser] x
where UserSid = @sid
print 'Updated containerid ' + @sid;
FETCH NEXT FROM ITEM_CURSOR INTO @sid;
END;
CLOSE ITEM_CURSOR;
DEALLOCATE ITEM_CURSOR;
  • remove entries from UserSidHistory table, disable AD sync to avoid entries are coming back with next AD sync, run EV collection to assign correct users in ContainerToUser table

Note:
Re-using of sAMAccountsName/MbxNTUser or MbxDisplayName in one domain can cause an issue with EV Archive assigning process.

Print Friendly, PDF & Email