Managing SQL Server trace flags effectively is a common task for DBAs and system engineers, especially when tuning the SQL Server behavior for specific use cases or performance optimizations. While trace flags can be enabled programmatically using T-SQL commands such as DBCC TRACEON, this approach has an inherent limitation: the flags are session-based or global only until the SQL Server instance is restarted. After a service restart, these trace flags are no longer active unless they are configured as startup parameters.
To ensure persistence across restarts, trace flags need to be set as startup parameters. Traditionally, this can be done manually through two main avenues: using the SQL Server Configuration Manager or editing the Windows Registry directly. However, both of these approaches require manual interaction and are not ideal for automated deployments, large-scale environments or automated deployments.
Unfortunately, SQL Server doesn’t provide a built-in command-line tool or T-SQL syntax to set trace flags as startup parameters programmatically. This gap leaves many DBAs and system engineers either scripting complex registry edits themselves or relying on manual configurations.
That’s exactly the problem I set out to solve. I developed a PowerShell function that allows you to set SQL Server trace flags as startup parameters in a programmatical way and I’m using this function already at one of my customers to set Trace flags within an automated deployment process. This function not only configures the registry settings required for each SQL Server instance on a server, but it also offers optional functionality to restart the SQL Server service—ensuring that your changes take effect immediately. Even better, it includes logic to detect which trace flags are already in place and avoids redundant updates.
In this blog post, I’ll walk you through how the function works, how to use it in your own environment, and how it can fit into your broader infrastructure automation strategy. Whether you manage a single SQL Server or dozens across a large environment, this solution aims to simplify your workflow and reduce the risk of human error.
Let’s take a look at how to set the Trace flag programmatically with the PowerShell Function:
I have the function stored in a ps1 file within my visual studio project directory.

To execute the function and pass the appropriate input parameters to the function, I create a second .ps1 file in the same directory.

In this file I add the following values in variables:
$Trace flags – The trace flags I would like to set for the particular instances
$Restart – This defines if the SQL-Server Service should be restarted after setting the trace flags (Y = restart, N = no restart)
$ServerName – This defines the Server on which the trace flags should be set as a startup parameter for every instance running on it
$Cred –This is the credential which is used to access the remote Server
Then I import the function as a module and execute the function with the values stored in the variables as input parameters.

After saving the file I execute it from the terminal. You can see that the Trace flags have been successfully set.

When we take a look in the registry on the particular server we can see, that the Trace flags have been added.

We can see the same result when taking a look on the startup parameters from the SQL Server Configuration Manager.

Let’s take a look from the SQL Server Management Studio. With the DBCC TRACESTATUS() function. You can see, that no trace flags are currently active.

This is because the trace flags are set as startup parameters and will become active on the next service start.
After restarting the SQL Server service, we can see that the trace flags are now active.

The function is as well “intelligent” enough to see which trace flags are already in place and only sets the trace flags which are missing.
When I execute the function again with the same trace flags, you can see, that the functions tells you that the trace flags are already in place.

The function can also trigger a restart of the SQL-Server service to ensure that the trace flags become active immediately. Let consider therefore, that we want to set additionally the trace flag 1211. I change as well the $Restart variable to ‘Y’ to trigger a service restart.

After saving the file and executing it again from the terminal you can see that the trace flag 1211 has been set and that the instance has been restarted.

As the function triggered a restart of the instance, you can now see from the SQL Server Management Studio that the trace flag has become already active.

I hope this post was interesting for you 😉 Let me know your thoughts in the comment section below.
I’ve uploaded the PowerShell function to GitHub. You can access it under this link: https://github.com/HocineMechara/SetSQLServerTrace flags.git