Azure Autopilot with Intune – Part Two — April 11, 2019

Azure Autopilot with Intune – Part Two

Salaam, Namaste, Ola and Hello!

For those new to the blog welcome, and to those returning a big thanks! In part one of this series on ‘Azure Autopilot with Intune’ (https://iamitgeek.com/?p=123) I discussed what the Autopilot Service is, prerequisite requirements for this service and finally how to set it up.

In part two of the series I will now go through some of the user experience when logging onto a device that is added to the Autopilot Service as well as some features around the Intune profile you can setup to help manage the Windows 10 devices. As I have mentioned in previous blogs, I will be doing a separate series around ‘Intune Application deployment’ as its too big a topic to include here even though it has a big part to play with the Autopilot service.

Before any user’s login we really need to ensure that the device will be secure for them to use. Security of the device is controlled through the ‘Device Compliance’ section on the Intune portal and in here is where you can create policies for the different device types (Windows, Android, MAC and so on).

Device Compliance

If you click on Policies > Create Policy, you can create your platform specific compliance settings your devices must meet to be allowed access to your corporate network. In this instance we need a Windows 10 compliance policy, however those who are familiar with the blog post I did on ‘Samsung Knox Enroll with Intune integration’ will see the settings you can configure for Windows 10 devices are very similar.

Policy Settings

We have the Setting section which has:

  • Device Health
  • Device Properties
  • Configuration Manager Compliance
  • System Security
  • Windows Defender APT

Device Health: Here you can configure if Bit locker encryption and Secure boot are required or not. Device Properties: You can specify the minimum and maximum OS level on your Windows devices. This isn’t really as significant as it is for mobile phone devices, however you may have an application that can only run on a specific build of Windows 10, so with this part of the policy you can ensure your devices meet that requirement. System Security: Here we configure the password requirement settings, including Password length, maximum minutes of inactivity, number of previous password and password type to name a few. Windows Defender APT settings are specific to Windows 10 and it lets you specify what minimum risk level the device needs to be at to be compliant. The final and in my opinion the most important setting is ‘Actions of non-compliance’ which defines what actions need to be taken for devices that do not meet the compliance policy requirements. The two actions around this are ‘Send email to end user’ or ‘Remotely lock the non compliant device’.

End User experience : After the compliance policy is set you are now in a position for the end users to login. The great thing about Autopilot service is that it allows the end user to have that out of box experience (OOBE) where they can remove the laptop from the original packaging and box as if they have just been out and purchased the laptop themselves, rather than have it handed over from IT with little marks on it from where IT have been using it to install the OS and configure the apps. The end user will need to choose the language, time/date, accept the license agreement and connect it to the Internet (via Wi-Fi). Once this is connected to the Internet the device makes that connection with the Autopilot service which already knows about this device as we imported it right at the start. It then loads a company specific login page that you can configure within Azure which includes your company name, logo and IT support contact details. The user then logs in with their corporate email address and Autopilot starts to install the compliance policy as well as any apps you have provisioned. The beauty of this is that there is no or very little management needed from IT, and rather than spend time on deploying devices, they can spend time working on the compliance and applications side.

That concludes my blog series on Autopilot with Intune folks, I hope you enjoyed this series and I would love to know what you thought so please feel free to leave a comment in the comments section. Until next time, ‘IamITGeek’ over and out!

Azure Autopilot with Intune – Part One — April 8, 2019

Azure Autopilot with Intune – Part One

Salaam, Namaste, Ola and Hello!

For those who are new to my blog welcome! To those who are returning, a big thanks!! I recently did a two part series on Samsung Knox enrollment with Intune Integration which went through the steps needed to enroll Samsung mobile devices to the Azure Intune portal and then how to manage the devices via Intune.

This weeks ‘IamItGeek’ blog series is going to be on a similar topic: Using Azure Autopilot to enroll Windows devices into an Azure AD domain and then how you can manage the Windows device with Intune.

What is Autopilot? I have found one incorrect assumption made around Autopilot is that its a cloud based imaging service, however it is in fact a collection of technologies used to setup and pre-configure new Windows 10 devices. Now these could be devices purchased direct from vendors like Lenovo and Dell or even devices obtained via high street shops like PC World and Curries.

Requirements: Before you can use this service however there are a number of pre-requisites that need to be met:

  • Windows 10 version 1703 or higher

Windows 10 Pro, Pro Education, Pro for Workstation, Enterprise and Education are all Autopilot supported platforms

  • Relevant Subscription

To allow enrollment into the Azure Intune MDM service you need to ensure the users corporate Azure account has the correct subscription. Relevant Subscriptions include: Microsoft 365 (Business Subscription), Microsoft F1, Academic A1, A3 and A5, Microsoft Enterprise E3 and E5, Intune for Education, Azure AD P1 and P2, and any Microsoft Intune subscription.

One final requirement is needed before you can provision which is a set of device details that includes:

  • Device Serial Number
  • Windows Product ID
  • Hardware Hash

This information can be obtained in a few different ways and this all depends on how you purchase the devices. If you have purchased via the vendor, they can and should provide this which would make the process a lot easier. If however you are not able to do this you will need to login to the device and use Powershell to extract this information. I used the the following commands within Powershell to output a file with the information and then reset the device to OOBE (Out Of Box Experience):

Set-ExecutionPolicy -ExecutionPolicy Bypass

Install-Script -Name Get-WindowsAutoPilotInfo

Get-WindowsAutoPilotInfo -OutputFile C:\AutoPilot.csv

Once you have the csv file output you then need to import/upload this into the Azure Intune Portal

Windows 10 Enrollment

As you can see from the image above, you need to upload the csv by going to Windows enrollment > Devices and then importing the file into Intune

Import Autopilot Hardware csv

Once the import is started it can take some time depending on how many devices, however once this is completed you can start to build your security profiles and applications that will be deployed via Autopilot when the users first login to Windows.

That is it for part one, keep an eye out for part 2 where I will go into more details around creating and Autopilot profile and the end user experience when logging into the device for the first time. Until next time, ‘IamITGeek’ over and out!