As we plan to move towards 1:1 mobile device deployment I decided to take a look at how this would actually work – I don’t want to be unboxing devices and having my team run each one through an OS Deploy task sequence. Pretty much all our services have moved to the cloud (“My Documents” are in OneDrive, “Shared drives” are in Teams) I thought it’d be a good idea to look at Intune and Autopilot, with the devices being Azure AD domain joined, rather than local AD or hybrid. In this post I’ll go through what I’ve done and how far I’ve got things set up.
As a pre-requisite you’ll need to have either a fully cloud based domain, or have set up AzureAD Connect to sync your user accounts. On our network we have AADConnect syncing the user accounts and ADFS for authentication, with password writeback enabled to support self-service password reset.
My aim here is to be able to hand the sealed box to the end user, for them to unwrap, power up and configure without any intervention from us.
The Intune admin centre can be accessed through the Azure portal, or directly at https://endpoint.microsoft.com/
Step 1: Importing the devices
First of all we need to get the devices into Intune. I’ve been testing this with a small pool of Surface Go devices, which were already configured for our AD domain. You’ll need to browse to Devices > Windows > Windows Enrollment > Devices.
There are a few ways of importing devices:
- Manually generate a CSV for each device by running a PowerShell script:
On the device you’ll need to run:
Install-Script Get-WindowsAutopilotInfo Get-WindowsAutopilotInfo -OutputFile c:\intune.csv
and answer “yes” to the prompts when installing the script. This will then give you a CSV containing the relevant detail. You can merge CSV files together for a maximum of 175 devices per file. If you don’t want to save to a CSV file you can use the -Online parameter instead of -OutputFile, this will prompt you for your Azure AD credentials and register the device for you.
- For Microsoft Surface devices, you can request Microsoft add these to your tenancy, or provide you with a CSV to import yourself. You’ll need proof of purchase which includes the device serial numbers. More details of this can be found here: https://docs.microsoft.com/en-us/surface/surface-autopilot-registration-support
- For other devices, your supplier/OEM should be able to register these on your behalf. See https://docs.microsoft.com/en-gb/mem/autopilot/oem-registration
Where you are asking for the devices to be registered for you, you’ll need to provide your tenancy ID and primary domain (Surface) and grant permission with a global admin account (OEMs).
If you are importing via CSV click on Import and follow the prompts.
Once you’ve imported your devices, or had them registered for you, you may need to click on Sync to make them appear:
Once you have synced you should see some devices have appeared.
Step 2: Creating and Assigning Deployment Profiles
Now we need to create a deployment profile – this will define the OOBE settings applied to the devices assigned to it. First of all I’ve created some groups to put the devices in – to make assigning the profiles easier.
Head over to Groups > New Group and create a Security group, I named mine “Intune – Staff Surfaces”. Leave membership type as “Assigned”. Then add your newly imported devices – all mine start with a 0 so I just searched for 0 on the “Add members” screen.
At a later date I will be creating student device groups in a similar manner. Using two groups, and two deployment profiles, I can pick different settings for each.
Next step is the deployment profile. Go to Devices > Windows > Windows Enrollment > Deployment Profiles and create new profile. I’ve named mine “Surface Staff” and told it to convert everything to Autopilot. Run through the OOBE screen selecting your desired settings, then under Assignments I assigned to “Selected groups” and picked “Intune – Staff Surfaces”.
Now I logged on to two of the Surface Go devices – currently set up with Config Manager and on the traditional domain – and went into Settings, then Reset PC. Once reset these devices came up with a mini OOBE prompting for language, keyboard layout and Wireless network details. When connected they then displayed a welcome screen branded with the Azure AD tenancy name (the display name, not domain name) and prompted for the user to enter their Azure AD credentials.
The devices then ran through a quick setup process where they discovered their deployment profiles and any other profiles assigned to them (covered in Step 3), eventually logging the user on.
Step 3: Configuration Profiles
Now we’ve got the device to join the Azure AD domain and skip most of the normal OOBE questions, we’ll want to assign some configuration profiles. These are used to push things like trusted certificates, WiFi profiles and other things such as Administrative Templates – think Group Policy but on Intune.
I now went back to Groups > New Group and set up another group – as I want some profiles applying to all devices. Note that there is a built in “All Devices” but this will include Azure AD registered devices (i.e. home computers where somebody has logged on to Office 365 and it has registered their device with Azure AD). I don’t want these settings applying to devices which we don’t own!
This time I went with a Security Group, named “Intune – Corporate Devices” and set the membership type to dynamic device. I then used the following rule:
(device.deviceOwnership -eq “Company”) and (device.deviceOSType -eq “Windows”)
to target Corporate devices running Windows.
To get started with the configuration profiles, go to Devices > Windows > Configuration Profiles. I created the following profiles to get started – the platform for all of these is Windows 10 and later:
Profile Name: Wireless
Profile Type: Wi-Fi
Settings: This profile adds the Enterprise 802.1X wireless network used on site, by including the certificate server name we avoid prompts for “Are you sure you want to trust this network?” when the user connects. As the user will be connecting with their credentials I set the authentication method to username and password. These aren’t stored in the profile, the user will have to manually enter when connecting.
Profile Name: OneDrive Settings
Profile Type: Administrative Template
Settings: This profile configures the following items to silently sign in to the OneDrive sync client, and restrict syncing to our tenancy.
- Silently sign in users to the OneDrive sync app with their Windows credentials
- Allow syncing OneDrive accounts for only specific organizations
- Use OneDrive Files On-Demand
Profile Name: Device Restrictions
Profile Type: Device Restrictions
Settings: This profile sets the lock screen wallpaper, and desktop background wallpaper, along with a few other restrictions.
Profile Name: Root CA
Profile Type: Trusted Certificate
Settings: This profile imports the Active Directory root CA certificate into the device’s trusted certificates store, so that users can access anything using local CA certificates without being prompted.
All the above policies I assigned to the Intune – Corporate Devices group.
Step 4: Configuring Windows Update
From Devices > Windows you can configure Windows Update settings, picking which servicing channel you want, whether to delay updates etc.
You can also use the Windows 10 feature updates screen to pick which version you want to stop updating at – i.e. if you pick 1909 here then your devices will not update to anything newer than 1909.
Step 5: Assigning local Administrator rights
With the setup above nobody will have admin rights on the devices. Ideally we want the same people to have admin rights as would have on a traditional domain environment – i.e. the technical support staff.
First of all you’ll need a group which has “Azure AD roles can be assigned” set to Yes. If you’ve not got one you’ll have to make a new one – it cannot be a synced group from AD at the moment, it has to be a cloud group. So I’ve gone and made one called “Intune – Device Administrators”, group type Security, and allowed Azure AD role assignment. I’ve then added the technical support staff admin accounts to this group.
Now head on over to Azure AD > Devices > Device Settings, and add the group you’ve just created under Manage Additional local administrators on all Azure AD joined devices. You can also configure whether MFA is required to join to the domain, and which users/groups have permission to do so. For now I’ve got this set to the staff group, but when we roll out to students they will also be included.
Whilst this is a really good start I’ve still got quite a bit left to figure out. Next post I’ll cover installing apps (store apps, and Office 365), along with seeing how I get on installing the “tricker” apps (an MSI where the content is in the folder rather than within the installer file, and EXE installers). Finally I’ll need to work out a solution for printing. We have PaperCut installed on a server however working out how to print from Azure AD joined devices to that – rather than from hybrid devices – may prove to be challenging. Ideally I’d want to be able to print when the devices aren’t on the network, without needing a VPN. I’ve also got to look at managing iPads with Intune.
- Intune Part 2 – Deploying applications to your Intune/Autopilot enrolled Windows 10 devices
- Hybrid Cloud Print – Printing from your Azure AD joined devices (the older way)
- Universal Print – the new, improved, easier way to print from Azure AD joined devices (but currently in preview)
- Intune Part 3 – iPads