Archive for the ‘OneDrive for Business’ Category

Migrating to SharePoint Online Part 2 (implementation)

December 23, 2018

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.

Advertisements

SharePoint Online and OneDrive for Business – Preventing external sharing of data

October 17, 2017

A recent (September 2017) article suggested that OneDrive for Business (ODfB) (and by extension SharePoint Online (SPO); ODfB is a SharePoint-based service), a key application in Office 365 was a potential source of data leaks and/or target for hacking attacks.

I don’t disagree that, if not configured correctly, any online document management system – not just ODfB/SPO – could be the source of leaks or the target of external attacks. Especially if these systems, and the security controls that can protect the data in them, are not properly configured, governed, administered, and monitored.

But, I would ask, what controls do most organisations have in place now for documents stored in file shares and personal file folders, not to mention USB sticks, and the ability to send document via Bluetooth to mobile devices or upload corporate data to third-party document storage systems? Probably not many, because users have no other way to access the data out of the office.

As we will see, the controls available in Office 365 are likely to be more than sufficient to allow users to access to their documents out of the office, while at the same time reducing (if not eliminating) the sharing of documents with unauthorised users.

How to stop or minimise sharing from OneDrive for Business and SharePoint Online

There is one simple way to prevent the sharing of data stored in SPO and ODfB with external people – don’t allow it.

There are several ways to control what can be shared, each allowing the user a bit more capability. All these options should be based on business requirements and information security risk assessments, and Office 365 configured accordingly.

In this article I will start with no sharing allowed, and then show how the controls can be reduced as necessary.

External sharing – on or off

This is the primary setting, found in the main Office 365 Admin centre under Settings > Services & add-ins > Sites. If you turn this off, no-one can share anything stored in SPO or ODfB.

The option is shown below:

O365_SC_Sites_SharingOnOff

If you do allow sharing, you need to decide (as shown above) if sharing will be with:

  • Only existing external users
  • New and existing external users [Recommended]
  • Anyone, including anonymous users

The second option is recommended because it doesn’t restrict the ability to share with new users. The last option is unlikely to be used in most organisations and comes with some risks.

The next place to set these options are in the SPO and ODfB Admin centres.

OneDrive admin center

If the previous option is enabled, the following options are available for ODfB. Note that BOTH SharePoint and OneDrive are included here because the latter is a part of the SharePoint environment.

  • Let users share SharePoint content with external users: ON or OFF.
    • NOTE: If this option is turned OFF, all the following options disappear.
  • If sharing with external users is enabled, the following three options are offered:
    • Only existing external users
    • New and existing external users [Recommended]
    • Anyone, including anonymous users
  • Let users share OneDrive content with external users: ON or OFF
    • This setting must be at least as restrictive as the SharePoint setting.
  • If sharing with external users is enabled, the following three options are offered
    • Only existing external users
    • New and existing external users [Recommended]
    • Anyone, including anonymous users

If sharing is allowed, there are three sharing link options:

  • Direct – only people who already have permission [Recommended]
  • Internal – only people in the organisation
  • Anonymous access – anyone with the link

You can limit external sharing by domain, by allowing or blocking sharing with people on selected domains.

External users have two options:

  • External users must accept sharing invitations using the same account that the invitations were sent to [Recommended]
  • Let external users share items they don’t own. [This should normally be disabled]

A final ‘Share recipients’ checkbox allow the owners to see who viewed their files.

SharePoint admin center

The SPO admin center (to be upgraded in late 2017) has two options for sharing.

The first option is under the ‘sharing’ section which currently has the following options:

Sharing outside your organization

Control how users share content with people outside your organization.

  • Don’t allow sharing outside your organization
  • Allow sharing only with the external users that already exist in your organization’s directory
  • Allow users to invite and share with authenticated external users [Recommended]
  • Allow sharing to authenticated external users and using anonymous access links

Who can share outside your organization

  • [Checkbox] Let only users in selected security groups share with authenticated external users

Default link type

Choose the type of link that is created by default when users get links.

  • Direct – only people who have permission [Recommended, same as above]
  • Internal – people in the organization only
  • Anonymous Access – anyone with the link

Default link permission

Choose the default permission that is selected when users share. This applies to anonymous access, internal and direct links.

  • View [Recommended]
  • Edit

Additional settings (Checkboxes)

  • Limit external sharing using domains (applies to all future sharing invitations). Separate multiple domains with spaces.
  • Prevent external users from sharing files, folders, and sites that they don’t own [Recommended]
  • External users must accept sharing invitations using the same account that the invitations were sent to [Recommended]

Notifications (Checkboxes)

E-mail OneDrive for Business owners when

  • Other users invite additional external users to shared files [Recommended]
  • External users accept invitations to access files [Recommended]
  • An anonymous access link is created or changed [Recommended]

Sharing via the Site Collections option

In addition to the options above, sharing options for each SharePoint site are set in the ‘site collections’ section as follows. Note that the default is ‘no sharing allowed’. A conscious decision must be taken to allow sharing, and what type of sharing.

O365_SPO_Sharing1

When a site collection name is checked, the following options are displayed.

Sharing outside your company

Control how users invite people outside your organisation to access content

  • Don’t allowing sharing outside your organisation (default)
  • Allow sharing only with the external users that already exist in your organization’s directory
  • Allow external users who accept sharing invitations and sign in as authenticated users
  • Allow sharing with all external users, and by using anonymous access links

If anonymous access is not permitted (setting above), a message in red is displayed:

Anonymous access links aren’t allowed in your organization

SharePoint Sharing option

The SharePoint Admin Centre has an additional ‘Sharing’ section with the same settings as shown above for ODfB. It is expected that these multiple options will be merged in the new SharePoint Admin Centre due for release in late 2017.

Additional security controls

In addition to all the above settings, there are a range of additional controls available:

  • All user activities related to SPO and ODfB, including who accessed, viewed, edited, deleted, or shared files is accessible in the audit logs.
  • SPO and ODfB content may be picked up by Data Loss Prevention (DLP) policies and users prevented from sending them externally. This is of course subject to the DLP policies being able to identify the content correctly.
  • SPO and ODfB content may be subject to records retention policies set by preservation policies. These may impact on the ability to send documents externally.
  • SPO and ODfB content may be subject to an eDiscovery case.
  • Administrators can be notified when users perform specific activities in both SPO and ODfB.
  • Sharing (and access to the documents once shared) may be subject to security controls enforced through Microsoft Information Protection.

Conclusion

In summary, the settings above allow an organisation to strongly control what can be shared. If sharing is allowed, certain additional controls determine whether the sharing is for internal users or for users external to the organisation. If the latter is chosen, there are further controls on what external users can do. Audit controls and policies may also control how users can share information externally.

The key takeaway is that organisations should ensure that the sharing options available in Office 365 are based on the organisation’s business requirements and security risk framework.