When configuring certificates for Remote Desktop Services (RDS) farms, many administrators encounter a peculiar issue where the GUI fails to reflect actual certificate assignments after reopening the deployment properties. While the certificates continue functioning (as evidenced by RD Web Access working without errors), the management console stubbornly displays "Not Configured" status.

To verify whether your certificate is truly being used despite the GUI display:

# Check currently bound certificates for RD Web Access
Get-ChildItem -Path IIS:\SslBindings | Where-Object { $_.Sites -match "RDWeb" }

# Alternative PowerShell verification:
Get-RDCertificate -Role RDWebAccess -ConnectionBroker [YourBrokerFQDN]

The most reliable approach involves bypassing the GUI entirely. Here are two methods:

Method 1: PowerShell Configuration

Import-Module RemoteDesktop

# For RDWebAccess role
Set-RDCertificate -Role RDWebAccess -ImportPath "C:\certs\rdwa.pfx" \
  -Password (ConvertTo-SecureString -String "YourPassword" -AsPlainText -Force) \
  -ConnectionBroker "rdcb.yourdomain.com"

# Verify all roles
Get-RDCertificate -ConnectionBroker "rdcb.yourdomain.com" | Format-List

Method 2: Direct Certificate Store Management

1. Import the certificate to the Local Computer's Personal store
2. Assign appropriate permissions using:

# Grant Network Service access to private key
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -match "yourcertname" }
$rsaCert = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($cert)
$fileName = $rsaCert.key.UniqueName
$path = "$env:ProgramData\Microsoft\Crypto\RSA\MachineKeys\$fileName"
$acl = Get-Acl -Path $path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("NT AUTHORITY\NETWORK SERVICE","Read","Allow")
$acl.AddAccessRule($rule)
Set-Acl -Path $path -AclObject $acl

Ensure your certificate meets all technical requirements:

• Subject Alternative Name: Must include all accessed FQDNs
• Key Usage: Digital Signature, Key Agreement (minimum)
• Enhanced Key Usage: Server Authentication (Client Authentication recommended)
• Private Key: Must be marked as exportable during creation

Certificate assignments are actually stored in the registry. You can verify them at:

# For RDWebAccess
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDMS\Certificates\RDWebAccess"

# For RDPublishing
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDMS\Certificates\RDPublishing"

If the GUI still won't reflect your changes after trying these methods, consider these last-resort options:

# 1. Reset RDS configuration store
Invoke-RDUserLogoff -HostServer $env:COMPUTERNAME -Force
Restart-Service TermService -Force

# 2. Recreate self-signed cert then replace (often "unsticks" the GUI)
New-RDCertificate -Role RDWebAccess -ConnectionBroker "rdcb.yourdomain.com" -Force
Set-RDCertificate -Role RDWebAccess -ImportPath "C:\certs\realcert.pfx" -Password $securePass

Many administrators encounter a peculiar behavior when configuring certificates for Remote Desktop Services (RDS) farms where the GUI fails to maintain certificate settings despite certificates being functionally applied. This creates confusion about whether the configuration was successful.

Through experimentation with RD Web Access self-signed certificates, we've identified these critical certificate properties:

# Required certificate properties:
- Enhanced Key Usage:
  • Server Authentication (1.3.6.1.5.5.7.3.1)
  • Client Authentication (1.3.6.1.5.5.7.3.2)
- Key Usage:
  • Digital Signature
  • Key Agreement
- Subject Alternative Name:
  • DNS Name matching your domain

The New-RDCertificate cmdlet documentation often omits a crucial step. Here's the corrected process:

# First import the required module
Import-Module RemoteDesktop

# Then create the certificate
$password = ConvertTo-SecureString -string "YourSecurePassword" -asplaintext -force
New-RDCertificate -Role RDWebAccess -DnsName "rds.example.com" 
    -Password $password -ConnectionBroker "rdcb.example.com" 
    -ExportPath "C:\rds-cert.pfx"

The Server Manager interface shows misleading "Not Configured" status even when certificates are properly applied. This appears to be a UI refresh issue rather than a functional problem. Verification steps:

1. Check IIS bindings on RD Web Access server
2. Verify certificate assignment via MMC
3. Test HTTPS connectivity

For reliable certificate assignment, consider these PowerShell alternatives:

# Assign certificate to RD Web Access
Set-RDCertificate -Role RDWebAccess -ImportPath "C:\rds-cert.pfx" 
    -Password $password -ConnectionBroker "rdcb.example.com" -Force

# Verify certificate assignment
Get-RDCertificate -Role RDWebAccess -ConnectionBroker "rdcb.example.com"

To ensure persistent certificate configuration:

• Document all certificate thumbprints used in the farm
• Create a verification script that checks certificate assignments
• Consider using Group Policy for certificate deployment

This script helps validate certificate assignments across the RDS farm:

function Test-RDSCertificates {
    param(
        [string]$ConnectionBroker
    )
    
    $roles = @("RDPublishing", "RDGateway", "RDWebAccess")
    
    foreach ($role in $roles) {
        try {
            $cert = Get-RDCertificate -Role $role -ConnectionBroker $ConnectionBroker -ErrorAction Stop
            Write-Host "[$role] Certificate assigned:" -ForegroundColor Green
            Write-Host "  Thumbprint: $($cert.Thumbprint)"
            Write-Host "  Expires: $($cert.NotAfter)"
        }
        catch {
            Write-Host "[$role] Certificate not assigned or error occurred" -ForegroundColor Yellow
        }
    }
}