Starting Services in Microsoft SQL Server 2025

In the previous lesson you learned about the services that make SQL Server 2025 functional — the Database Engine, SQL Server Agent, SQL Server Browser, and Integration Services. This lesson explains how to start, stop, restart, pause, and configure those services using the four methods available in SQL Server 2025: SQL Server Configuration Manager, Windows Services, the command line, and PowerShell. It also covers how to configure services to start automatically at system boot, how to change service accounts, and how to manage SQL Server services on Linux.

SQL Server Configuration Manager — The Preferred Tool

SQL Server Configuration Manager is the recommended tool for managing SQL Server 2025 services on Windows. Unlike the generic Windows Services snap-in, Configuration Manager understands SQL Server service dependencies, validates service account permissions, and handles protocol configuration in the same interface. It is accessed by pressing the Windows key, typing SQLServerManager17.msc, and pressing Enter — the 17 in the filename corresponds to SQL Server 2025 (version 17.x).

The four-step workflow shown in the diagram above covers every common service management task:

1. Start Configuration Manager — run SQLServerManager17.msc as administrator.
2. Select SQL Server Services in the left pane to display all installed SQL Server services and their current state in the right pane.
3. Right-click the target service and choose Start, Stop, Restart, Pause, or Resume depending on the required action.
4. Open Properties to set the Start Mode (Automatic, Manual, or Disabled) or change the service account on the Log On tab.

SQL Server 2025 Services — Names and Startup Types

Additional services such as SQL Server Integration Services, Full-Text Filter Daemon Launcher, and SQL Server Reporting Services appear in Configuration Manager when those features are installed. Each service can be managed independently — stopping SQL Server Agent does not stop the Database Engine, but stopping the Database Engine automatically stops SQL Server Agent since Agent depends on the Engine being in a Running state.

Method 1 — SQL Server Configuration Manager (Recommended)

For each service operation, right-click the service name in the right pane and select the appropriate action. The five available actions map directly to the three service states covered in the previous lesson:

• Start — transitions the service from Stopped to Running
• Stop — transitions the service from Running or Paused to Stopped
• Restart — stops then starts the service in a single operation, useful after configuration changes such as enabling a new network protocol
• Pause — transitions the service from Running to Paused, allowing existing connections to complete while blocking new connections
• Resume — transitions the service from Paused back to Running

To configure automatic startup, right-click the service, select Properties, go to the Service tab, and set Start Mode to Automatic. Setting the Database Engine and SQL Server Agent to Automatic ensures both services start when Windows boots without requiring manual intervention after a server restart.

Method 2 — Windows Services (services.msc)

The Windows Services snap-in provides an alternative interface for managing SQL Server services alongside all other Windows services on the machine. Press Windows + R, type services.msc, and press Enter. Locate the SQL Server service by name — for the default instance it appears as SQL Server (MSSQLSERVER) — right-click, and choose Start, Stop, Restart, or Properties.

The Services snap-in is adequate for basic start and stop operations but does not provide access to SQL Server-specific configuration such as startup parameters or network protocol settings. SQL Server Configuration Manager is preferred for any configuration task beyond simple service state changes.

Method 3 — Command Prompt

Open an elevated Command Prompt (Run as administrator) and use the net start and net stop commands:

-- Start the default Database Engine instance
net start MSSQLSERVER

-- Start a named instance
net start MSSQL$YourInstanceName

-- Start SQL Server Agent (default instance)
net start SQLSERVERAGENT

-- Start SQL Server Browser
net start SQLBrowser

-- Stop the default Database Engine instance
net stop MSSQLSERVER

Command-line service management is useful in automated deployment scripts, server provisioning workflows, and remote administration scenarios where a GUI is not available. The service names used with net start are the internal Windows service names — not the display names shown in Configuration Manager.

Method 4 — PowerShell

PowerShell provides the same capabilities as the command line with richer scripting support:

# Start the Database Engine (default instance)
Start-Service -Name "MSSQLSERVER"

# Stop the Database Engine
Stop-Service -Name "MSSQLSERVER"

# Start SQL Server Agent
Start-Service -Name "SQLSERVERAGENT"

# Start SQL Server Browser
Start-Service -Name "SQLBrowser"

# Check service status
Get-Service -Name "MSSQLSERVER" | Select-Object Name, Status, StartType

# Set Database Engine to automatic startup
Set-Service -Name "MSSQLSERVER" -StartupType Automatic

The Get-Service cmdlet is particularly useful for verifying service state after a start or stop operation in a script. Set-Service -StartupType Automatic is the PowerShell equivalent of setting Start Mode to Automatic in Configuration Manager Properties — it persists the startup configuration without requiring a manual GUI step.

Method 5 — SQL Server Management Studio

SSMS provides a service restart option directly from Object Explorer. Connect to the SQL Server instance, right-click the server name at the top of the Object Explorer tree, and select Restart. This restarts the Database Engine service and automatically restarts SQL Server Agent. This method requires an active connection to the instance — it cannot be used when the Database Engine service is already in a Stopped state.

Managing SQL Server Services on Linux

SQL Server 2025 is fully supported on Red Hat Enterprise Linux, Ubuntu, and SUSE Linux Enterprise Server. On Linux, SQL Server runs as the mssql-server systemd service. All service management is performed through the systemctl command:

# Start SQL Server on Linux
sudo systemctl start mssql-server

# Stop SQL Server on Linux
sudo systemctl stop mssql-server

# Restart SQL Server on Linux
sudo systemctl restart mssql-server

# Enable automatic startup at boot
sudo systemctl enable mssql-server

# Disable automatic startup at boot
sudo systemctl disable mssql-server

# Check SQL Server service status
sudo systemctl status mssql-server

The systemctl status mssql-server command shows the current running state, the process ID, recent log output, and whether the service is enabled for automatic startup. This is the Linux equivalent of checking service properties in SQL Server Configuration Manager. SQL Server Agent on Linux is managed through the mssql-server-agent package and the same systemctl commands with the service name mssql-server-agent.

Service Account Best Practices for SQL Server 2025

The service account — the Windows or domain account under which a SQL Server service runs — determines which system resources the service can access. Choosing the wrong service account is one of the most common SQL Server configuration mistakes. SQL Server 2025 service account best practices:

• Use group Managed Service Accounts (gMSA) — gMSA accounts are automatically managed by Active Directory, including password rotation, eliminating the need for manual password management. They are the recommended account type for production Database Engine and SQL Server Agent services in domain environments.
• Use dedicated domain accounts with minimal privileges when gMSA is not available. The account needs Log on as a service rights and access only to the specific resources SQL Server requires — not administrator rights on the server.
• Avoid Local System and Network Service for the Database Engine and SQL Server Agent in production. Local System has excessive local privileges. Network Service is acceptable for lower-privilege services such as SQL Server Browser.
• Change service accounts through Configuration Manager, not through the Windows Services snap-in. Configuration Manager correctly adjusts file system permissions and registry ACLs when the account is changed. Changing the account directly in services.msc leaves these permissions uncorrected and can cause the service to fail on next restart.

Startup Parameters and Advanced Configuration

SQL Server 2025 supports startup parameters that modify Database Engine behavior at service startup. These are configured in SQL Server Configuration Manager by right-clicking the Database Engine service, selecting Properties, and navigating to the Startup Parameters tab:

• -m — start in single-user mode for emergency database recovery when the master database is corrupted or when only one administrative connection is needed
• -T3226 — suppress successful backup completion messages in the SQL Server error log, reducing log noise in environments with frequent backup jobs
• -c — run SQL Server as a console application rather than a Windows service, used for troubleshooting startup failures in development environments

After adding or modifying startup parameters, restart the Database Engine service for the changes to take effect. Startup parameters persist across service restarts and are stored in the registry under the SQL Server instance configuration key.

Troubleshooting Failed Service Starts

When a SQL Server service fails to start, two diagnostic sources provide the most useful information:

• SQL Server Error Log — located at C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\ERRORLOG for the default instance. The error log records the exact point of failure during startup, including permission errors, corrupt system database detection, and port conflicts. It can be read in SSMS through Management → SQL Server Logs, or directly as a text file.
• Windows Event Viewer — check both the Application log and System log for events from the MSSQLSERVER source. Windows-level errors such as service account permission failures and TCP port binding conflicts appear here rather than in the SQL Server error log.

Common causes of failed starts include: the service account lacking Log on as a service rights after a password change; a port conflict where another process is already bound to TCP 1433; a corrupt master or model database requiring single-user mode recovery; or insufficient disk space for the transaction log on the tempdb volume.

Post-Configuration Checklist

After installing SQL Server 2025 or making configuration changes, verify the following before declaring the instance production-ready:

1. Set the Database Engine service to Automatic startup in Configuration Manager
2. Set SQL Server Agent to Automatic startup if job scheduling is required
3. Enable SQL Server Browser if using named instances or multiple instances on the same machine
4. Configure proper service accounts — gMSA or dedicated domain accounts with minimal privileges
5. Restart all services after enabling new network protocols in SQL Server Network Configuration
6. Verify startup success by checking the SQL Server Error Log for the "SQL Server is now ready for client connections" message
7. Connect from SSMS or Azure Data Studio to confirm the instance accepts client connections

Starting MS SQL Server Service — Exercise