In-Depth
Intune Gets a Major Facelift
Admins should benefit from the recent integration of Intune with the Azure portal and support for conditional access, but should prepare to encounter some migration issues.
Microsoft has overhauled Intune, its cloud-based PC and mobile device configuration and management tool and a core component of its Enterprise Mobility + Security (EMS) service. The company has moved Intune into the Azure console, and has also added some new conditional access capabilities.
Ultimately, this should allow for much easier and more seamless management for mobile users. However, the transition process may end up being anything but painless. There are several issues Intune and Azure subscribers are likely to encounter as they go through the transition. Nevertheless, it's an important and beneficial move.
Consistency and Scale
Microsoft moved Intune into the Azure portal to create an easier and more consistent administrative experience, while also improving scalability. Like competing cloud services, Azure workloads can scale infinitely. Moving Intune into the Azure portal allows it to take full advantage of Azure's scalability. According to Microsoft, this transition will allow an admin to manage hundreds of thousands of devices if necessary.
Intune's move to Azure isn't just about scalability. After all, not every organization needs to manage 250,000 devices. Moving Intune into Azure is also about creating a better overall management experience. Other core components of EMS are already based on Azure, including Azure Active Directory. Moving Intune into Azure makes it easier for Intune to interact with those services.
Another benefit is that the new Intune management interface is device-agnostic. According to Microsoft, Intune admins will be able to manage it from nearly any device, even a smartphone.
Conditional Access
The addition of the conditional access feature is also a significant upgrade to Intune. To understand why it's so important, consider the way basic file-share access works in a Windows environment. When a user attempts to access a file within a Windows file share, the system hosting the file uses an access control list to determine whether the user should be allowed to access to the file. This access control list might grant access to the file, it might deny access or it might allow read-only access. However, that's pretty much the extent of the intelligence built into the process.
Using simple access control lists was fine back in the day when everyone was working from tightly controlled, domain-joined PCs residing inside of a perimeter firewall. Today, however, things aren't quite as simple. Our data is no longer centrally located. While some data might reside on-premises, organizations are just as likely to have data stored in remote datacenters and on multiple public clouds.
Device access has also changed. While some users might continue to work from domain-joined PCs at the corporate office, it has become increasingly common for users to work from devices that can't be domain-joined. These devices can be anything from a Mac desktop to an Android phone. Furthermore, the devices users are using to do their jobs don't necessarily reside on-premises. Almost everyone works remotely at least some of the time.
Decentralizing data storage and allowing users to work from the device and location of their choice have created tremendous flexibility within the workplace. At the same time, though, it has also created some problems for IT pros. One of the biggest problems is security. How do you keep data secure when you never know exactly how it'll be accessed?
This is where the new conditional access feature comes into play. Conditional access is based on the notion data access needs to be balanced with risk management. For example, I'm writing this article in Microsoft Word. I own the Word document because I created it, and conventional wisdom would suggest I should have unconditional access to the document. But what if I was at a friend's home or office, and decided to use a PC there that's not as secure or well-protected against malware? Should I be permitted to access my document from that system? It's my document, and the access control list says I have access to it, but that doesn't mean accessing it from an insecure device is wise.
Conditional access works by letting an administrator decide the circumstances that constitute an unacceptable level of risk. Those conditions can then be built into an access policy. The nice thing about the conditional access feature is it looks at the big picture by taking into consideration things such as who's attempting to access the data, whether or not that person is using a compliant device, which app is being used to open the data and the user's geographic location.
There are two noteworthy benefits of the conditional access feature. First, not only can administrators define granular policies, but also granular responses to attempted access. If an authorized user attempts to access sensitive data from a non-compliant device, for example, Intune might be able to bring that device into a compliant state before granting access.
The other benefit is its ease of use, which is quite an accomplishment for a feature like this.
Intune Availability
Although Intune is now generally available within the Azure portal, Microsoft hasn't yet made it available to all customers. Even if the Intune option exists within the list of Azure services, it doesn't guarantee you'll be able to use Intune through Azure. At least some customers are still receiving messages indicating their Intune account isn't quite ready for use with the Azure portal. The solution to this issue is to be patient and give Microsoft time to complete its migration—in fact, it could be resolved by the time you're reading this.
Account Inconsistencies
Another issue relates to some inconsistencies with how Microsoft accounts work. This one is sure to have some Intune administrators ripping their hair out in frustration as it did for me.
As noted, this problem stems from inconsistencies with how Microsoft does things. Normally, an Azure subscription gives you access to nearly all the Azure services. Microsoft doesn't really care which services you use. You're simply sent a bill at the end of the month based on your usage.
Things work a little bit differently with Intune. Intune has always been a separate service, and requires a separate subscription. Unfortunately, Microsoft didn't update the Intune subscription model when it moved Intune into Azure. Azure produces an Access Denied error message if you try to access Intune functionality without a dedicated Intune subscription (see Figure 1). Microsoft will let you browse around the Intune console without an Intune subscription, but you can't do anything.
[Click on image for larger view.]
Figure 1. Microsoft requires a separate subscription for Intune.
The solution is to get an Intune subscription and add it to Azure, right? In theory, that's indeed what you'll need if you want to use Intune. However, it's not that simple. I've maintained an Azure account for many years. This account is tied to an MSDN subscription (which previously was a TechNet subscription) I've had since the 1990s. It's the longevity of my subscription that created the problem.
Back in the 1990s when I set up my TechNet subscription, Azure didn't exist. Neither did Office 365. At the time, when you created a Microsoft account, the account was usually tied to a hotmail.com domain. Hence, my TechNet subscription was based on a Hotmail e-mail address. Over time, Microsoft eventually did away with TechNet subscriptions and moved existing TechNet subscribers to MSDN. Hence, my MSDN account and my Azure account (which is included in my MSDN subscription) are tied to a Hotmail e-mail address. This is the same address I've had for more than 20 years.
The problem is that Intune doesn't allow Hotmail accounts. When you go to sign up for Intune, the sign-up screen gives you the option of linking Intune to an existing account (see Figure 2). This is exactly what needs to happen if Intune is to be used within the Azure portal.
[Click on image for larger view.]
Figure 2. The Intune sign-up page gives you the option of linking your Intune subscription to an existing account.
When you click on the option to use an existing account, a Microsoft Office 365 sign-in screen appears. Hence, Microsoft wants you to tie your Intune account to an Office 365 account. Intune doesn't recognize Hotmail accounts (see Figure 3).
Unable to find a workaround, I established a new Azure account based on an Office 365 @onmicrosoft.com username to create an Intune account and linked it to the Azure account.
[Click on image for larger view.]
Figure 3. The Intune sign-in screen doesn't recognize the hotmail.com domain.
Fish Out of Water
When Microsoft moved Intune to Azure, the company completely changed the familiar interface. These changes aren't purely cosmetic and you might feel like a fish out of water at first. The methods used to perform many common Intune tasks are going to be extremely unfamiliar to experienced Intune admins.
Microsoft didn't make all these changes because the company wanted to confuse Intune admins. The changes were made to tie Intune to existing Azure functionality in order to create a more seamless management experience across Intune and Azure. It takes some getting used to, but given what Microsoft is trying to accomplish, these changes were necessary.
The good news is Microsoft has created a very helpful resource to help Intune admins acclimate to the new environment. A page within the Intune documentation describes where all the Intune features are located in Azure.
Migration Issues
Like many migrations, there are certain things that will break when moving to the new Intune. If you've worked with Azure for a while, you're certainly aware of the major differences between the Azure portal and the classic portal that preceded it. These differences aren't all cosmetic. The portals are linked to separate environments and there are some things that worked in the classic portal that no longer work in the new portal. The same thing holds true for Intune.
For instance, the Azure portal for Intune doesn't support default corporate device enrollment profiles for Apple Device Enrollment Program (DEP)-compatible devices. Similarly, compliance policies that were created in the classic Intune portal will continue to be enforced, but these policies don't show up in the new portal. Likewise, the Azure portal won't show status information for policies that were migrated from the classic portal. Microsoft lists these and other issues on a "Known Issues in Microsoft Intune" page. It would be prudent to take the time to familiarize yourself with these issues.
Prep for a Smoother Transition
Ultimately, I believe Microsoft's decision to move Intune into the Azure portal makes sense. I look forward to spending more time with the conditional access feature. Unfortunately, the transition seems to be anything but smooth, and Intune subscribers are likely to experience a few issues during the transition. Becoming familiar with those different hitches should ease the transition (for some tips, see Microsoft Corporate VP of Enterprise Client and Mobility Team Brad Anderson's blog post).
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.