Microsoft Intune Explained: User vs Device Configuration Profiles

Microsoft Intune is one of the most important tools in modern Windows endpoint management.

This is especially important for organisations moving away from traditional on premises Group Policy and toward cloud managed devices.

At its core, Intune is Microsoft’s cloud based endpoint management platform.

It helps organisations manage devices, applications, security policies, compliance settings, and access to company resources across Windows, macOS, Linux, Android, iOS, and virtual endpoints.

Microsoft describes Intune as a cloud based endpoint management solution that manages user access to organisational resources and simplifies app and device management across many device types.

One area that still causes confusion is the difference between user configuration and device configuration, especially when administrators try to manage something practical like mapped network drives.

This is where things get interesting.

A mapped drive may look simple to the end user, but from an Intune management perspective, it sits right on the boundary between identity, device state, network availability, user context, and legacy Windows behaviour.

What Is Microsoft Intune?

Microsoft Intune is a cloud based endpoint management and security platform used to manage devices, apps, policies, and access to organisational resources.

In a traditional environment, many Windows settings were managed through:

Active Directory.
Group Policy Objects.
On Premises Domain Controllers.
VPN connectivity.
Configuration Manager.
Login Scripts.
Group Policy Preferences.

In a modern environment, Intune allows administrators to manage many of those same areas from the cloud.

With Intune, IT teams can:

Enrol and manage corporate owned devices.
Apply configuration policies.
Deploy applications.
Enforce compliance rules.
Configure security baselines.
Manage Microsoft Defender settings.
Control access to company data.
Support Zero Trust security models.
Manage remote and hybrid users more effectively.

Microsoft’s endpoint management documentation describes Intune as part of a cloud based unified endpoint management solution that simplifies management across operating systems, cloud, on premises, mobile, desktop, and virtualised endpoints.

In simple terms, Intune is the modern cloud control plane for endpoint management.

Why Intune Matters

The old model assumed that most users worked from the office, signed into domain joined machines, and regularly communicated with domain controllers.

That model no longer fits many organisations.

Today, users may be:

Working from home.
Working from multiple offices.
Connecting over VPN.
Using Microsoft Entra joined devices.
Using hybrid joined devices.
Using cloud apps.
Switching between corporate and personal networks.
Accessing resources from laptops, mobiles, and virtual desktops.

This is where Intune becomes valuable.

Instead of relying only on local network connectivity and traditional Group Policy processing, Intune allows policies to be delivered over the internet to managed devices.

However, Intune is not just “Group Policy in the cloud.” That is an important distinction.

Intune uses Mobile Device Management, configuration service providers, settings catalog profiles, administrative templates, scripts, remediation policies, compliance policies, and app management.

Some settings behave similarly to Group Policy, but they are not always processed in exactly the same way.

That difference becomes very important when dealing with mapped network drives.

What Are Configuration Profiles In Intune?

A configuration profile in Intune is a policy object that contains settings you want to apply to users or devices.

For most platforms, Microsoft Intune configuration profiles are created using either Templates or the Settings Catalog.

The Settings Catalog lists available settings in one place, while templates group related settings for specific features such as VPN, email, kiosk devices, and device firmware.

For Windows devices, common configuration profile areas include:

Device restrictions.
Microsoft Defender antivirus.
BitLocker.
Firewall.
OneDrive settings.
Microsoft Edge policies.
Administrative Templates.
Certificates.
VPN profiles.
WiFi profiles.
Custom OMA-URI settings.
Settings Catalog policies.

Once created, the profile is assigned to users or devices. Microsoft’s documentation explains that configuration profiles are assigned through the Intune admin center, where administrators select the profile and edit its assignments.

This is where the important distinction begins.

A profile can be assigned to a user group or a device group, but the settings inside the profile may also be user scoped or device scoped.

Those are related concepts, but they are not the same thing.

User Configuration vs Device Configuration: The Core Difference

The simplest way to understand the difference is this:

A user configuration follows the user. A device configuration follows the device.

That sounds simple, but in practice it has major consequences.

User Configuration

A user configuration applies to the signed in user.

It is best used when the setting is connected to the person, their role, their permissions, or their working environment.

Examples include:

Mapped network drives.
OneDrive user settings.
Browser homepage preferences.
User specific Microsoft Edge policies.
Desktop experience settings.
User based restrictions.
Application preferences.
User shell or Explorer behavior.

A user configuration normally affects areas such as:

HKEY_CURRENT_USER

That means the setting belongs to the user profile, not the physical machine.

Device Configuration

A device configuration applies to the machine itself.

It is best used when the setting should apply regardless of who signs in.

Examples include:

BitLocker encryption.
Firewall configuration.
Defender antivirus settings.
Local security settings.
Device restrictions.
WiFi profiles.
VPN device tunnels.
Certificate deployment.
BIOS or firmware related settings.
Shared device lockdown settings.

A device configuration normally affects areas such as:

HKEY_LOCAL_MACHINE

That means the setting belongs to the device, not a specific user profile.

The Important Intune Nuance: Assignment Target vs Setting Scope

This is where many admins get caught out.

There are two separate questions:

Question 1: Who or what is the policy assigned to?

A policy can be assigned to:

Question 2: What scope does the setting itself use?

The setting itself may be:

The Settings Catalog is where many of these settings are configured. Microsoft explains that the Settings Catalog contains thousands of configurable settings, including administrative templates, with more settings added as Windows exposes more configuration service provider settings to MDM providers.

That distinction matters because assigning a profile to a device group does not magically make every setting a device setting.

For example, a mapped drive is normally a user context object. It appears in File Explorer for the signed in user and is usually stored in the user profile context.

Even if you deploy the policy using Intune, the actual drive mapping still needs to exist in the user’s session.

Network Drive Mapping As The Practical Example

Mapped network drives are a perfect example because they feel like a simple desktop setting, but technically they depend on several moving parts:

The signed in user.
The user's permissions to the file share.
Network connectivity.
DNS resolution.
VPN connectivity if remote.
Kerberos or NTLM authentication.
File Explorer refresh behavior.
Drive persistence.
User profile registry keys.
Whether the mapping is created in user or system context.

A mapped drive is not really a “device setting” in the same way BitLocker or firewall configuration is.

A mapped drive is normally about giving a specific user access to a specific file share.

For example:

The device itself does not need the drive. The user does.

That makes mapped drives naturally suited to user configuration.

Example Scenario: Mapping A Department Drive

Imagine a company has this file share:

\\fileserver01\Finance

The requirement is:

Finance users should see this as:

F:

Now ask the key question:

Should every device get the F: drive?

No.

Only Finance users should get it.

If an IT admin signs into the same laptop, they should not automatically receive the Finance drive unless they are also a member of the Finance access group.

This is a user based requirement.

The correct logic is:

Target the Finance user group.
Apply the mapping when a Fihnance user signs in.
Ensure the user has permission to the share.
Ensure the device can reach the file server.
Ensure the mapping runs in user context.

This is a user configuration use case.

What Happens If You Treat Drive Mapping As A Device Configuration?

If you try to treat drive mapping as purely device based, things can become messy.

For example, suppose you target all Finance laptops instead of Finance users.

That may work if each laptop is permanently assigned to a Finance user.

But what happens when:

A finance laptop is reassigned to another department?
A non finance user signs into the device?
A shared machine is ued by several departments?
The user works remotely and the VPN is not connected at sign in?
The file server is reachable by hostname but not available when the policy runs
The mapping is created under the wrong context?

You can end up with inconsistent behaviour.

Some users may see the drive. Others may not.

Some mappings may appear only after sign out and sign in. Some may require policy sync. Some may exist in the registry but not show in File Explorer.

That is why mapped drives are one of those legacy Windows features where understanding context is critical.

Why User Context Matters For Mapped Drives

Mapped drives are usually visible inside the signed-in user session.

A drive mapped as one user does not automatically appear for another user.

A drive mapped under the SYSTEM account may not appear in the interactive user’s File Explorer session.

That is a major reason why mapped drive scripts or remediation scripts can behave differently depending on whether they run as:

Logged on user.
SYSTEM.
Administrator.
32 bit PowerShell
64 bit PowerShell
Scheduled task.
Login script.
Intune Management Extension script.

This is also why an Intune policy may appear to apply successfully, yet the user still does not see the expected drive.

The policy engine may have done its part, but the user session, network state, or mapping context may not be correct.

Where ADMX Fits In

Administrative Templates, or ADMX backed settings, are another important part of this discussion.

Microsoft’s Intune documentation explains that the Intune Settings Catalog includes Administrative Templates that can be used to manage Windows client devices, and that custom or non Microsoft ADMX and ADML files can also be imported.

This can be useful for scenarios where an organisation wants to reproduce some Group Policy like behaviour through Intune.

However, ADMX backed Intune policies are still not the same thing as classic Group Policy Preferences.

Traditional Group Policy Preferences had a built in “Drive Maps” preference item.

Intune does not offer that exact same legacy experience as a simple native drive mapping profile.

So, in real world Intune environments, mapped drives are often handled using one of these methods:

Custom ADMX templates.
PowerShell scripts.
Remediation scripts.
Win 32 apps that deploy mapping logic
Scheduled tasks running in user context.
Third party drive mapping tools.
Migration away from drive letters toward OneDrive, SharePoint, Teams, or Azure files where appropriate.

User Configuration Profile Example For Network Drives

A user based network drive mapping design may look like this:

Target

Finance users.

Mapping

F: → \\fileserver01\Finance

Assignment

Microsoft Entra security group:

SG-Users-Finance

Expected Behaviour

When a Finance user signs into an Intune managed Windows device, the drive mapping is created for that user.

Why This Makes Sense

The mapping is based on the user’s department and access rights.

The drive should follow the user across their managed devices.

This is the cleanest model when the business requirement is user based access.

Device Configuration Profile Example

A device based configuration may look like this:

Target

All corporate Windows laptops.

Settings

Enable Bitlocker.
Configure Microsoft Defender.
Configure firewall rules.
Deploy WiFi profile.
Apply device restrictions.
Configure local security policies.

Assignment

Microsoft Entra device group:

SG-Devices-Corporate-Windows

Expected Behaviour

Every corporate Windows device receives the same baseline security configuration, regardless of who signs in.

Why This Makes Sense

The settings protect the device itself.

They should not depend on a specific user being logged in.

This is the cleanest model when the business requirement is device security or device behaviour.

The Key Difference Using Drive Mapping

Using network drive mapping as the example:

User Configuration

“Give the user the drives they need when they sign in.”

Device Configuration

“Configure this laptop securely, regardless of who signs in.”

That is the core difference.

A mapped drive is normally about the user’s access to data.

BitLocker, firewall, Defender, and device restrictions are about the endpoint itself.

Common Mistakes With Intune And Drive Mapping

Mistake 1: Assigning User Based Settings Only To Devices

If a setting is user scoped, it still needs a user context to apply properly.

Assigning everything to device groups may look tidy from an admin perspective, but it can create unpredictable results for user specific settings.

Mistake 2: Running Drive Mapping Scripts As SYSTEM

A script running as SYSTEM may successfully create something, but not necessarily in the logged in user’s visible session.

For mapped drives, running in the correct user context is often essential.

Mistake 3: Ignoring VPN Timing

Remote users may not have access to the file server at sign in.

The device may process Intune policy before the VPN is connected.

That means the mapping attempt can fail even though the policy itself is correct.

Mistake 4: Assuming Ping Means SMB Works

Being able to ping a file server does not prove that SMB drive mapping will work.

You also need to confirm:

TCP 445 connectivity.
DNS resolution.
Authentication.
Share permissions.
NTFS permissions.
VPN routing.
Firewall rules.
Conditional access or network restrictions.

Mistake 5: Confusing Policy Success With User Experience Success

Intune may show that a policy applied successfully, but the user may still not see the drive.

That does not always mean Intune failed.

It may mean the mapping was created in the wrong context, the network path was unavailable, or File Explorer did not refresh as expected.

Best Practice Approach

For most environments, I would treat drive mappings as a user experience and access requirement, not as a pure device configuration.

A sensible model would be:

Use Device Configuration For Baseline Security

Apply device profiles for:

BitLocker.
Defender.
Firewall.
Certificates.
WiFi.
VPN.
Device restrictions.
Security baselines.

Use User Configuration For User Experience

Apply user profiles or user context scripts for:

Use Groups Carefully

Use meaningful Microsoft Entra groups such as:

This makes troubleshooting far easier.

Use Assignment Filters Where Needed

Microsoft recommends assigning configuration profiles carefully through Intune’s assignment process, and assignment filters can help refine targeting based on device or app properties.

This can help avoid broad, messy targeting where policies apply to too many devices or users.

When Device Assignment Can Still Make Sense For User Settings

There are edge cases where assigning a user scoped setting to a device group may still be valid.

For example:

A shared training room device where every user should get the same user experience.
A fixed purpose machine used by a small controlled group.
A kiosk like environment.
A lab machine with predictable usage.
A device group where all users should receive the same setting when signing in.

That is powerful, but it must be used carefully.

For mapped drives, user group targeting is usually cleaner because the drive should normally follow the person, not the physical device.

Troubleshooting Drive Mapping In Intune

When a drive mapping does not appear, troubleshoot in layers.

1. Confirm Policy Assignment

Check whether the policy is assigned to the correct:

2. Confirm User Context

Check whether the mapping logic runs as:

For mapped drives, this matters a lot.

3. Confirm Registry Location

Persistent user drive mappings are commonly associated with the user profile context, especially under:

HKEY_CURRENT_USER\Network

If you are checking the registry, make sure you are checking the correct user hive.

4. Confirm Network Access

Test:

DNS name resolution.
SMB access.
Share permissions.
NTFS Permissions
VPN connectivity.
Firewall rules.
TCP 445.

5. Confirm Timing

If the user is remote, the drive may fail to map because the VPN is not connected when the mapping logic runs.

In those cases, remediation scripts, scheduled tasks, or user triggered reconnect logic may be more reliable than a one time sign in mapping.

6. Confirm File Explorer Refresh

Sometimes the mapping exists, but File Explorer does not immediately display it.

Signing out and back in, restarting Explorer, or refreshing the user session may reveal whether the drive exists but is not being displayed properly.

Intune Is Not Just Cloud Group Policy

One of the biggest mindset shifts with Intune is accepting that it is not simply Group Policy moved into the cloud.

Group Policy was built for domain joined machines regularly connected to domain controllers.

Intune is built for modern endpoint management where devices may be internet connected, cloud joined, hybrid joined, remote, mobile, or intermittently connected.

That means admins need to think differently.

Instead of asking:

“How do I recreate every GPO?”

A better question is:

“What is the outcome I need, and should it be applied to the user, the device, the app, or the data?”

That question leads to cleaner policy design.

Why This Matters For Security

Good Intune design is not just about making settings apply successfully.

It is also about security.

Poorly scoped policies can:

Give users access to resources they do not need.
Leave devices inconsistently configured.
Make troubleshooting harder.
Increase privilege and access sprawl.
Create hidden dependencies on VPN or legacy infrastructure.
Break the user experience in ways that users work around insecurely.

A well designed Intune environment supports Zero Trust principles by applying the right configuration to the right identity, on the right device, under the right conditions.

This links naturally to the broader endpoint hardening discussion which you can read about in my other blog post entitled Windows 11 Privacy Hardening vs Hardened Linux Workstations, where endpoint control, trust boundaries, visibility, and governance are presented as core parts of modern workstation security.

It also connects with Hardening Windows 11 and Reclaiming Your Security, which focuses on practical steps organisations and users can take to regain more control over the Windows endpoint.

Final Thoughts

Microsoft Intune is a powerful cloud based endpoint management platform, but it requires a different way of thinking from traditional Group Policy.

The difference between user configuration and device configuration is one of the most important concepts to understand.

A simple rule of thumb is:

If the setting should follow the person, think user configuration.
If the setting should stay with the machine, think device configuration.

Mapped network drives are a perfect example.

A mapped drive is usually about the user’s access to data, not the device itself.

That means it normally belongs in a user based design, targeted through user groups and applied in the correct user context.

Device configuration, on the other hand, is where baseline security belongs: BitLocker, Defender, firewall, certificates, Wi-Fi, VPN, and restrictions that should apply no matter who signs in.

Getting this distinction right makes Intune cleaner, more reliable, more secure, and much easier to troubleshoot.

Call To Action

If your organisation is moving from Group Policy to Microsoft Intune, do not simply copy every old policy into the cloud.

Review each setting and ask:

Does this belong to the user, the device, the app, or the data?

That single question can prevent hours of troubleshooting and help you build a stronger, cleaner endpoint management strategy.

Leave your thoughts and comments down below, and follow Eagle Eye Technology for more cybersecurity, endpoint management, and infrastructure security insights.

Sources

EagleEye Technology Related Blog Posts