Microsoft Intune is a valuable tool for businesses that rely on largely distributed workforces. It gives IT administrators the power to retain control over devices that they can't physically interact with by setting password length and complexity requirements, pushing software updates, and remotely troubleshooting technical issues. It even makes BYOD (bring your own device) policies possible within a secure context that ensures solid data governance and loss prevention. For Microsoft users whose businesses have been reshaped by the pandemic—or even those who have been relying on remote workforces for years—this technology is becoming crucial to successful IT and device management.
That said, the technology itself does pose some challenges, especially for teams that might not be used to administrating complex cloud environments and managing endpoints remotely. The configuration is often quite complicated, and it can be challenging to promote standardization while ensuring that your users get a smooth experience of using their devices. This is especially true in cases where networks are designed to limit access, i.e. in settings with strong firewalls. In fact, configuring an Intune deployment to play nicely with a firewall is a challenge that comes up not infrequently, and the Intune-specific knowledge for how to navigate this complexity is often hard to come by.
Luckily, if you’re grappling with this kind of challenge, you’re not alone—it’s something that we at Intertec have seen and dealt with over the course of our considerable cloud expertise. Today, we’ll sit down with Manuel Arce—Intertec’s resident Azure Solutions Architect—to walk through the challenge of getting Intune to work in a restrictive firewall environment:
Recently, I was trying to get Intune up and running in a way that worked with existing firewall configurations. Seems like it should be pretty straightforward, right? Turns out, it’s a little more complex than it seems.
When you need to integrate Intune into an environment where network access is limited, Microsoft’s official recommendation is that you should allow this site for management: https://docs.microsoft.com/en-us/mem/intune/fundamentals/intune-endpoints.
Then, you’re supposed to add this for Scripts and Win32 applications.
I went ahead and whitelisted this endpoint based on the information I gathered from my existing endpoints, and I then began testing the enrollment.
I created profiles as usual and performed the normal slate of activities to test them—but, for some reason, Intune just refused to work. I hadn’t downloaded the Intune Agent (which, of course, wouldn’t have allowed me to download the Scripts or Win32 applications), so I knew that couldn’t be the problem.
I spent a while making little adjustments and trying a handful of possible solutions, hoping that Intune would eventually kick in and connect successfully. When none of these attempts stuck, I started to troubleshoot: I installed WireShark on both the desired client and on an open network environment, then analyzed the network traces. I was amazed with my findings.
Intune started the initial connection without issues on both computers. But—after the initial configuration—the desired endpoint sent a disconnect trace. As it turned out, the disconnect trace didn’t come from Intune; it came from http://www.msftconnecttest.com/connecttest.txt, which seemed to let Microsoft know whether the relevant computer did or didn’t have internet access.
This seemed to be the missing ingredient. Without adding this address to the whitelist for the firewall, the connection icon would show the warning symbol; then, the client would decide that it had no internet access—which meant that Intune would not proceed.
Since the issue appeared to be resolve, after I added http://www.msftconnecttest.com/connecttest.txt to the whitelist URLs, I ran the suite of relevant tests again. Everything continued to run without issues.
I can't confirm that this was definitively the problem I was running into—it’s possible I just got lucky and everything started to work for mysterious, unrelated reasons—but from the outside this appears to resolve it. Either way, as an admin this was a much less straightforward deployment than I was expecting. Though the Microsoft knowledge base is pretty copious, in situations like these I wish they were a little bit more clear about the necessary procedures to get the technology to work.
For anyone who’s run into a similar problem getting their MDM configured with a firewall, we hope that this article helps to clear up some confusion and give a relatively easy fix to the problem. Like Manuel noted above, sometimes the existing documentation provided by Microsoft doesn’t give you the full picture of everything you need to do to get Intune up and running in your particular IT environment. In situations like these, it's often helpful to have experience with a wide variety of different technology deployments, with a background of troubleshooting cloud technology and MDM technology in particular. For admins that are only ever exposed to their own IT environments, it can often be difficult to troubleshoot this kind of technology effectively.
This is where Intertec’s robust cloud expertise comes in. In addition to offering traditional cloud migration and management services for our diverse clientele, we also offer the remote management of physical infrastructure, including MDM solutions like Intune. In this way, we’re able to take a lot of the burden of configuration and active management of your device network off of your IT staff, so that they can focus on more valuable tasks.
As a Microsoft Partner organization with strong cloud experience, we’re able to register devices, create device groups, establish policies, and monitor device usage—all according to your specifications—more quickly and efficiently then a less experienced team could manage. At the same time, our nearshore business model means that we’re able to reduce labor costs by up to 30% while maintaining time zone alignment. The result is that you can maintain security compliance with your remote workforce, enforce consistent device standards, and gain greater visibility into your device usage—all at a fraction of what it would cost to do in-house.