INTRODUCTION
Hello everyone, and welcome to Techaptic.
Today, we are going to walk through the installation of Microsoft SQL Server 2025 and discuss how to configure it according to enterprise standards.
We will perform this setup in an Active Directory domain environment. This means that we will not simply follow the default installation steps. We will also apply important best practices covering service account management, disk separation, SQL Server memory optimization, authentication, TempDB configuration, MAXDOP, autogrowth settings, network access, and post-installation validation.
We will also improve security by avoiding unnecessary use of highly privileged accounts and by using Windows Authentication wherever possible.
Our goal is to build a SQL Server infrastructure that is organized, secure, high-performing, manageable, and ready to be adapted for a production environment.
Let’s get started.
𝗥𝗘𝗩𝗜𝗘𝗪𝗜𝗡𝗚 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝟮𝟬𝟮𝟱 𝗛𝗔𝗥𝗗𝗪𝗔𝗥𝗘 𝗥𝗘𝗤𝗨𝗜𝗥𝗘𝗠𝗘𝗡𝗧𝗦
Before starting the installation, we should review the prerequisites.
On the Microsoft requirements page, we can see both the hardware and software requirements for SQL Server 2025.
For the processor, the minimum requirement shown here is a 1.4 GHz x64-compatible processor. A faster processor, such as 2.0 GHz or higher, and multiple virtual CPUs are recommended for practical workloads.
For memory, the listed minimum is 1 GB, but that value is only enough for very limited scenarios. For a realistic SQL Server installation, 16 GB or more is a much more reasonable starting point.
For storage, the installation itself requires several gigabytes of free disk space. However, this minimum value does not include the space required for user databases, transaction logs, TempDB, backups, cumulative updates, and future database growth.
The recommended hardware values are not fixed rules for every environment. SQL Server resource requirements can vary significantly depending on the database size, number of databases, number of concurrent users, query workload, application type, reporting activity, index maintenance, backup operations, high-availability design, and expected future growth.
You should treat the published values as a starting point and perform proper sizing according to the actual workload.
𝗣𝗟𝗔𝗡𝗡𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗗𝗜𝗦𝗞 𝗟𝗔𝗬𝗢𝗨𝗧
For better organization and performance, we will separate different SQL Server workloads across multiple disks.
In this setup, we will use five drive letters.
The C drive will contain the Windows operating system and the SQL Server application files.
The D drive will contain the SQL Server user database data files.
The L drive will contain the SQL Server transaction log files.
The T drive will contain the TempDB data and log files.
The B drive will contain SQL Server backup files.
Separating these workloads helps us manage capacity, permissions, monitoring, and storage performance more effectively.
However, simply creating multiple drive letters does not automatically guarantee better performance. In a production environment, the underlying physical storage, RAID configuration, SAN design, storage controller, cache, latency, IOPS, throughput, redundancy, and failure domains are just as important as the Windows drive letters.
In this lab, the disks may still be located on the same underlying physical storage. The separation shown here is mainly intended to demonstrate a clean and manageable SQL Server directory structure.
𝗥𝗘𝗩𝗜𝗘𝗪𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗢𝗙𝗧𝗪𝗔𝗥𝗘 𝗥𝗘𝗤𝗨𝗜𝗥𝗘𝗠𝗘𝗡𝗧𝗦
The software requirements section lists the supported Windows operating systems and supporting components.
SQL Server can be installed on supported Windows client and Windows Server operating systems. For production use, it is generally better to install SQL Server on a current and supported Windows Server operating system.
The server should be fully updated and should meet the required .NET Framework and Windows component prerequisites for the selected SQL Server version.
After installing the SQL Server Database Engine, we will separately install SQL Server Management Studio, or SSMS. SSMS is the graphical administration tool that we will use to connect to and manage SQL Server.
We also need the SQL Server 2025 installation media. This can be provided as an ISO file or another supported installation package.
𝗖𝗛𝗢𝗢𝗦𝗜𝗡𝗚 𝗧𝗛𝗘 𝗖𝗢𝗥𝗥𝗘𝗖𝗧 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗘𝗗𝗜𝗧𝗜𝗢𝗡
SQL Server is available in different editions.
For production environments, SQL Server Standard or Enterprise editions are commonly used, depending on the organization’s licensing model, performance requirements, resource limits, high-availability design, and required features.
SQL Server Express is free, but it includes database size, resource, and feature limitations. It is suitable for small applications, learning environments, and limited workloads, but it is not appropriate for every production scenario.
Developer editions are intended for development, demonstration, and testing. They allow access to the corresponding SQL Server features without requiring a production license, but they are not licensed for production workloads.
SQL Server may also provide a time-limited Evaluation edition that can be used for testing.
When choosing an edition, you should not look only at whether the installation can be completed. You must also consider licensing, CPU and memory limits, database size, high availability, encryption, performance features, support requirements, and the SQL Server capabilities required by the application.
Trial and Developer editions can be obtained from Microsoft’s SQL Server download page.
For a licensed production deployment, the installation media and product key can be obtained through the organization’s Microsoft licensing portal or another authorized Microsoft licensing channel.
The relevant Microsoft download pages can be found in the video description.
𝗥𝗘𝗩𝗜𝗘𝗪𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗡𝗘𝗧𝗪𝗢𝗥𝗞 𝗥𝗘𝗤𝗨𝗜𝗥𝗘𝗠𝗘𝗡𝗧𝗦
The most commonly used TCP port for a SQL Server default instance is TCP 1433.
For remote clients to connect through this port, the TCP/IP protocol must be enabled for the SQL Server instance. SQL Server must also be configured to listen on the required port, and the network and local Windows firewall must allow the connection.
Named instances work slightly differently.
A named SQL Server instance may use a dynamic TCP port. In that type of configuration, client systems may use the SQL Server Browser service to discover which port belongs to the named instance.
The SQL Server Browser service normally listens on UDP 1434.
However, in environments with strict firewall rules, assigning a static TCP port to the named instance is generally more controlled and manageable. You can then allow only that specific port from authorized application servers, management systems, or client networks.
Internet access is not mandatory for the SQL Server Database Engine itself, but it is useful during installation and maintenance. It can be used to download SQL Server cumulative updates, SQL Server Management Studio, drivers, documentation, and other supporting components.
In a restricted environment, these files can be downloaded from another system and transferred through an approved method.
𝗝𝗢𝗜𝗡𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗧𝗢 𝗔𝗖𝗧𝗜𝗩𝗘 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬
SQL Server can be installed on a standalone workgroup server.
However, in an enterprise environment, joining the server to Active Directory provides important benefits for centralized identity management, group-based authorization, service account management, auditing, and access control.
SQL Server should normally be installed on a dedicated member server.
Installing the SQL Server Database Engine directly on a Domain Controller is not recommended because it combines critical infrastructure roles and creates additional security, maintenance, recovery, and operational risks.
In this demonstration, the SQL Server is a separate Active Directory member server.
𝗣𝗟𝗔𝗡𝗡𝗜𝗡𝗚 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗦𝗘𝗥𝗩𝗜𝗖𝗘 𝗔𝗖𝗖𝗢𝗨𝗡𝗧𝗦
Service accounts are another important part of the design.
SQL Server services should not run under Domain Administrator, Enterprise Administrator, or other highly privileged administrative accounts.
Where supported and appropriate, a Group Managed Service Account, or gMSA, can simplify password management and improve security.
A Managed Service Account or a virtual account may also be suitable in some environments.
If those options are not appropriate, separate low-privilege domain accounts can be created for the SQL Server Database Engine and SQL Server Agent services.
Using separate accounts provides better service isolation and makes permissions easier to understand and audit.
For this demonstration, we created two low-privilege Active Directory accounts: one for the SQL Server Database Engine and one for SQL Server Agent.
A Windows account that runs a service requires the Log on as a service right.
When we enter the domain accounts during SQL Server Setup, the installation process uses our installation privileges to apply the required local rights. We do not need to grant those local rights manually before the installation in this scenario.
𝗣𝗥𝗘𝗣𝗔𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗪𝗜𝗡𝗗𝗢𝗪𝗦 𝗦𝗘𝗥𝗩𝗘𝗥
To keep the video focused, several server preparation steps have already been completed.
The Windows Server has been given a meaningful computer name.
A static IP address has been assigned.
The server has been joined to the Active Directory domain.
The two SQL Server service accounts have been created.
The required additional virtual disks have also been attached to the server.
We can now initialize and format those disks.
𝗜𝗡𝗜𝗧𝗜𝗔𝗟𝗜𝗭𝗜𝗡𝗚 𝗔𝗡𝗗 𝗙𝗢𝗥𝗠𝗔𝗧𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗗𝗜𝗦𝗞𝗦
Open Computer Management and then open Disk Management.
Initialize the new disks if Windows has not already initialized them.
We will format the SQL Server data, log, TempDB, and backup volumes as NTFS.
For the non-system SQL Server volumes, we will use a 64 KB allocation unit size.
A 64 KB allocation unit size is widely used for SQL Server storage. We are not expecting it to create a magical performance improvement on its own. The goal is to use a storage layout that is commonly aligned with large SQL Server data and log files.
The exact performance still depends on the underlying storage platform and workload.
𝗖𝗥𝗘𝗔𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗗 𝗗𝗥𝗜𝗩𝗘 𝗙𝗢𝗥 𝗗𝗔𝗧𝗔 𝗙𝗜𝗟𝗘𝗦
The first additional disk has 40 GB of capacity.
Start the New Simple Volume Wizard and click Next.
Assign the D drive letter.
Set the allocation unit size to 64 KB.
Enter Data as the volume label.
Continue through the wizard and finish the format operation.
This drive will contain the user database data files.
𝗖𝗥𝗘𝗔𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗕 𝗗𝗥𝗜𝗩𝗘 𝗙𝗢𝗥 𝗕𝗔𝗖𝗞𝗨𝗣𝗦
The next disk will be used for SQL Server backup files.
Start the volume creation process and assign the B drive letter.
Set the allocation unit size to 64 KB.
Enter Backup as the volume label and complete the format.
We are using a separate backup disk for organization and demonstration purposes.
In a production environment, keeping the only backup copy on the SQL Server itself is not sufficient. If possible, backups should also be transferred to a protected remote server, dedicated backup repository, immutable storage platform, or another failure domain.
A local backup can still be useful for fast restores, but it should not be the organization’s only recovery copy.
𝗖𝗥𝗘𝗔𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗟 𝗗𝗥𝗜𝗩𝗘 𝗙𝗢𝗥 𝗧𝗥𝗔𝗡𝗦𝗔𝗖𝗧𝗜𝗢𝗡 𝗟𝗢𝗚𝗦
We have two additional 20 GB disks.
One will be used for SQL Server transaction log files, and the other will be used for TempDB.
For the transaction log disk, assign the L drive letter.
Set the allocation unit size to 64 KB.
Use SQLLog or Log as the volume label.
Complete the format operation.
𝗖𝗥𝗘𝗔𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗧 𝗗𝗥𝗜𝗩𝗘 𝗙𝗢𝗥 𝗧𝗘𝗠𝗣𝗗𝗕
For the final disk, assign the T drive letter.
Again, set the allocation unit size to 64 KB.
Use TempDB as the volume label.
Complete the format operation.
Open This PC and confirm that the D, B, L, and T drives are available.
The storage layout is now ready for the SQL Server installation.
𝗦𝗧𝗔𝗥𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝟮𝟬𝟮𝟱 𝗜𝗡𝗦𝗧𝗔𝗟𝗟𝗔𝗧𝗜𝗢𝗡
Mount the SQL Server 2025 ISO file on the Windows Server.
Open the mounted installation media and double-click setup.exe.
The SQL Server Installation Center opens.
From the left-hand menu, select Installation.
Click New SQL Server Stand-Alone Installation or Add Features to an Existing Installation.
The SQL Server Setup wizard now begins.
𝗦𝗘𝗟𝗘𝗖𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗘𝗗𝗜𝗧𝗜𝗢𝗡 𝗔𝗡𝗗 𝗣𝗥𝗢𝗗𝗨𝗖𝗧 𝗞𝗘𝗬
The Edition page provides multiple licensing options.
If you are using a free Developer or Evaluation edition, select the appropriate free edition from the list.
If you have a licensed edition, enter the product key and select the licensing option supplied by your organization.
This environment is a lab and demonstration environment, so we will select the Enterprise Developer edition.
Remember that Developer editions are not licensed for production use.
Click Next.
Review the Microsoft license terms.
Accept the terms if you agree and click Next.
𝗘𝗡𝗔𝗕𝗟𝗜𝗡𝗚 𝗠𝗜𝗖𝗥𝗢𝗦𝗢𝗙𝗧 𝗨𝗣𝗗𝗔𝗧𝗘
SQL Server Setup recommends using Microsoft Update to check for product updates.
We will enable this option so that the installation can check for relevant SQL Server updates.
Click Next.
The wizard runs setup support checks and verifies whether any blocking conditions exist.
In this environment, there are no failed checks, but there is a Windows Firewall warning.
We will configure the required TCP port and local firewall rule with a PowerShell script after the installation, so we can continue.
A firewall warning should not be ignored in a real implementation without a plan. You must know which clients require access, which port will be used, and where the firewall rule will be applied.
Click Next.
𝗦𝗘𝗟𝗘𝗖𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗙𝗘𝗔𝗧𝗨𝗥𝗘𝗦
The Feature Selection page asks which SQL Server components should be installed.
The best approach is not to select every feature automatically. Install only the components required by the application and operational design.
For this video, we will select Database Engine Services.
The Database Engine is the core SQL Server service responsible for storing, processing, securing, and retrieving relational data.
If your environment requires other features, you can add them according to the application requirements and Microsoft documentation.
At the bottom of the page, Setup displays shared feature and installation directories.
These directories contain SQL Server program files and shared components.
The actual user database, transaction log, backup, and TempDB locations will be configured separately in the Database Engine settings.
Click Next.
𝗖𝗛𝗢𝗢𝗦𝗜𝗡𝗚 𝗔 𝗗𝗘𝗙𝗔𝗨𝗟𝗧 𝗢𝗥 𝗡𝗔𝗠𝗘𝗗 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗜𝗡𝗦𝗧𝗔𝗡𝗖𝗘
The Instance Configuration page provides two main choices: a default instance or a named instance.
An instance can be considered an independent SQL Server Database Engine installation.
A single Windows Server can host one default instance and one or more named instances, subject to support, licensing, resource, and operational requirements.
Each instance has its own services, system databases, configuration, logins, databases, and network settings.
For a default instance, the standard instance name is MSSQLSERVER.
When TCP/IP is enabled and the default instance listens on TCP 1433, clients can normally connect by using only the server hostname or FQDN.
A named instance is addressed by using a format such as SERVERNAME\INSTANCENAME, unless the application uses a specific port or connection alias.
Named instances often use dynamic ports by default. The SQL Server Browser service may be required to help clients discover the active port.
Alternatively, a static TCP port can be assigned to the named instance. This is generally more predictable in production networks and easier to manage through firewalls.
Because this is a clean, standard, stand-alone installation, we will use the default instance.
Click Next.
𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗦𝗘𝗥𝗩𝗜𝗖𝗘 𝗔𝗖𝗖𝗢𝗨𝗡𝗧𝗦
The Server Configuration page contains the Service Accounts and Collation tabs.
The installation can work with the default virtual accounts, but because this server is joined to Active Directory and we are following an enterprise design, we will assign the dedicated low-privilege domain accounts created earlier.
For SQL Server Agent, click Browse.
Make sure the search location is set to the entire Active Directory domain.
Search for and select the SQL Server Agent service account.
Enter the account password.
Set the SQL Server Agent startup type to Automatic if the environment will use scheduled SQL Server Agent jobs, maintenance plans, alerts, or other Agent-based operations.
Next, assign the dedicated Database Engine service account to the SQL Server Database Engine service.
Click Browse, locate the correct account, and enter its password.
Keep the SQL Server Database Engine startup type as Automatic.
Do not use a personal administrator account or a Domain Administrator account as a SQL Server service account.
𝗘𝗡𝗔𝗕𝗟𝗜𝗡𝗚 𝗜𝗡𝗦𝗧𝗔𝗡𝗧 𝗙𝗜𝗟𝗘 𝗜𝗡𝗜𝗧𝗜𝗔𝗟𝗜𝗭𝗔𝗧𝗜𝗢𝗡
At the bottom of the Service Accounts page, there is an option to grant the Perform Volume Maintenance Tasks privilege to the SQL Server Database Engine service.
This privilege enables Instant File Initialization for SQL Server data files.
Instant File Initialization can significantly reduce the time required for data file creation, data file autogrowth, and database restore operations because SQL Server does not need to overwrite the entire data file with zeros before using the allocated space.
This feature applies to data files. Transaction log files still require zero initialization.
Enabling Instant File Initialization can provide an important operational and performance benefit, especially for large databases.
However, the setting should still be evaluated according to the organization’s security policy. Historically, the concern has been the possibility of remnants from previously deleted disk contents being present in newly allocated space.
In many environments, the performance and recovery benefits are considered acceptable, but the option should not be enabled without understanding the security implications.
For this installation, we will enable Grant Perform Volume Maintenance Tasks privilege to SQL Server Database Engine Service.
𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗖𝗢𝗟𝗟𝗔𝗧𝗜𝗢𝗡
Before moving to the next page, open the Collation tab.
Collation determines how SQL Server compares and sorts character data. It also defines characteristics such as case sensitivity and accent sensitivity.
The correct collation depends primarily on the application.
If SQL Server is being installed for a specific product, always review the application vendor’s documentation before choosing the collation.
An unsupported collation can cause installation failures, comparison problems, sorting differences, reporting errors, or compatibility issues later.
If the application does not require a specific collation, use the organization’s standard SQL Server collation.
If there is no corporate standard, evaluate the language, region, case sensitivity, accent sensitivity, and compatibility requirements.
In this environment, we will change the collation from the Turkish default to SQL_Latin1_General_CP1_CI_AS, which is commonly used by many applications.
CI means case-insensitive, and AS means accent-sensitive.
Click Customize.
Open the SQL Collation, Used for Backward Compatibility section and select SQL_Latin1_General_CP1_CI_AS.
Although this collation is widely used, it is not automatically correct for every environment. Confirm the required value before installing the production database server.
Click Next.
𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗔𝗨𝗧𝗛𝗘𝗡𝗧𝗜𝗖𝗔𝗧𝗜𝗢𝗡
The Database Engine Configuration page contains several tabs.
The first tab is Server Configuration.
Here, we select the authentication method that will be used to connect to SQL Server.
Mixed Mode enables both Windows Authentication and SQL Server Authentication.
Windows Authentication uses Windows and Active Directory identities.
Where possible, Windows Authentication is usually the more secure and manageable option because user and group access can be controlled centrally through Active Directory.
For this installation, we will select Windows Authentication Mode.
Because SQL Server Authentication is not enabled, we do not need to configure or use the built-in sa account.
If an application specifically requires SQL Server Authentication, Mixed Mode can be enabled, but the sa account and all SQL logins must then be protected with strong passwords, limited permissions, monitoring, and appropriate security controls.
𝗔𝗦𝗦𝗜𝗚𝗡𝗜𝗡𝗚 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗦𝗬𝗦𝗔𝗗𝗠𝗜𝗡 𝗣𝗘𝗥𝗠𝗜𝗦𝗦𝗜𝗢𝗡𝗦
The lower section asks which Windows accounts or groups should receive SQL Server sysadmin permissions.
Avoid assigning broad and highly privileged groups such as Domain Admins, Enterprise Admins, or all local Administrators unless there is a documented requirement.
The better approach is to create a dedicated Active Directory security group specifically for SQL Server administration.
Relevant database administrators can then be added to or removed from that group without changing the SQL Server installation.
For this purpose, we created an Active Directory group named SQL-DBA-Admins and added the appropriate administrator accounts.
Click Add and select the SQL-DBA-Admins group.
Members of this group will receive sysadmin access to this SQL Server instance.
Carefully control membership of this group because sysadmin is the highest SQL Server privilege level.
𝗖𝗥𝗘𝗔𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗬 𝗦𝗧𝗥𝗨𝗖𝗧𝗨𝗥𝗘
The next step is to configure the Data Directories tab.
SQL Server can operate with the default directories, but we want a cleaner and more manageable structure.
Before entering the paths, create the required folders on the prepared disks.
Open This PC.
Create a folder named SQL in the root of the D, L, B, and T drives.
Under D:\SQL, create a Data folder.
Under L:\SQL, create a Log folder.
Under B:\SQL, create a Backup folder.
Under T:\SQL, create a TempDB folder.
Make sure the SQL Server service account has the required permissions on these locations. SQL Server Setup normally applies the required permissions when the directories are selected during installation.
𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗗𝗔𝗧𝗔, 𝗟𝗢𝗚, 𝗔𝗡𝗗 𝗕𝗔𝗖𝗞𝗨𝗣 𝗗𝗜𝗥𝗘𝗖𝗧𝗢𝗥𝗜𝗘𝗦
Return to the SQL Server Setup window.
Set the data root directory to the planned SQL directory.
Set the user database data directory to D:\SQL\Data.
Set the user database log directory to L:\SQL\Log.
Set the backup directory to B:\SQL\Backup.
With this design, the Windows operating system and SQL Server application files remain on the C drive.
User database data files are placed on the D drive.
Transaction log files are placed on the L drive.
Backup files are placed on the B drive.
Data files and transaction log files have different I/O patterns.
Database data files generally perform a mixture of random reads and writes.
Transaction log files are primarily sequential and write-intensive.
Separating them can improve manageability and may reduce storage contention when the underlying storage is genuinely separated and designed correctly.
As mentioned earlier, storing backups on the B drive is useful for this lab. In production, backups should also be copied to a separate and protected storage platform.
The underlying physical disk, RAID, SAN, storage pool, redundancy, latency, and backup architecture are at least as important as the directory paths.
𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗘𝗠𝗣𝗗𝗕 𝗙𝗢𝗥 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝟮𝟬𝟮𝟱
Open the TempDB tab.
TempDB is a SQL Server system database used for temporary tables, internal worktables, sorting, hashing, row versioning, index operations, and many other temporary workloads.
Leaving TempDB at a very small default size and forcing it to grow repeatedly is not a good production design.
We should provide a reasonable initial size and predictable autogrowth settings.
This lab server has eight logical processors.
A common starting recommendation for systems with eight or fewer logical processors is to configure the same number of TempDB data files as logical processors.
For that reason, we will create eight TempDB data files.
The number of files is not the only important factor.
All TempDB data files should have the same initial size and the same autogrowth increment. Equal sizing allows SQL Server to distribute allocations more evenly across the files.
For each TempDB data file, set the initial size to 512 MB.
With eight files, the total initial TempDB data size will be 4 GB.
This 4 GB value is not a universal Microsoft best practice for every workload. It is a controlled starting point for this lab, where we do not yet know the actual TempDB usage.
In a production environment, the correct TempDB size should be determined by monitoring application behavior, temporary object usage, query workload, index maintenance, version store activity, and peak operations.
𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗘𝗠𝗣𝗗𝗕 𝗔𝗨𝗧𝗢𝗚𝗥𝗢𝗪𝗧𝗛
For TempDB autogrowth, use a fixed megabyte value rather than a percentage.
Set the autogrowth increment of each TempDB data file to 256 MB.
Using the same fixed increment helps keep all files evenly sized and makes growth behavior more predictable.
Autogrowth is not a substitute for capacity planning.
It is a safety mechanism for unexpected growth.
The correct approach is to size TempDB as accurately as possible based on monitoring and avoid depending on frequent autogrowth events.
For the TempDB log file, set the initial size to 1,024 MB and the autogrowth increment to 256 MB.
We do not want the TempDB log file to remain too small because log growth operations can cause pauses or delays on busy systems.
Set both the TempDB data and log directories to T:\SQL\TempDB.
Remove the old default TempDB path entries after adding the new path.
The TempDB files will now be separated from the main user database data and log directories.
Click Next or continue to the next configuration tab.
𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗠𝗔𝗫𝗗𝗢𝗣
The next setting is MAXDOP, which stands for Maximum Degree of Parallelism.
MAXDOP determines the maximum number of logical processors that a single parallel query can use.
The goal is not simply to allow every query to use as many processors as possible. The goal is to keep query parallelism and overall CPU usage controlled according to the workload.
Microsoft’s general guidance uses the processor and NUMA layout as a starting point, but the value must still be validated through monitoring.
On systems with eight or fewer logical processors, MAXDOP can often be set to a value equal to or lower than the available logical processor count.
In larger systems, a value such as 8 is frequently used as an initial starting point, but it is not automatically correct for every server.
This lab has eight logical processors.
We could begin with MAXDOP 8, but we want a more conservative starting configuration, so we will set MAXDOP to 4.
This is not a definitive value for every environment.
After the server begins handling the real application workload, CPU usage, wait statistics, query duration, parallelism, and application performance should be monitored. MAXDOP can then be adjusted if necessary.
𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗠𝗜𝗡𝗜𝗠𝗨𝗠 𝗔𝗡𝗗 𝗠𝗔𝗫𝗜𝗠𝗨𝗠 𝗦𝗘𝗥𝗩𝗘𝗥 𝗠𝗘𝗠𝗢𝗥𝗬
The next tab controls SQL Server memory.
If max server memory is left at its default value, SQL Server can use a very large portion of the server’s available RAM as the workload requires.
This does not mean that SQL Server immediately consumes all memory when it starts.
However, if SQL Server is allowed to grow without an upper limit, the Windows operating system, backup agents, monitoring tools, antivirus software, drivers, and other services may not have enough memory.
This can create operating system paging and performance problems.
For that reason, we will use the recommended memory configuration option to define an upper limit for the SQL Server Database Engine.
The max server memory value limits the amount of memory that the SQL Server buffer pool and related components can use under this configuration.
Enough memory must remain available for Windows and all other processes running on the server.
We will leave minimum server memory at 0 MB.
Minimum server memory does not mean that SQL Server immediately reserves that amount when the service starts. It influences how much memory SQL Server tries to retain after it has acquired memory under workload.
Because this lab contains a single SQL Server instance and we do not yet know the real workload, we do not need to increase minimum server memory.
The setup memory recommendation is only a starting point.
In production, memory usage, available system memory, page life expectancy, memory grants, workload characteristics, and operating system pressure should be monitored. The minimum and maximum memory values can then be adjusted.
Select the option to accept the recommended memory configuration for the SQL Server Database Engine.
𝗥𝗘𝗩𝗜𝗘𝗪𝗜𝗡𝗚 𝗧𝗛𝗘 𝗙𝗜𝗟𝗘𝗦𝗧𝗥𝗘𝗔𝗠 𝗢𝗣𝗧𝗜𝗢𝗡
The final technical tab is FILESTREAM.
FILESTREAM allows SQL Server to store large binary objects, such as documents, images, and other BLOB data, through integration with the Windows file system while maintaining transactional consistency with the database.
FILESTREAM is useful for specific application architectures.
It may be enabled when the application supports it, when large BLOB data must be managed through SQL Server, or when efficient streaming access is required.
It should not be enabled automatically if the application does not need it.
Because this environment does not require FILESTREAM, we will leave it disabled and avoid unnecessary configuration and management overhead.
Click Next.
𝗜𝗡𝗦𝗧𝗔𝗟𝗟𝗜𝗡𝗚 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝟮𝟬𝟮𝟱
We have completed the technical configuration pages.
Review the installation summary and confirm that the selected edition, features, instance, service accounts, collation, authentication, administrators, directories, TempDB, MAXDOP, and memory settings are correct.
Click Install.
SQL Server Setup begins installing the selected Database Engine components.
The process may take several minutes.
When the installation finishes, confirm that the selected features show a successful status.
𝗩𝗘𝗥𝗜𝗙𝗬𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗦𝗘𝗧𝗨𝗣 𝗦𝗨𝗠𝗠𝗔𝗥𝗬 𝗟𝗢𝗚
To verify the overall installation status, open the SQL Server Setup summary log.
Under Overall Summary, the final result is Passed.
The exit code is 0.
This indicates that the SQL Server installation completed successfully.
If Setup reports a failure or warning, review the detailed summary and component logs before using the server.
The SQL Server Database Engine installation is now complete.
We can continue with the post-installation checks.
𝗥𝗨𝗡𝗡𝗜𝗡𝗚 𝗔 𝗣𝗢𝗪𝗘𝗥𝗦𝗛𝗘𝗟𝗟 𝗣𝗢𝗦𝗧-𝗜𝗡𝗦𝗧𝗔𝗟𝗟𝗔𝗧𝗜𝗢𝗡 𝗖𝗛𝗘𝗖𝗞
We will run a PowerShell script to perform several essential checks for the default SQL Server instance.
Create a folder named C:\Temp.
Create a text file inside that folder and paste the PowerShell script into it.
Save the file and change the extension from .txt to .ps1.
Before running it, let’s explain what the script does.
The script checks the SQL Server Database Engine and SQL Server Agent services.
It identifies which accounts the services are running under.
It checks whether the TCP/IP protocol is enabled.
It verifies whether the default instance is configured to use the static TCP 1433 port.
It also checks whether the required inbound Windows Firewall rule exists.
If TCP/IP is disabled, the script enables it.
If the TCP 1433 configuration is missing, the script configures the required static port.
If the local Windows Firewall rule does not exist, the script creates an inbound rule for TCP 1433.
The script should be reviewed and tested before it is used in another environment. Firewall rules should be restricted according to the authorized source networks whenever possible.
𝗘𝗫𝗘𝗖𝗨𝗧𝗜𝗡𝗚 𝗧𝗛𝗘 𝗣𝗢𝗪𝗘𝗥𝗦𝗛𝗘𝗟𝗟 𝗦𝗖𝗥𝗜𝗣𝗧
Open PowerShell as an administrator.
Change the directory to C:\Temp.
Run the PowerShell script.
The output shows the SQL Server services and confirms that they are running under the service accounts we configured.
The TCP/IP protocol and static TCP port checks complete successfully.
The local Windows Firewall inbound rule is also present and allows the required connection.
The script has completed successfully.
The script can also be downloaded from the Techaptic website.
𝗜𝗡𝗦𝗧𝗔𝗟𝗟𝗜𝗡𝗚 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗠𝗔𝗡𝗔𝗚𝗘𝗠𝗘𝗡𝗧 𝗦𝗧𝗨𝗗𝗜𝗢
We can now install SQL Server Management Studio, or SSMS.
The SQL Server Database Engine is the core database service.
SSMS is a separate management application that connects to SQL Server and provides a graphical interface for administration, configuration, security, databases, queries, backups, jobs, and monitoring.
SSMS is not automatically installed with the SQL Server Database Engine.
It must be downloaded and installed separately.
Open Microsoft’s official SQL Server Management Studio download page.
The link will be included in the video description.
Download the current SQL Server Management Studio installer. In this demonstration, we will use SQL Server Management Studio 22.
Open the downloaded installer.
The installation interface does not require any special package selection for this basic setup.
Click Install.
Wait for the SSMS installation to complete.
The installer may recommend restarting Windows Server.
A restart can be performed after completing the current validation, but production changes should follow the organization’s maintenance and change-control process.
𝗢𝗣𝗘𝗡𝗜𝗡𝗚 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝗠𝗔𝗡𝗔𝗚𝗘𝗠𝗘𝗡𝗧 𝗦𝗧𝗨𝗗𝗜𝗢
Open SQL Server Management Studio.
We now need to connect to the new SQL Server instance.
The Windows account used for this connection must be a member of the SQL-DBA-Admins Active Directory group that we granted sysadmin access during Setup.
The administrator account used in this demonstration is a member of that group.
Because we installed a default instance, we can connect by using the Windows Server hostname or FQDN.
Select Database Engine as the server type.
Enter the SQL Server hostname in the Server Name field.
Select Windows Authentication.
The connection will use the currently signed-in Windows account.
𝗖𝗢𝗡𝗙𝗜𝗚𝗨𝗥𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗦𝗠𝗦 𝗘𝗡𝗖𝗥𝗬𝗣𝗧𝗜𝗢𝗡 𝗢𝗣𝗧𝗜𝗢𝗡𝗦
For this lab connection, set encryption to Optional and select Trust Server Certificate.
This allows the connection to continue even though we have not yet installed a trusted SQL Server TLS certificate.
For a production environment, a certificate issued by a trusted certificate authority should be configured for SQL Server, and encryption requirements should be defined according to the organization’s security policy.
Click Connect.
We are now connected to the SQL Server Database Engine.
𝗩𝗘𝗥𝗜𝗙𝗬𝗜𝗡𝗚 𝗧𝗛𝗘 𝗦𝗤𝗟 𝗦𝗘𝗥𝗩𝗘𝗥 𝟮𝟬𝟮𝟱 𝗩𝗘𝗥𝗦𝗜𝗢𝗡
Let’s run a quick query to verify the SQL Server version.
Open a new query window.
Enter:
SELECT @@VERSION;
Execute the query.
The results pane displays the installed Microsoft SQL Server 2025 version information.
This confirms that we successfully connected to the new SQL Server instance and can execute a basic query.
𝗖𝗢𝗡𝗖𝗟𝗨𝗦𝗜𝗢𝗡
We have now completed the Microsoft SQL Server 2025 installation and initial best-practice configuration.
We reviewed the hardware and software prerequisites, SQL Server editions, licensing considerations, network ports, Active Directory membership, and service account design.
We created separate storage locations for the operating system, database data files, transaction log files, TempDB, and backups.
We formatted the SQL Server volumes with NTFS and a 64 KB allocation unit size.
During SQL Server Setup, we selected Database Engine Services, configured the default instance, assigned dedicated low-privilege domain service accounts, enabled Instant File Initialization, selected the required collation, used Windows Authentication, and granted sysadmin permissions through a dedicated Active Directory security group.
We configured separate data, log, backup, and TempDB directories.
We created eight equally sized TempDB data files, defined fixed autogrowth values, configured the TempDB log, selected an initial MAXDOP value, and applied a recommended SQL Server memory limit.
After the installation, we verified the Setup summary log, checked the SQL Server services, enabled TCP/IP, configured TCP 1433, validated the Windows Firewall rule, installed SQL Server Management Studio, connected with Windows Authentication, and confirmed the SQL Server 2025 version by running SELECT @@VERSION.
These settings provide a clean and secure starting point, but they are not a replacement for workload-specific monitoring and capacity planning.
In a production environment, database size, query performance, CPU usage, memory pressure, TempDB activity, storage latency, backup and restore testing, security, cumulative updates, high availability, and disaster recovery must continue to be monitored and maintained.
I hope you found this video helpful.
Thank you for watching.
I will see you in the next video.
Take care. Goodbye.