Inactive mailboxes are a very nifty feature in Exchange Online, allowing you to preserve mailbox data indefinitely in order to meet legal requirements. And as an added bonus – they are free. So in case you are not aware of this functionality or if you are not actively using it, make sure to check out more about it for example here or here.
When legal requirement are considered however, there is usually one more vital requirement – control who has access to the relevant data. Even without any legal requirements, you will probably want to carefully consider who has access to inactive mailboxes. As they are only accessible by means of performing an eDiscovery search, either from the EAC or via the New-MailboxSearch or the Search-Mailbox cmdlets, the task of restricting access is narrowed down to creating a custom RBAC Role or Role Group and assigning it to the people you can trust. At least that’s the theory!
In practice however, there is a small hiccup. If you have a single team responsible for meeting audit and compliance needs for the entire company, you can just create a new Role Group, add the Legal Hold and the Mailbox Search roles to it, and add the corresponding users. Nice and easy! If however your company is a large enterprise, with multiple subsidiaries across the globe, or even different businesses, things might be a bit more complicated. You might have to ensure that a specific group of (inactive) mailboxes can only be accessed by say, ‘legal team A’. Plus ‘legal team B’ should be the only one that deals with managers mailboxes, and so on. “No problem”, every Exchange guru will say, “the RBAC model is flexible enough to cover such scenarios as well”. “Just create a new management scope that includes only those specific mailbox and create a role assignment with it”. Well, here’s the catch: the only *supported* way of doing this is via DG membership. Quoting from the TechNet documentation:
For In-Place eDiscovery, the only property on a user mailbox that you can use to create a recipient filter for a custom scope is distribution group membership (the actual property name is MemberOfGroup). If you use other properties, such as CustomAttributeN, Department, or PostalCode, the search fails when it’s run by a member of the role group that’s assigned the custom scope.
As previously stated, you can only use group membership as the recipient filter to create a custom recipient filter scope that is intended to be used for eDiscovery. Any other recipient properties can’t be used to create a custom scope for eDiscovery searches. Note that membership in a dynamic distribution group can’t be used either.
How is this a problem? Well, when a mailbox is marked as inactive one, it is removed from all distribution groups. Moreover, the mailbox is not visible for any of the management cmdlets, so you cannot just add it back as a member of a DG. Pretty much the only things you can do is to list the inactive mailboxes and their attributes, perform an eDiscovery search on them and create/remove holds. Bad luck, eh?
Well, the situation is not that desperate actually. There is a reason I emphasized on the word *supported* above. Management scope based on DG membership is actually the only scope for which ALL the eDiscovery related functionality will work: you will be able to ESTIMATE the results, PREVIEW them, COPY them to a Discovery mailbox or EXPORT them via the EAC tool. If you are OK with sacrificing one or more of these functions, you can use scopes based on other attributes as well. For example, you can prepend “INACTIVE” to the display name of every mailbox just prior to making it inactive and use a management scope such as: ((RecipientType -eq ‘UserMailbox’) -and (DisplayName -like ‘inactive*’))}. You will lose the Preview results functionality, but let’s be honest, who needs that? In order to be able to copy the results, your Discovery mailbox needs to be included in the scope, but that can easily be arranged by changing its display name to say, “Inactive Discovery Mailbox”.
Another attribute you can use with almost issues is the EmailAddresses one. It’s very convenient for cases where you need to filter out mailboxes based on domain, as chances are they will either have a primary or secondary alias for that domain. Again, make sure the Discovery mailbox falls into the management scope. Examples of filters that do not work (i.e. break important functionality) include: filters based on CustomAttributeXX (COPY results will fail with error ‘Property ‘CustomAttributeXX’ is not present on object ‘mailbox”); filters based on the WindowsEmailAddress (which is a real shame, as this attribute supports -like filters, unlike the PrimarySMTPaddress one); etc.
So, as not entirely *supported*, custom management scopes based on attributes other than DG membership can work for you, at least in some scenarios. Including inactive mailboxes in them however is tricky. In my opinion, the Exchange PG should really come up with a suitable method to handle those cases, and in general, provide a better filtering/scoping options that will allow us to include for example all mailboxes that are under any type of hold. Until then, we will have to ‘hack’ our way around the RBAC controls and pray for the best.
As an end note, I should mention two other scenarios. First of all, if you want an active/inactive split, yno ou can still use the DG membership criteria, but with the -not clause. As inactive mailboxes cannot be a member of any DG, you can create a DG and add all active mailboxes to it, then create a (*supported*) management scope against any other mailbox that is not a member of that DG. Lastly, you can always rely on Exclusive management scopes. For me at least, going that route is a bit of overkill, as you will have to inadvertently create several new roles or role groups in order to make sure that all the relevant administrative tasks can still be performed against the ‘exclusive’ mailboxes, as well as to restrict the eDiscovery functionality. But if your organization is already using exclusive scopes, they certainly offer a way out of this mess.