Cisco, GlobalProtect, Zscaler and F5 VPN profiles in Intune: per-app VPN and errors

Intune has built-in VPN profile types for Cisco, Palo Alto Networks, Zscaler, F5 and others, but the mechanism changes by platform: sometimes a VPN profile configures the client, sometimes only an app configuration policy can. Most failures come down to that choice, the certificate chain or a Windows reporting quirk. In this post I'll map what each platform supports, decode the errors and show where the client logs live.

Symptoms#

• A Windows VPN profile, often a custom OMA-URI one, shows an error although users connect fine.
• A profile shows Conflict or Not applicable for some devices.
• The vendor you need isn't offered as a connection type for a platform, or the VPN app on an Android Enterprise device has no connection configured.
• Windows 11 devices lose VPN connectivity right after you edit or swap a VPN profile.
• The profile installs, but the connection fails with certificate or authentication errors in the VPN client.

The statuses and codes you'll see in the Intune admin center:

2016281112 (Remediation Failed)
0x87D1FDE8
Conflict
Not applicable

0x87D1FDE8 and -2016281112 are the same 32-bit value, shown in hex and as a signed decimal.

Why it happens#

Profile or app configuration?#

Microsoft's connection-type list (as published in mid-2026; re-check it) decides the mechanism:

Where a vendor isn't offered as a profile connection type, its client has to be configured through an app configuration policy instead. Profiles assigned to groups that contain other platforms show Not applicable on those devices (an iOS/iPadOS profile doesn't apply to Android). And the vendor's app must be deployed before the profile.

Other common causes#

• Certificate chain: with certificate authentication, the VPN profile picks a SCEP or PKCS profile as the identity certificate. Microsoft says to assign the VPN, certificate and trusted root profiles to the same groups, and PKCS imported certificates aren't supported for VPN authentication.
• XML comparison on Windows: for custom VPN profiles built with OMA-URI, Windows can return the VPN XML formatted differently from what Intune sent. Intune treats the mismatch as a remediation failure even though the profile works. Microsoft's article describes this on Windows 10 up to version 1809.
• Conflict: two or more profiles configure the same setting with different values.
• Windows 11 VPNv2 issue: Microsoft documents that a device processing several VPN profile changes at once (editing a profile, two new profiles together, or removing one while assigning another) loses VPN connectivity until its next check-in. Windows 11 also needs all or none of the IKE and child security association parameters configured.
• Per-app VPN wiring: on iOS/iPadOS and macOS user enrollment only per-app VPN is supported, and apps only use the tunnel when they're managed and associated with the profile.

How to fix it#

1. Use the right mechanism. For app-configuration types (GlobalProtect, Zscaler and Check Point on Android Enterprise), use the vendor's managed configuration keys from their Intune guide. Otherwise create the profile under Devices › Manage devices › Configuration › Create › New policy, choose the platform and Templates › VPN, then pick the vendor's connection type.
2. Prove the certificate chain first. On Devices › All devices › device › Device configuration, the trusted root and SCEP/PKCS profiles must succeed before the VPN profile can. If they don't, follow the SCEP/PKCS certificate chain guide or consider Microsoft Cloud PKI.
3. Handle 2016281112 on custom Windows profiles. If users connect, Microsoft says you can safely ignore the error; on current builds, prove it with a connection test before you do. The cleaner fix is to rebuild the connection as a built-in Windows VPN profile, which doesn't produce it. For any other 0x87D1FDE8, open the per-setting status to see which setting failed; the 65000 and remediation failed guide covers the general causes.
4. Resolve conflicts. Keep one profile per connection name and platform, check whether something else on the device already defines that connection (such as a manually created VPN with the same name), and use the MDM diagnostic report to find the competing source.
5. Change Windows 11 VPN profiles one at a time. Don't remove an active profile and assign its replacement in the same change. If users lost the tunnel, a second sync restores it.
6. Wire per-app VPN properly. On iOS/iPadOS, set Automatic VPN to Per-app VPN in the profile (use on-demand or per-app, not both; per-app isn't supported on IKEv2), then select that VPN profile in each managed app's assignment. On Android Enterprise, the VPN profile has its own Per-app VPN section where you add the managed apps that use the tunnel; for app-configuration types, use the vendor's managed configuration keys instead.
7. Read the client side. On Windows, check the MDM event log and the VPN entries:

# Intune policy processing (look for VPNv2 entries)
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" -MaxEvents 300 |
  Where-Object Message -match "VPNv2" |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

# VPN connections Windows knows about (run as the signed-in user)
Get-VpnConnection | Select-Object Name, ServerAddress, ConnectionStatus
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, ConnectionStatus

# Connection attempts made through the Windows VPN platform
Get-WinEvent -FilterHashtable @{LogName="Application"; ProviderName="RasClient"} -MaxEvents 20 |
  Select-Object TimeCreated, Id, Message

For deeper Windows detail, export the management logs from Settings › Accounts › Access work or school; the report lands in C:\Users\Public\Documents\MDMDiagnostics. On iPhone, iPad and Mac, collect device logs with the Console app on a Mac and search for the VPN profile name. If the profile is on the device but the tunnel won't come up, Microsoft notes it's typically not an Intune problem: the VPN client app's logs (and, for Windows, the RADIUS server logs) usually hold the real error, along with the VPN gateway's own logs.

Verify the fix#

• The VPN, certificate and trusted root profiles all show success on the device, with no failed settings.
• On Windows, Get-VpnConnection lists the connection name and a test connection reaches Connected; with Always On, it reconnects after a restart and sign-in.
• On mobile devices, the connection appears in the VPN settings.
• For per-app VPN, an associated app brings the tunnel up, and an unassociated app doesn't use it.
• The VPN gateway logs show the device authenticating with the Intune-issued certificate.

Prevent it next time#

• Deploy in order (VPN app, trusted root, identity certificate, VPN profile) to the same groups, and keep the group type consistent: user groups for user certificates, device groups for device certificates.
• Batch VPN profile changes for Windows 11 into planned, single changes and pilot them first.
• For Cisco ISE posture checks, Microsoft's Apple VPN settings say to integrate ISE with Intune and enable network access control (NAC) in the iOS/iPadOS VPN profile so the device ID is included. Profiles built on the original NAC service must be redeployed to move to the Compliance Retrieval Service.
• Considering Microsoft's own client? See Microsoft Tunnel setup and troubleshooting.

References#

• Create VPN profiles to connect to VPN servers in Intune (Microsoft Learn)
• Troubleshooting VPN profile issues in Microsoft Intune (Microsoft Learn)
• Add VPN settings to Apple devices in Microsoft Intune (Microsoft Learn)
• Android Enterprise device settings to configure VPN in Intune (Microsoft Learn)