As I wrote recently, I made a business decision to sever ties with VMware and dig deeper into the Microsoft stack. The reasons don’t matter and I won’t bore people with the drama. Today, we cover part one of my new transitional series: “The Workspace ONE Admin’s Guide to Intune” where we teach Workspace ONE admins how to translate their today into their tomorrow. Specifically, this is for someone who is now moving to Intune and needs to get ready/leverage their WS1 background. As opposed to previous articles, this isn’t about proving which platform is better, but the translation of platforms.

In Part 1, we will cover what I commonly refer to as UEM Core. That encompasses:

• Infrastructure
• Enrollment
• Device Compliance
• Integrations

This series is specifically scoped to Windows devices, with other platforms coming in the future (or potentially in a book as Christiaan Brinkhoff has suggested). Let’s get started with infrastructure.

You can access the subsequent articles below:

• Profiles, Baselines, Scripts, and Products
• Apps

Infrastructure

From an infrastructure perspective, Workspace ONE UEM has a few products:

• Cloud Connector
• Unified Access Gateway

Simply, the Cloud Connector gives you these services:

• Directory Sync
• PowerShell
• SMTP
• SysLog
• Certificate Services

The UAG, which I linked my article on provides a Secure Email Gateway (SEG) for on-prem email services, Content Gateway (CG) for integration with WebDav, Fileshares, etc., and Tunnel for secure connectivity to on-prem services. Obviously, there’s other stuff like reverse proxy, Horizon, etc. but that is not in scope for this conversation.

Let’s discuss the infrastructure components present within Intune.

Translating Infrastructure to Microsoft Intune

We have a few areas of focus on Microsoft Intune infrastructure:

• Microsoft Entra Connect
• Intune Certificate Connector
• Intune Connector for Active Directory
• Microsoft Tunnel Gateway

Let’s discuss Microsoft Entra Connect.

What is Microsoft Entra Connect?

The great thing about Intune is your directory services are already handled for you with Microsoft Entra Connect. Quickly, Entra Connect provides a few features:

• Password hash sync (syncs a hash of a user’s on-prem AD password with Entra)
• PTA (pass-through authentication) which lets a user use the same password in the cloud and on-prem
• Federation (supports integrated AD FS)
• Sync (synchronizes user, groups, devices, etc.)
• Health Monitoring

Let’s cover the Entra Connect Sync service a bit more in detail. Microsoft Entra Connect Sync is a main component in Entra Connect. It handles the sync functions, which are crucial (replaced the old DirSync and Azure AD Sync).

Entra Connect Sync builds upon a metadirectory sync platform. This platform provides connectivity to data sources, data sync between sources, along with provisioning and deprovisioning services.

On your Connect server, a “connector” is installed providing agentless communication using remote system protocols to talk to connected directories. Its job is handling all import and exports based on a schedule to the system itself. Developers can even create custom connectors to connect to any data source.

The metaverse is a consolidated view of all joined identities from neighboring connector spaces. In the graphic above the arrows show this attribute flow. Attribute flow is the copying or transforming of data between systems. Attribute flow happens when syncs are run and defined in sync rules on Entra ID Connect.

Each data source is essentially a filtered subset of objects and attributes in the connector space. This lets the sync service function locally without needing to contact the remote system when syncing objects. This also restricts the interaction to imports and exports. During delta sync (just what has changed), this design provides substantial performance improvements by limiting the data transfer. The connector space protects the data source by enforcing schedules, which limits propagation.

The metaverse assigns authority to the linked identities for various attributes through import flow mappings, which supports the centralized object aggregating data from the different sources and carries data out to Entra ID. When those connections are severed, the object is deleted from the metaverse triggering things like deprovisioning. Attribute flow facilitate everything, which protects the integrity of the data.

Intune Certificate Connector

Ideally, you might look at the new Cloud PKI, which I covered here. For those still using on-prem, the Intune Certificate Connector lets you deliver certificates via your CA to Intune-managed devices.

It’s pretty simple. You just download the installer on your internal network, and it gives you these capabilities:

• PKCS12 certs
• SCEP
• Cert Revocation

Once it’s installed, you run through the setup wizard, which takes a few minutes and you setup the services you want to run. Once done, you have a fully functional setup with the cert connector.

Intune Connector for Active Directory

In hybrid environments, you may need the Intune Connector for Active Directory. This service creates autopilot-enrolled computers in the on-prem AD domain. When it comes to architecture, this is more so to let you know it’s available but doesn’t really address gap you had in Workspace ONE. With Intune, you have a ton of benefit in using Autopilot just like you would with iOS supervised devices.

Microsoft Tunnel Gateway

The only service that you can offer in Intune from the UAG is WS1 Tunnel. Microsoft similarly calls their product the “Tunnel Gateway.” It is a significantly harder lift than the UAG was for your typical Workspace ONE administrator. Additionally, this ONLY works on iOS and Android currently. It’s a really nice service, so I want to cover it anyways, but there is no Windows support at this time. Honestly, I’ve never really liked how WS1 Tunnel operates on MacOS and Windows. It works fine, but I’m not sure I saw a ton of value at companies where I ran it.

First, you need to build a Linux server either on-prem or in the cloud. You need to run either Docker or Podman for RHEL. The full pre-reqs can be read here. It’s another important callout that you can’t do cascade like you did in the VMware world. Basically, you end up fronting the Tunnel Gateway with a Load Balancer and then optionally have a proxy in front of our corporate network.

An administrator’s process is basically:

1. They create the Server Config and Sites in the Console.
2. They install the Tunnel Gateway while the auth plugin authenticate the Tunnel Gateway with Entra (The Gateway will get assigned to a site).
3. Management Agent communicates to Intune to get the server config policies and sends logs up to Intune.
4. You create VPN profiles and push down the Defender app like you would have in WS1.

The rest of things work in the exact same way. Your device will auth to Entra, conditional access evaluation happens, and you leverage capabilities like Split Tunnel. I will plan to record some video demos on this in the near future as I think it will be one of the harder lifts for WS1 admins.

Filling the Infrastructure Gaps in Intune

The only items that I don’t really speak to are SMTP and SysLog.

SysLog is a little tricky. Basically, you go into Diagnostic Setting, send it to Azure Event Hub, and then integrate Event Hub. You can see below that you can select what log categories you want to ship over.

The good thing is products like Splunk have easy ways to integrate with Azure Event Hub as you can read about here.

SMTP is not particularly relevant in Intune as there isn’t a stuff like “Send Message” or any of that stuff. Since things are fully integrated into the Intune.

Another issue around that is what you can notify on. You can configure enrollment notifications for when you enroll new devices, but we will discuss more when we get to compliance.

Device Enrollment

As I covered in my original article on Workspace ONE vs. Intune, we have specific enrollment capabilities in Workspace ONE. Your options are based on your needs. We have:

• Command Line Enrollment
• Hub Enrollment
• Entra ID Enrollment
• Device Staging
• Automatic Enrollment
• Bulk Provisioning and Enrollment
• Dropship Provisioning
• Unmanaged Enrollment (Enrolling without Device Management)

Most of these are fairly self-explanatory. For the most part, you can group them into a few easier categories:

• Using the Hub to enroll (command line, GUI driven, or unmanaged enrollments)
• Entra-based enrollment (dropship provisioning, automatic enrollment, connecting a device to Entra, etc.)
• Bulk enrollment (device staging, bulk provisioning, etc.)

For those that aren’t WS1 admins, you can sum it up in that you either install the VMware agent (WS1 Hub) and enroll that way, leverage direct ship from OEMs (similar to pre-provisioning), connect to Entra ID in a few different ways to automatically enroll, bulk enroll, or just install the agent and login to access certain products. Feel free to check out this video on dropship provisioning for context.

WS1 enrollment restrictions are pretty basic. We can basically create a policy to enforce OS versions, management types, etc. You can also support multiple enrollment restrictions today as well.

Translating WS1 Enrollments to Intune

Many of the concepts we discussed in the previous section still apply, but in slightly different ways. Within Intune, we can enroll in these ways:

• Automatic Enrollment
• Windows Autopilot
• BYOD: User Enrollment
• Co-managed with ConfigMGR

We will go a bit deeper into each of these especially Autopilot as many of you may not know what it is. Let’s start with Automatic Enrollment.

What is Windows Automatic Enrollment?

Marketing aside, this enrollment type is pretty self-explanatory. When a user joins or registers to Entra ID on their device, it can automatically enroll them into Intune. This is commonly used in many of the enrollment scenarios for Intune like BYOD, bulk enrollment, GPO-driven, Windows Autopilot, or ConfigMGR.

Firstly, the requirements to use Windows Automatic Enrollment are:

• Entra P1 or P2
• Intune licensing
• Global Admin (just for enabling/setting it up)

Many WS1 admins will be familiar with setting it up. You will go to Entra > Settings > Mobility and configure the “Microsoft Intune” app with the proper user scope. “All” or possibly “Some” if you are going to use a migration group to move people over.

Basically, what automatic enrollment does is:

• Picks up the Mobility settings when you log in during OOBE OR inside of “Access Work or School” when you connect your device in Azure and passes the URLs from this area. You can see for Intune we have 3 URLs for terms of use, discovery, and compliance:
  • MDM terms of use is used to display terms of use to a user before they enroll in Intune.
  • MDM discovery is the enrollment endpoint.
  • MDM compliance shows why a device is considered non-compliant, or let users initiate self-service remediation so their device becomes compliant and they can continue to access resources.

What is Windows Autopilot?

The entire concept of Windows Autopilot is confusing for most people. I’m not sure any of us fully understand it, but once you start to look at it, things start to make more sense.

Windows Autopilot is a set of technologies that assists in the set up and pre-configuration of new devices. It’s supported for both Windows PCs and HoloLens 2. In addition, Windows Autopilot can reset, repurpose, and recover devices simplifying your device lifecycle.

At device deployment, Autopilot uses an OEM-optimized version of the Windows client eliminating needs to maintain images/drivers of various models. This lets us deliver a device that is instantly ready to receive settings, policies, apps, and upgrading to Windows Enterprise.

Once you deploy, you can manage these devices via Intune, Windows Update for Business, ConfigMGR, or other MDM platforms like Workspace ONE. Some of the things that Autopilot gives you is:

• Automatic Entra ID join and Intune enrollment
• Automatic assignment to config groups based on device profiles
• Custom OOBE content specific to your company

The Many Flavors of Windows Autopilot

In Windows Autopilot, there are multiple scenarios where you can use it. We have:

• User-driven (single user device, where the user runs the deployment)
• Pre-provisioned (device pre-provisions at your OEM, the admin sets up part of it, and the user logs in and finishes things up)
• Self-deploying mode (kiosk and multi-user devices which is fully automated)
• Existing devices (ConfigMGR installs a fresh version of Windows and runs the Autopilot deployment)
• Windows Autopilot Reset (Resets an existing device back to factory settings)

It’s good to have a solid understanding of the capabilities of each scenario as well:

We have a ton of pros and cons for each type overall, which is based on your landscape. Ideally, the target should be to make most devices pre-provisioned if you can achieve it. The existing devices should ideally be user-driven because you don’t want to have to wipe devices. I would try to use existing devices method for stock devices that you haven’t deployed yet. Let’s cover a few gotcha’s to be aware of:

• Pre-provisioned and self-deploying devices requires physical devices with supported TPMs.
• Self-deploying is device-enrolled and cannot be assigned to a user.
• Existing devices requires ConfigMGR.
• Existing devices isn’t a true deployment method and requires another scenario alongside (does not work with pre-provisioned and self-deploying).
• Reset and Self-deploying do not work on Entra hybrid join devices.

I do recommend reading more about scenarios in Microsoft’s documentation as there are more things to consider. One last thing to mention are the Autopilot profiles, which look like this below:

Bulk Enrollment

Bulk Enrollment I will keep simple because in the near future I have a special blog article coming on migration from Workspace ONE to Intune. Their main article is here on it.

Simply, we use the Windows Configuration Designer to create a provisioning package for provisioning desktop devices. This will let us:

• Set a device name format
• Enter product keys
• Add a network
• Create/imbed a bulk enrollment token for Intune
• Add applications
• Add certificates

You can then use that bulk enrollment package to bulk enroll devices, which makes life much easier. For now, I recommend checking out Steve’s Intune Migration utility, which is built around the bulk enrollment process, including profile migrations, setting the primary user of the Intune device, etc. The main takeaway vs. Dropship Provisioning is it requires more work than Dropship Provisioning did but can deliver a seamless experience without significant user impact.

What is BYOD: User Enrollment in Intune?

This enrollment type is for personal, “bring your own device” scenarios, or org-owned devices. This scenario is basically someone going into “Access Work or School” and connecting their device to Entra ID:

You can either “register” a device where you just sign in and don’t approve management or “join” which is the Intune enrollment. One of the values in this enrollment type is that it doesn’t require P1 or P2. Beyond that, we can limit things to that. VMware supports many more “unmanaged” capabilities, but Intune enrollment is not as big of a deal with users because its more subtle.

What is a Co-Management Enrollment?

Companies that use ConfigMGR aka SCCM and prefer to continue using it can enroll devices with co-management. Essentially, you cloud-attach SCCM to Intune, which will run some capabilities in ConfigMGR and some inside of Intune.

This diagram below shows how various workloads work with co-management. In co-management, you can support the following workloads in ConfigMGR still:

• Compliance
• Windows Update
• Resource Access
• Endpoint Protection
• Device Configuration
• Office C2R Apps
• Client Apps

Overall, my goal typically is to try to shift critical items to Microsoft Intune like apps and patching because of challenges like paying for Azure Egress of pushing SCCM apps to Intune-managed devices (via the CMG).

The CMG (Cloud Management Gateway) is a product that lets you deliver workloads without VPN like apps and patching. The good news is that patching is free, but application deployments run through Azure and incur an Azure egress cost. I try to avoid it if possible, because some great products we will discuss later fill the gaps.

Enrollment Restrictions

We have two areas around enrollment restrictions for Intune. We have the device platform restrictions (MDM, OS versions, Personal Devices):

We also have device limit restrictions across all platforms.

Enrollment Status Pages

The enrollment status page is an interesting capability. We can configure the page that people see during their enrollment process and first user sign in. You can see below that it’s simple. One of the items I prefer to shutoff is “block device use until all apps and profiles are installed” as that can take forever sometimes. Alternatively, you can tell it what apps to block.

Gaps in Device Enrollment

The main gap is that if you have any use-cases for unmanaged WS1 Tunnel or Content Gateway, you cannot facilitate those any longer. You can access resources as a “registered user”, but you can’t use Tunnel unfortunately. Otherwise, there is a major step-up in device enrollment in Windows devices with the great capabilities around Autopilot as we have discussed.

Device Compliance

Workspace ONE’s device compliance is fairly straight forward. We have these compliance settings:

• MDM Terms of Use (within a certain period)
• Antivirus Status (Good, Not Monitored, Poor, Snoozed)
• Automatic Updates (Install Auto, Check but Choose, Never Check, etc.)
• Device Environment Status (Boot Debugging Enabled, OS Kernel Debugging Enabled, Safe Mode, Test Signing Enabled, VSM Enabled, WinPE)
• Device Tags
• Device Last Seen (within a certain period)
• OMA DM Client Last Seen (within a certain period)
• Encryption (not encrypted)
• Firewall Status (Good, Not Monitored, Poor, Snoozed)
• OS Version (within a certain version)
• Passcode (not present)
• Roaming (is roaming)
• Compromised Status (compromised or not)

Based on what you choose, you can take an action:

• Block/Remove All Managed Apps or Specific Apps
• Wipe or Force Device Check-In
• Block/Remove All Profiles or Specific Profile
• Send Notifications

Device Compliance in Microsoft Intune

Intune focuses on different areas for device compliance:

• Device Health (BitLocker, Secure Boot, Code Integrity)
• OS versions and builds
• SCCM Compliance
• System Security (Password enabled, Encrypted, Firewall, TPM, AV, Antispyware, Defender Antimalware, Defender update status, Defender real-time protection)
• Defender ATP Risk Score Threshold

You can leverage two actions in compliance with email and retiring devices. It’s a bit different than we did in Workspace ONE, but I think some of the granularity can be appreciated. One thing that they did introduce now is custom compliance as referenced here. A great article by Jannik shows an AV script that enforces compliance based on having AV installed here.

Windows Integrations

When it comes to integrations, Workspace ONE has a few key areas that we focus on:

• Windows Sensors (little piece of PowerShell that collect data from the device to use in automations)

• Workspace ONE Intelligence

• Workspace ONE Assist (their remote management platform, video below)

Let’s see how we will solve these in Intune.

Integrations in Microsoft Intune

Firstly, we can solve remote management easily with the new Microsoft Intune’s Remote Help. Check out the video below on their great remote support product:

From an integration perspective, Intune can support these integrations:

• TeamViewer
• ServiceNow
• Mobile Threat Defense (Out of scope for this)

Most of their integration is powered by leveraging Microsoft Power Automate, which supports these connectors here with some of the popular ones:

• Dropbox
• Jira
• PagerDuty
• Slack
• Twilio and much more!

Some examples you might use are:

1. Notify admins when Intune Connector is unhealthy.
2. Update the primary user in Intune.
3. Trigger remote device actions.

It’s certainly trickier and takes more effort than Workspace ONE Intelligence but is definitely achievable. Peter wrote a nice blog article on this previously.\

The last item that I wanted to talk about are remediations.

Intune Proactive Remediations

We’ll finish things up with discussing proactive remediations. Remediations are a script package that can detect and fix common support issues on a device. It’s not a perfect match against WS1 Intelligence, but it can fix many types of issues. We’ll run through an example, but first to point out license needs. You just need Windows 10/11 Enterprise or Education E3/E5. Most people should have those, but you could also use a VDA user license.

With proactive remediation, you have a detection script and a remediation script. We have some samples here. An example detection script is below. It’s pretty simple, it just looks for a result and returns it:

# Define Variables
try {
    $gpResult = [datetime]::FromFileTime(([Int64] ((Get-ItemProperty -Path "Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Extension-List\{00000000-0000-0000-0000-000000000000}").startTimeHi) -shl 32) -bor ((Get-ItemProperty -Path "Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Extension-List\{00000000-0000-0000-0000-000000000000}").startTimeLo))
    $lastGPUpdateDate = Get-Date ($gpResult[0])
    [int]$lastGPUpdateDays = (New-TimeSpan -Start $lastGPUpdateDate -End (Get-Date)).Days
        
    if ($lastGPUpdateDays -gt 7){
        #Exit 1 for Intune. We want it to be within the last 7 days "Match" to remediate in SCCM
        Write-Host "Match"
        exit 1
    }
    else {
        #Exit 0 for Intune and "No_Match" for SCCM, only remediate "Match"
        Write-Host "No_Match"
        exit 0
    }
}
catch {
    $errMsg = $_.Exception.Message
    return $errMsg
    exit 1
}

Then we also have the remediate script:

try {
    $compGPUpd = gpupdate /force
    $gpResult = [datetime]::FromFileTime(([Int64] ((Get-ItemProperty -Path "Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Extension-List\{00000000-0000-0000-0000-000000000000}").startTimeHi) -shl 32) -bor ((Get-ItemProperty -Path "Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Extension-List\{00000000-0000-0000-0000-000000000000}").startTimeLo))
    $lastGPUpdateDate = Get-Date ($gpResult[0])
    [int]$lastGPUpdateDays = (New-TimeSpan -Start $lastGPUpdateDate -End (Get-Date)).Days
    if ($lastGPUpdateDays -eq 0){
        Write-Host "gpupdate completed successfully"
        exit 0
    }
    else{
        Write-Host "gpupdate failed"
        }
}
catch{
    $errMsg = $_.Exception.Message
    return $errMsg
    exit 1
}

Remediation scripts are still new, but they do fill many of the gaps today.

Filling the Integration Gaps

With Microsoft Intune, I can’t talk about integration without talking about the great ControlUp Edge DX

ControlUp Edge DX helps address some of the rigidity of the integrations, specifically automated remediations and makes them more achievable. You can read my article to see how it makes manageable, remote support, and proactive remediation much more effective. You do still have some integration gaps around EDR, but if you’re using Microsoft Defender, it’s not a problem.

The validity of integrations is based on your deployment and where your gaps are. Security-in-depth strategies are easier when you work with a compete ecosystem like Microsoft. I believe for most companies your landscape will be solid.

Final Thoughts

Part 1 of our journey is now in the books. Below, you will see my TLDR graphic showing what your current Workspace ONE service will turn into in the Intune side of the house. We have 3 more blog articles to go. Our next one will focus on profiles, policies, scripts, etc. I decided that really needs its own article. Profiles are the most important part of this journey. We’ll go through it together while saying goodbye to our ex-best friend Workspace ONE.