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

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

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)

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.

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.

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.

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

This script does not accept any parameters.

This command runs the script to update the hosts file with the current active SQL node IP address.


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


# Add-HostRecord function adds a record to the hosts file.
function Add-HostRecord {

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

# Test-ActiveSQLNode function checks if a given SQL node is active.
function Test-ActiveSQLNode {

    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 {
        [bool]$IncludeTimestamp = $true

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

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


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

Recently, I worked on a project where the workload needed to shift from using a Citrix Published Desktop to a physical laptop, with locally installed applications. As always, there are applications that, for various reasons, cannot be moved from the Citrix Published Desktop to the physical laptop. For these applications, we chose to offer them as Citrix Published Applications. Although this transition went well technically, end users reported that working with published applications was not considered very pleasant.

Scenario: The published apps were offered from a Citrix Virtual Apps en Desktops Farm, utilizing Ivanti Workspace Control. Ivanti Workspace Control is a workspace management solution provided by Ivanti, a company specializing in IT management software. It offers features for managing user workspaces across various devices and environments, including physical desktops, virtual desktop infrastructure (VDI), and application virtualization platforms. Unfortunately, Ivanti has announced that Ivanti Workspace Control will reach end of life on December 31, 2026, but at the moment, we are using it to our full satisfaction. When starting a Citrix Published Application, it takes some time due to, among other factors, the loading of the Windows profile and Ivanti Workspace Control settings before the application actually starts. When you subsequently start a second published application, it loads faster since the entire profile and UEM (User Environment Management) don’t need to be processed again. When you close the last Citrix Published Application, it also logs out the entire user session, resulting in the next Citrix Published application taking some time again, as your entire Citrix sessions needs to be loaded

Read More →
Citrix Gateway connector for Exchange ActiveSync

Recently I was asked to increase the security for a public reachable ActiveSync url. Although the customer was using Citrix Endpoint Management (XenMobile) and Citrix Secure Mail was available in their Enterprise AppStore, employees were also allowed to use their native “un-secure” mail client, which made use of a public reachable ActiveSync URL.

A big advantage they had, was that almost all mobile devices were already enrolled within Citrix Endpoint Management, so we knew which ActiveSync ID’s where legit and allowed to access ActiveSync.

Cause we were already making use of Citrix Endpoint Management, we decided to use the Citrix Gateway connector for Exchange ActiveSync (formerly XenMobile NetScaler Connector), to add an extra layer of security to the public reachable ActiveSync url.

Read More →