Install SQL Server 2025 Developer Edition on Windows Server 2025

You need a full SQL Server to build against, without paying or living inside Express limits. SQL Server Developer Edition is the answer: it is free, it carries the complete engine, and the only thing it forbids is production use. The SQL Server 2025 release changed how you get it, though. There is no single “Developer” download anymore and the installer you pick decides the edition. On top of that, the bundled sqlcmd now runs on ODBC Driver 18, so the first query on a fresh box fails with a certificate error.

Original content from computingforgeeks.com - post 46249

In this walkthrough we install SQL Server 2025 Enterprise Developer on Windows Server 2025 the repeatable way. We download the installer from Microsoft, pull the full ISO with the bootstrapper and run setup unattended, then check the instance with sqlcmd, open TCP 1433 for remote clients and create a test database. First, though, Developer vs Express. I ran through this on a Windows Server 2025 VM in my homelab in October 2026 with the SQL Server 2025 RTM media, and it works end to end; every output below comes from that box.

SQL Server Developer vs Express: which free edition do you need?

Pick Developer when you are building or testing, and Express when the database will serve real users on a small budget. Developer is licensed for development and test only, so it cannot back a production app, but it has no size or memory caps. Express is free for production, yet it stops at 50 GB per database and a 1,410 MB buffer pool. With SQL Server 2025, Microsoft split Developer into two editions so your test box can match what production will run:

Edition (SQL Server 2025)	Cost	Production use	Max database size	Compute and memory
Express	Free	Yes	50 GB (10 GB on older versions)	Lesser of 1 socket or 4 cores, 1,410 MB buffer pool
Standard Developer	Free	No, dev and test only	No edition cap	Same feature set as Standard
Enterprise Developer	Free	No, dev and test only	No edition cap	Every Enterprise feature, OS maximum
Standard (paid)	Licensed	Yes	No edition cap	Lesser of 4 sockets or 32 cores, 256 GB buffer pool

Every figure in that table comes from the SQL Server 2025 editions and features page on Microsoft Learn. Enterprise Developer is the old “Developer” under a new name, so it is the default choice for most people. Standard Developer earns its place when production runs Standard, because a query plan or feature that works on Enterprise can quietly fail on Standard, and you want to find that on your laptop rather than during the release. We used Enterprise Developer in the lab; the steps are identical for Standard Developer apart from the download link.

Prerequisites

SQL Server 2025 supports Windows Server 2019, 2022 and 2025, and the Microsoft OS matrix lists Windows 10 and 11 for Express, Standard and Standard Developer only. The official hardware floor is low. A development box that also runs your app and tools needs more than the floor. This list pairs what we gave the lab VM with the minimum Microsoft lists:

• Windows Server 2025 Standard or Datacenter (our VM ran Datacenter Evaluation)
• 4 vCPU and 8 GB RAM in the lab (minimum 1 GB, 4 GB recommended)
• 6 GB free disk at minimum, plus about 1.2 GB for the ISO
• .NET Framework 4.7.2, already present on Windows Server 2025
• An elevated PowerShell session and internet access

If the server itself is not built yet, follow the Windows Server 2025 installation guide first. On Proxmox, a Windows Server template saves you the install entirely, which is how our VM was created. The engine took 0.74 GB on disk after setup, so the 6 GB floor is mostly headroom for databases and logs.

Step 1: Download the SQL Server Developer Edition installer

On the SQL Server downloads page you now get two Developer buttons, one per edition. Each one is a small bootstrapper of about 4.5 MB, not the full product. If you prefer to stay in PowerShell, the same links download directly. Create a working folder and fetch the Enterprise Developer bootstrapper:

New-Item -ItemType Directory C:\lab -Force
Invoke-WebRequest -Uri 'https://go.microsoft.com/fwlink/?linkid=2344711&clcid=0x409&culture=en-us&country=us' -OutFile C:\lab\SQL2025-SSEI-EntDev.exe -UseBasicParsing

For Standard Developer, use linkid=2344626 instead; that file arrives as SQL2025-SSEI-StdDev.exe. Before running anything, check that you got what you asked for, because the metadata inside the file names the edition.

(Get-Item C:\lab\SQL2025-SSEI-EntDev.exe).VersionInfo | Select ProductName,ProductVersion,OriginalFilename | Format-List

Our download reported the SQL Server installer at 17.0.1000.7, which is the SQL Server 2025 RTM build:

ProductName      : Microsoft Sql Server Installer
ProductVersion   : 17.0.1000.7
OriginalFilename : SQL2025-SSEI-EntDev.exe

On the homelab line the download took 3.4 seconds, so do not be surprised by how small it is. A 4.5 MB file cannot hold a database engine, and the real payload comes in the next step, when the bootstrapper fetches the media it was built for.

Step 2: Pull the full ISO with the bootstrapper

Double-clicking the bootstrapper gives you three buttons, and only one of them suits a server you plan to rebuild:

• Basic: installs the engine with defaults and no choices
• Custom: downloads the media, then opens the full setup wizard
• Download Media: saves an ISO or CAB for offline installs

We prefer the ISO because you can reuse it on other servers, run setup offline and keep it for a later uninstall or repair. The bootstrapper accepts a quiet download on the command line, which saves clicking through it.

Start-Process C:\lab\SQL2025-SSEI-EntDev.exe -ArgumentList '/ACTION=Download','/MEDIAPATH=C:\SQLMedia','/MEDIATYPE=ISO','/QUIET' -Wait

Nothing prints while it works, and the command returns once the download is complete. Our ISO came to about 1.2 GB.

FullName                                         Length
--------                                         ------
C:\SQLMedia\SQLServer2025-x64-ENU-EntDev.iso 1265688576

Mount it and read the default setup file, which is where the edition is decided:

$m = Mount-DiskImage -ImagePath C:\SQLMedia\SQLServer2025-x64-ENU-EntDev.iso -PassThru
$d = ($m | Get-Volume).DriveLetter
Get-Content "$($d):\x64\DefaultSetup.ini"

Enterprise Developer media ships with its product key already filled in.

;SQL Server 2025 Configuration File
[OPTIONS]
PID="22222-00000-00000-00000-00000"

We downloaded the Standard Developer ISO on the same box to compare, and its DefaultSetup.ini holds PID="33333-00000-00000-00000-00000" instead. That is why there is no edition switch to pass later: the media you mount is the edition you get. If you mount the wrong ISO, setup will happily install the wrong Developer edition, so check this file when you keep both on a share. In our case the ISO mounted as D:, which the rest of the guide uses.

Step 3: Install SQL Server 2025 Developer unattended

Running D:\setup.exe without arguments opens the SQL Server Installation Center, and the wizard asks the same questions the parameters below answer. We went with the unattended route because every choice sits on one line you can save and run again on the next server. The parameters are documented in Microsoft’s install from the command prompt reference. Set your own sa password first, because you will need it again in Step 6:

$SaPassword = 'Str0ng!Passw0rd'

Now start setup from the mounted ISO. This installs only the Database Engine as the default instance, makes the local Administrators group sysadmin, turns on mixed authentication and enables TCP/IP during the install:

D:\setup.exe /Q /ACTION=Install /IACCEPTSQLSERVERLICENSETERMS /SUPPRESSPRIVACYSTATEMENTNOTICE /FEATURES=SQLENGINE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS="BUILTIN\Administrators" /SECURITYMODE=SQL /SAPWD="$SaPassword" /TCPENABLED=1 /SQLSVCSTARTUPTYPE=Automatic /AGTSVCSTARTUPTYPE=Automatic

A few of those switches are not optional, and the ones you leave out change the result:

• /IACCEPTSQLSERVERLICENSETERMS and /SUPPRESSPRIVACYSTATEMENTNOTICE: required with /Q
• /SQLSYSADMINACCOUNTS: required on every edition except Express
• /SECURITYMODE=SQL with /SAPWD: leave both out for Windows-only logins
• /TCPENABLED=1: saves a trip to Configuration Manager later

Setup prints nothing while it works. On our 4 vCPU VM it ran for 8 minutes and 24 seconds, and the result lands in the summary log. If your ISO mounted under a letter other than D:, change the path to match. Wait until Get-Process setup returns nothing before you read the log, otherwise you read a half-written file:

Get-Content 'C:\Program Files\Microsoft SQL Server\170\Setup Bootstrap\Log\Summary.txt' -TotalCount 30

Two lines matter most, the final result and the installation edition.

Overall summary:
  Final result:                  Passed
  Exit code (Decimal):           0
  Start time:                    2026-10-29 20:54:10
  End time:                      2026-10-29 21:02:34
  Requested action:              Install
...
Package properties:
  Description:                   Microsoft SQL Server 2025
  ProductName:                   SQL Server 2025
  Type:                          RTM
  Version:                       17
  SPLevel:                       0
  Installation location:         D:\x64\setup\
  Installation edition:          Enterprise Developer

Product Update Status:
  None discovered.

Look at the last line. Setup checks for updates by default, yet it found none and installed plain RTM even though cumulative updates up to CU10 (build 17.0.5035.5, October 2026) were already out. Do not assume the installer patched itself; plan to apply the latest CU from the SQL Server 2025 build list once the instance is up.

Step 4: Verify the install with sqlcmd

Setup installs sqlcmd under C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\180\Tools\Binn and adds it to the machine PATH, but the PowerShell window that ran setup still has the old PATH. Reload it in the same window rather than opening a new one, because a new window would also lose the $SaPassword variable that Step 6 needs:

$env:Path = [Environment]::GetEnvironmentVariable('Path','Machine')

Then ask the instance what it is. The -C flag matters here, and the next section shows what happens without it:

sqlcmd -S localhost -E -C -Q "SELECT @@VERSION"

Our instance reported the RTM build with the Enterprise Developer label, running on Windows Server 2025:

Microsoft SQL Server 2025 (RTM) - 17.0.1000.7 (X64)
	Oct 21 2025 12:05:57
	Copyright (C) 2025 Microsoft Corporation
	Enterprise Developer Edition (64-bit) on Windows Server 2025 Datacenter 10.0 <X64> (Build 26100: ) (Hypervisor)

Services tell the rest of the story. The engine and SQL Server Agent are both set to start automatically, which is one practical difference from Express, while the SQL Server Browser is disabled because a default instance on port 1433 does not need it:

If you see Express Edition or Enterprise Evaluation Edition in that output instead, the wrong media or a missing PID went into setup. Evaluation stops working after 180 days, so it is worth catching now rather than in six months.

Error: “The certificate chain was issued by an authority that is not trusted”

Our first sqlcmd call, without -C, failed with this:

Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : SSL Provider: The certificate chain was issued by an authority that is not trusted.
.
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Client unable to establish connection. For solutions related to encryption errors, see https://go.microsoft.com/fwlink/?linkid=2226722.

Why does a brand new instance refuse a local connection? The sqlcmd that ships with SQL Server 2025 runs on ODBC Driver 18, which encrypts the connection by default and validates the server certificate. A fresh instance only has a self-signed certificate, so validation fails even on localhost. The -C switch tells the client to trust that certificate, which is fine on a dev box. Applications hit the same thing, and they take TrustServerCertificate=True in the connection string for the same effect. On a shared server, install a certificate from your internal CA instead of teaching every client to skip the check.

Step 5: Cap max server memory

An unattended install leaves the memory cap at its unlimited default, which you can see in the configuration:

sqlcmd -S localhost -E -C -W -Q "SET NOCOUNT ON; SELECT name, value_in_use FROM sys.configurations WHERE name IN ('max server memory (MB)','min server memory (MB)');"

Our fresh instance showed the defaults. A maximum of 2,147,483,647 MB is how the engine says “no limit at all”, since no server has that much memory.

name value_in_use
---- ------------
min server memory (MB) 16
max server memory (MB) 2147483647

Idle, our engine used about 405 MB, but SQL Server grows its buffer pool until something stops it. On a development machine that also runs Visual Studio, Docker or your application, that means the database slowly starves everything else. We capped it at 4 GB, half of the memory on the VM.

sqlcmd -S localhost -E -C -Q "EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'max server memory (MB)', 4096; RECONFIGURE;"

No service restart is needed, because the new limit applies as soon as RECONFIGURE runs.

Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.
Configuration option 'max server memory (MB)' changed from 2147483647 to 4096. Run the RECONFIGURE statement to install.

Ignore the “Run the RECONFIGURE statement” line, which is printed by sp_configure itself; the RECONFIGURE in the same batch already took care of it. If you install with setup.exe later, the /SQLMAXMEMORY parameter sets the same value at install time.

Step 6: Allow remote connections on TCP 1433

Because we passed /TCPENABLED=1, the engine was already listening on 0.0.0.0:1433 and [::]:1433 after setup. A client on another machine still could not reach it, because Windows Defender Firewall had no rule for SQL Server. Add one:

New-NetFirewallRule -DisplayName 'SQL Server TCP 1433' -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow -Profile Domain,Private

That rule alone did not open the port in our lab, and the reason is easy to miss. The network adapter on our server was on the Public profile, which a rule scoped to Domain and Private never touches. Check which profile yours uses:

Get-NetConnectionProfile | Select InterfaceAlias,NetworkCategory

Ours came back as Public, the default for a workgroup server that has not been told otherwise:

InterfaceAlias NetworkCategory
-------------- ---------------
Ethernet                Public

On a trusted lab or office LAN, move the adapter to Private. A domain-joined server switches to the Domain profile on its own, so this only bites workgroup boxes like ours. The Private profile also applies every other Private rule on the box, such as file sharing, so never do this on a network you do not trust:

Set-NetConnectionProfile -InterfaceAlias Ethernet -NetworkCategory Private

Port 1433 answered from a Linux machine on the same LAN right after that. Do not “fix” it by adding Public to the rule unless you understand who else sits on that network. The Windows Server firewall guide covers rule scoping in more detail. Next, prove that SQL authentication works over TCP rather than over shared memory, using the LAN address of the server. Replace 10.0.1.50 with the IPv4 address your server reports in Get-NetIPAddress -AddressFamily IPv4.

sqlcmd -S tcp:10.0.1.50,1433 -U sa -P "$SaPassword" -C -W -Q "SET NOCOUNT ON; SELECT c.net_transport, c.auth_scheme, c.local_tcp_port FROM sys.dm_exec_connections c WHERE c.session_id=@@SPID;"

Our session reported TCP on port 1433 with SQL authentication, so both the protocol and the sa login are working.

net_transport auth_scheme local_tcp_port
------------- ----------- --------------
TCP SQL 1433

From the Linux machine, a small python-tds client logged in as sa and read back ('SQLDEV01', 'Enterprise Developer Edition (64-bit)', '17.0.1000.7', 'TCP', 'FALSE'), which proves the firewall path end to end. If you want a fixed non-default port instead of 1433, the guide to make SQL Server listen on a given port shows the Configuration Manager side, and the remote access guide walks through the same checks from the client side.

Step 7: Create a test database

A last check writes real data, which shows that the data directory, the transaction log and permissions are all in order. Create the database first:

sqlcmd -S localhost -E -C -Q "CREATE DATABASE labdb;"

Then add a table, insert three rows and ask where SQL Server put the files. We did not pass any data directory parameters to setup, so the answer shows the defaults you will be living with.

sqlcmd -S localhost -E -C -W -d labdb -Q "SET NOCOUNT ON; CREATE TABLE dbo.hosts (id INT IDENTITY PRIMARY KEY, name NVARCHAR(50), role NVARCHAR(50)); INSERT INTO dbo.hosts (name, role) VALUES ('pve01','hypervisor'),('nas01','storage'),('sqldev01','database'); SELECT * FROM dbo.hosts; SELECT name, physical_name FROM sys.database_files;"

All three rows come back with their identity values, followed by the data and log file paths under the MSSQL17.MSSQLSERVER folder:

id name role
-- ---- ----
1 pve01 hypervisor
2 nas01 storage
3 sqldev01 database
name physical_name
---- -------------
labdb C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\DATA\labdb.mdf
labdb_log C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\DATA\labdb_log.ldf

Our first attempt put GO inside the -Q string and got Msg 102, Level 15, State 1, Server SQLDEV01, Line 1 Incorrect syntax near 'GO'. That is expected: GO is a batch separator that sqlcmd understands only in scripts and interactive mode, not a T-SQL statement, so separate statements with semicolons in -Q. For a GUI, install SQL Server Management Studio, which stays a separate download; then move on to creating logins, users and permissions so your applications stop connecting as sa. Readers still on the older release can follow the SQL Server 2019 Developer guide.

Remove SQL Server Developer cleanly

Developer boxes get rebuilt often, and the same ISO removes the engine as cleanly as it installed it. Keep the ISO mounted, then run setup with the uninstall action and the same instance name:

D:\setup.exe /Q /ACTION=Uninstall /FEATURES=SQLENGINE /INSTANCENAME=MSSQLSERVER /SUPPRESSPRIVACYSTATEMENTNOTICE

On our VM the removal ran for 4 minutes and 33 seconds, and the summary log reported it the same way as the install:

Overall summary:
  Final result:                  Passed
  Exit code (Decimal):           0
  Start time:                    2026-10-29 21:11:23
  End time:                      2026-10-29 21:15:56
  Requested action:              Uninstall

The services and system databases were gone afterwards, but labdb.mdf and labdb_log.ldf were still sitting in the old DATA folder. Setup does not delete user database files, which means a rebuild can attach them again. That is handy when you reinstall on purpose and surprising when you expected a clean disk, so copy out what you want to keep and delete the MSSQL17.MSSQLSERVER folder yourself before you call the box clean.