Welcome back. This lesson is where your DBA lab becomes real.
You will install the operating system inside your virtual machine and apply the baseline hardening steps
DBAs and sysadmins do before SQL Server ever touches the server.
A poorly configured OS causes endless pain: unstable performance, security gaps, broken patches,
unreliable time settings, and random restarts. Your goal is not “just install Windows.”
Your goal is to build a clean, stable foundation you can repeat.
Lesson description: You will install Windows Server (recommended) or Windows 11 Pro (acceptable for labs),
configure core settings (name, updates, time, power plan, networking),
enable administrative essentials (RDP, local admin practices),
apply basic security and stability hardening,
and prepare the system to install SQL Server and tools confidently.
You will also build a short OS install checklist you can reuse whenever you rebuild your lab.
Course guidance: If you can run Windows Server in your VM, do it.
If you cannot, use Windows 11 Pro and follow the same hardening principles.
Before booting the installer, confirm:
DBA note: If your VM is slow during install, fix resources now.
Do not “push through” a broken foundation.
When prompted for Windows Server edition:
Create a password you will not forget. Store it in your secure notes.
DBAs must practice good credential hygiene even in labs.
Rename the VM to something obvious, for example:
SQLLAB01 or SQLDBA-LAB
DBA reason: In real environments, servers must be identifiable in logs, scripts, and monitoring.
Ensure the VM time zone matches your environment. Incorrect time causes:
Apply all updates and reboot until there are no pending updates.
DBA rule: Patch the OS before installing SQL Server, not after.
Set power plan to:
High performance (or best available equivalent).
Why DBAs care: Aggressive power saving can throttle CPU and create misleading performance results.
Enable Remote Desktop so you can connect cleanly to the VM.
Also allow RDP through Windows Firewall when prompted.
DBA note: RDP is common in enterprise environments; you should be comfortable using it.
Instead of using the built-in Administrator account for everything,
create a dedicated local admin user for your lab, for example:
dba.admin
Reason: Helps you practice least privilege and clearer auditing habits.
In labs, keep built-in security enabled. Do not disable security features unless you have a strong reason.
Your goal is to learn how to run systems safely, not “turn off everything.”
Keep firewall enabled. Later, if you practice remote connections to SQL Server,
you will open only the required ports intentionally.
Create consistent folders you will reuse in the course. Example:
C:\DBA\C:\DBA\Installers\C:\DBA\Backups\C:\DBA\Scripts\C:\DBA\Logs\C:\DBA\Docs\DBA reason: Consistent structure prevents confusion and makes rebuilds faster.
If you are using VMware/VirtualBox/Hyper-V integration features, enable:
DBA warning: In real production, you must control these features carefully.
In a lab, they help productivity.
For now, keep networking simple:
Later, you will learn how to configure SQL Server connectivity more intentionally.
Copy this checklist into your notebook and reuse it whenever you rebuild:
C:\DBA\.Next, you will learn how DBAs plan SQL Server service accounts,
what “least privilege” means for services, and the correct approach for labs versus real production environments.
Not a member yet? Register now
Are you a member? Login now