Quick Summary – Installing SQL Server on Windows Server
The hypothetical SQL01 lab plans a SQL Server 2022 Developer installation on Windows Server 2022. The goal is not just a running service, but restricted access and recoverable data.
- Environment and licensing — 4 vCPUs and 8 GB RAM are an example starting capacity; Developer is for development and testing only and does not license production use.
- Minimal installation scope — Install only Database Engine Services, using the default MSSQLSERVER instance and the NT SERVICE\MSSQLSERVER service account.
- Limited application permissions — Use Windows authentication for local administration; if SQL authentication is required, enable mixed mode and grant the application only the necessary object permissions.
- Measurable starting settings — This lab uses 4096 MB for max server memory, four equally sized tempdb data files, and one tempdb log file as starting settings.
- Protected remote connections — Restrict static TCP 1433 access to application and management IP addresses, and use Mandatory encryption with a verifiable TLS certificate for SSMS connections.
- Proof of recovery — Keep full and transaction log backups off-server as well, and do not consider the backup process complete until you restore to a separate database.
A running SQL Server service does not mean setup is finished. To install SQL Server on Windows Server, prepare licensing and storage, install the Database Engine, assign an administrator, and apply updates. Before use, verify memory settings, TLS-protected TCP access, and backup recovery. These examples describe a hypothetical, non-production Windows Server 2022 lab.
Table of Contents
- Check VPS Resources, Storage, and Licensing Before Installation
- Install the SQL Server 2022 Database Engine
- Choose Windows Authentication or Mixed Mode
- Set Initial Memory, Database File, and tempdb Options
- Restrict TCP 1433 Access with TLS and Firewall Rules
- Verify the SSMS Connection Layer by Layer
- Complete the First Backup with a Restore Test
- Check Before Connecting Your Application
- Frequently Asked Questions
- Sources
Check VPS Resources, Storage, and Licensing Before Installation
An installer opening proves little. I would rather catch a missing volume now than move database files later.
The hypothetical, non-production SQL01 lab uses Windows Server 2022 Standard Desktop Experience 21H2, build family 20348, with 4 vCPU and 8 GB RAM. Microsoft Learn’s SQL Server 2022 requirements support this OS and require x64: minimum RAM for non-Express editions is 1 GB; minimum free disk space is 6 GB. These are installation minimums, not sizing targets. The lab’s starting capacity needs headroom for Windows, data, logs, and backups.
License for the intended use
Microsoft’s edition comparison identifies Developer as development/test only, not licensed for production. This lab uses SQL Server 2022 Developer 16.x, default instance MSSQLSERVER, and only Database Engine Services. Express permits free production use within CPU/memory restrictions and a 10 GB limit per relational database. Assess Standard or Enterprise production licensing separately; Windows Server licensing does not cover SQL Server.
No Active Directory is present. Sign into SQL01 with an authorized local account; open PowerShell as administrator. This read-only example checks elevation, OS, resources, volumes, and directories:
$identity = [Security.Principal.WindowsIdentity]::GetCurrent()
$principal = [Security.Principal.WindowsPrincipal]::new($identity)
$principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
Get-CimInstance Win32_OperatingSystem |
Select-Object CSName, Caption, Version, BuildNumber, OSArchitecture
Get-CimInstance Win32_ComputerSystem |
Select-Object NumberOfLogicalProcessors,
@{Name='RAM_GiB'; Expression={[math]::Round($_.TotalPhysicalMemory / 1GB, 2)}}
Get-Volume -DriveLetter C,D,L,T,B -ErrorAction Stop |
Select-Object DriveLetter, FileSystem, HealthStatus,
@{Name='Free_GiB'; Expression={[math]::Round($_.SizeRemaining / 1GB, 2)}}
'C:\Install\SQL2022','D:\SQL\Data','L:\SQL\Log',
'T:\SQL\TempDB','B:\SQL\Backup' | ForEach-Object {
[pscustomobject]@{
Path = $_
Exists = Test-Path -LiteralPath $_ -PathType Container
}
}
Expected results: elevation True, four logical processors, approximately 8 GiB RAM, and SQL01 reporting Windows Server 2022 Standard, 64-bit, build 20348. Pre-created volumes should report NTFS and Healthy. Compare free space with projected growth; separate drive letters do not guarantee physical I/O isolation. Directory False indicates a missing folder; True does not prove write permission.
Get installation media and the current approved CU from Microsoft; verify the CU number and full build before publication. Review Windows Update status and setup-rule restart warnings. Complete required restarts first.
Back up the existing system before installation. Follow the recovery preparation in Windows Server Backup: Methods, Scheduling, and Recovery; a VPS snapshot alone is insufficient. I would not start setup without confirming access to the backup and the provider’s console or recovery environment.
Caution
SQL Server 2022 Developer does not license production workloads; owning the VPS does not change that. The example's 4 vCPUs and 8 GB RAM are neither Microsoft's minimum requirements nor a guarantee of adequate capacity for every application.
Install the SQL Server 2022 Database Engine
I keep component selection narrow: every extra adds maintenance. Start small. This hypothetical, non-production SQL01 lab uses 4 vCPU, 8 GB RAM, and Windows Server 2022 Standard Desktop Experience 21H2 (20348 build family). Microsoft Learn’s requirements document confirms OS support for SQL Server 2022.
Prepare Microsoft-sourced media in C:\Install\SQL2022. With SQL01’s authorized local account, open elevated PowerShell to inspect the installer signature:
Get-AuthenticodeSignature -FilePath 'C:\Install\SQL2022\setup.exe' |
Format-List Status, StatusMessage, SignerCertificate
Expect Valid and Microsoft as signer. This checks only that file, not the entire media. Stop if verification fails. Run setup.exe as administrator; under Installation, choose a new standalone SQL Server installation. Resolve prerequisite errors.
Select Developer. Microsoft Learn’s edition documentation permits development and testing, not production; assess production licensing separately. Under Feature Selection, select only Database Engine Services. In Instance Configuration, choose Default instance: MSSQLSERVER.
Under Server Configuration, retain the engine’s virtual account, NT SERVICE\MSSQLSERVER. Match collation to application requirements, including Turkish-character comparisons and case sensitivity. Under Database Engine Configuration, select Windows Authentication. SQL01 has no Active Directory: click Add Current User to explicitly make your authorized local account a SQL Server administrator.
In Data Directories, set user data to D:\SQL\Data, logs to L:\SQL\Log, and local backups to B:\SQL\Backup. On the TempDB tab, set both directories to T:\SQL\TempDB. These are pre-created NTFS volumes; separate drive letters do not guarantee physical I/O isolation.
Finish installation, then apply Microsoft’s current, approved cumulative update (CU). Verify its number and full build before publication. Restart if required; check the service in SQL01’s PowerShell:
Get-Service -Name MSSQLSERVER | Select-Object Name, Status
Expect Running. Through an authorized SQL connection, record the version:
SELECT
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('InstanceName') AS InstanceName;
ProductVersion should match the approved full 16.x build; Edition should identify Developer. The default instance returns NULL for InstanceName. If installation fails, inspect Summary.txt under C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\Log and Detail.txt in that run’s timestamped subfolder before retrying.
Example
This is a hypothetical lab check, not a real incident. If setup fails on SQL01, inspect Summary.txt and the relevant installation's Detail.txt under C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\Log. No test execution or observed error output is claimed.
Choose Windows Authentication or Mixed Mode
I would keep the default Windows Authentication during setup. Manage SQL01 locally with the authorized local Windows account added as a SQL Server administrator during installation. Being a Windows administrator does not automatically grant SQL Server sysadmin privileges.
This hypothetical, non-production lab has no Active Directory. SQL01 does not automatically trust your Windows 11 client account; matching usernames are insufficient. Remote SSMS 20.2 connections follow the optional Mixed Mode branch. Microsoft Learn’s edition documentation confirms SQL Server 2022 Developer is not licensed for production; assess production licensing separately.
If you need SQL authentication, select Mixed Mode during setup. To switch later, open SSMS server properties, then Security, and select SQL Server and Windows Authentication mode. Restart the Database Engine service-MSSQLSERVER for this default instance-to apply it. Schedule the interruption: existing connections will disconnect. Mixed Mode retains Windows Authentication without requiring sa to be enabled.
Keep privileges narrow. Before this example, use an authorized administrator connection in SSMS to create SQL login AppLogin. Generate its password in a password manager, store it in a secure vault, leave password-policy checking enabled, and assign no additional server roles. Keep real passwords out of query files and application accounts separate from human administrators.
Run this T-SQL once as an authorized administrator. It creates the not-yet-existing AppDb and a hypothetical work-item table, maps the application user to its login, and adds it to a custom role with only table-level read and insert permissions.
USE master;
GO
CREATE DATABASE AppDb;
GO
USE AppDb;
GO
CREATE TABLE dbo.WorkItems
(
WorkItemId int IDENTITY(1,1) NOT NULL PRIMARY KEY,
Title nvarchar(200) NOT NULL
);
GO
CREATE USER AppUser FOR LOGIN AppLogin;
CREATE ROLE AppWriter AUTHORIZATION dbo;
GRANT SELECT, INSERT ON OBJECT::dbo.WorkItems TO AppWriter;
ALTER ROLE AppWriter ADD MEMBER AppUser;
GO
EXECUTE AS USER = 'AppUser';
SELECT
HAS_PERMS_BY_NAME('dbo.WorkItems', 'OBJECT', 'SELECT') AS CanSelect,
HAS_PERMS_BY_NAME('dbo.WorkItems', 'OBJECT', 'INSERT') AS CanInsert,
HAS_PERMS_BY_NAME('dbo.WorkItems', 'OBJECT', 'DELETE') AS CanDelete;
REVERT;
GO
Without other permissions, expect 1, 1, 0: read and insert allowed, no delete permission. This checks database-user permissions, not remote connectivity or passwords. REVERT restores the previous execution context. Do not use sa, sysadmin, or db_owner for application connections.
Authentication does not replace transport encryption; configure TLS separately following Microsoft Learn’s connection-encryption documentation. If the application needs updates later, grant UPDATE only on the required object, not broad database permissions.
Set Initial Memory, Database File, and tempdb Options
Windows still needs RAM. Leave room. On hypothetical, non-production SQL01 with 8 GB RAM, I’d start max server memory at 4096 MB, adjusting after measurement. This neither caps every SQL Server process allocation nor reserves all remaining memory for Windows.
Microsoft Learn recommends at least 4 GB RAM for non-Express SQL Server 2022 editions-a hardware recommendation, not an engine setting. Microsoft’s edition documentation restricts Developer to development and testing; production licensing needs separate consideration.
In SSMS 20.2, connect with sufficient privileges to SQL01’s default MSSQLSERVER instance. These commands configure memory and report its effective value, default paths, and existing files.
USE master;
GO
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 4096;
RECONFIGURE;
GO
SELECT name, value, value_in_use
FROM sys.configurations
WHERE name = 'max server memory (MB)';
SELECT
SERVERPROPERTY('InstanceDefaultDataPath') AS default_data_path,
SERVERPROPERTY('InstanceDefaultLogPath') AS default_log_path;
SELECT
DB_NAME(database_id) AS database_name,
name AS logical_name,
type_desc,
physical_name,
size / 128.0 AS size_mb,
is_percent_growth,
CASE WHEN is_percent_growth = 0
THEN growth / 128.0 END AS growth_mb
FROM sys.master_files
WHERE database_id = 2 OR database_id > 4
ORDER BY database_id, file_id;
Expect value_in_use to show 4096 without restarting. Default data and log paths should be D:\SQL\Data and L:\SQL\Log. Check physical_name too: changing defaults does not relocate files. Fresh installations may have no user-database rows.
Start with equally sized tempdb data files
For this 4 vCPU lab, use four equally sized data files and one log file under T:\SQL\TempDB. Example sizing: 256 MB initially per file, with fixed 128 MB growth. Verify free space first; actual capacity depends on workload.
Count existing files in SSMS under tempdb properties, Files. Already have four data files? Don’t add more. Equalize data-file sizes and growth increments without shrinking larger files to fit the example. Use fixed MB growth for user databases too; 128 MB isn’t universal.
Rerun the query: is_percent_growth=0 and growth_mb=128 indicate the example’s fixed growth. Changing tempdb paths requires a service restart; verify necessary destination file access for NT SERVICE\MSSQLSERVER beforehand. Separate drive letters don’t guarantee physical I/O isolation.
I’d leave MAXDOP and cost threshold for parallelism unchanged pending measurement. Record current settings; monitor CPU usage, waits, disk latency, and memory pressure under representative load. Pre-size files for expected usage rather than treating autogrowth as capacity planning.
Restrict TCP 1433 Access with TLS and Firewall Rules
TLS encrypts traffic; firewalls restrict who connects. I would use both. This hypothetical, nonproduction SQL01 lab runs the default MSSQLSERVER instance on Windows Server 2022. Microsoft’s edition documentation confirms SQL Server 2022 Developer is not licensed for production.
In SQL Server Configuration Manager, enable TCP/IP under SQL Server Network Configuration → Protocols for MSSQLSERVER. With Listen All = Yes, IPAll controls ports: clear TCP Dynamic Ports, then set TCP Port to 1433. Dynamic-port value 0 requests allocation, not disabling. Clear other IP sections’ dynamic-port values too.
Following Microsoft Learn’s encryption instructions, import a private-CA certificate and private key into Local Computer → Personal. The valid certificate must support Server Authentication, include SAN sql01.lab.example.com, and meet Microsoft’s key-provider requirements. Establish CA-chain trust on both clients; without Active Directory, do not expect automatic certificate distribution.
Under Manage Private Keys, grant NT SERVICE\MSSQLSERVER private-key read access. In Configuration Manager’s protocol properties, select it under Certificate; set Flags → Force Encryption = Yes. TCP and certificate changes require an engine restart, disconnecting existing sessions.
This example requires elevated PowerShell on SQL01. Replace documentation-only example.com and TEST-NET-1 addresses with actual private-network values.
New-NetFirewallRule -Name 'SQL01-TCP1433-Clients' `
-DisplayName 'SQL01 TCP 1433 approved clients' `
-Direction Inbound -Action Allow -Protocol TCP `
-LocalAddress 192.0.2.10 -LocalPort 1433 `
-RemoteAddress 192.0.2.20,192.0.2.30 `
-Profile Any -Enabled True |
Format-Table DisplayName, Enabled, Direction, Action
Restart-Service -Name MSSQLSERVER
The rule allows application client 192.0.2.20 and management client 192.0.2.30. Expect Enabled=True, Direction=Inbound, and Action=Allow; this table does not verify TLS. Keep default inbound blocking and remove broader SQL allowances. At the provider firewall, allow TCP 1433 only from these same sources, never the general internet.
In Windows 11’s SSMS 20.2, use tcp:sql01.lab.example.com,1433, Encryption=Mandatory, and unchecked Trust server certificate. Keep application certificate validation enabled too. Specifying the static port removes the need for SQL Server Browser discovery: disable Browser in this lab and leave UDP 1434 closed.
Tip
A direct connection using static TCP port 1433 does not require SQL Server Browser or UDP 1434 access. sql01.lab.example.com and 192.0.2.10, 192.0.2.20, and 192.0.2.30 are documentation placeholders; replace them with your actual private-network hostname and addresses. The certificate's SAN must match the actual DNS name the client uses.
Verify the SSMS Connection Layer by Layer
I would not diagnose this from an SSMS error dialog alone. Separate the layers. In the hypothetical, non-production SQL01 lab, check DNS, then TCP from the Windows 11 management client (192.0.2.30). Replace documentation-only example.com and TEST-NET-1 addresses with your private network values. Microsoft Learn’s editions documentation confirms SQL Server 2022 Developer is not licensed for production.
Resolve-DnsName -Name sql01.lab.example.com -Type A
Test-NetConnection -ComputerName sql01.lab.example.com -Port 1433 -InformationLevel Detailed
Expect 192.0.2.10 and TcpTestSucceeded : True, not recorded test results. If the address differs, check the DNS record and client resolver. TCP success proves port reachability, not SQL authentication or certificate validity. Unanswered ping does not establish TCP failure.
In SSMS 20.2, use tcp:sql01.lab.example.com,1433, set Encryption to Mandatory, and leave Trust server certificate unchecked. With no AD, this remote example follows the optional mixed-mode branch: select SQL Server Authentication. Microsoft Learn’s encryption documentation explains that the client must trust the certificate chain and the certificate must match the connection’s server name.
This password-free Microsoft.Data.SqlClient string requires a username and password supplied separately through secure secret management; without credentials, it cannot connect.
Server=tcp:sql01.lab.example.com,1433;Database=master;Integrated Security=False;Encrypt=True;TrustServerCertificate=False;
- Connection refused: Check SQL01’s
MSSQLSERVERservice, TCP/IP enablement, and TCP 1433 listener. - Timeout: Check routing, VPS network rules, and Windows Firewall’s TCP 1433 allowance from
192.0.2.30. - Certificate trust error: Fix the trust chain, validity dates, and FQDN match-not by disabling validation.
- 18456: Check mixed mode, SQL account status, password, and target database access. Read SQL ERRORLOG for the detailed reason and state code.
These queries read the current SQL ERRORLOG and this session’s encryption status. SQL Server 2022 requires VIEW ANY ERROR LOG and VIEW SERVER PERFORMANCE STATE, respectively. I would not grant broad diagnostic privileges to the application account.
EXEC master.sys.sp_readerrorlog 0, 1;
SELECT session_id, net_transport, encrypt_option, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
If remote access fails, inspect the log using SQL01’s authorized local Windows account. Expect net_transport = TCP and encrypt_option = TRUE remotely; encryption alone does not prove certificate validation. Local success cannot substitute for the remote connection: after fixing it, rerun the query in SSMS on the management client.
Complete the First Backup with a Restore Test
A backup file exists. Not finished. In SQL01’s hypothetical, non-production SQL Server 2022 Developer lab, I would accept AppDb only after a separate restore and data checks. These commands are illustrative, not tested. Microsoft Learn’s edition documentation excludes production use from Developer licensing; assess production licensing separately.
Microsoft Learn’s backup documentation specifies a data backup after switching to FULL to start the log backup chain. The first full backup supplies it. Our hypothetical schedule: full backups every 24 hours, transaction log backups every 15 minutes. Choose actual frequency by acceptable data loss. Full backups cannot replace log backups; missing log backups can cause growth, and other factors can prevent log-space reuse.
Verify NT SERVICE\MSSQLSERVER can create/read backups in B:\SQL\Backup and create destination data/log files. Never grant Everyone full control. Existing AppDb must have exactly one data and one log file; logical names come from the catalog. Destination files must not exist. Run the block together to preserve variable scope.
USE master;
IF DB_ID(N'AppDb_RestoreTest') IS NOT NULL
THROW 50000, N'AppDb_RestoreTest zaten var; işlem durduruldu.', 1;
IF (SELECT COUNT(*) FROM sys.master_files
WHERE database_id = DB_ID(N'AppDb')) <> 2
THROW 50001, N'Bu örnek yalnızca iki dosyalı AppDb içindir.', 1;
DECLARE @dataLogical sysname, @logLogical sysname;
SELECT @dataLogical = name
FROM sys.master_files
WHERE database_id = DB_ID(N'AppDb') AND type = 0;
SELECT @logLogical = name
FROM sys.master_files
WHERE database_id = DB_ID(N'AppDb') AND type = 1;
IF @dataLogical IS NULL OR @logLogical IS NULL
THROW 50002, N'Bir veri ve bir günlük dosyası gerekli.', 1;
ALTER DATABASE [AppDb] SET RECOVERY FULL;
DECLARE @id nvarchar(36) = CONVERT(nvarchar(36), NEWID());
DECLARE @full nvarchar(260) =
N'B:\SQL\Backup\AppDb_' + @id + N'_full.bak';
DECLARE @log nvarchar(260) =
N'B:\SQL\Backup\AppDb_' + @id + N'_log.trn';
BACKUP DATABASE [AppDb] TO DISK = @full
WITH CHECKSUM, STATS = 10;
BACKUP LOG [AppDb] TO DISK = @log
WITH CHECKSUM, STATS = 10;
SELECT @full AS FullBackupPath, @log AS LogBackupPath;
RESTORE VERIFYONLY FROM DISK = @full WITH CHECKSUM;
RESTORE VERIFYONLY FROM DISK = @log WITH CHECKSUM;
RESTORE FILELISTONLY FROM DISK = @full;
RESTORE DATABASE [AppDb_RestoreTest]
FROM DISK = @full
WITH MOVE @dataLogical TO N'D:\SQL\Data\AppDb_RestoreTest.mdf',
MOVE @logLogical TO N'L:\SQL\Log\AppDb_RestoreTest_log.ldf',
NORECOVERY, CHECKSUM, STATS = 10;
RESTORE LOG [AppDb_RestoreTest]
FROM DISK = @log
WITH RECOVERY, CHECKSUM, STATS = 10;
DBCC CHECKDB (N'AppDb_RestoreTest') WITH NO_INFOMSGS;
SELECT name, state_desc
FROM sys.databases
WHERE name = N'AppDb_RestoreTest';
Unique names avoid overwriting backups. FILELISTONLY lists files; MOVE redirects paths. NORECOVERY leaves restoration pending until log application with RECOVERY opens the database. Expect ONLINE without CHECKDB consistency errors. Microsoft Learn cautions that RESTORE VERIFYONLY cannot replace restoration. CHECKSUM cannot prove application-data correctness either: check critical tables and application reads.
Set SQL Server Agent to start automatically. Schedule separate full/log backup jobs without restore-test commands. Configure failure notifications to an operator through Database Mail; confirm delivery. Independently monitor Agent stoppages and overdue backups. This immediate log backup creates no schedule.
Local B: cannot protect against server loss. Consider Windows Server Backup: Methods, Scheduling, and Recovery for server-level planning alongside SQL backups. My final operational step would be an access-restricted off-server copy, with scheduled restore rehearsals from that copy.
Example
The hypothetical AppDb schedule takes a full backup every 24 hours and a transaction log backup every 15 minutes; these intervals are not a ready-made prescription for every workload. RESTORE VERIFYONLY does not replace an actual restore to AppDb_RestoreTest. Copy backups from B:\SQL\Backup to off-server storage too; a separate drive letter does not protect against server loss.
Check Before Connecting Your Application
- Verify Windows Server compatibility, licensing, pending restarts, a system backup, and access to the provider's console.
- Prepare the NTFS directories D:\SQL\Data, L:\SQL\Log, T:\SQL\TempDB, and B:\SQL\Backup, and check the service account's required permissions.
- Use official SQL Server 2022 media, verify the current approved CU package, and record the full build after installation using SERVERPROPERTY.
- Add the authorized local Windows account as a SQL administrator, and exclude sa, sysadmin, and db_owner from application access.
- Evaluate the 4096 MB memory starting setting, fixed-MB file growth, and four equally sized tempdb data files against workload measurements.
- Restrict TCP 1433 at both firewall layers, and check DNS, Test-NetConnection, and SSMS certificate validation separately.
- Create the initial full backup and log backup jobs under the FULL recovery model, then verify failure notifications, off-server copies, and a restore to a separate database.
Before allowing the application to connect, restore the AppDb backup to a separate AppDb_RestoreTest database. Record the recovery time and verify that it meets your service target.
Frequently Asked Questions
Can I use SQL Server 2022 Developer for free on a Windows VPS?
SQL Server 2022 Developer is free for development and testing; it does not grant the right to run a production database. Hosting it on a Windows VPS does not change those license terms. For production, evaluate an appropriate commercial license or Express if its resource and feature limits suit your application. Check Windows Server licensing separately from SQL Server licensing.
Are 4 vCPUs and 8 GB RAM enough for SQL Server?
4 vCPUs and 8 GB RAM are the starting capacity for this non-production lab, not a performance guarantee for your application. Data volume, concurrent queries, and storage latency change what you need. The example starts max server memory at 4096 MB, but that setting is not an absolute cap on all memory consumed by the SQL Server process. Adjust capacity using measurements.
What is the difference between Windows authentication and mixed mode?
Windows authentication uses Windows accounts; mixed mode adds sign-in with a SQL Server username and password. In this example without Active Directory, a remote Windows account is not automatically trusted. If SQL authentication is required, enable mixed mode and restart the Database Engine service. Give the application a separate account with narrowly scoped permissions rather than using sa.
Which ports should I open for remote SQL Server connections?
This example uses static TCP 1433 for the Database Engine. Allow only the application and management clients' actual private IP addresses in Windows Firewall and the provider firewall. Do not expose the port to the public internet. When the client specifies the server and port directly, SQL Server Browser discovery is unnecessary, so this connection path does not require UDP 1434.
How do I distinguish an SSMS certificate error from error 18456?
First check DNS resolution, then TCP 1433 reachability with Test-NetConnection. In SSMS 20.2, select Encryption=Mandatory and leave Trust server certificate disabled. For certificate errors, check the trust chain, validity period, and SAN hostname. Error 18456 is a login failure; inspect its state code in SQL ERRORLOG for the detailed reason. Disabling certificate validation is not a permanent fix.
Do I need transaction log backups after the first full backup?
Under the FULL recovery model, schedule regular transaction log backups after the initial full backup; full backups alone do not provide the log truncation needed for log space reuse. The hypothetical lab uses full backups every 24 hours and log backups every 15 minutes. Choose intervals based on acceptable data loss. Keep off-server copies and perform an actual restore test rather than relying only on RESTORE VERIFYONLY.
Sources
- Microsoft Learn – SQL Server 2022 Hardware and Software Requirements — learn.microsoft.com
- Microsoft Learn – SQL Server 2022 Editions and Supported Features — learn.microsoft.com
- Microsoft Learn – Configure SQL Server Connection Encryption — learn.microsoft.com
- Microsoft Learn – Documentation Portal for SQL Server Backup and Restore — learn.microsoft.com