Are you considering deploying Intune? Then here are a few things you really need to know:
There is no universal enrollment experience accross devices or OS’es
When you direct your users to your Intune Portal, the portal attempts to detect the OS you’re running. If it detects Windows 7 or 8, it will display a prompt to enroll your device, the user has to download a client and wait for at least an hour, reboot for updates, etc etc. Quite a hassle, not every user will intuitively understand this process.
On Windows 8.1 or on mobile devices (iOS, Android, Windows Phone) you’ll have to manually install an app from whatever store your OS has. Intune actually directs your users to a technet article for this which few ‘normal’ users will be able to follow. This app will require a signon and will sometimes enroll your device automatically. On iOS and Android this works fairly seamlessly.
On Windows Phone and Windows 8.1 and Windows 10, the device first has to go through a Workplace Join. This registers the device in your Active Directory (through ADFS) or in Azure Active Directory. Note that you’ll need 2 DNS records for this:
- EnterpriseRegistration.contoso.com => enterpriseregistration.windows.net
- EnterpriseEnrollment.contoso.com => manage.microsoft.com
The registration URL is needed for Azure Workplace Join, the Enrollment URL is needed to register the device with Intune. If you’re not using Workplace Join in Azure, but want to use your own ADFS, this has to point to your ADFS instance.
For Windows 10, the experience is slightly less awkward, but the device will only be ‘light’ managed. This means security policies and SSO, up to some degree, but no true application deployment unless you install the Intune Client. Which, by the way, you won’t be able to if SCCM or the Company Portal app is already installed. In addition, the Intune Client looks old and very basic, don’t expect much in the way of device management from it.
Enrolled devices on Windows 10 still need a Microsoft account in the Windows Store even though the Windows store automatically signs in with a Work Account
Or they will not be able to download the Company Portal application. This is so counter-intuitive and baffling I have no idea why this is still not possible.
A lot of your users will not be able to enroll their device without help
The Workplace Join and app installation process is in no way userfriendly, and is not clearly described in the Intune Portal. This means you will often end up having to support your less techsavvy users when they attempt to enroll their device.
The Intune portal is not really customizable
You can adjust the logo and colors of the Intune Portal, and add some contact info, but you cannot adjust anything else. No custom messages, nothing. It is also impossible to set language specific descriptions(!), logo’s or names of applications you want to deploy with Intune.
Make use of ADFS SmartLinks if you can
If you use ADFS, use a SmartLink for the Intune Portal, so users don’t have to wait for an ADFS redirect.
Don’t link Intune and SCCM
When you link Intune and SCCM, you get some additional management functionality you would not have otherwise. But, you lose consistency and you can never, ever go back because Microsoft doesn’t really know how. A developer has been assigned to fix this, but of course no timeline or promises.
You’ll have to manage your mobile and Windows 8.1 devices in SCCM, the rest in Intune. Microsoft is dedicated to the development of Intune, this fits their Cloud First strategy, SCCM already receives new features much later than Intune does. It’s only a matter of time until Intune is superior to SCCM. Let’s hope Microsoft soon releases an Intune Proxy Deployment Point 🙂
Don’t expect conditional access to work with OnPrem ADFS
Microsoft has decommissioned DirSync, the popular tool used to sync your local Active Directory to Office 365 / Azure. A new tool is available, called Azure Active Directory Sync. This tool does NOT support device-writeback, only the preview version (not for production environments) supports device-writeback at this moment and haltingly at that. Because you don’t have device writeback, you cannot create conditional access rules on your ADFS servers that check if the device has been workplace joined to Azure.
edit: this is now supported and working, read up on Conditional Access using on premises ADFS.