What you will learn
Start by proving which SQL Server instance accepted your connection. An instance hosts system and user databases; a database is not a separate Windows service. This lesson turns the introductory training material into a small inventory you can repeat before every administration task.
Before you begin
Use an isolated SQL Server 2022 Developer lab on host1.sample.com and a current SQL Server Management Studio client. Developer edition is for nonproduction use. Connect with a dedicated lab administrator for setup; application access is tested separately. The examples use TutorialDB and synthetic rows only. GO is a client batch separator, not a Transact-SQL statement. Sample paths are on the database server, not your workstation.
1. Establish a trusted connection
In SSMS select Database Engine, enter host1.sample.com, choose the authentication method provisioned for your lab, and require encryption with a certificate trusted by the client. A named instance or explicit TCP port must match the server configuration. Do not bypass certificate validation simply to make a connection succeed. Open a new query window and keep its database context visible.
2. Record the engine identity
SELECT SERVERPROPERTY('ServerName') AS server_name,
SERVERPROPERTY('ProductVersion') AS product_version,
SERVERPROPERTY('Edition') AS edition;
SELECT DB_NAME() AS current_database, ORIGINAL_LOGIN() AS original_login;
The engine version is independent of your SSMS version. Record both when troubleshooting. A successful connection only establishes authentication and network reachability; it does not prove permission to administer every database.
3. Inspect databases and file locations
SELECT name, state_desc, recovery_model_desc
FROM sys.databases ORDER BY name;
SELECT DB_NAME(database_id) AS database_name, name, type_desc, physical_name
FROM sys.master_files ORDER BY database_id, file_id;
master stores instance metadata, model supplies defaults for new databases, msdb supports administration such as jobs and backup history, and tempdb holds temporary work. Inspect actual recovery models rather than assuming all system databases use the same setting. Metadata visibility depends on your login permissions.
4. Read the example output
The following is illustrative, normalized output, not a transcript from a customer system. Values depend on your release and lab state.
server_name edition
host1 Developer Edition
current_database
master
This shortened example deliberately omits build numbers. Compare the actual build with the release you installed; never treat a training screenshot as evidence of the deployed patch level.
Verify the result
Save the instance name, build, edition, database list, and storage locations together. Switch the query context to an intended user database and rerun DB_NAME(). Confirm a second connection reaches the same instance before using the inventory for a change.
Troubleshooting
A connection timeout can indicate DNS, listener, firewall, or instance-port issues. A login error is a different failure. Certificate-name mismatches require checking the connection hostname against the certificate. An empty metadata result can reflect permissions rather than missing databases.
Recovery and next steps
This lesson makes no database changes. Keep the inventory with the lab notes and continue to database creation. Avoid changing service accounts or authentication mode as an unexamined connection workaround.