The content below is taken from the original (Bringing Compliance to Office 365 Groups), to continue reading please visit the site. Remember to respect the Author & Copyright.
Retention Policies for All
On April 6, Microsoft announced that “You are now able to manage group content produced by setting up retention policies to keep what you want and get rid of what you don’t want. Admins can now create Office 365 Groups retention policies that apply to the group’s shared inbox and files in one step using the Office 365 Security and Compliance Center.” Sounds good. But what does this mean in practical terms?
In my last article, I explained how Office 365 classification labels and retention policies function inside the new Office 365 data governance framework. In this, I explore how to apply retention policies to Office 365 Groups.
Keeping Office 365 Groups Compliant
Is compliance important for Groups? The answer is obviously yes, especially when organizations use Groups as the basis for teams to collaborate using conversations, OneNote, and documents. Valuable information that needs to be controlled by an organization can swiftly accumulate inside Groups and that information is no less important than what exists inside mailboxes and public folders.
My previous article covers the basic of Office 365 classification labels and retention policies. You can use both features with Office 365 Groups. Group owners (but not members) can use classification labels to mark specific conversations for special processing. Only OWA shows classification labels for conversations in the group mailbox today. Outlook and the Outlook Groups mobile app both need refreshes before labels show up in their interfaces.
However, all group members can assign classification labels to files in the group document library and any group member can overwrite a label previously assigned by another group member, except if that label is a formal record (in which case only the site collection administrator can update the item). The reasons why labels behave differently in a group’s mailbox and document library are because of the way that Exchange retention tags and SharePoint permissions work. Although this might be confusing at times, I doubt it will cause much concern to end users.
Yammer-based groups do not support the application of classification labels to their conversations, but you can apply the labels to files in the document library.
Cleaning up Connectors
As an example of how retention policies work with Groups, we assume that you have configured an Office 365 connector to bring some information from a network data source into a group. In many cases, this information is of transient interest, so we should clean out these items after they are no longer useful. To do this, we create a retention policy to remove items after 7 days and apply the policy to the relevant groups.
Go to the Data governance section of the Security and Compliance Center, select Retention, and then Create. Only members of the Compliance Administrator role group for the Security and Compliance Center can create or manage retention policies. The first step is to assign a name and description (which only administrators see) to the new policy (Figure 1).
Figure 1: Retention Policy Settings (image credit: Tony Redmond)
Keep or Remove
The next step is to decide whether the policy is going to keep content or remove it from Office 365 (Figure 2). A delete action in a retention policy is the equivalent of “delete and allow recovery” in an Exchange retention tag. Items are not permanently removed and can be recovered later if necessary.
In either case, we must know how long the retention period lasts and how to decide when the period expires. You can keep content forever, but it is more usual to set a period like five years. To remove content, you must tell Office 365 how to calculate the age of the content. For mail messages, this is when they are created, but for documents and other items, you can choose creation or modification date.
Figure 2: Should the policy remove or keep content? (image credit: Tony Redmond)
At the bottom of Figure 2, you see the choice to use advanced retention settings. This means that you want to create a policy to find content based on a KQL query or DLP sensitive data types. For instance, you might want to find all content that has the keyword “Project Moonshot” and keep that for ten years. Or you could find all content that has sensitive data covered by the U.S. Patriot Act (credit cards, bank account numbers, taxpayer identification numbers, and social security numbers) and make sure that these items are removed from Office 365 after five years.
Be Careful with Settings
One of the interesting aspects of creating Office 365 retention policies and classification labels is that many of the settings that control how the policy functions cannot be changed after creation. You can alter the retention period for a policy, add new locations to its scope, and alter the KQL query to find content for the policy to apply. However, you cannot change its basic operation. For instance, you cannot change a policy that keeps content into one that simply removes content.
The logic is that users expect consistency in how their data is processing. If you can change the fundamental operation of how retention works inside a tenant, users will not know whether their data will be kept or removed or when this will happen. Cue fear, doubt, and uncertainty.
For this reason, it is wise to take time to chart out how retention will work before across the tenant you create any policies. Fools rush to implement retention without thought.
Selecting Locations
Next, we set the scope for the policy (Figure 3). You can decide to apply to all supported locations across Office 365 (an org-wide policy) or you can select specific locations (a non-org wide policy). You can have up to 10 org-wide and 1,000 non-org wide retention policies in a tenant. In general, you should simplify retention whenever possible by limiting the number of active policies.
In this case, we know that only a subset of groups that are configured with the kind of connectors that import data that we might want to clean up, so we opt for specific locations.
Figure 3: Deciding the scope for a retention policy (image credit: Tony Redmond)
When you choose specific locations (Figure 4), you can select which Office 365 workloads that you want to process plus decide to include or exclude sub-locations. Unless you really want to remove every piece of content in every location a week after it is created, it would not make sense to apply a general “Remove everything after 7 days” policy across Office 365. We know that we only want to apply the policy to a small set of selected Office 365 Groups, so we can focus on that workload. However, you can apply the same policy to selected parts of multiple locations, like the single SharePoint site and the 2 groups selected here.
Figure 4: Many Office 365 locations to choose from (image credit: Tony Redmond)
Click Choose groups to select the groups to process and expose the dialog shown in Figure 5. As you can see, you can search to find the groups to include in the policy. You can add groups that use Yammer to store their conversations. In this case, the conversations are ignored because Yammer does not yet support the data governance framework, but the documents in the group document library are covered.
Figure 5: Selecting specific groups for the policy (image credit: Tony Redmond)
When complete, click Choose to return to the Choose Locations screen and then Next to move to complete the policy.
No Locking Without Thinking
Before reviewing the policy settings (Figure 6), you have the choice to turn on preservation lock. Do not turn on preservation lock without very good reason. If you do, you will only be able to make limited changes to the policy in the future (add new locations to its scope) and the policy cannot be disabled. In addition, any content that comes within the scope of the policy cannot be updated or removed while the policy is in force.
Figure 6: Should the policy lock data? (image credit: Tony Redmond)
Preservation locks exist for a good reason – to ensure that information needed to satisfy certain regulatory requirements cannot be interfered with by anyone, including administrators, for the duration of the policy. However, most tenants do not need preservation lock and indeed, locking data down complicates situations like tenant merges and splits or, should that happen, if you ever want to leave Office 365 and move your data to another service.
Resist the temptation to enable the lock and move quickly to the last step in creating a retention policy (Figure 7). If you are happy with the settings, click Create this policy.
Figure 7: Confirming the policy settings (image credit: Tony Redmond)
Making Groups Aware of Policies
After saving the new policy, Office 365 makes the individual workloads aware that the policy exists. Each workload then uses its own mechanism to distribute and enforce the policy settings on the locations included in the policy. Because a retention policy assigned to a group applies to both the mailbox and the group’s team site, both Exchange and SharePoint must acknowledge and implement the policy.
A retention policy applies to all folders in the group mailbox, so it will clean out the Sent Items folder and Calendar folder too. And of course, because SharePoint implements the same policy for the group document library, the policy affects documents stored there. Unfortunately, tenants do not have any way of knowing when the background jobs run to process SharePoint content belonging to a group.
For group mailboxes, the Managed Folder Assistant (MFA) applies the policy and then processes the mailboxes. Because the MFA runs on a seven-day workcycle, it can take up to a week before a new retention policy is effective. The only way you know that the policy works is by checking the conversations in the mailbox. If any conversations are still present after 7 days, you know that something is not right.
Another way of checking is to use the Export-MailboxDiagnosticLogs cmdlet to examine the properties updated by the MFA when it processes a mailbox. The cmdlet outputs the properties in XML format, so some formatting is needed to make the information more legible. In this case, the ElcLastRunDeletedFromRootItemCount property tells us that MFA removed 12 items in the last run. In these examples, “Office365TenantServiceHealth” is the alias for the Office 365 Group we want to process.
[PS] C:\> $Log = Export-MailboxDiagnosticLogs -Identity Office365TenantServiceHealth -ExtendedProperties
[PS] C:\> $xml = [xml]($Log.MailboxLog)
[PS] C:\> $xml.Properties.MailboxTable.Property | ? {$_.Name -like "ELC*"}
Name Value
---- -----
ElcLastRunTotalProcessingTime 637
ElcLastRunSubAssistantProcessingTime 140
ElcLastRunUpdatedFolderCount 0
ElcLastRunTaggedFolderCount 0
ElcLastRunUpdatedItemCount 0
ElcLastRunTaggedWithArchiveItemCount 0
ElcLastRunTaggedWithExpiryItemCount 0
ElcLastRunDeletedFromRootItemCount 12
ElcLastRunDeletedFromDumpsterItemCount 0
ElcLastRunArchivedFromRootItemCount 0
ElcLastRunArchivedFromDumpsterItemCount 0
ELCLastSuccessTimestamp 10/04/2017 22:26:55
If necessary, you can run the Start-ManagedFolderAssistant to force MFA to process the retention settings for a group. For example:
[PS] C:\> Start-ManagedFolderAssistant -Identity Office365TenantServiceHealth
If all goes well, MFA refreshes the retention settings for the mailbox and new tags and labels are available to users. Sometimes kicking the MFA convinces it to do the right thing and process a mailbox, sometimes it does not. The problem is that Exchange Online throttles background processing and does not allow mailbox assistants like MFA to run on demand. Microsoft wants to smoothen server load to reduce the risk that background processing interferes with the ability to be responsive to clients, which is why a seven-day workcycle exists for mailbox assistants. Telling MFA to process a mailbox will have an effect if MFA considers that it is reasonable to go ahead because it has not processed the mailbox recently. Running Start-ManagedFolderAssistant several times to convince MFA to start processing is a fruitless exercise.
Recovering Deleted Content
You can recover items removed from the SharePoint document library by accessing the site recycle bin. However, because OWA does not support access to the Recoverable Items structure for a group mailbox, if a retention policy removes some items from a group mailbox that you need, you must use another method to recover the items before they expire from Recoverable Items 14 days after their deletion. If you know enough about the items to find them (for instance, they all include a common phrase), you can use a content search to find the items and then export them to a PST. At least the items are then available, even if you cannot restore them direct to the group mailbox.
The New Compliance Status for Groups
Bringing Office 365 Groups into compliance is a major step forward for many tenants. Microsoft is removing obstacles to deployment with recent progress like the ability to recover deleted groups and now support for retention policies. It is all good news.
I have criticized Microsoft for their failure to implement compliance for Groups in the past and it is good to see them fix the problem now. Maybe so much so that I might even forgive the occasional tactical error in the evolving story of Office 365 Groups.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle
The post Bringing Compliance to Office 365 Groups appeared first on Petri.
