Managing the retention and disposal of emails in Office 365

In a recent blog post (https://thinkingrecords.co.uk/2019/02/14/managing-email-in-office-365/), James Lappin provided a good overview of the direction that Microsoft have gone with retention and disposal in Office 365.

A key point with almost anything to do with SharePoint Online (that differentiates it from on-premise) is that SharePoint Online (and its ‘personal’ end-user service, OneDrive for Business) is just one element of the Office 365 ecosystem. That is, you can no longer really regard SharePoint as a standalone service that can be managed independently of the other services you may or may not decide to use.

For example:

• Office 365 Groups (which are an Exchange object, similar to Distribution Lists and Security Groups) all have an associated SharePoint site. O365 Groups are in many way at the ‘heart’ of the Office 365 security/permission model. You cannot create an O365 Group without a SharePoint site.
• Teams in MIcrosoft Teams (yes the duplication of wording is unfortunate) create an Office 365 Group (which in turn creates a SharePoint site). Alternatively, you can create an Office 365 Group (with a SharePoint site) and link that Group to the new Team. So, Teams in Microsoft Teams have their own Team site.
• If you enable the ‘Create Site’ option in the end-user SharePoint portal, and the user selects ‘Team site’, this creates an Office 365 Group also.
• If you allow anyone to create an Office 365 Group, then any new Yammer group creates an Office 365 Groups and – yes, you got it right – a SharePoint.
• Retention policies for Exchange and SharePoint are set as ‘classification policies’ in the Office 365 Security and Compliance admin portal. This, by the way, is also where you set the new Information Security policies that have only recently appeared. They are both a type of label.

It can be quite overwhelming at first, but the key point is that you cannot regard SharePoint as an isolation application any more. However, most IT shops are pretty ‘hardened’ to the idea that the Exchange ‘box’ (the server) and the SharePoint box are managed by different teams, and one challenge in the new Office 365 world may be to convince the Exchange admins that they should be friends with the SharePoint admins AND the records team.

Backing up as a retention option

It is important to understand that IT departments often regarding ‘backing up’ as a form of retention (or ‘archiving’). Your IT department will almost always have a back-up regime for its on-premises servers.

However, you cannot (easily, cost efficiently) back up SharePoint Online or Exchange Online like you could back up your on-premises environments, but there are many vendors in the market who will offer you a solution to this.

Most IT shops consider back ups to be an archive from which they can retrieve content, a kind of alternative records retention regime. This factor may impact on any decisions that may need to be made with retention policies applied to both Exchange Online and SharePoint Online.

The problem with applying retention and disposal policies to email

It almost goes without saying that, while retention policies can be applied to Exchange Online, typically (a) the content is structured (in multiple folders) differently by every person and (b) the content is mixed together so no retention policy can normally apply to all emails in a single folder.

It is why, generally speaking, we ask users to copy emails into SharePoint (or other EDRM) containers or aggregations (document libraries, files), to keep the content in context.

But in most cases the content (the emails) still remains in Exchange too.

Challenges when applying retention and disposal actions to emails

There are several challenges for the application of records retention and disposal policies in Exchange/Outlook.

• Do you have a blanket approach to all email, disallowing the deletion of any email for say 7 years?
• Or do you apply a much shorter retention policy to all emails (say 12 months or less)? (Cue – ‘but what if I want to get my email back after 5 years’ from a user with a labyrinthine email folder structure)
• Do you rely on users to copy emails to SharePoint or other EDRM containers where they will be stored in context?

The core problem with email is that it’s personal to each user. While it may be good to be able to apply a retention policy to emails, my sense is that anything that is optional will almost always fail to be taken up.

Having a single retention policy (e.g., 7 years) applied to the email accounts of departed users may be a good option (similar to the same policy applied to the OneDrive accounts of departed users).

Another newish option is to use the new Microsoft Flow options to automatically move emails and/or attachments to SharePoint document libraries.

Every organisation is likely to be different and all options need to be considered, understood and then applied – along with the question: ‘Do we (really) need to back this up’?

Advertisements

Migrating to SharePoint Online Part 2 (implementation)

In my previous post I described what we did to prepare for the migration of our SharePoint 2013 (SP2013) environment to SharePoint Online (SPO). In this post I describe the process we undertook and the lessons we learned along the way.

By August 2017 we had around 245 SP2013 sites across seven web applications: apps (13 ‘purpose-built’ sites); intranet (1 site); ipform (an old site that was closed several years back); projects; publication (30 sites); sptest (used for testing sites); and team.

The bulk of our sites (around 210 sites split almost equally) containing most of our corporate records were in either the teams and projects web applications.

The details of our root sites were recorded in several key artefacts:

• A SharePoint Online list in our SharePoint Admin site, used for new site requests. This was always our ‘master’ listing of sites and included a range of additional metadata, including the business owner and a ‘yes/no’ if the site had been migrated or not. This was one of the first sites we migrated.
• Another SharePoint list that recorded the details of site collections and subsites.
• An Excel spreadsheet used to ‘map’ of all our root sites (one per cell_ grouped under business areas. This map provided a simple, printable visual map of all our SP2013 sites grouped by business area. We used colours to indicate when sites were migrated to SPO, providing an immediate visual reference.

Configuring and learning about Office 365 Admin and SharePoint Online (and OneDrive) admin

By August 2017 we had access to our Office 365 tenant admin environment, access to which is required to get to the SharePoint Admin portal initially (subsequently, the SharePoint Service Administrator could access it directly).

After setting up and configuring the Office 365 elements and SharePoint Online (SPO) environment, we created some initial test sites (via the Admin portal) to understand the new environment.

One of the early SPO sites was a re-created SharePoint User Group site, used to store general training and other useful information about the new environment. This site has remained our primary go-to point for all SharePoint users.

Our SharePoint developer also re-created various scripts, including scripts to automatically create and configure new sites from a request in a SharePoint Online list.

Monitoring changes in Office 365 and SharePoint Online

We learned the importance of monitoring – daily – the Office 365 message centre and also the Microsoft techcommunity site (which had been moved off a Yammer platform a year or so earlier), as well as the Microsoft Office 365 roadmap to ensure we were aware of any likely changes – many of which were introduced during the time we were migrating.

We quickly learned a few things:

• Customisation was not a friend of migration. Fortunately, almost none of our sites were customised. However, page-based content would need to be re-created.
• Any complex workflows, integration or data extraction (e.g., ETL for business intelligence purposes which needed to be re-linked) could delay migrations. As it turned out, these sites ended up at the very end of the migration process and a couple were still waiting for migration as at the date of this post.
• New ‘modern’ sites based on Office 365 Groups needed careful planning to get them right early on. We decided that any request for an Office 365 Group would go through the same request process as SharePoint requests.

Towards the end of 2018, when they were introduced, we also learned that hub sites were preferred over subsites.

Project management

While the migration of SharePoint sites was included as part of an internal IT project, that project was focussed for most of the first year on a range of other core networking elements including the broader network architecture model and high level designs required for our new cloud environment.

It would only later start work on the migration of Exchange mailboxes to Exchange Online and personal drives to OneDrive.

SharePoint migrations continued through the life of the project.

Migration tool

There were a number of options to migrate our SP2013 sites to SPO. We decided against going with an external provider for a number of reasons and instead – after reviewing the market – acquired the ShareGate migration tool in September 2017.

Final architecture

By September 2017 we had finalised the architecture for our SPO environment. As we had been using web applications in our on-premise environment we needed to ‘map’ this to the new environment.

The new model was based on the following:

• All team and project sites would be created under the ‘/teams’ path. Project sites would have the prefix ‘PRJ’ to identify them. (Some would also be created as Office 365 Group-based sites, with ‘O365_PRJ’ as the prefix). ‘Team’ sites had to be based on a logical business unit or team.
• All other sites, including communication sites and sites that crossed over multiple business areas would be created under ‘/sites/’.

SharePoint migrations were ready to go.

First batch

Our earlier analysis indicated that around 50 of our SP2013 project sites were inactive (because the projects had since closed). As no-one was accessing any of these sites we decided to use the ShareGate tool to test the migration process and learn from the experience.

We migrated 51 project sites in October 2017. The migrations initially took place during the day but we then changed to an early morning migration (before 9 AM usually) to avoid any network traffic issues.

First lessons learned

The ShareGate tool worked as expected, and proved to be a very useful tool for other reasons too, such as moving libraries and lists between sites.

The early batch of SP2013 sites were migrated ‘as is’ in terms of their look and feel. They looked exactly the same but were now in SPO. That is, they did not get the new ‘modern’ page look and were not mobile friendly. This didn’t matter too much as the sites were rarely accessed.

After the first batch, we did the following for all new sites:

• Added a new page (named ‘home2’) and swapped over the old ‘classic’ page (renamed to ‘homex’) with the new one.
• Edited the replacement home page and add any text/images from the old site home page.
• Fixed up the left hand navigation; indented libraries and lists on old sites were now under a heading with a drop down menu option. In some cases we left them ‘as is’, in other cases we promoted the indented libraries via the left hand ‘Edit’ option.

For any sites that had the publishing feature enabled on the site collection and site settings, we disabled this on the SPO site post-migration as there was generally no need to have these settings enabled.

Some sites had Active Directory security groups in their SharePoint permission groups. As these were not migrated to our Office 365 environment (for multiple reasons, including the complexity of this legacy environment), these had to be added back in a different way to provide the same level of access. In almost all cases, existing SP permission groups (Owner, Member, Visitor) were sufficient. The primary one we had to re-create was the AD Group for ‘everyone’; this was replaced by the ‘Everyone except external users’ option.

The other factor we had to consider were Office 365 licences. By October 2017 few people had these licences. Anyone who needed to access SharePoint would need a licence, but these might not be issued to everyone until mid 2018. This limited the number of sites that we could migrate. By mid 2018, more or less anyone who accessed SharePoint 2013 before could now access the SPO environment.

Next batch – to end June 2018

From November 2017 to end June 2018 we migrated another 57 sites, including a further 16 inactive project sites in December 2017. The primary reason for the low number was (as noted above) the need for staff to have Office 365 licences, which were not allocated more broadly until mid 2018.

At the same time, however, we were also starting to create a range of new SPO sites, including Office 365 Group-based sites and new communication sites.

Publication sites re-created as communication sites

Almost none of our publication sites could be migrated ‘as is’ to SharePoint Online because the page-based content, while it could be migrated, was not in modern pages or mobile friendly.

Accordingly, it was decided to re-create all the publication sites as SPO communication sites. In almost all cases this was a relatively simple process of creating pages and copying content from the old to the new.

Our intranet was the only except to this process and, as of end 2018, remains as a SP2013 site because of heavy customisation.

Other project impacts

From July 2018 two key projects impacted on the SharePoint migrations.

The first was the roll-out of new Windows 10 devices. While a Windows 10 device was not required to access SharePoint, some of our older Windows 7 devices had Internet Explorer 9 that had issues with SPO. These users were asked to use Chrome instead.

The second related project work (which was part of the overall Office 365 project that included SharePoint migrations) was the migration of Exchange mailboxes and personal drives to Exchange Online and OneDrive respectively. This part of the project encountered a problem with Windows 7 devices and as a result that part of the project activity was delayed.

Final migrations – from July 2018

From July to the end of 2018 we migrated all except around 10 of the remaining sites, at an average rate of around 20 per month. Many of these were simple migrations.

For each migration we followed the same process:

• Engaged with the business area to provide awareness of, and where required, training in, the new environment. (By the end of 2018, this training included information about Office 365 and MS Teams to help site owners understand that SharePoint is not an ‘isolated’ product as it was before, but part of a much larger ecosystem)
• Identified a suitable date and time to migrate the site (most of these were completed before 8 AM on a working day, but some were done over a weekend)
• Alerted our Service Desk to the proposed change
• Migrated the site
• Made minor changes to the site (home page swaps mostly)
• Made the old site read only with a pointer to the new site
• ‘Released’ the migrated site to the business area, usually before 9 AM.
• Provide post-migration support to the business area. In most cases the business area was able to use the new site immediately as the new site was very similar to the old one in look and layout.

The last sites to migrate included sites with complex workflows, integration or ETIL elements and several large, complex and sensitive sites.

New site request process

While we had always had a SharePoint-based site request form, the new environment meant that we needed an updated form. The (SPO) online form changed several times during 2018 as we learned from experience what worked and what didn’t.

The current form captures the following (not all columns/fields are listed):

• Site Acronym (up to 12 characters – becomes the DocID prefix)
• Site Type: (a) team or project site (no Office 365 Group), (b) team or project site (with Office 365 Group, (c) communication site
• Approver
• Business area owner
• Owner/s
• Member/s
• Sensitivity (information security)
• Suggested site URL

Each of these requests was reviewed by the SharePoint administrators who, if the site request is OK, then run a workflow for non Office 365 Group-based sites only. For Office 365 Group based sites, these were created by creating the Office 365 Group.

By the end of 2018 we had approximately the same number of migrated sites as new sites and our SPO environment was ‘live’ and active.

Almost all the old SP2013 sites were made read only. We expect that these will be deleted by June 2019.

Is Microsoft Teams the future for office communications?

At a recent presentation on Office 365, the presenter started with Microsoft Teams and spent the next half hour or so demonstrating how it, not Outlook, had become the centre of his daily life. He didn’t mention the connection with Office 365 Groups until asked.

Is Microsoft Teams the future of office communications, replacing Outlook?

Teams was introduced to the Office 365 environment in late 2016. (See this video). At the time, it was described as ‘a true chat-based hub for teamwork and give customers the opportunity to create a more open, fluid, and digital environment.’ (https://docs.microsoft.com/en-us/microsoftteams/teams-overview)

Many early reviews suggested that Teams was Microsoft’s response to Slack, but this comparison is simplistic. Teams has much more functionality than Slack.

How do Teams link into the Office 365 environment?

Teams is not an isolated application in the Office 365 (O365) environment. It has direct links with O365 Groups.

This means that, unless your organisation controls the creation of O365 Groups, every new Team will create a new O365 Group – which in turn creates a Group mailbox and calendar, a SharePoint site, and a Planner.

If your organisation controls Group creation (which is not a bad idea), a Team cannot be created by users using the ‘Create Team’ option.

Instead, whoever controls the creation of Groups (ideally a defined Admin role) can create a Team through the ‘Create Team’ option or, preferably, by linking an existing Group to a new Team. That is, a Team is created (from the Teams interface) with the same name as the O365 Group.

The linkage with O365 Groups is important to understand. Both the Exchange and/or SharePoint Administrators should have a role in the creation of both O365 Groups, SharePoint sites and Teams in environments where this is controlled.

Where Group, Team and SharePoint site creation is not controlled, there is potential for their proliferation. There is some debate as to which is the best option but my own recommendation is to maintain controls, at least as the new Office 365 environment is being rolled out. Otherwise, the SharePoint Admin may have to deal with a plethora of similarly or poorly named SharePoint sites, and the Exchange Admin will also have a job on their hands.

The Outlook paradigm – 30 years of poorly managed records

Almost every office worker for the past 30 years has used Outlook as the primary communication medium, using folders to categorise content. Distribution Lists (DLs) helped to provide a way to communicate (in a single direction) with a known group of users.

The primary way to share a document in the Outlook environment was been to attach it to a new email. Email attachments may be left in Outlook and/or saved to a drive somewhere. Multiple copies probably exist.

Organisations that have deployed SharePoint over the last decade have learned that links in emails to documents are a much more effective way of controlling document versions and reducing copies, but this is a hard change for many users to accept.

The idea that there can be one version of a document in a globally accessible location seems counter-intuitive to users who prefer to squirrel information away in ‘personal’ email or network drive folders.

The rise of social networking and messaging

A range of social network applications, including MySpace, began to appear from the early 2000s (Facebook was open generally from September 2006). Originally browser-based, the general popularity of these applications took off once smartphones included those apps.

It wasn’t long before messaging apps such as Yahoo Messenger started to replace SMS messaging as the default way to communicate with others via phones.

Social networking and messaging apps began to change the way we communicated and connected and began to move personal communications away from email. Instead of emailing each other photos, we could now share them in a single location for all of our friends to view, like and comment.

Email has persisted, however, as the primary ‘formal’ way to communicate.

Probably the main reason for this was its recognition and persistence as a ‘record’ – many document and records management systems integrated with email systems, allowing emails to be captured as records.

Instant messaging, on the other hand, remained largely (and artificially) outside the formally accepted recordkeeping world despite the efforts of records managers to try to capture all this ephemeral content.

Enter Microsoft Teams

Microsoft Teams is an interesting technology from a social change point of view, and one that Microsoft seems to believe will be a game changer for business communications.

To understand Teams, it is important to understand what it’s not. It’s not ‘just’ an alternative to Slack. It’s not ‘just’ a replacement for Skype for Business. It’s not ‘just’ a messaging app. It’s a new way to connect, communicate, and collaborate any device.

Teams:

• Is accessible on almost any device or browser.
• Includes 1:1 messaging and group messaging.
• Includes a range of emojis and gifs.
• Includes voice and video calling.
• Has its own Office 365 Group (which has its own mailbox in Outlook).
• Has an email address for anyone who still prefers to use email to connect.
• Has its own dedicated (O365 Group) SharePoint site.
• Allows (and in fact encourages) users to share and work on a document at the same time in the Teams interface (rather than attaching it).
• Allows a team to communicate in multiple channels.
• Has cool ‘toast’ notifications.
• Includes a range of connectors to other services.
• Allows a user to see where other people fit into the organisation.
• Saves all the chat content to a hidden folder in the associated Group’s mailbox.
• Allows external (guest) access.

The Teams interface is, in fact, so useful, that some users might find it more useful than Outlook. If you use it for long enough, you may soon find yourself checking Teams instead of Outlook. In fact, Outlook looks a bit dated by comparison.

Is the end near for email?

I don’t think so, at least not for a few years.

Email is a heavily ingrained way of communicating for many people and is still seen as the ‘official’ communication medium for many organisations (having replaced the old paper Memo or Minute).

But, just as Facebook and Instragram (and other applications) replaced email because they were a more effecient and effective way for people to keep in touch (despite all the security issues), Teams – or its natural successor – has the potential to move a lot of communication traffic (and attachments) away from Outlook.

This change has already happened in part. Many (if not most) people – including government officials (allegedly) – already use a range of ‘unofficial’ applications such as Whatsapp, Facebook Messenger, Signal and so on, for both personal and professional use. The use of email is, slowly, being eroded in favour of more instant ways to communicate and share information.

Why? Because it’s faster and easier to use and meets the new paradigm of limited attention spans and interest in reading long sentences (TL;DR).

Is Microsoft really the game changer?

Perhaps, but it may not be the only one.

It is a relatively new app, and one that will probably get a lot of traction with lots of marketing by Microsoft, its inclusion in O365 licences, and the very recent ability to connect with external ‘guests’.

Whether users will use its full, Team-based collaboration functionality or remain more a Skype-replacement will remain to be seen. But for now, Outlook is looking like an ‘old’ person’s way to communicate.

Learn more here:

https://www.microsoft.com/en-us/education/products/teams/default.aspx

Applying (new) Retention Policies to Office 365 Content

From time to time I’m asked about the way records retention policies ‘work’ in SharePoint. A common criticism has been that SharePoint’s retention model is based on applying retention policies to individual records (e.g., documents in a library or individual emails) rather than to aggregations of records, the most obvious of which is a document library.

The idea of storing and managing related records together in a single aggregation derives from the management of paper records – in files, boxes, and series. This model (of aggregations containing all records relating to a given subject) was largely replicated in electronic document management systems (EDMS – many of which were used to register paper files and boxes previously) when they appeared or were modified to manage digital records in the late 1990s.

In fact, many EDM systems did not actually manage records in an aggregation; the actual digital records were stored in a secure network file stored, and presented in the EDMS user interface though a common ‘file number’ (or similar) ID.

In any case, the ability to store all digital records on the same subject together in the one system (e.g., EDMS) was always hampered by the fact that (a) email and documents were created by different systems, (b) stored in different locations (servers), and (c) use of network file shares continued more or less unabated.

The increasing complexity and types of digital records underlines the difficulty of ever storing, let alone managing or applying retention and disposal actions, to them in a single aggregation.

Until recently, Microsoft’s retention and disposal options reflected the fact that applications used to create digital records stored them in different locations (servers) – Exchange and SharePoint. Retention policies targeted individual records stored in those applications, rather than aggregations.

In March 2017, Microsoft introduced a new, single central way to create and apply retention and disposal policies to most Office 365 content, wherever it was stored – Exchange, SharePoint, OneDrive for Business, Office 365 Groups, and Skype for Business.

This post:

• Summarizes the existing ‘out of the box’ retention and disposal options in SharePoint, but not Exchange (see my earlier post on this subject).
• Discusses issues with existing retention and disposal options in SharePoint.
• Describes how the new centrally-managed retention policies and labels can be applied to most content in Office 365.
• Discusses why applying retention policies to individual records rather than aggregations may be a better option in the digital world.

Records managers working in organisations that use Office 365 to manage records should familiarize themselves with the way these new retention policies work.

Note: The details in this post are based on the Australian recordkeeping context, which may be different from your specific location.

SharePoint out of the box (OOTB) retention and disposal options

Until recently, the only available OOTB options to apply retention and disposal actions to SharePoint were to:

• Apply an information management policy to an entire site via the Site Collection Settings. This option is suitable for short-lived sites such as project or closed, archived sites, but less suitable for long-lived team sites which might have a range of different content.
• Create a retention policy using the information management policy settings in Content Types. This option applies the policy to individual records. Content Types also include the ability to ‘transfer’ (actually copy) records after a defined period to another location, such as a Records Center.
• Use a folder-based information management policy. This option requires the default Content Type-based policy on a document library to be changed via Library Settings – Information Management Policy Settings, to Library and Folders.

Another option was to adopt a form of ‘retention in place’ and regard each library as a logical aggregation of records, the equivalent of a ‘file’, and manage retention and disposal manually or using PowerShell scripts to identify libraries for potential disposal based on the last modified date of the records. Some vendors have developed a similar model to manage retention policies on libraries using a central ‘console’.

Applying retention and disposal actions to individual records

Both the Content Type and folder-based options noted above apply the retention policy to individual records in the library, not the library (aggregation/container) as a whole.

That is, disposal was based on a time period after which each individual record was created, modified, or declared a record. The logic behind this model appears to be that a document library may store multiple record types each with different retention requirements. This may not be true for all document libraries, but it usually is for many.

Applying automated disposal actions on individual records (rather than an aggregation of records) is probably counter-intuitive for most records managers. The main concerns, from a recordkeeping (and possibly also archival) point of view are the absence of (a) a documented review and approval process before the records are destroyed, and (b) a metadata record of what was destroyed. That is, the records simple disappear from the document library, removing records that may would be relevant to the context of the original aggregation. This, of course, assumes that all records relating to the subject were stored in a single aggregation which, as noted above, may not always be the case.

Global Retention Policies and Labels in Office 365

In March 2017, Microsoft introduced two new ‘global’ retention options – retention policies and labels – to Office 365. The two options allow organisations to apply centrally set and apply retention policies to the same type of record, in whatever form and wherever they are stored – emails in Exchange, documents and lists in SharePoint, conversations (in Office 365 Groups and Skype)..

Examples of ‘types’ of information could include:

• Corporate records that must be kept for the life of the company.
• Financial records that need to be kept for 7 years.
• ‘Working records’ that could be deleted after a minimum period of time.
• Personnel records or staff files that had to be kept indefinitely.

As Tony Redmond noted in this recent article, these new retention policies build on the type of retention policies first released in Exchange 2010 using folder, system, personal and default tags. The article suggests that organisations that have applied Exchange retention policies may need to consider the impact of these new types of policies. In particular, the ability to move email to archive mailboxes is lost, replaced with a retention policy.

How Retention Policies work

Retention policies in Office 365 are created by authorized users (ideally, records managers) in the Retention section of the Security and Compliance Center.

Creating a new retention policy

Each policy has the following options: Name, Settings, Locations and Preservation Lock.

Name

The name of the retention policy should reflect the class name or number in the records retention schedules so that it can be easily identified and applied to content wherever it can be applied in Office 365 (see below for ‘Locations’).

Settings

The two Settings options are based on two questions:

• Do you want to retain the content? 
  • If ‘Yes, I want to retain it’ is selected, the choices are either ‘Forever’ or a configurable ‘n days/months/years’ (e.g. 7 years). The administrator must then decide if, once it reaches that point, the record should be deleted or not. If ‘Yes’ is selected, the content will be deleted from where it is currently stored as described in the next two points.
  • >>For SharePoint content there are two options when the retention period expires. (1) If the record has not been modified or deleted it will be deleted from the original library where it was stored, and then remain in the two-stage Recycle Bin for up to 90 days. (2) If the content has been modified or deleted, it is transferred to the hidden Preservation Hold library that is created when the retention policy is applied to a SharePoint site and deleted from that library. In this case, the administrator has only 7 days to recover the content before it is deleted permanently.
  • >>For Exchange content there are also two options. (1) If the item is modified or permanently deleted by the user during the retention period, the item is copied (if modified) or moved (if deleted) to the Recoverable Items folder. The retention policy process identifies and deletes items whose retention period has expired within 14 to 30 (configurable) days of the end of the retention period.  (2) If the item is not modified or deleted during the retention period, the same process runs on all folders in the mailbox and identifies items whose retention period has expired. These items are also permanently deleted within 14 to 30 days of the end of the retention period. (Note: If a user leaves the organization, and their mailbox is included in a retention policy, the mailbox becomes an inactive mailbox. ‘The contents of an inactive mailbox are still subject to any retention policy that was placed on the mailbox before it was made inactive.)
  • If ‘No’ is selected, the content will be left in place and must be manually deleted at some point.
• No, just delete the content that’s older than … The options are to delete: (a) after ‘n days/months/years’, and (b) based on when it was created or modified.

The (subtle) difference between these two options is that the first option (Yes) ensures that records are not permanently deleted before the end of the retention period, while the second option (No) just deletes records permanently at the end of the retention period.

Advanced retention settings are also available these allow the administrator to create a search query with specific words phrases, or link the policy with the same sensitive information options found under DLP policies, e.g., financial, medical and health, privacy, and custom.

Locations

The Locations section sets where the policy will be applied. By default this is all locations across Office 365, including content in Exchange, SharePoint, OneDrive, Office 365 Groups and Skype for Business.

• Office 365 has a limit of 10 organisation-wide policies and entire-location policies combined per tenant. Therefore, careful consideration should be given to what specific types of record need a global policy, especially given that not all types of records will be found globally across the organisation.

The alternative option is to apply the policy only to specific locations or users. In most cases this is likely to be Exchange and SharePoint where the majority of key records are created and stored.

• A retention policy that includes or excludes over 1,000 specific users can contain no more than 1,000 mailboxes and 100 sites. A tenant can contain no more than 1,000 such retention policies. According to Microsoft ‘… you can get over these limits by applying either an org-wide policy or a policy that applies to entire locations’.

Retention policies applied to a SharePoint site or OneDrive account result in the creation of a hidden Preservation Hold library as noted above.

Retention policies applied to Exchange user mailboxes apply the policy to the mailbox. For public folders, the retention policy is applied at the folder level.

Preservation Lock

Finally, the administrator has the option to apply a Preservation Lock, which prevents anyone from changing or deleting the policy after it is turned on. This option should only be applied in specific circumstances as it cannot be turned off or made less restricted (by anyone, including the administrator) after it has been applied. .

Review and save

Finally, the new retention policy should be reviewed, may be saved for later, or published.

Labels

A separate option for managing retention and disposal is to use (retention) labels, which should not be confused with security labels. This option is designed to replace the following:

• Exchange Online retention tags and retention policies, also known as messaging records management (MRM).
• In SharePoint Online and OneDrive for Business: (a) in-place records management, (b) the Records Center, and (c) information management policies.

Labels are used to manage retention policies for specific types of content across the Office 365 environment. Labels can be applied automatically to content if it matches certain conditions or keywords (E5 licence only), or manually by users to emails, documents, or Office 365 Group conversations.

See below for the relationship and priority between retention policies and labels.

Who can create labels

Labels are created by individuals (ideally records managers or similar) assigned to a compliance role in the Security and Compliance Admin portal in Office 365.

Creating Labels

Labels are created in the Security and Compliance Admin Portal under ‘Classifications’. Labels may also be created without having an associated retention policy; that is, a label can be created and applied to content as no more than a visual ‘tag’. A policy can be added to it at a later stage.

If the ‘Retention’ option is enabled for labels (on/off switch), a new section appears titled ‘When users apply this label to content’. This section is where the retention policy is defined with two options:

• Retain the content. The choices are either ‘Forever’ or ‘n days/months/years’ (e.g., 7 years). The administrator must decide if, once it reaches that point, the labelled record should be deleted or not. The ‘Yes’ and ‘No’ options are the same as for retention policies, described above.
  • If ‘Yes’ is selected, the record will be deleted from where it is stored. Administrators have 93 days to recover records that have not been edited or deleted, or 7 days to records that have been edited or deleted (and moved to the Preservation Hold library).
  • If ‘No’ is selected, the content will be left in place and must be manually deleted.
• Don’t retain the content. The choices are to delete (a) after ‘n days/months/years’, and (b) based on when the record was created, modified, or labelled.

If the first option (‘Retain the content’) above is selected a check box option allows the administrator to use the label to classify content as a record. If the content is classified as a record, users are unable to change or delete the content or change or remove the label. They may still, however, edit the metadata.

The final step in the process is to review the settings. Once created, the administrator is returned to the main Labels screen which displays the label that has been created, allowing the administrator to then publish it.

Label limitations when used on a SharePoint document library

There are some limitations to applying a default label to a SharePoint document library:

• It applies the label to all records except those that already have a label and those contained in document sets.
• If the default label is removed, it removes the label from all records except those that have a label and those contained in document sets.
• Labels cannot be applied to folders in SharePoint or OneDrive (but can be applied to folders in Exchange).
• If the record is moved to a different library that has a different default label, it will inherit that label. Conversely, if it is moved to a library with no label, the existing label will be removed.

Note: When labels are published to an Office 365 group, the labels appear in both the group site and group mailbox in Outlook on the web. The experience of applying a label to content is identical to that shown above for email and documents.

What about legal holds?

eDiscovery in Office 365 is based around the creation of ‘cases’ in a SharePoint eDiscovery site. Cases are generally established in response to litigation (or potential litigation) and can be used to search across a range of sources. Once found, the information that forms part of the case can then be placed on hold, overriding any retention policy. However, once the hold is released, retention policies on records continue.

For more information on this subject, see:

https://support.office.com/en-gb/article/Add-content-to-a-case-and-place-sources-on-hold-in-the-eDiscovery-Center-54d70de9-1ec2-4325-84f3-aeb588554479?ui=en-US&rs=en-GB&ad=GB

What’s the relationship between retention policies and labels?

Retention policies and labels do the same thing but the former is more likely to be set centrally, while the latter is set by the end user. This means that a record could have more than one retention policy applied to it.

According to Microsoft’s documentation (link below), records will be retained until the end of the longest retention period applied to it, regardless of whether that policy was based on the retention policy or the label.

Are retention policies and labels better than previous retention options?

One of the primary benefits of the new retention policy regime in Office 365 is that it enables organisations to apply retention policies centrally rather than do this separately for each application (e.g., Exchange, SharePoint) as was the case until recently. It also allows end users to apply retention policies via labels.

Retention and disposal continues to be based on the individual record, or type of record (as defined by the policy or label), not logical aggregations or containers of records such as a document library.

As noted above, the concept of an aggregation that contains all the records on a given subject is ill-suited to the digital world. The reality is that records may be created using different applications (e.g., email in Exchange, document, list item or page in SharePoint, conversation in Groups, discussions in Skype etc) and stored in multiple application locations (e.g. in Exchange folders, SharePoint libraries, etc).

The dilemma for many records managers using Office 365 is how to store or manage records together in context, including based on the organisation’s File Plan or Business Classification Scheme (BCS) terms. The need to keep records together has been the driver behind the integration of EDRM systems with email applications, allowing email to be ‘captured’ in the EDRM along with other types of documents. This has rarely been successful in practice and, in most cases, emails are duplicated and remain stored in the email server.

The new Office 365 retention policies, including those applied as labels to specific types of content, may well be the answer to this dilemma. Rather than try to capture all types of records (e.g, document email, list item, conversation) in a single aggregation or container, Office 365 allows the option for them to be stored wherever the user prefers, with the same retention policy applied.

If necessary, all records with the same label can then be found using a content search in the ‘Search and Investigation’ section of Office 365.

In my view, there are still some shortcomings in basing retention policies on individual record types:

• Individual documents, rather than logical aggregations of documents, will be continue to be subject to disposal actions.
• Records that may provide context to other records (including those stored in different locations) may be destroyed.
• Appraisal options may be limited and appropriate review and approval steps before disposal may not be possible.
• Disposal actions may be automatic and unrecoverable.
• There may be no record kept, including the metadata, of the individual records that were destroyed.
• It is not known how courts might view the automatic disposal of records without prior review and approval.

Final thoughts

The new Office 365 records retention policy and label options centralise the management of retention and disposal for most types of records across Office 365, reducing complexity.

Retention and disposal continues to be based on individual records rather than aggregations, but this may be better suited to the digital world in which aggregations of records may not always be achievable.

Records managers working in organisations using Office 365 need to understand and provide guidance to IT on how records retention schedules can be applied as retention policies, and how they can be directly involved in decisions regarding the new options.

For more information: –

https://support.office.com/en-us/article/Overview-of-retention-policies-5e377752-700d-4870-9b6d-12bfc12d2423

https://support.office.com/en-us/article/Overview-of-labels-af398293-c69d-465e-a249-d74561552d30

 

Managing Project Records in Office 365

The introduction of Office 365 Groups brings a new way of working with and managing project records, including emails, documents and other types of records. But controls need to be in place to prevent uncontrolled growth.

A typical project team is likely to create two main types of record – documents and emails. More often than not in the digital world these are kept separate and unconnected to with the main project records, unless the user saves emails to where the documents are stored, or all documents remain attached to emails.

The introduction of Office 365 Groups brings an innovative way to work in projects and keep all project-related records together.

What are Office 365 Groups?

Groups are similar in some respects to a both (a) Distribution List (DL) in that they allow a group of people with a common interest to communicate with each – albeit on a point-to-point basis without new users being able to access earlier emails, and (b) a (public or private) Yammer group in that they allow the members of the group to discuss issues together ‘out loud’ instead of in one-to-one emails.

In addition to ‘conversations’ that take place in Groups, Groups also have an associated SharePoint site, a shared calendar, a plan in Planner, and a notebook in OneNote. These options are visible from the Group view in Outlook:

A (private) Group can be linked directly to a Team (in Microsoft Teams), allowing further types of exchange, including in multiple channels.

Office 365 Groups allow all types of project records – emails, conversations, documents, plans, chats, notes – to be accessed in the one place linked by the unique name given to the Group when it was created. External guests may also be invited a Group.

But, to be clear, this does not mean that these records are all stored in the one location; the records remain in Exchange, SharePoint, OneNote, Planner, or Teams. What connects them together is the unique name or identifier.

Creating Groups

The default settings in Office 365 allow Office 365 Groups (and SharePoint sites and Teams) to be created by anyone in the organisation. The danger in allowing these default settings is uncontrolled growth; when a Group or Team is created it also creates an associated SharePoint site (that is not yet visible in the SharePoint Admin portal).

To minimise uncontrolled growth, it is recommended that these default options be disabled, and that the creation of Office 365 Groups, SharePoint sites and Teams, be limited to the Office 365 Administrators, based on requests from users.

Groups should, ideally, be assigned a prefix to distinguish them from each other and from DLs and Security Groups (SGs) that are also used in Outlook. It will be interesting to see to what extent DLs are replaced over time by Office 365 Groups, as the latter are more functionally useful.

A suggest prefix for name of a project Group could be ‘PRJ’ as shown below. The same name is then used on the SharePoint site, in Planner, in OneNote and, if the Group is private, on the associated Team in Microsoft Teams making the connection between them clear.

Note:

• It is not possible to associate a public Group with a new Team; if a new Team is created with the same name as a public Group, it will create a Group with the same name).
• Creating a new Modern Team Site from the ‘New Site’ option (if enabled) on the user’s SharePoint portal also creates a Group. If controls do not exist (and the options are not disabled), users will quickly start to create multiple SharePoint sites that have associated Groups, and things could get out of hand very quickly).

Managing Project Records More Effectively

Office 365 Groups, and their associated elements – SharePoint, Planner, Teams etc – allow project records to be accessed from a single point – Outlook (on a browser or mobile device app).

Each of these elements can also be accessed from both iOS and Android apps, allowing all members of the team to communicate and share information more effectively.

Instead of sending project documents attached to emails, documents can be sent as links in email, conversations and team chats. Documents can also be proactively and jointly edited by multiple people at the same time, including using both apps-based and online versions of Office applications.

These options, via Office 365 Groups, should improve the way project records are managed.