Entra Global Secure Access (GSA) Client Intune Deployment PowerShell Script

The Microsoft Entra Global Secure Access (GSA) client is commonly deployed using Microsoft Intune. To deploy the client as an Intune Win32 app, administrators package the installer and a PowerShell installation script into an .intunewin file. Microsoft provides a sample PowerShell script that creates a log, configures Windows to prefer IPv4 over IPv6, and launches the installer. However, the sample has several limitations that can make it unreliable in production environments. To address these shortcomings, I’ve refactored the code to make it more robust and better aligned with enterprise deployment best practices.

Script Improvements

Microsoft’s PowerShell script for installing the GSA client has several significant limitations. My refactored version includes the following improvements.

  1. Preserved the existing DisabledComponents setting. Microsoft’s example overwrites the entire registry value, potentially removing previously configured settings. My version sets the 0x20 bit to prefer IPv4 while preserving any other flags already present.
  2. Validates the installer’s Authenticode signature. My revised script verifies that the installer has a valid Authenticode signature and that the signing certificate identifies Microsoft Corporation as the publisher.
  3. Preserves the pending reboot state. My script records when the registry setting was changed and compares that timestamp with the device’s last boot time. If the device has not restarted, subsequent runs continue to return exit code 3010, even if an earlier installation attempt failed.
  4. Expanded exit-code handling. The script writes a timestamped PowerShell transcript to the Intune Management Extension log directory, allowing it to be included with collected Intune diagnostics. Logging failures do not prevent the installation from continuing.
  5. Intune-integrated logging. I’ve updated the script’s logging to use the Intune Management Extensions logs folder, so logs are captured by Intune’s diagnostics collection. Each run of the script generates its own timestamped log file, making troubleshooting easier. Also, logging failures never block installation.
  6. Best practice alignment. I’ve added comment-based help, culture-invariant timestamps, and a $PSScriptRoot guard with a clean error to handle script execution issues. In addition, the script is digitally signed to support environments that enforce signed-script execution policies.

GitHub

I’ve published my refactored GSA client installation script on GitHub. You can download the script here:

https://github.com/richardhicks/gsa/blob/main/Install-GSAClient.ps1

Note: The script expects the installer to be named GlobalSecureAccessInstaller.exe. However, downloaded installers typically include the version number in the filename, such as GlobalSecureAccessInstaller_<version>.exe. Before creating the .intunewin package, either rename the installer or update the $InstallerName variable in the script.

Contribute

Suggestions and contributions are welcome. If you have ideas for making the GSA client deployment more robust or reliable, please submit a pull request on GitHub.

Summary

Microsoft provides a PowerShell script to deploy the Entra GSA client via Intune, but it has several limitations. This refactored version preserves existing registry settings, validates the installer, improves reboot and exit-code handling, integrates logging with Intune diagnostics, and better aligns with enterprise deployment best practices.

Additional Information

Install-GSAClient.ps1 PowerShell Script on GitHub

Prepare Win32 App Content for Upload to Microsoft Intune

Install the Global Secure Access Client for Microsoft Windows

What’s New in Always On VPN DPC v5.4.0

A new edition of the popular Always On VPN Dynamic Profile Configurator (DPC) is now available. Version 5.4.0, released on May 5, 2026, includes some new features, reliability improvements, and additional miscellaneous fixes.

What’s New in DPC v5.4.0

The following new features and improvements are included in the latest release of DPC.

Signed Binaries

Beginning with release v5.4.0, all binaries, including the installer, are digitally signed. This streamlines the installation process and allows DPC to better integrate with application controls.

EAP-TLS

By popular demand, EAP-TLS support has been added as an authentication option in DPC. Historically, DPC strictly adhered to security best practices and only allowed Protected EAP (PEAP). However, many administrators required EAP-TLS to better integrate with non-Microsoft VPN services.

Additional Enhancements

Other changes include better profile change comparison and a new logo. In addition, the DPC ADMX files are now publicly accessible on ADMScope.

Summary

Administrators running earlier versions of DPC are encouraged to upgrade to v5.4.0 as soon as possible.

Additional Information

Always On VPN DPC v5.4.0 on GitHub

Resolving PKCS Certificate Mapping Issues in Windows Autopilot Hybrid Join Deployments

Microsoft Windows Autopilot streamlines device provisioning through Intune, allowing IT administrators to preconfigure new Windows devices with minimal hands-on effort. However, when combined with Hybrid Entra Join and PKCS certificate deployment, specific challenges arise—particularly with certificate mapping and authentication.

Hybrid Entra Join

During autopilot provisioning, administrators may also choose to join the device to their on-premises Active Directory domain, a deployment model called Hybrid Entra join. Hybrid Entra join presents some unique challenges when using Autopilot to remotely provision devices. Specifically, the user must have connectivity to a domain controller to perform the first logon, as they do not have a user profile on the endpoint.

Device Tunnel

To support offline Hybrid Entra join during Autopilot provisioning, administrators can deploy the Always On VPN device tunnel to provide pre-logon connectivity to domain controllers. A device tunnel connection enables users to log on to their newly provisioned device remotely.

Requirements

The following prerequisites must be met to support the Always On VPN device tunnel.

  • The endpoint must be running Windows Enterprise edition.
  • An Always On VPN device tunnel profile must be assigned to the device.
  • A machine certificate must be deployed to the endpoint that includes the Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2).

Note: If you plan to use the subscription step-up upgrade from Windows Professional to Windows Enterprise, the device tunnel will not connect automatically after provisioning is complete, which prevents the user from logging in. More details and a workaround for this issue can be found here.

Strong Certificate Mapping

Microsoft knowledge base article KB5014754, released in May of 2022, introduced changes to domain controllers to require strong certificate mapping when using certificates to authenticate to Active Directory (AD). It was initially deployed in compatibility mode, only warning administrators when certificates are used for authentication that aren’t strongly mapped. However, full enforcement is mandatory beginning with the September 2025 security updates. This requirement introduces some challenges when issuing certificates to the device using PKCS during Autopilot provisioning.

Intune PKCS Certificates

When using PKCS certificates and the Intune Certificate Connector, the endpoint’s on-premises AD security identifier (SID) is not added to the issued certificate during Autopilot. Interestingly, this does not happen when using SCEP certificates. If the device certificate is not strongly mapped, the Always On VPN device tunnel will still authenticate successfully because Always On VPN does not use AD to authenticate device connections. Instead, Always On VPN simply verifies the certificate (e.g., that it is not expired or revoked) and allows authentication if the certificate passes the validation.

However, enterprise Wi-Fi access may fail without strongly mapped certificates if device authentication is required. Also, there may be other scenarios where a device authentication certificate without strong mapping may cause authentication to fail.

Workarounds

There are a few ways to work around this limitation. Consider the following options.

Native Entra ID Join

The simplest way to avoid the challenges of PKCS certificates and Hybrid Entra join is to avoid it altogether in favor of native Entra join. However, this may not be an option for everyone.

Use SCEP

For some reason, certificates issued with SCEP do not suffer from this limitation. In my testing, SCEP certificates are always strongly mapped. However, deploying SCEP certificates is much more complex than using PKCS. (Pro tip: Cloud PKI for Intune uses SCEP and requires no configuration! It’s definitely something to consider.)

Short-Lived Certificates

Another option is to deploy temporary, short-lived certificates (valid for only a few days) using PKCS to ensure the Always On VPN device tunnel works, and then deploy a permanent, long-term certificate post-deployment that includes the strong mapping. To do this, administrators can leverage dynamic group assignments in Intune. For example, the administrator can assign the short-lived certificate to an Autopilot Provisioning devices group and later assign a long-term certificate to the Hybrid Joined devices group.

Here’s an example of the dynamic group membership configuration.

Autopilot Provisioning Devices:

(device.devicePhysicalIDs -any (_ -contains “[ZTDId]”)) -and (device.deviceTrustType -ne “ServerAD”)

Hybrid Entra Join Devices:

(device.deviceTrustType -eq “ServerAD”)

In this configuration, the initial PKCS certificate is deployed without the strong mapping when the endpoint is enrolled to Autopilot but has not yet joined the domain. During this time, the endpoint will only be a member of the Autopilot Provisioning Devices group and will receive the short-lived, temporary certificate. Later, once the endpoint has successfully joined the domain, the device will move from the provisioning group to the Hybrid Entra Join Devices group. When this happens, a permanent, strongly mapped long-term certificate is enrolled on the device.

Manual Certificate Mapping

Certificates can be manually mapped via the altSecurityIdentities property of the computer object in AD. Obviously, this doesn’t scale well, so my good friend Steve Prentice published a PowerShell script to automate this process. You can find more details and the script here.

Summary

Windows Autopilot streamlines device provisioning with Intune, but Hybrid Entra Join introduces challenges when PKCS certificates lack strong mapping during initial deployment, potentially disrupting VPN and Wi-Fi authentication. Administrators can avoid this by switching to native Entra join or by using workarounds such as switching to SCEP, using short-lived certificates, or manually mapping certificates.

Additional Information

KB5014754 – Certificate-based authentication changes on Windows domain controllers

How To: Map a user to a certificate via all methods available in the altSecurityIdentities attribute

Hybrid Autopilot: Automating altSecurityIdentities

Configure Microsoft Entra hybrid join

Overview: Cloud PKI for Microsoft Intune