After the next reboot, which SQL Server services will start automatically? Querying service startup type and status makes that check repeatable. Read the service metadata, then compare stored TCP settings with the ports the instance actually listens on.
Read Service Startup Type and Status Together
sys.dm_server_services reports services associated with the current SQL Server instance. Its columns include service name, current status, startup type, account, and last startup time. Those fields answer different questions and should remain together in an operational inventory.
I check startup policy when scheduled work must survive a Windows restart. SQL Server Agent can be running now while configured for Manual startup. The current success of its jobs does not prove it will resume automatically after the next reboot.
The next query also includes instant_file_initialization_enabled. That describes the relevant reported service capability, not a measured file-growth performance result. Interpret it for the engine service rather than treating every service row as a storage benchmark. A status column is useful. It has never volunteered to reboot the server and prove the rest of the plan.
SELECT servicename,status_desc,startup_type_desc,service_account,
last_startup_time,instant_file_initialization_enabled
FROM sys.dm_server_services
ORDER BY servicename;Review service startup type alongside service status, because the next restart tests a different part of the configuration.
Match the Agent Service Startup Type to Its Jobs
Agent starts scheduled jobs only when its service is available. A Manual startup policy requires another approved process to start it. That can be intentional, but it needs an owner and a tested operating procedure. Otherwise, a reboot can leave essential jobs waiting indefinitely.
I compare the startup policy with the job inventory, not merely with a preferred default. Required backups, integrity checks, and processing schedules need an explicit restart path. A test instance with no scheduled responsibility can have a different policy from a production instance.
What should happen to the jobs after the next planned restart? Record the expected service state and verify it through the actual restart process when that process is in scope. Do not restart a live server just to satisfy an inventory query. Configuration review and restart validation are separate activities, and each needs the appropriate change context. Successful jobs today supply no evidence about a future unattended startup.
Keep the Service Account in the Review
service_account identifies the account reported for the service. That identity connects the service with file access, network authentication, and other operational requirements. Review it under the environment's account policy rather than using the query result to distribute unnecessary account details broadly.
Changing a service account affects more than the name shown in a catalog. Use SQL Server Configuration Manager and the supported service-account procedure for the approved change. That keeps the associated configuration handling consistent with the SQL Server installation.
Check folder permissions and authentication dependencies when reviewing the account. A service can start while a job fails to write a backup or output file. A running status is therefore only one checkpoint. Preserve the distinction between service availability, account rights, and successful workload execution. The inventory directs those follow-up checks; it does not prove them by returning one row with a familiar account name.
Inspect Stored TCP Port Values Through the Registry DMV
sys.dm_server_registry exposes selected SQL Server registry configuration. The following query selects TCP port and dynamic-port values under the relevant network configuration path. Backslashes are literal path characters in T-SQL and must remain present in the pattern.
The values describe stored configuration. They do not prove which listener is active right now or whether a pending change needs restart. Keep the registry key with the value name so IP-specific entries are distinguishable from shared configuration entries.
Do not edit registry values through an unsupported shortcut because they are visible in a query. Use the supported configuration interface for an approved port change. The DMV is an inspection surface. Metadata access also requires the supported permissions for your server version. Collect it through an approved administrative account instead of expanding an application's privileges merely for this inventory.
SELECT registry_key,value_name,value_data
FROM sys.dm_server_registry
WHERE registry_key LIKE N'%SuperSocketNetLib\Tcp\%'
AND value_name IN(N'TcpPort',N'TcpDynamicPorts')
ORDER BY registry_key,value_name;Compare Configuration With the Active Listener
The listener DMV reports the current TCP addresses, ports, types, and states. Pair it with the registry output when troubleshooting a mismatch. A configured port and an active port can differ during a change that has not completed its required lifecycle.
The following query retains listener type so a Service Broker or database-mirroring endpoint is not mistaken for the ordinary T-SQL listener. Read the actual rows and compare the relevant type. A wildcard address also has a different meaning from a specific interface binding.
Which connection route does the application use? Test that route after any approved change, establishing a new connection. Existing connections do not prove that a newly configured listener accepts requests. Firewall and named-instance discovery behavior remain outside these service and registry results. Keep those network checks separate so an online service is not presented as proof of end-to-end connectivity.
SELECT ip_address,port,type_desc,state_desc
FROM sys.dm_tcp_listener_states
ORDER BY type_desc,ip_address,port;Keep the Scope of the Service Inventory Clear
This DMV covers the current instance's relevant services. It is not a complete Windows service inventory and does not list SQL Server Browser or every other instance on the host. Use an approved Windows inspection when the operational question includes those wider services.
Save the service, registry, and listener results with a capture timestamp. Compare them after a supported configuration change and any required restart. Then verify the jobs and application paths that depend on the service rather than stopping at a successful status readback.
Checking service startup type is valuable because current availability and restart behavior are separate facts. Read both, connect them with the service account's responsibilities, and validate the active listener independently. The result should explain whether the instance and its scheduled work can resume through the intended operating process.
Related reading on this blog: SQL Service Not Getting Started Automatically After Server Reboot While Using gMSA Account and Running SQL Server Under a Group Managed Service Account.
A running service is not a restart guarantee, it is a current state beside a separate startup policy.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
