Introduction

When talking about how Intune works with a colleague, I likened assembling a working Intune configuration to protect corporate devices and data to working with small pieces of Lego to build a house.

The reason for this comparison is that a managed Intune environment is built up of lots of different components that can all be slotted together - or left out - to build the environment you want.

Intune's Building Blocks

When a user installs Company Portal for the first time and authenticates through it they will be asked to enrol their device. This steps through the Device Management policies, which allow us (as the Intune Administrator) to control the features on their device (e.g. block or allow use of the Camera, require a device password, allow us to lock or wipe the device (or at least corporate information) later on if the device is stolen, etc.

When a user attempts to access Corporate data via applications, we can require the applications are configured in a certain way, that the apps themselves are protected by a password, and so on.

We can also use conditional access policies to require certain other things of the user, such as only allowing access under certain risk profiles (e.g. blocking access from jailbroken devices, or from ‘suspicious’ Internet addresses).

We can combine some or all of these to provide a carefully managed environment for accessing corporate data on the move, for ensuring corporate devices are protected in the event of theft, and that users cannot easily move data from a secure environment to an insecure one.

If users are working with their own devices rather than corporate ones, it’s possible to just use Mobile Application Management (MAM) to control how your corporate data is accessed without changing the way your users have to interact with their own personal devices on a day-to-day basis. This presents some risks but the choices is yours to make.

If you wish, you can just use Mobile Device Management (MDM) to configure a corporate device to meet some basic standards and leave the users to manage applications themselves. Again, this presents some risks (and these days, certainly, I’d advise against just doing that) but the choice is yours to make.

If you don’t have the budget for Azure AD Premium then you can configure the more basic elements of MDM and MAM and not worry about Conditional Access rules, DLP or other features. Again this is a risk but the choice is yours to make.

Obviously the ideal situation is to use Azure AD Premium features along with the full Intune suite of MDM and MAM features, but even here there are choices to make about how you build up your policies and what experience your users are going to have.

Putting the blocks together

Now that we’ve seen the building blocks, we can try putting them together.

First you have your users in Azure Active Directory (AAD). You may not realise it if you’re just using Office 365 for your business, but all the User Identity and Access Management for Office 365 is managed in AAD.

This means that for better or worse, features from O365 and features from Azure AD will both apply to your users, who will be listed in both places as per my example here.

You need to make a decision based on licences and your intentions as to where you will manage devices, in Office 365 or in Azure. This is known as setting your MDM Authority.

The Office 365 Device Management tools (As an Office 365 admin, look under Admin Centers, Device Management) give you access to the basic Mobile Device Management capabilities found in the base-level O365 MDM product.

The full Intune suite, available under the Azure portal gives you additional features such as Application Management, along with access to more granular reporting and configuration options for Mobile Device Management. If you have the full Enterprise Mobility Management package, you will also be working with the Azure portal for features like Conditional Access.

App Stores

Intune allows you to link to the Apple iOS, Google Android and (obviously perhaps) Microsoft Windows App stores. This allows you to control what apps can and cannot be installed and even make some apps mandatory. More on this later.

PowerShell management

Lastly in terms of management tools, I should mention PowerShell. As I'm sure most people reading this will already know, PowerShell is Microsoft's command line interface to both its on-premises and cloud components. It's probably fair to say that Microsoft's PowerShell support is still undergoing rapid development as it aims to become a full toolkit for managing what previously was a GUI experience, but it's still incredibly powerful and useful.

PowerShell starts to make sense for Intune if you need to do some repetitive tasks or ones that would be difficult to do through the GUI, such as back up your configuration, which is a great way of documenting a “baseline” for your install and tracking changes; as well as a useful way for moving settings from a test to a production environment; or for consultants to rapidly deploy certain common scenarios to  multiple customers. I plan to talk more about Microsoft Graph myself but I very much recommend John Seerden’s introduction to the Intune PowerShell SDK, along with his backup tool I link to above.

Intune’s PowerShell modules are built around the Microsoft Graph API. This is a set of programming interfaces that was originally developed for Office 365 and which has been expanded to cover larger parts of the Microsoft cloud services. It seems intimidating to delve beneath the hood at first but Graph is quite useful for managing large parts of your online services. If you’re unsure where to start with Graph then I’ll point you to Microsoft’s 30 days of Microsoft Graph blogs and the Microsoft Graph Explorer.