A “security.txt” file is a standard proposed by security researcher Ed Foudil in 2017 as a way for websites to define a security policy. It’s akin to the well-known “robots.txt” file which specifies rules for web crawlers. The security.txt file allows website owners to provide information to security researchers about how to report security vulnerabilities or concerns.

Since April 2022, Security.txt has been an Internet Engineering Task Force (IETF) informational standard

Read More →

Recently, we worked on upgrading a Citrix NetScaler VPX from version 13.0 to the latest 14.1 build. The Citrix NetScaler VPX, which had been running for quite some time, had not been upgraded because it still used features and functionalities, including Classic Policies, which essentially needed to be replaced by Advanced Policies starting from the 13.1 build.

During the preparation for the upgrade, our main focus was on the legacy configuration in the running ns.conf file that needed to be adjusted.

Citrix ADC scripts for migrating and converting Citrix ADC configuration with deprecated features https://github.com/netscaler/ADC-scripts/tree/master

By using the NSPEPI tool, you can not only check for legacy configuration but also convert it to new configurations in many cases. Always ensure that you download and use the latest version during the analysis. If you are upgrading from a version older than build 13.1, always use NSPEPI beforehand to ensure that everything continues to work as expected after the upgrade.

check_invalid_config /nsconfig/ns.conf

After replacing all legacy configurations in the ns.conf and ensuring there were no blocking issues according to the NSPEPI tool to upgrade to the latest 14.1 build, we conducted a trial upgrade migration within our acceptance environment.

After the upgrade, the Citrix NetScaler restarted smoothly, but it was no longer possible to log in using our domain accounts (LDAPS). Fortunately, logging in with the local nsroot account still worked. Once logged in, it was immediately apparent that several load-balanced VIPs were down, causing the LDAPS load balancer to be inactive. Additionally, various NetScaler features were suddenly no longer visible.

Show Unlicensed Features

The navigation suddenly included an item labeled “Show Unlicensed Features,” which we hadn’t seen before. After clicking on it, all features became visible again. However, it became immediately apparent that many things seemed to be unlicensed all of a sudden. Features that we were using prior to the upgrade to build 14.1. While browsing through the NetScaler GUI, we navigated to System > License and discovered that we were running an Express edition instead of Platinum. Consequently, many of the commonly used features were indeed unlicensed.

ADC License

Next, we examined the existing license files located in the directory /nsconfig/license. What immediately caught our attention was the date present in the license file. In our case, the expiration date was older than the Eligibility Dates required for using the Citrix NetScaler 14.1 build, which is July 12, 2023 🙁

NetScaler License File

Citrix products and their Eligibility dates https://support.citrix.com/article/CTX111618/citrix-product-customer-success-services-eligibility-dates

Since this was a Citrix NetScaler VPX with a valid software subscription, the solution was fortunately quite simple. Simply redownload your license file via the MyCitrix license portal and upload it to the Citrix NetScaler VPX. The new license file will include a new SA Date, enabling you to run build 14.1. After restarting the Citrix NetScaler, all previously licensed features reappeared.

Check your product eligibility dates before you proceed with the upgrade!

In the past, it was possible to upload your NetScaler configuration file (ns.conf) to the Citrix Insight Service, which would then conduct an automated health check of the configuration. You would receive a report detailing any potential issues, best practices not followed, and so on. This was incredibly helpful during setup. Unfortunately, Citrix discontinued this self-diagnostic service some time ago.

During E2EVC 2022 Athens, I stumbled upon the “Arrow’s NetScaler config analyser” in one of the sessions—a tool more than handy. After registration, it allows you to check your NetScaler configuration for free. However, in practice, I still regularly encounter NetScaler administrators who are unaware of its existence, so I thought I’d mention it again.

Arrow’s NetScaler config analyser https://app.xconfig.io

Although they offer more than just the free health check, in this case, I want to specifically mention the FREE “Online Config Analysis.”

Unless you choose to save your ns.config within your personal account, your ns.config is not uploaded to their website; instead, it is analyzed locally from your browser session.

For added security, it’s advisable to first mask any confidential data such as passwords, IP addresses, etc., ensuring they’re not usable.

Without registration, not all results are visible, so go ahead and register yourself.

After creating an account, you’ll have full visibility into all the issues discovered within your ns.conf. These issues are categorized into four categories:

  • Critical
  • Major
  • Medium
  • Low

If you ask me, your configuration shouldn’t contain any Critical, Major, or Medium findings! 😊

An example of a Critical finding might be:

An example of a Medium finding might be:

What’s also very handy besides the analysis of your NetScaler configuration is the easy browsing through your configuration. By selecting an item on the left side (which looks identical in structure to a NetScaler), you’ll see the corresponding lines from your configuration on the right. This makes the configuration much more readable and understandable.

The tool is constantly evolving, with new recommendations being added regularly. For a comprehensive overview of the change log, you can navigate to the “What’s new” section. If you encounter false positives or have recommendations for improvements, don’t hesitate to let them know. In my experience, they are responsive to user feedback and often address issues or implement suggestions in subsequent releases!

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.

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 →