Installing SQL Server Silently From the Command Line

The setup wizard is convenient once and difficult to reproduce exactly. Installing SQL Server silently gives you a repeatable Windows command, provided the configuration file and result checks are treated as part of the installation.

Start With a Reviewed Configuration File

SQL Server Setup can save the selections made through its interface in ConfigurationFile.ini. Generate one with the same major version you intend to install. The file contains feature, instance, directory, and other setup choices as name and value pairs. Read it line by line rather than assuming that a captured wizard run is a good standard. Remove settings that belonged only to the machine used to create it.

I keep the file beside a short explanation of why each nondefault choice exists. That prevents an old tempdb path or service identity from spreading across new machines. Passwords are not written into the generated file. Supply secrets through an approved secure process, not a shared text file or visible command history.

Know the Required Inputs for Installing SQL Server Silently

An unattended installation needs an action, a feature selection, an instance target, and the required license acceptance switch. For the Database Engine, assign a SQL Server administrator. Other required parameters depend on edition, features, and the selected service account model. Review the official parameter list for the exact version. Quiet mode with /Q shows no Setup dialog. /QS displays progress but does not ask questions.

The license switch is an explicit acceptance of the software terms. Do not add it to a command before the organization has approved those terms. SQL Server Setup also requires the privacy notice suppression parameter for current quiet installations. I verify those prerequisites before running the command. A missing required switch should fail early, not halfway through a server build.

Run Setup From an Elevated Session

The example uses Windows PowerShell and a local media path. Replace the path, configuration file, and instance name with reviewed values. The script checks the process exit code. It does not store a password in plain text. The configuration file must contain the remaining selections, including the Database Engine feature and administrator account where required.

Run in an elevated session on the intended Windows server. If installation media lives on a network share, the installing account needs appropriate access. I copy approved media locally for repeatable builds when that fits the deployment process. A quiet command should still leave a clear run record and an obvious failure signal.

# PowerShell
& 'C:\SQLMedia\setup.exe' /Q /ACTION=Install /ConfigurationFile='C:\SQLBuild\ConfigurationFile.ini' /IACCEPTSQLSERVERLICENSETERMS /SUPPRESSPRIVACYSTATEMENTNOTICE
if ($LASTEXITCODE -ne 0) { throw "Setup failed with exit code $LASTEXITCODE" }

Read the Result, Not Just the Exit Code

Setup writes summary and detail logs under its bootstrap log directory. Find the log for this run and inspect the overall result, failed rules, and feature status. A zero exit code is useful, but the acceptance check should also connect to the new instance. If Setup asks for a reboot, record it and complete it before testing dependent configuration.

I check the SQL Server service state and connect with the account that will administer the instance. Then I query version and edition from SQL Server itself. That query confirms the server you reached, which matters on machines with multiple named instances. The name on the command line is not proof that the next query window connected there.

SELECT @@SERVERNAME AS connected_server,
       SERVERPROPERTY('ProductVersion') AS product_version,
       SERVERPROPERTY('Edition') AS edition_name;

Verify Active Configuration

Some setup choices affect instance properties, while others control file paths or service accounts. Check each category with the right evidence. Read server collation from SERVERPROPERTY, database file paths from catalog views, and active configuration values from sys.configurations. Compare them with the reviewed build specification. Do not infer success from the presence of a program directory.

The query below checks a few instance choices without changing them. Keep the expected values in the build record and flag a mismatch. I pay particular attention to memory and collation because they can make a test server behave unlike its target. A successful install with the wrong settings is still the wrong install.

SELECT SERVERPROPERTY('Collation') AS server_collation,
       name, value, value_in_use
FROM sys.configurations
WHERE name IN (N'max server memory (MB)',
               N'max degree of parallelism')
ORDER BY name;

Handle Reboots and Reruns When Installing SQL Server Silently

Do not rerun a failed installation blindly. Read the Setup logs and determine which features or services were created. An install command is not automatically idempotent. A second attempt can encounter an existing instance name or partially installed feature. Decide whether to repair, remove the disposable build, or resume through the documented Setup workflow.

Which machine states does your automation accept? Write those preconditions into the script. Check for an existing instance before setup, verify disk space and paths, and ensure the selected account has the required rights. I prefer a clear stop over an installer that makes a second machine slightly different from the first. Repeatability includes the failure path.

Make Installing SQL Server Silently Maintainable

Keep the configuration file versioned with the deployment instructions, but keep passwords and private keys elsewhere. Record the exact media build, selected edition, and approved feature list. When the SQL Server major version changes, generate a fresh configuration file and review changed parameters. Installing SQL Server silently with a command copied forward without review can preserve obsolete choices.

Finish with a short smoke test under a nonadministrator application login where possible. Confirm connection, database creation rights only where intended, and the required network path. A first query should not require a detective story. Installing SQL Server silently from the command line makes Setup repeatable, while post-install checks make the result trustworthy.

After installation, verify the features and network surface you actually intended to deploy. A zero exit code from Setup is evidence that Setup completed, not proof that the instance accepts the expected connection or has the approved service accounts. Check the instance name, edition, build, authentication mode, collation and installed features from the running server. Keep the installation log with the build record so that a later difference has an explanation.

I also test the uninstall and rebuild story on a disposable machine. An unattended command can be perfectly repeatable while repeating the wrong setting every time. If the configuration file came from another environment, inspect paths, accounts and feature switches before reuse. Treat secrets and product keys as separate protected inputs. A colleague should be able to read the command and say exactly what server it will create without guessing which dialog choices were accepted last month.

Related reading on this blog: How to Install SQL Server 2019? Interview Question of the Week #287: SQL in Sixty Seconds #092 and Install Error: The Account Running SQL Server Setup Does Not Have Administrator Rights On the Computer. To Continue, Use an Account With Administrator Rights.

A silent installation is not an invisible installation, it is one whose choices and results are visible in a script.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.