All posts in category Intune

90 DAYS LEFT: Windows Server 2016 End of Life January 2027 – Plan Your AD CS Migration Now

Heads up, fellow Windows Server administrators! There are now just THREE MONTHS remaining before Windows Server 2016 reaches end of support, so now is the time to finalize any migrations for workloads hosted on this platform. Mainstream support ended on January 11, 2022, and Windows Server 2016 has since remained in extended support. However, extended support ends on January 12, 2027. After that date, Microsoft will no longer provide security updates or technical support, increasing the risk of running production workloads due to exposure to newly discovered vulnerabilities and exploits.

Active Directory Certificate Services

Many organizations are still running critical infrastructure on Windows Server 2016. Administrators often delay upgrading Microsoft Active Directory Certificate Services (AD CS) due to its complexity. However, a well-planned AD CS migration not only reduces risk but also provides an opportunity to modernize cryptography, certificate templates, and operational practices.

Certificate Authorities

Administrators must carefully migrate Certificate Authorities (CAs) running on Windows Server 2016 to minimize downtime. In environments where ongoing CA maintenance has been limited, migrating the CA database can be especially challenging. If the CA is installed on a domain controller, now is a good time to consider separating these services to ensure reliable operation. Also, it’s a good idea to evaluate the CA’s configuration and security posture during migration to enhance security and improve service resilience.

NDES Servers

Microsoft Network Device Enrollment Services (NDES) servers, commonly deployed to facilitate certificate enrollment via Microsoft Intune, pose a unique challenge during migration. Unfortunately, configuring NDES is exceedingly complex and error-prone. NDES relies on a delicate combination of specialized IIS configuration, AD service accounts, custom certificate templates, and CA permissions, making even minor changes risky without proper planning. Not surprisingly, administrators are often hesitant to touch these systems as they are notoriously difficult to troubleshoot when problems arise.

Pro Tip: We spend an entire day covering NDES configuration in the Mastering Enterprise PKI Certificates with Microsoft Intune training course. The next session is September 1-3, 2026. Register now!

Intune Certificate Connectors

Don’t overlook Windows Server 2016 servers with the Intune Certificate Connector installed. Fortunately, this is one of the more manageable workloads to migrate. All that’s required is to install new connectors on supported servers and delete the old ones.

Summary

With extended support for Windows Server 2016 ending on January 12, 2027, organizations running production workloads—especially critical infrastructure such as Active Directory Certificate Services (AD CS), Certificate Authorities (CAs), and NDES servers—face significant security risks from unpatched vulnerabilities once the OS reaches end-of-life. Careful migration planning to newer versions such as Windows Server 2022 or 2025 is essential to minimize downtime, improve security posture, and ensure long-term resilience.

Start Planning Now

Don’t risk running unsupported workloads in 2027! Complete your migration today. If you’d like expert guidance, I have many years of experience migrating these workloads. I have developed specialized tools and techniques to ensure a smooth, secure, and successful transition. Fill out the form below to schedule a free one-hour consultation to assess your Windows Server 2016 AD CS workloads, identify migration risks, and outline next steps.

Additional Information

Windows Server 2016 Lifecycle Policy

PKI Fundamentals with Microsoft Active Directory Certificate Services (AD CS) Online Training Course

Mastering Enterprise PKI Certificates with Microsoft Intune Online Training Course

Microsoft Intune Certificate Connector Configuration Failed – String Cannot Be of Zero Length

When deploying on-premises enterprise PKI certificates using Microsoft Intune with Simple Certificate Enrollment Protocol (SCEP) certificate profiles, administrators must deploy a Windows Server with the Network Device Enrollment Service (NDES) role installed. Once configured, the Microsoft Intune Certificate Connector can be installed and configured to allow administrators to issue and manage certificates for their Intune-managed endpoints.

Configuration Failed

After configuring NDES, administrators may encounter an error message when installing the Microsoft Intune Certificate Connector. The message states:

Configuration Failed

Configuring Microsoft Intune Certificate Connector failed. No changes were made to Feature or Proxy settings. Please try again.

Unexpected Failure. Error: System.ArgumentException: String cannot be of zero length.
Parameter name: name
at System.Security. PrincipaI.NTAccount..ctor(String name)
at Microsoft.lntune.Connectors.ConfigUlScep.SetServiceUserPermissions(String username)
at Microsoft.lntune.Connectors.ConfigUlScep.SetNdesUserPermissions(String username)
at Microsoft.lntune.Connectors.ConfigUlScep.Enable()
at Microsoft.Intune.Connectors.ConfigUI.ApplyConfiguration.<ApplyChanges>d__10.MoveNext()

Missing Service Account

This error occurs because the administrator configured the NDES role using the default application pool identity, which the Intune Certificate connector does not support.

Resolution

To resolve this issue, configure the SCEP application pool to run as a Group Managed Service Account (gMSA), which is a security best practice. Alternatively, you can configure the SCEP application pool to run as a regular domain service account (not recommended).

SCEP Application Pool Configuration

To update the SCEP application pool to run as a gMSA or domain service account, add the service account to the IIS_IUSRS group. If running as a domain service account and not a gMSA, be sure to also grant the service account the Logon as a Service right.

Next, open Internet Information Services (IIS) Manager (inetmgr.exe) and follow the steps below.

Expand the NDES server in the navigation tree.
Highlight Application Pools.
Right-click the SCEP application pool and choose Advanced Settings.
In the Process Model section, highlight Identity.
Click the ellipses next to ApplicationPoolIdentity.
Select Custom account.
Click Set.
Enter the service account using the domain\username format. Be sure to include the trailing $ when specifying a gMSA.
If using a standard domain service account, enter and confirm the password.
Click Ok three times.
Finally, stop and start the application pool for the changes to take effect.

Note: Using a gMSA requires additional configuration in the domain. Details here.

Once complete, be sure to assign the Request Certificates permission to the gMSA or domain service account on the issuing certification authority (CA) server. In addition, assign Enroll permission to the service account on the NDES certificate template in Active Directory (AD).

Intune Certificate Connector

The Intune Certificate Connector does not support running under a gMSA. However, when using NDES/SCEP, it’s acceptable to run the connector service under the SYSTEM account. Ensure the connector server’s computer account is granted Issue and Manage Certificates permissions on the issuing CA server.

Summary

For NDES used with Intune SCEP certificate profiles, a group Managed Service Account (gMSA) is the preferred service account. A standard domain user account is supported if a gMSA is not an option. Specify the account when you configure the NDES role or leave the default ApplicationPoolIdentity and replace it with the gMSA before installing the Intune Certificate Connector.

Additional Information

Microsoft NDES Information Disclosure: Detection and Remediation

Microsoft NDES Security Hardening: Protecting and Monitoring the SCEP Registry Configuration

Troubleshooting NDES Error 0x80070003 Path Not Found on Windows Server 2025

Troubleshooting NDES Error 0x80094800 Unsupported Cert Type on Windows Server 2025

Training: Mastering Enterprise PKI Certificates with Microsoft Intune

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.

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.
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.
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.
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.
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.
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

Richard M. Hicks Consulting, Inc.

Microsoft MVP

Consulting

Pluralsight

Newsletter

All posts in category Intune

90 DAYS LEFT: Windows Server 2016 End of Life January 2027 – Plan Your AD CS Migration Now