In our environment, we use several gMSA accounts, which are more secure than conventional service accounts. While testing our scripts on Windows Server 2025, we ran into issues when installing a gMSA.

Install-ADServiceAccount : Cannot install service account. Error Message: ‘The provided context did not match the target.’

We began by double checking the gMSA itself. To rule out account issues, we tested installing the gMSA on an older Windows Server 2022 system, where everything worked as expected. Next, we checked the PrincipalsAllowedToRetrieveManagedPassword attribute using:

Read more: Troubleshooting gMSA Installation Failure Caused by Kerberos Encryption Mismatch (28 vs 24)
Get-ADServiceAccount -Identity 'gMSA Accountname' -Properties PrincipalsAllowedToRetrieveManagedPassword

This confirmed that the Windows Server 2025 host was authorized to use the gMSA. We also noticed that the affected gMSAs failed the following test:

Test-ADServiceAccount -Identity 'gMSA Accountname'

On Windows Server 2025, this command returned False, indicating the account could not be used successfully.

It took us a while to realize the issue was encryption related. The security baseline on Windows Server 2025 differed from that of Server 2022. The policy “Network security: Configure encryption types allowed for Kerberos
(Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options)
was configured to allow only AES128_HMAC_SHA1 and AES256_HMAC_SHA1. The option “Future encryption types” is reserved for potential new Kerberos encryption algorithms that may be introduced in future Windows versions. It does not specifically include AES128 or AES256, as these have their own settings.

When we temporarily added RC4_HMAC_MD5 to the allowed list, we were able to install the gMSA successfully. But this raised a red flag, why lower security just to get a gMSA to install? First, we checked the current encryption level on our new Windows Server 2025 using:

Get-ADComputer -Identity $env:COMPUTERNAME -Properties msDS-SupportedEncryptionTypes | Select Name, msDS-SupportedEncryptionTypes

Next, we checked the gMSA itself using:

Get-ADServiceAccount -Identity 'Serviceaccount' -Properties msDS-SupportedEncryptionTypes | Select Name, msDS-SupportedEncryptionTypes

We noticed a mismatch between the server and the gMSA. The server was set to 24, while the gMSA was set to 28. To clarify the relevant Kerberos encryption bitmask values:

  • RC4 = 4
  • AES128 = 8
  • AES256 = 16
  • AES-only (AES128 + AES256) = 24
  • AES + RC4 = 28

Note: A value of 0 or null means “follow the domain/GPO default,” which often still allows RC4.

In short, Windows Server 2025 was enforcing AES only, while the gMSA was configured for AES + RC4.

This was the most confusing part for us. We initially assumed that if RC4 wasn’t available on the server, Kerberos would simply fall back to AES after all, the gMSA was also capable of AES. However, Kerberos doesn’t really “negotiate” in this scenario. The Key Distribution Center (KDC) selects one encryption type based on what the gMSA allows. If RC4 is enabled on the gMSA, the KDC may choose RC4. If the client (server) is AES only and doesn’t accept RC4, there is no fallback to AES and the operation just fails.Since we didn’t want to lower our security baseline, we decided to update the affected gMSAs to AES-only by running:

Set-ADServiceAccount -Identity 'gMSA Accountname' -KerberosEncryptionType AES128,AES256

After running the command above, the gMSA’s encryption type changed from 28 to 24. We also reviewed the creation process for new gMSAs. By default, they were still being created with AES + RC4, which we already knew would not work on Windows Server 2025. To address this, we added the -KerberosEncryptionType parameter to the New-ADServiceAccount command so that new gMSAs are created with AES only. Just like computer accounts, their passwords are random, complex, and change every 30 days by default

New-ADServiceAccount -Name 'gMSA Accountname' -DNSHostName 'hostname.domain.local' -PrincipalsAllowedToRetrieveManagedPassword 'AllowedGroupOrServer' -KerberosEncryptionType AES128,AES256

The last thing we looked into and tested was the behavior of an AES only gMSA when installed on a Windows Server 2022 system that still allowed AES + RC4. In this scenario, even though the server permitted RC4, the AES only gMSA worked without any issues. This confirmed that all gMSAs we had updated to AES-only (EncryptionTypes 24) continued to function on legacy Windows Server 2022 hosts configured with AES + RC4.

While replacing Citrix StoreFront (2203 CU5 LTSR) servers running Microsoft Server 2019 with servers running Server 2022, we encountered an error message during login attempts to Citrix StoreFront. Users were shown an error message stating: “Cannot complete your request.”

We were running a GSLB setup with a multi-server group (across sites), each containing several Citrix StoreFront servers (2203 CU5 LTSR). As described in “Virtual Apps and Desktops – 1912/2203 – Citrix Infrastructure / OS Upgrade” (CTX278869), we exported the configuration from an old StoreFront server running Server 2019 and imported it onto the newly created StoreFront servers running Server 2022. All servers were deployed in the same OU, received the same GPOs/settings, and apart from the different operating systems, all settings were pretty much identical.

Read More →

Within a large environment where Ivanti Workspace Control is used in combination with a Microsoft SQL Database, the SQL Server has to handle numerous connections initiated by all the Ivanti Workspace Control Agents.To minimize the load and connections on the SQL Server, Ivanti introduced the Ivanti Relay Servers, which act as proxies for all agent connections to the SQL Server, thereby reducing the total number of SQL connections and the overall load.

While monitoring our Ivanti Relay Server, we noticed that a couple of times a day, the Ivanti Relay Servers started queuing all messages. The transactions folder filled up with transactions that weren’t forwarded to the SQL Server. The Ivanti Relay Servers have a built-in failsafe option, where they stop accepting new transactions when the queue exceeds 50,000 transactions. So, in a short period of time, all Ivanti Relay Servers went offline because they hit the 50,000 transaction threshold.

Read More →

Let’s start by stating I’m not a SQL DBA 😉 when it comes to databases, I’m just a user who needs a database for my applications 🙂 Lately, in various environments, we’ve been creating different Ivanti Workspace Control and Automation Manager databases. We simply request an empty database from the SQL department and are assigned DBO rights. Subsequently, we establish a connection to the database from Ivanti Automation Manager (for example) and handle the initial database setup within the application itself.

After initializing the SQL database, the user who performed the initialization can start Ivanti Workspace Control, for example, without encountering any issues. Another user, who has the same permissions (DBO) on the database, is unable to launch the application. The second user is able to access the SQL Database using SQL Management Studio, where they seem to have full control over the database.

Read More →

For managing several environments, we utilize Ivanti Automation Manager, leveraging Microsoft SQL Server as the database. According to the documentation, Ivanti Automation Manager does not support “SQL Server Always On availability groups,” and unfortunately, there is no mention of using a “SQL Server multi-subnet failover cluster.”

Supported database systems https://help.ivanti.com/res/help/en_US/IA/2024/Admin/Content/48735.htm

Within our environments, however, the use of a “SQL Server multi-subnet failover cluster” is the standard database configuration that we must use. Simply by adding the parameter “MultiSubnetFailover=True” to the database connection string, the SQL Client recognizes that it’s a MultiSubnetFailover cluster. However, since the database connection string is initiated by Ivanti Automation Manager, we don’t have the ability to add “MultiSubnetFailover=True” to it directly. This parameter will need to be included from within the Ivanti Automation Manager software.

SqlConnection.ConnectionString Property https://learn.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlconnection.connectionstring

Upon inquiry with Ivanti, it was indeed confirmed that there is no support for a “SQL Server multi-subnet failover cluster.” The request from Ivanti was to submit a Uservoice through the Ivanti Ideas Portal for this feature. We have duly submitted the request as requested. However, for unclear reasons, Ivanti has chosen not to implement this feature.

Uservoice: MultiSubnetFailover support (Microsoft OLE DB Driver for SQL Server) https://ivanti.ideas.aha.io/ideas/IA-I-44

MultiSubnetFailover Uservoice

Without the “MultiSubnetFailover=True” value in the connection string, for example, Ivanti Automation Manager may fail to start after the active SQL node is changed.

Connection error

Since we couldn’t avoid using a SQL Server multi-subnet failover cluster, we have temporarily resolved this by implementing a script. It may not be the most elegant solution, but it gets the job done!

We have created a scheduled task on all servers where the Ivanti Automation Manager Console and Ivanti Dispatchers are installed. This task runs every 5 minutes and executes a PowerShell script, which checks if the connection to the database is still possible. If not, it identifies the active SQL node and updates the hosts file accordingly, allowing the Consoles and Dispatchers to establish a connection with the database again.

<#
.SYNOPSIS
This PowerShell script updates the hosts file on a target machine with the current active SQL node IP address.
It checks if the specified target hostname is reachable. If not, it determines the active SQL node and updates the hosts file accordingly.

.DESCRIPTION
This script is designed to be run on a target machine to ensure that it always resolves a specific hostname to the active SQL node IP address.
It checks the availability of the target hostname and updates the hosts file with the IP address of the active SQL node if necessary.

.NOTES
- Script Name: Update-HostsFile.ps1
- Version: 1.0
- Authors: Rink Spies
- Date: 08-04-2024

.PARAMETER None
This script does not accept any parameters.

.EXAMPLE
.\Update-HostsFile.ps1
This command runs the script to update the hosts file with the current active SQL node IP address.

#>

# VARIABLES
$HostsFile = "$env:SystemRoot\System32\drivers\etc\hosts"
$TargetHostname = "MySqlServerName" # <<Update with SQL Server Instance name >>
$SQLNodes = @("1.2.3.4", "2.3.4.5", "3.4.5.6")  # << update with all SQL Node IP's >>
$LogFile = "C:\Windows\Temp\Update-hosts-file.log"

# FUNCTIONS

# Add-HostRecord function adds a record to the hosts file.
function Add-HostRecord {
    param(
        [string]$HostsFilePath,
        [string]$IP,
        [string]$Hostname
    )

    Add-Content -Path $HostsFilePath -Value "$IP`t`t$Hostname"
}

# Test-ActiveSQLNode function checks if a given SQL node is active.
function Test-ActiveSQLNode {
    param(
        [string]$SQLNode
    )

    return (Test-NetConnection -ComputerName $SQLNode -Port 1433 -InformationLevel Quiet -ErrorAction SilentlyContinue)
}

# Update-HostsFile function updates the hosts file with the IP address of the active SQL node.
function Update-HostsFile {
    foreach ($Node in $SQLNodes) {
        if (Test-ActiveSQLNode $Node) {
            Add-HostRecord -HostsFilePath $HostsFile -IP $Node -Hostname $TargetHostname
            return $Node
        }
    }
    return $null
}

# Log-Output function logs messages to the console and a log file.
function Log-Output {
    param(
        [string]$Message,
        [bool]$IncludeTimestamp = $true
    )

    $logEntry = if ($IncludeTimestamp) {
        "$(Get-Date -Format 'dd-MM-yyyy HH:mm:ss') $Message"
    } else {
        $Message
    }

    Write-Output $logEntry
    Add-Content -Path $LogFile -Value $logEntry
}

# SCRIPT

# Start the script
Log-Output "#############################################"
Log-Output "Starting update hosts file script."

# Check if the current IP for the target hostname is active
if (-not (Test-ActiveSQLNode $TargetHostname)) {
    Log-Output "Current IP for $TargetHostname is not active anymore."
    $activeNode = Update-HostsFile
    if ($activeNode) {
        Log-Output "Active IP $activeNode is online and configured in the hosts file."
    } else {
        Log-Output "None of the IPs are active."
    }
} else {
    Log-Output "Current IP for $TargetHostname is still active."
}

# End the script
Log-Output "Stopping update hosts file script."

As mentioned, not really the solution you’d ideally want to use, but hopefully Ivanti Automation Manager will still receive support for MultiSubnetFailover in the future.

Since quite some time Office has a AutoRecover feature which saves your documents every couple minutes. A super handy function to prevent you from losing a lot of work. By default Office saves an AutoRecover file every 10 minutes, for example in Word this is the default location : %AppData%\Microsoft\Word. In an enterprise environment however, the AutoRecover file location is often adjusted. For example it’s redirect to the users homedrive, in my case “H:\My Documents\AutoRecover”.

Read More →

Prior to Windows 10 (build 1607) Sticky Notes was a “Desktop App”, for which it was quite easy to roam all user settings and notes. But since the Windows 10 anniversary update Sticky Notes is available as a “Windows App” (Universal App). This creates a new challenge.

We have to make sure that Sticky Notes settings and notes, which a created by the users are being roamed. In case that roaming profiles are being used, this won’t be very challenging, because the whole user profile will be stored soon as an user logs off. However when local or mandatory profiles are used, in combination with a Zero Profile technology, like the technology offered by Ivanti Workspace Control (formerly RES Workspace Manager), some challenges lie ahead.

Read More →

Last week I upgraded our production XenMobile environment to version 8.7, after which I wanted to enroll a Windows 8.1 RT. Unfortunately there is no Worx Home application in the Windows Store, nor does Citrix offer a WorxMail of WorxWeb client. The Windows 8.1 enroll process is slightly different than a iOS of Android device and can be found in the eDocs. Ok, let’s enroll a Windows 8.1 RT and let us see what we can do with it.

Click “Settings”                                                               Click “Change PC Settings”

XD87-016    XD87-017

Read More →

Recently one of our customers migrated from an environment with several print queue’s to a centralized solution using ‘follow me printing’. Over time several users started complaining that their print jobs were not being displayed when the logged on to the printer.Instead other print jobs were visible. The problem was very inconsistent and difficult to reproduce.

In the knowledgebase of Microsoft we found an article what seemed to be our problem:

Http://support.microsoft.com/kb/958741

Unfortunately we were already running Windows 2008 R2, in which the problem should have been solved.

Read More →

This morning I was confronted with an email from the service desk because the Wi-Fi BYOD network authentication had been changed. All existing accounts were removed and BYOD users had to apply for a new user account.  I created a new user account and tried connecting to the existing WiFi BYOD network. Windows 8 detected my old username/password were not valided and requested the new password. Unfortunattely not only my password, but also my username had been changed.

BYOD

For some reason it’s not possible to delete the username of WiFI Profile from within the GUI in Windows 8 anymore. Luckily  there are several other alternatives to delete or manage an existing WiFi profile. Read More →