Shift to the Cloud: Moving a school to OneDrive and Teams

Six years ago we started a migration to cloud services at work. In this post I'm going to go through the steps we took and what our network looked like back then, now, and the future steps.

We ran a traditional network - three node VMWare cluster with shared storage (fibre channel SAN), desktop PCs in most areas with a small laptop deployment, Exchange Server on-premises, and home and shared drive maps to a local file server. Remote access to documents was via a Remote Desktop Services cluster, and this was the only remaining use for RDS as we have previously migrated to a cloud based MIS.

We initially wanted to shift the Exchange workload to Exchange Online and take advantage of the fact that - for education customers - it was free. We followed this up, once Office 365 had matured a bit, with migrating home drives to OneDrive, and then shared drives to a mixture of SharePoint and Teams. Finally we started piloting Teams in 2019 and were thrown into a full roll-out in March 2020 with the surprise of Coronavirus.

Exchange On-Premises to Exchange Online

Back in about 2015 we made the decision to migrate all mailboxes to Exchange Online, using the Exchange Admin Centre (Online) > recipients > migration screen. We batched this with an initial trial which consisted mostly of technical staff and a few of the more "tech keen" teaching staff. We ran this for a term and there were not many issues - the only one I recall that cropped up were to do with free/busy visibility when an Exchange Online user was attempting to look at an Exchange on-premises user's calendar.

Next step was all staff mailboxes - we split this into two batches, teaching and non-teaching, and picked two weekends in the holidays where we told users that mailboxes would be unavailable. Luckily the migration speed was fairly decent and each batch completed within the "weekend" window.

Finally student mailboxes - this was much easier to plan than staff mailbox migration as we could pick a full week during the holidays and notify students that their mailbox would be unavailable. We batched this into year groups.

Home Drives to OneDrive

Next step in our journey was migrating documents to OneDrive. There was quite a bit of planning and testing required for this to work:

• OneDrive Sync Client was needed on every PC - so staff could open legacy files such as Promethean Flipchart files through File Explorer. Due to the shared nature of all our desktops, and the fact the majority have 128GB SSD drives, we needed to take advantage of Files on Demand so this required Windows 10 1709. At the time most of our estate was running 1607 so the full site needed updating.
• Office 365 Click-to-run version - most of our estate was using Office 2016 volume licence edition, we needed to update to the 365 C2R version for much better integration with OneDrive/SharePoint.
• Automatic configuration and sign in to OneDrive sync client via Group Policy settings. For this to work reliably we also needed the devices to be hybrid Azure AD joined.
• Folder redirection for Documents (and the other folders which follow it - Photos etc) to OneDrive. We didn't want to use the "Known Folder Move" feature as we have desktops redirected to a single shared folder, read only, and wanted some control over the migration.
  

Once we had the above steps working in a test environment, and had updated the client PCs, we began the staff document migration. Our first step here was to advertise the fact that OneDrive exists, and was available both through the browser and through File Explorer. At this point we did not update the folder redirection to point to OneDrive, so staff had their existing files available as both a mapped drive and the "Documents" folder, but also had access to OneDrive. They were then given a couple of options:

• Move files they wanted to keep over to OneDrive, and encouraged to clear up and delete anything they don't need. Anything left in the on-premises home drive at a cut-off date would be migrated for them into a folder named "Migrated"
• Don't do anything, and at the cut-off date everything would be migrated for them, into a folder named "Migrated".
  

A few people used the opportunity to clean up their files and folders, and get access to them within OneDrive before the cut-off date, but most just left it for me to migrate.

We picked a week in the Easter holidays and let users know they would no longer be able to write to their on-premises home drives, then performed the migration using the SharePoint Migration Tool. This worked really well and only had a few issues with very long file names. We followed this up in the Summer holidays with the pupil document migration - batched into year groups, I think we ran two year groups per week.

The main benefits that we've seen from this are the ability to access documents from anywhere with Internet connectivity, no need to establish a VPN or RDS session, and the ability for collaborative work. We had far too many instances where a document would be forwarded around a group of staff, and you'd end up with a file called "Document v1 v2 Final updated v3 FINAL.docx".

Shared Drives to SharePoint and Teams

Following the successful migration of home drives to OneDrive, the next step was to move all the shared document stores. At this time we had three mapped drives - Students, Staff, SLT and Media (shared photos and videos). The SLT drive was easy as this logically should just be a Team called SLT, we left the migration of files to SLT (or more likely, their PAs) themselves so they could create channels and organise.

For the student and media shared drives we just created two SharePoint sites with document libraries and migrated the files using SharePoint Migration Tool. Easy enough as we've already used it for the OneDrive migration.

For the staff drive, we had to decide as to whether we move to SharePoint or to Teams. SharePoint was probably the easiest option (and involved less change for staff to get used to) but we really liked the idea of Teams and wanted to push collaborative working, perhaps not initially but in the future, and took the view of "one (slightly harder) change now is better than two changes" so went to Teams.

We created a new set of folders on a shared drive, one per department to match the set of departmental Teams we had created. Within these we set up the folder structure to match Teams - so one folder per channel, and then allowed staff write access to these channel folders. They were instructed to move anything they wanted to keep from their old shared staff drive to this new set of folders, which was then migrated to Teams. This was migrated manually as it was run by an assistant head rather than technical, but it could have been performed using SharePoint Migration Tool.

Now that we've moved all shared and personal documents to the cloud, the Remote Desktop Services cluster is no longer required - so this has been decommissioned and deleted.

Azure

We also looked at trying to reduce the workload running on the on-premises VMWare cluster, as it is getting on in age. Our trust already runs central services in Azure and so each site already has a VPN to Azure configured. We moved some services into Azure Virtual Machines (specifically the ADFS Web Proxy and a domain controller running ADFS, plus two web servers) to reduce the need for on-premise servers exposed to the Internet, and to allow login to Office 365 services to still work even if the VPN was down. We also moved our backup workload from tape to Azure Backup Server, mainly to reduce the need for somebody to go in and change tapes during the Coronavirus lockdown but also as the tapes were due replacement and the tape library itself is getting on in age.

Class Teams

The next step on our journey was trialling Class Teams with a couple of subject groups. Teams were created manually for these (as there wasn't a lot of them). We had a lot of good feedback about Class Teams and our plan was to encourage their use across more subjects, ideally along with the implementation of mobile devices for staff and pupils. However we were interrupted by Coronavirus and government-ordered lockdown and closure of schools in March 2020.

A couple of weeks before closure we created a team for each class on the timetable using a PowerShell script which pulled data from our MIS system API, worked through to filter subjects we didn't need (such as Detention) and created the teams using PowerShell. These teams were then used for remote teaching (although for live lessons at this point we used Skype for Business - as at this point Teams meetings did not have all the controls we needed, such as putting pupils in the lobby, setting pupils as attendees rather than participants by default).

When it became obvious that we want to carry on with "one team per class" (and that further lockdowns were likely) during the summer I evolved my PowerShell script into something which would talk to School Data Sync and set this up to create and update the Class Teams.

What's Next?

As we've moved all data to the cloud, and removed a lot of the on-premise workload, we reduced the 3 node VMWare cluster down to a 2 node Hyper-V cluster with Storage Spaces Direct. Although this is a reduction in node count it's actually turned out to be an increase in resources as the new hosts have much more RAM and CPU cores than the old ones. As we used refurbished hardware for this we've done it for a very small cost.

The logical conclusion to this journey will be the roll-out of individual devices to staff and students, and to remove the majority of the shared desktop computers. Some will need to be kept in specialist areas, such as music, art and design, but the majority can be removed. As the only on-premises work load which users interact with is now printing, we can move this to Hybrid Cloud Print or Universal Print (UP wins here as it's a lot easier to configure and is replacing HCP). We can then deploy devices managed by Intune, Azure AD joined, and each used by a single person. These devices can then be used wherever the user happens to be, onsite or offsite.