Recently I was working on getting Exchange Online Archiving configured for a client in a hybrid Exchange 2013 scenario. There are a lot of moving parts in a hybrid configuration and I was pleased with how things progressed. I created a cloud-based archive for a few users and everything seemed to be going well. Then I tried creating an online archive for a member of the IT team and immediately ran into an issue. The archive mailbox was created in Exchange Online and the user could see it in Outlook, but the retention policies were not kicking in and their archive said that it was in a pending state in the EAC. The archive also did not appear in OWA. The fix was relatively simple (as most fixes are) but the process of getting there was rather complicated.
Keep reading past the break for more information...
When a cloud-based archive is created, a request is sent to the Exchange Online instance to create a new archive mailbox for the mail user. This provisioning process can take two or more hours for the actual mailbox to be created. If you'd like to check the status, connect to Exchange Online via PowerShell and run Get-MailUser -identity username | fl *archive*. The output will include the archive GUID and status. If the archive mailbox has not yet been created, the GUID will be all 0's and the status will be None. When the archive has been provisioned the GUID is populated and the status changes to Active. This attribute will be synced back down to the on-premises AD environment through rich coexistence in DirSync. The on-premises AD environment has two relevant archive attributes, ArchiveStatus and ArchiveState. ArchiveStatus is a writable attribute. ArchiveState is written programmatically based on other attributes including ArchiveStatus. When you provision a cloud-based archive, the ArchiveState goes into HostedPending (displayed as cloud-based archive pending in the GUI) and it waits for the ArchiveStatus attribute to be updated.
The DirSync process has a security group called MSOL_AD_Sync_RichCoexistence and a user called MSOL_AD_Sync. The group is granted access within AD to edit a set of attributes which includes msExchArchiveStatus. If a particular user has permission inheritance turned off, then the group will not get access to the attributes. When you go to provision that user for Exchange Online features, DirSync will not be able to update the relevant attributes.
What types of users would have inheritance turned off? Any current or former member of an AD Protected Group will. And notice that I included former members. When a user is added to an AD Protected Group, their AD attribute admincount is set to 1. When the SDPROP process runs it turns off inheritance and sets the security of the user to match that of adminSDHolder. You can read all the grimy details here. The article also details how to tell if a user or group is a member of a protected group. It uses the adfind.exe utility, but you can also use a custom LDAP query from within ADUC. For users it is (objectcategory=person)(samaccountname=*)(admincount=1) and for groups it is (objectcategory=group)(admincount=1). ADUC will add the relevant &'s in for you. If you remove a user or group from a protected group, you will need to set the admincount attribute to 0 and re-enable permission inheritance. This can also be done through ADUC - you will need to enable advanced features - by using the Attribute Editor and Security tabs in the user properties.
If you run into this situation the solution is simple:
- Remove the user from the protected groups
- Edit the admincount attribute and permission inheritance
- Disable and enable the archive
When an archive is disabled the GUID is written to a property called DisabledArchiveGuid. When archiving is enabled, Exchange checks to see if this GUID points to an existing archive mailbox. If it finds an existing archive mailbox, it will reconnect the archive. Exchange Online keeps disconnected archives for 30 days by default, so even if the end user has manually moved data into the archive, it will not be lost by disconnecting and reconnecting. The intent of the process is to kick off the DirSync that updates the attribute in the on-premises AD.
If you cannot remove the user from a protected group, then you will need to add the permissions manually following this
MS kb article. It is important to note that a standard user should never be a member of a protected group, and this is likely to cause headaches down the road with Exchange and other applications. So if you think a user needs to be in a protected group, you should have a really good justification and prepare yourself for future difficulties.
Labels: Active Directory, archiving, cloud-based archives, DirSync, exchange 2010, Exchange 2013, Exchange hybrid, exchange online, office 365