Monday, 21 December 2020

Moving to a ‘cloud first’ IT strategy.

 Introduction.

Schools thinking of adopting a ‘cloud first’ strategy can often be overwhelmed by the number of things that need to be considered, many of which appear to be project blockers. 

However if you tackle each issue in isolation the process can be simplified. Most of these issues can be addressed as independent mini projects, many working in parallel with each other so significant progress can be achieved in a short amount of time. 

This post outlines an approach that a school might consider when moving to the cloud. The advice is specific to UK schools but many of the ideas can be transferred to other countries.

Basic Strategy and Project definition.

As a first step the school needs to decide if they are moving to Google only (no Windows devices or Microsoft Office) or a solution that uses both platforms. If a school is planning to go solely with Microsoft Azure most of this document still applies, just ignore the Google references.

If  the school is moving to “Google only” this is a different pathway that focuses on migrating the existing application set to SaaS resources and retraining staff.  Both pathways have the aim of reducing the dependency on local server infrastructure.

In reality many schools will retain an element of both. In the UK it’s common to use Google for teaching and learning and Microsoft for administration, finance and supporting the SLT team.

This post assumes the school will maintain some Microsoft applications and will be running a local copy of MS Office. It also assumes the school already operates an Office365 tenancy using A1 (free) licences. 

This document does not cover the requirements of the internal network in detail.

However the basic network requirements for a cloud solution are:

  • Robust wireless network linked by an appropriately sized wired backbone.
  • High speed internet connection.
  • Edge Security device  (Firewall)

Mini-project List.

 Implementing G Suite                                                                     >

G Suite can be introduced without relying or affecting the local system. If possible use the existing Office365 domain for the Google organization and adopt the same naming schema for staff and student accounts. This approach makes Single-Sign-On easy to implement.

School Action: Create a G Suite Tenancy.



 Organise the Cloud Directories.                                                     >

The Office365 domain will hold user accounts in Azure AD. These accounts are very likely synchronized from local Active Directory using the Microsoft toolset.

Using standard facilities provided by Microsoft the Google tenancy can be made to defer to Azure AD for authentication.  In this way a user will logon to Google using the password held in Azure.

Having two cloud directories requires a method to keep them in sync and a policy decision to decide which is the ‘master directory’. Since most schools already have a well developed Azure AD with Office365 this normally maintains the position of master, pushing accounts into Google and letting Google check passwords against the Microsoft cloud directory.. 

It is possible to work the other way round but it’s uncommon. While it’s easy for a Chromebook to authenticate using an Azure service the ability for Windows10 laptops to communicate with a Google directory service is still a development feature.


School Action: Set the Cloud Directory hierarchy and install a syncing mechanism.


 Align applications to Cloud Directories                                            >

Legacy applications may require a local Active Directory to maintain a user list. Common examples include cashless catering, RADIUS based wireless authentication and web content filtering.
A ‘cloud first’ school does not incorporate local AD and so these functions need to be updated to support external hosted user directories and the related authentication services.

There are SaaS alternatives to cashless catering, web content filtering which natively support web directories so one solution might be to shift suppliers. However most vendors now have a road map that includes a SaaS offering that supports external directories. Enquire about timelines for release and migration tools.

A cloud first school gives an opportunity to re-examine the requirements for wireless authentication. In a traditional solution the internal network has to be protected to reduce the attack vector on the local server infrastructure. In a serverless situation that’s no longer the case as systems are hosted externally. In general SaaS services are accessed using wireless networks that do not require user level authentication (home broadband, mobile).  A simpler system based on a WPA2  PSK might be appropriate.

School Action: Approach incumbent vendors to gauge support for Cloud Directories.



 Align licensing to Cloud Services.                                                   >

Cloud licensing is based on a subscription model. Previous Microsoft licencing terms have been centred on user/device qualities or concurrent access and are out of step with modern cloud deployments. New services such as Azure Information Protection and Mobile Device Management are not covered by existing licencing. The version of Azure AD that comes with Office 365 (Basic) does not have the feature set to support a full cloud deployment.

Schools need to move to the new CSP model and purchase Microsoft 365 A3 license for all staff members who will continue to use a Microsoft desktop.


School Action: Re-evaluate the Microsoft licensing model



 Develop a data migration strategy for local data.                           >

A cloud first solution does not hold centralised data on-premise. To be specific, Windows files shares are not supported.

The cloud model stores holds all files external to the site, synchronizing data to the local desktop as required. Both Microsoft (OneDrive) and Google (Drive) have facilities that allow you to work offline and experience the advantage of local access while maintaining the benefits of cloud storage. They can also be incorporated with upsetting existing workflows or the application set.

By promoting cloud storage over an extended period of time the value of the local store will degrade over time. It may even be possible to migrate without transferring large amounts of legacy data.


School Action: Re-evaluate the value of locally held data and promote cloud storage.



 Develop a data migration strategy for email.                                   >

It’s highly likely that the school mailboxes are already cloud hosted, normally within Office365 or a district service using Office365.

Migrating email into the core service is not a requirement but it can provide efficiencies. If a migration is required sufficient time should be allowed for the data transfer. 


School Action: Re-evaluate the location of email.



 Examine local devices.                                                                         >

Windows devices operating within a cloud first school must run a recent version of Windows10. All devices not physically capable of running Windows10 in a responsive manner should be upgraded or retired. For legacy devices the Cloud Ready option provides an alternative strategy to decommissioning.

Microsoft has a toolkit that can be run to evaluate upgrade readiness for a large estate.

School Action: Establish the upgrade readiness for the Windows estate.



 Setup a PoC for Windows cloud device management                          >

A proof of concept (PoC) should be established on a sub-set of Windows devices to identify the blockers to a full migration.  The PoC should include Azure AD user authentication, enrolment in Microsoft Endpoint management (InTune),  application deployment, compliance checking and data security.

The plan could also include early adoption for BYOD devices that are not catered for using local Active Directory.

School Action: Plan a PoC for cloud based device management.



 Reevaluate the application set                                                                 >

Not all applications will be suitable for a cloud based solution. The application set should be standardised prior to migration and SaaS alternatives adopted where possible.

If the application is incompatible with Windows 10 it’s function needs to be examined and replaced.

If the school is planning a BYOD strategy the browser will be the common interface across all platforms so it makes sense to move as many services to a web delivery platform as possible.

School Action: Create a software catalogue. Start the migration to SaaS.



 Reevaluate the use of Print                                                                    >

The importance of print is greatly reduced in a cloud first school. The adoption of collaborative working practices and the ease of document sharing has the capability to remove the requirement for students to print altogether.  From a management perspective arranging print services across a BYOD environment that allows home use is a challenge that is best avoided.

One point that is generally overlooked is that once data is transferred to paper it moves outside any security control mechanism and therefore presents a potential backdoor to any data control policy.


School Action: Promote sharing as an alternative to print for students.



 Move MIS and other admin functions to SaaS.                                    >

Schools should look to move the MIS system and related functions such as finance to a SaaS platform. 

School Action: Start a program to migration on-premise admin apps to SaaS.



 Examine the internet connection.                                                            >

In a cloud first school the internet connection is the primary channel to services and data. For this reason it holds the same level of priority as the network backbone with a focus on bandwidth, latency and resilience.  A large secondary should be looking to upgrade to a 1Gbs contract with some form of failover option. Try not to pay for bundled services that are not used.

School Action: Re-examine the ISP contract.



 Adopt a security model that protects data not systems.                         >

One advantage of a cloud first school is that it embraces mobility which often includes personal devices that are outside the security boundary of Active Directory.  A security policy that controls user access to the network (802.11X) or user access to file data from the local network (Kerberos) is not suitable for a based cloud model.

Both Azure AD and Google can create a secure boundary around data that protects sensitive information on both school and personal devices.  The challenge is to migrate the access control checks away from the network, hosting systems and containers and onto the data itself.


School Action: Create a data security policy.




Tuesday, 3 November 2020

GDPR and the Googles model contract.

It's a universal truth that a parent on the board of governors of a British school will at some time ask the question;

             "Where does Google store the schools data and is it within the EU."

The first response to this question is that GDPR itself does not require data to remain within the EU. 

The second fact is - GDPR is whatever you decide it is.

To this end the Department for Education  and Google have negotiated what is called a 'model contract' which defines what GDPR compliance means with respect to using Google Cloud as a Data Processor.

So long as Google sticks to the clauses of the model contract and the school agrees to the same clauses both the school and the Google are working within the GDPR framework. Although the model contract does not require Google to hold data exclusively within the EU it's almost certain that the schools data stored on the datacentre in Dublin. However it's likely that recovery copies also exist in other data centres outside the EU.

The more important question is where does the school agree to the model clause?  

It can be found in the admin console under Account Settings - Legal and Compliance.

A school administrator needs to accept the model contract clause and also fill in the details of the local data officer.  If these actions are not completed the school is technically non-compliant if, in the unlikely event, it ever came to an data audit.  This fact is probably more important than worrying about exactly where the data is stored.

Of course if the school has an independent GDPR policy which states that all data MUST remain in the EU then you'll have to migrate it all back to local servers.

Hold on... England's not in the EU either.   Hmmm - USB sticks.

Tuesday, 6 October 2020

Managing Digital Displays with InTune.

A common requirement for schools is the management of digital displays. While there are a dozens of excellent SaaS applications that will do the job perfectly well it’s also possible to put together a workable solution using the standard features provided by Intune and a third party resources such as Google Slides without any additional cost.

One of the more useful features of Intune are the preconfigured device templates and one of these is Single Application Kiosk which is exactly what you need for digital displays. It’s not worth going through the details of how this is set up as it’s covered in a number of other posts including this excellent video walkthrough. Rather this post lists some of the tweaks that take this general idea and makes it work in practice.

One tip mentioned in the video and worth repeating is that you really need to set a maintenance window when you config the kiosk policy. You really don’t want your digital player to be rebooting in the middle of the days to take a feature update.

You don’t need any special windows app to run a web session in kiosk mode - Explorer/Edge will do nicely. The standard kiosk policy takes care of all the auto-login and full screen requirements without any extra effort on your part. What you do need to do is create a separate policy to control the target URL for the display.

This is done through creating a new Device restrictions policy shown below replacing your value for the URL.

If you are running a number of displays all presenting different slide shows, each will need it’s own policy assigned through security groups containing the appropriate display device. Changing the display then becomes as simple as moving the device between groups.

You need to be a little careful working with Kiosk mode as some of the features such as autologon will conflict with standard security settings set in other policies especially if these are held by the All Devices group. The best approach is to create an All Digital Displays security group and then explicitly exclude it from all policies set on All Devices unless it carries a policy you require.

Setting your policy apply should force an autologon and present a full screen display and so you might well believe it’s a job well done - not quite. If you return in ten minutes you’re likely to find sleep mode has kicked in and your screen is now a blank page.

Intune has a number of configuration policies that control aspects of sleep mode but these are not always effective in kiosk mode, The solution is to create a new custom profile type with three OMA-URI entries using the information below.


Name: DisplayOffTimeoutPluggedIn

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Power/DisplayOffTimeoutPluggedIn

Data type: String

Value: <enabled/><data id="EnterVideoACPowerDownTimeOut" value="0"/>


Name: StandbyTimeoutPluggedIn

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Power/StandbyTimeoutPluggedIn

Data type: String

Value: <enabled/><data id="EnterACStandbyTimeOut" value="0"/>


Name: HibernateTimeoutPluggedIn

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Power/HibernateTimeoutPluggedIn

Data type: String

Value: <enabled/><data id="EnterACHibernateTimeOut" value="0"/>


Once these are set and applied to your security group the display will stay fixed.


Its also worth checking if your hosting device has a BIOS setting that allows reboot on power loss. This is a standard feature on the Intel NUC and allows the screen to recover to the display from a power on without any manual intervention. You don't really want to be searching for the on/off switch when the screen is 2m from the floor.

In this example I used a Google Slide that’s published to the web as the target. You can use any URL or third party resource. If you know how to replicate the functions of published Google Slides with Microsoft PowerPoint please drop me a line.

If you are using a third party platform it's likely that the display will be driven through a local application that controls the update cycle. Using a simple URL like the one provided by Google Slides allows you to control the advance rate but not it's refresh. Once the slide deck is loaded it's cached locally which has some advantages if the internet connection is dropped but it also means that new information is only going to be visible once the URL is reloaded.

The easiest way guarantee a URL reload is schedule a reboot of the device.  This can be achieved using another custom profile type.


Name: ReoccuringRebootSchedule

OMA-URI: ./Vendor/MSFT/Reboot/Schedule/DailyRecurrent

Data type: String

Value: 2019-10-01T02:00:00Z

The date and time value is in ISO8601format and both are required. This will reboot the device each day at 02:00 am to ensure the presentation is current for each day.  

Other reset options can be found in this post.