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

Always On VPN Dynamic Profile Configurator (DPC) Webinar

Managing Microsoft Always On VPN deployments doesn’t have to be complicated. Always On VPN Dynamic Profile Configurator (DPC) is a free, open-source solution that simplifies deploying and managing Always On VPN client configuration settings while extending the capabilities of native deployment methods such as Microsoft Intune VPN profiles, custom XML, and PowerShell scripts.

Whether you’re deploying Always On VPN for the first time or looking to streamline an existing implementation, DPC provides powerful features that make advanced VPN configuration easier to deploy, manage, and maintain.

Join Our Live Webinar

Join me on Tuesday, August 18, at 1:00 PM EDT for a live webinar featuring Leo D’Arcy, creator and lead developer of Always On VPN DPC. During this live session, we’ll demonstrate many of DPC’s latest capabilities and show how they can simplify even the most complex Always On VPN deployments. Topics include:

  • Configuring flexible VPN deployment strategies
  • Optimizing interface and route metrics
  • Dynamically excluding Microsoft 365 and custom domains from the VPN tunnel
  • Configuring IKE mobility settings for improved roaming
  • Defining and managing IPv6 routes
  • Deploying DPC using Active Directory and Microsoft Intune
  • Exploring additional advanced features and deployment scenarios

Throughout the webinar, we’ll share practical guidance, configuration tips, and real-world examples to help you get the most from Always On VPN DPC.

Register Today

Registration is free, but you must register in advance to attend. If you can’t attend the live session, register anyway, and you’ll receive access to the on-demand recording after the event.

We’ll also reserve time for a live Q&A at the end of the presentation, giving you the opportunity to ask questions directly to the developers and experts behind DPC.

We look forward to seeing you there!

Additional Information

Always On VPN Dynamic Profile Configurator (DPC)

Always On VPN DPC Advanced Features

Always On VPN DPC with Microsoft Intune

Migrating from Always On VPN DPC Commercial to Open Source

Always On VPN DPC Commercial Support Now Available

Always On VPN DPC Discord Channel

Microsoft AD CS Adds Post-Quantum Cryptography Support with ML-DSA

Despite predictions of its decline, Microsoft Active Directory Certificate Services (AD CS) continues to evolve. Following significant enhancements introduced in late 2025, including CRL partitioning and support for 16K database pages, the May 2026 update adds another important capability: support for Post-Quantum Cryptography (PQC).

ML-DSA

Specifically, the May 2026 update adds support for ML-DSA-44, ML-DSA-65, and ML-DSA-87 in Windows Server 2025 for AD CS. This enables administrators to begin evaluating post-quantum cryptographic algorithms and assessing PQC readiness in enterprise PKI environments

Configuration

After applying the May 2026 update to an issuing Certification Authority (CA), administrators will find new PQC algorithms under the Algorithm name drop-down list, as shown here.

Note: If you don’t see these new algorithms, ensure you have selected Key Storage Provider from the Provider Category drop-down list. In addition, ensure that you select Signature on the Request Handling tab.

Test Results

Initial testing across common enterprise certificate scenarios produced mixed results. While PQC works well in some scenarios, other workloads still show limitations.

Code Signing

Code signing with an ML-DSA-44 certificate issued by AD CS works perfectly. For example, I can use Set-AuthenticodeSignature to sign a PowerShell script, as shown here.

Viewing the file’s properties shows that the encryption algorithm used to sign the file was ML-DSA-44, as expected.

IIS

TLS-based workloads proved more challenging. Attempts to configure an HTTPS binding in IIS failed with the following error message.

There was an error while performing this operation. A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520).

RRAS and SSTP

Similar limitations occurred when testing remote-access VPN scenarios using RRAS and SSTP. Specifically, configuring a PQC TLS certificate for SSTP in RRAS failed. Although I was able to assign the certificate using Set-RemoteAccess, the RemoteAccess service failed to start.

Remote Desktop

Unfortunately, using PQC certificates for RDP also fails. Although I could assign the PQC certificate to the RDP listener, clients fail to connect using RDP and return the following error message.

This computer can’t connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

Error code: 0x904
Extended error code: 0x7

Summary

The May 2026 update marks an important milestone for AD CS by introducing initial support for PQC algorithms, allowing organizations to begin evaluating ML-DSA certificates in enterprise environments. Early testing shows promising results for signing scenarios such as code signing; however, broader infrastructure workloads, including TLS, VPN, and Remote Desktop, remain limited today. Although PQC support is still in its early stages, these updates demonstrate Microsoft’s ongoing investment in AD CS and provide administrators with an opportunity to begin preparing their PKI environments for the post-quantum future. Additional PQC enhancements, including ML-KEM support and broader ecosystem integration, are anticipated in future Windows updates.

Additional Information

Microsoft May 2026 Security Updates (KB5087539)

Post Quantum Cryptography in the Enterprise