Tag: Recent News

[youtube https://www.youtube.com/watch?v=JrEU84KK2lQ?feature=oembed&w=500&h=281]

In my job I chat a lot with both school leaders and IT admins about how they can simplify the management of their devices, making it faster and easier for their end users (usually students, teachers and admin staff) to get started and complete the work they need to do on a device.

Unlike many corporate environments, schools have a very high number of “shared devices” in operation, where students of different year levels require access on the same device and, in some scenarios, even teachers need to log into the same device and access different apps and security settings. In the next two blog posts I’m going to go a bit deeper into how schools can approach this challenge with modern deployment practices, leveraging cloud identity in AzureAD, easier enrollment of devices using Microsoft Autopilot and finally a couple of tweaks for a faster user sign-in experience using Microsoft Intune as the Mobile Device Management (MDM) tool.

Overview:

As this blog post will be a little longer (and more technical) I’m going to give you a break down of what is to come so you can skip to the important sections relevant to you:

• Part One:
  • Identity – why use a cloud identity?
  • Why use AutoPilot?
  • Configuring Autopilot
  • Enrolling your device
• Part Two:
  • Intune vs Intune for Education
  • What are CSP?
  • Building a custom CSP Policy
  • Using LOB App Deployment in Intune

Now it’s worth stating at this stage that I am not an IT administrator by profession. Whilst I’m probably more technical than many, I’ve got the following working through a combination of relying on the detailed guides in the Microsoft Docs and awesome technical colleagues who have shared some of their expertise with me. Additionally, like you, I read a bunch of blogs to see how people have done this in the past. This blog is a small contribution to the community who like to learn from other’s experiences. If you’re reading this and are more technical than me and see some improvements or corrections in what I’ve done – I’d love to hear from you in the comments section below.

With that said, let’s get started!

Identity – why use a cloud identity?

It’s amazing how many conversations I’ve been having around cloud identities recently as school leaders are starting to understand they need to be able to simplify user access to key resources via Single Sign On (SSO), and open up both cloud/internet solutions as well as traditional on-premise hosted solutions. There are plenty of confusing diagrams out there trying to explain what this is about – the following is the simplest I could find:

Essentially, the above is showing two scenarios:

1. The user may sign into an “on-premise” identity platform (on the left), in this case Active Directory (still incredibly common in schools) which, through the use of a tool called AzureAD Connect can automatically sign into a cloud identity as well, in this case Azure Active Directory (AzureAD or even AAD).
2. Alternatively, the user may sign directly into a cloud service (on the right) using their AzureAD credentials. In fact, if their device is managed by the school, it may even be joined to AzureAD only.

Why does this matter? As an example, I was talking with a school recently where teachers were required to use up to four different usernames/passwords to access their key platforms such as signing into a computer, accessing their email, accessing their Student Management System (SMS) and accessing their cloud collaboration suite (Office365 in this case). Simplifying this through a single cloud identity saves time and frustration for everyone! It also improves security as people are more likely to choose a secure password if they only have one to remember.

Additionally, schools are increasingly wanting to sign into third party cloud apps with the same credentials – this blog post I wrote shows a school accessing eight different solutions with just their AzureAD identity.

The key point is: identity matters. If your school does not have a cloud identity of some sort, you’re going to be inherently limited in what you can do.

As the focus of this blog is primarily around AutoPilot, I’m not going to go deep into Identity – some useful background reading I would share is earlier blog posts I’ve written around:

For the purposes of this blog, if you’re wanting to use AutoPilot then your Office365 Tenant must have either the AzureAD P1 or P2 plans – see the differences here. With many schools opting for the M365 A3 Suite, this includes AzureAD P1:

Azure Active Directory Premium P1. In addition to the Free and Basic features, P1 also lets your hybrid users access both on-premises and cloud resources. It also supports advanced administration, such as dynamic groups, self-service group management, Microsoft Identity Manager (an on-premises identity and access management suite) and cloud write-back capabilities, which allow self-service password reset for your on-premises users.

To proceed with AutoPilot you need your users in AzureAD (and licensed with P1 or P2) so if you’ve not got that far, best to stop and sort before continuing on (if you want help with this, check out School Data Sync which can automatically add users from your Student Information System).

Why use AutoPilot?

It’s always a good question to ask, and before answering if you’re brand new to AutoPilot then it’s worth watching the video at the top of this blog post and then getting into the official AutoPilot Documentation here. If you’re coming from an Apple device management world and are familiar with the Device Enrollment Program (DEP) then the concepts of AutoPilot will be very familiar for you.

Windows Autopilot is a collection of technologies used to set up and pre-configure new devices, getting them ready for productive use. You can also use Windows Autopilot to reset, re-purpose and recover devices.
This solution enables an IT department to achieve the above with little to no infrastructure to manage, with a process that’s easy and simple.

Windows Autopilot is designed to simplify all parts of the life cycle of Windows devices, for both IT and end users, from initial deployment through the eventual end of life. Leveraging cloud-based services, it can reduce the overall costs for deploying, managing, and retiring devices by reducing the amount of time that IT needs to spend on these processes and the amount of infrastructure that they need to maintain, while ensuring ease of use for all types of end users.

Back to the why use it…..

• Devices become enrolled / locked to your organisation. If a user (authorised or not) resets the Win10 OS back to factory settings, as soon as it connects to the internet again it will register back to your organisation, making it largely useless to anyone if it was stolen.
• Speeds up and simplifies the Win10 setup process – you can optionally skip quite a few of the steps you normally need to undertake in Win10 e.g. requiring the user to agree to the EULA, choosing their privacy settings, configure whether the user will be an Administrator or a Standard user, and depending on deployment mode, can even skip keyboard preferences.
• Devices can be assigned to specific users, meaning when they turn it on for the first time, connect to the internet they’re greeted by name as part of their organisation.
• AutoPilot Reset allows an IT Admin to remotely reset the device, returning it to the original state, but keeping it joined to AzureAD and enrolled into Intune for management – think of this like a “spring clean” at the beginning of the school year or new Term.

In short, AutoPilot is designed to make your life easier!

Configuring Autopilot

For my demo and testing, I’m using an Acer B117 laptop, something that is available in the NZ Education Right Device Campaign, a low cost, low spec Win10 device with 4GB RAM and options around 64/128GB SSD storage. One of the beauties of AutoPilot is that supported OEM devices can send the unique Hardware Identifier (HWID) to the purchasing organisation / school in advance of receiving the devices, allowing for the configuration of the entire environment in advance of even receiving the hardware.

An obvious upside for this would be the ability to ‘drop ship’ devices to remote employees directly from purchase, without the need for IT Admins to even site the device.

In my case, I needed to manually extract the HWID from the Acer laptop, which can easily be accomplished with some basic PowerShell (run as local Administrator):

md c:HWID Set-Location

c:HWID Set-ExecutionPolicy Unrestricted

Install-Script -Name Get-WindowsAutoPilotInfo

Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv

With the HWID obtained, the process to complete the configuration of AutoPilot is easily followed by these step by step instructions here, but largely consist of the following steps:

1. Add your devices (HWID) into Intune
2. Create an AutoPilot Device Group (tells Intune which devices in your organisation should be managed by AutoPilot). Note you can do both static and dynamic rules for adding devices here.
3. Create an AutoPilot Deployment Profile – this is the configuration settings you want to choose and allows you to skip a number of the standard Win10 decisions that need to be made when a device is being set up for the first time.
4. Assign an AutoPilot Deployment Profile to a Device Group – this matches what you’ve created in Step 2 with Step 3
5. Assign a user to a specific AutoPilot Device – this optional step allows you to match a user in your organisation with a specific device. The net result of this is the first time the user turns on the computer and connects it to the internet their name and email address is pre-populated in the setup process, meaning they only need to confirm their password during the setup – very cool!

The documentation I’ve linked to is pretty clear – it took me about thirty minutes to follow along and set the above up the first time I ran it.

Enrolling Your Device

Now the fun really beings. With the configuration completed, you can take your brand new ‘out of the box’ device and enroll it using AutoPilot for a truly streamlined, managed experience.

I took some photos of the experience using my phone camera (photo quality is average) and anyone that has ever set up Windows 10 will be familiar with this process:

At this point, the device settings and applications are installed (or possibly still coming down over the internet) but the device is ready for us.

The end user had minimal choices and actions required of them:

1. Choose their country
2. Choose their keyboard
3. Connect to the internet (this could even be their home WiFi)
4. Enter their organisation password (Office365)

My Thoughts

Modern deployment relies on the cloud for identity and provisioning of devices – there are no on-premise servers in the above model. This allows for fast, flexible and lower cost management of devices – something that appeals to education institutes where every dollar counts!

Whilst I’ve gone through the configuration pretty quickly above, along with a high level ‘rationale’ of why you’d want to do this, the next post will go a bit deeper into when to use Intune vs Intune for Education, and a couple of tweaks to make your devices run even faster at sign in and have key applications appear instantly whenever a new user signs in. I’ll likely post this in the next week or so.

This post was originally published on this site.