Windows Server for beginners. Part 1: Windows Server from scratch
All parts of the series “Windows Server for beginners”This is the first article of the "Windows Server for beginners" series. The series is for those who want to understand how Windows Server and Active Directory work on the inside: what happens between pressing Ctrl+Alt+Del and the desktop appearing, how domain controllers come to an agreement with each other, what lives in the directory and how to read it. By the end of the series we will be walking the directory over LDAP, taking Kerberos tickets apart field by field and moving roles between controllers.
The series follows two principles.
First: for every component, not only why it is needed, but how it works. Which objects appear in the directory, which packets go over the wire, what breaks and why. That is why almost every part will have command output, event logs and a walkthrough of what they say.
Second: we do everything from PowerShell, not with the mouse. Windows Server does have snap-ins and wizards, and now and then we will say "this is what it looks like in the UI", but the main path is the command. There are three reasons. A command can be repeated, put into a script and run on twenty servers; a command can be shown in an article more precisely than any screenshot; and on Server Core, which has no graphical shell, there simply is no other way.
Here is the plan of the series. First the foundation: installing a server, working with disks and the network, how Active Directory is built. Then the domain: the first domain controller, LDAP and Kerberos from the inside, DNS, DHCP for IPv4 and IPv6, a second controller and replication, a read-only controller, time. Then management: the ActiveDirectory module, PowerShell Remoting over WinRM, tools on the workstation, SSH with PowerShell as the shell. Next, operations: FSMO roles, troubleshooting, replacing controllers, backups. After that, forests and trusts between them, Group Policy, a certificate authority, NPS with RADIUS for Wi-Fi and VPN, Linux machines in the domain and synchronization with Entra ID. The articles come out one at a time, and the end of each says what the next one will cover.
Protocols that have already been covered in the "Networking for beginners" series will not be taken apart again: when we get to DNS or DHCP, I will link to those articles and recap the essentials in a couple of sentences.
What you will need
One computer with virtualization is enough to follow the examples. Hyper-V in Windows 10/11 Pro, VMware Workstation, VirtualBox or KVM on Linux will all do. The lab network of the series looks like this:
192.168.1.0/24 (site Office)
┌──────────────┬──────────────┬──────────────┬──────────────┐
│ │ │ │ │
dc1.corp. dc2.corp. srv1.corp. ws1.corp. router
example.com example.com example.com example.com 192.168.1.1
.10 .11 .20 .100
controller controller member Windows 11
DNS, DHCP DNS, DHCP server with RSAT
The domain will be called corp.example.com with the NetBIOS name CORP. Names and addresses in the series are neutral: example.com is reserved for documentation and leads nowhere, and everyone has 192.168.1.0/24 at home. Later a second site 192.168.2.0/24, the IPv6 prefix 2001:db8:1::/64 and a partner forest partner.example.net will appear for the discussion of trusts.
The Windows Server image comes from Microsoft's Evaluation Center: the ISO runs for 180 days without a key, which is enough for the whole series. For a domain controller VM, two virtual CPUs, 2 GB of memory and a 40 GB disk are enough.
Editions, channels and versions
Before installing, you need to choose three things: the edition, the installation option and the version.
Editions. Windows Server has two main ones:
| Standard | Datacenter | |
|---|---|---|
| Hyper-V virtual machines | two per license | unlimited |
| Storage Spaces Direct, unlimited Storage Replica, SDN, Shielded VM | no | yes |
| Everything else: AD, DNS, DHCP, files, IIS, RDS, clusters | the same | the same |
The only difference is virtualization and storage. A domain controller, file server or web server needs nothing from Datacenter, and Datacenter costs several times more. There is also Essentials for organizations of up to 25 users with special restrictions, and Datacenter: Azure Edition, which exists only in Azure and Azure Stack HCI and gets some features earlier than the rest.
Windows Server is licensed per processor core: at least 16 cores per server and 8 per physical processor, plus client access licenses (CALs) for every user or device accessing the server. Licensing is of no further interest to us in this series: the evaluation version runs for 180 days and, if you want, turns into the full one with a single command and a key — more on that at the end of the article.
Installation option. In the installer each edition appears twice: plain "Standard" and "Standard (Desktop Experience)". The first is Server Core: no desktop, no File Explorer and no snap-ins; after you sign in, a command prompt window opens. The second is the familiar Windows with a graphical shell.
Server Core is the recommended option for everything that doesn't need graphics on the server itself: domain controllers, DNS, DHCP, file servers, Hyper-V, IIS. It takes several times less disk space and memory, has fewer updates and fewer reboots, and its attack surface is smaller too: no browser, no File Explorer, no half of the libraries where vulnerabilities get found. It is managed remotely — from PowerShell, snap-ins on a workstation, Windows Admin Center — and that is exactly how we are going to work. Desktop Experience is needed when the server runs an application with windows or when the server will be administered locally, from the console.
Important: the choice is made at installation and cannot be changed later. In Windows Server 2012 you could add or remove the shell with a command; since 2016, only by reinstalling.
Versions and channels. The main channel is LTSC (Long-Term Servicing Channel): a release every two or three years, five years of mainstream support and five of extended support:
| Version | Released | End of extended support |
|---|---|---|
| Windows Server 2016 | 2016 | January 2027 |
| Windows Server 2019 | 2018 | January 2029 |
| Windows Server 2022 | 2021 | October 2031 |
| Windows Server 2025 | 2024 | October 2034 |
There is also the Annual Channel for containers: a new version every year, 18 months of support, Server Core only and by subscription only. General-purpose servers don't need it.
The series uses Windows Server 2025, but almost everything written here works from 2016 onwards: Active Directory has changed little over these years, and the cmdlets even less. Where there are differences, I will point them out.
Installation
Boot from the ISO. The installer asks for the language and keyboard layout, the image (this is where you choose the edition and option), has you accept the license, offers an installation type — you want Custom, not Upgrade — and asks for a disk. On an empty disk it creates the partitions by itself: a 100 MB EFI partition, a 16 MB MSR service partition, the system partition taking everything else, and a recovery partition. There is no need to touch this, and if you do need to (for example, you want a system partition of a specific size), the next part covers diskpart, which does the same from the console.
A couple of words about the platform. Windows Server 2025 requires UEFI and supports Secure Boot; TPM 2.0 isn't mandatory, but it is needed for BitLocker and some security features. In Hyper-V this means a generation 2 virtual machine with Secure Boot enabled (the Microsoft Windows template) and, optionally, a virtual TPM. VirtualBox and VMware can do UEFI too, but it has to be enabled in the machine settings before installation.
After copying files and a couple of reboots, the installer asks you to set the password of the built-in Administrator. The password must be complex: the default policy is at least seven characters and three categories out of four (lowercase, uppercase, digits, special characters). This password will become the Directory Services Restore Mode password once the server becomes a controller, so it is better to pick one you will remember later.
Sign in. On Server Core a black cmd.exe window appears, and on top of it, starting with Windows Server 2022, sconfig launches automatically — a text menu with numbered items: domain, name, updates, remote management, network, date and time. Everything described below can be done through it, but we will close it (item 15) and do the same with commands: first, to understand what is going on, and second, because commands come in handy in scripts and the menu doesn't. On Desktop Experience, Server Manager opens instead of the console; close it too and open PowerShell by right-clicking the Start button or with Win+X.
The first minutes in PowerShell
Windows Server ships with Windows PowerShell 5.1 — the one started by the powershell command. It hasn't gone anywhere and won't: all the role management modules run on it. Alongside it there is PowerShell 7 (pwsh), cross-platform and actively developed; it is installed separately, and in this series we will use the built-in 5.1: it is guaranteed to be on every server, and the syntax differences don't matter for our tasks. On Server Core, which has no winget, PowerShell 7 is installed like this:
Invoke-WebRequest -Uri https://aka.ms/install-powershell.ps1 -OutFile install-powershell.ps1
.\install-powershell.ps1 -UseMSI -Quiet
Three things you need to know about PowerShell before moving on.
Commands return objects, not text. When Get-Service prints a table, those aren't strings: they are ServiceController objects with properties and methods that the console formatted into a table at the last moment. That is why you can keep working with the result:
PS C:\> Get-Service | Where-Object Status -eq 'Running' | Sort-Object DisplayName | Select-Object -First 3
Status Name DisplayName
------ ---- -----------
Running BFE Base Filtering Engine
Running BrokerInfrastru... Background Tasks Infrastructure Service
Running CDPSvc Connected Devices Platform Service
Get-Member shows what is inside an object:
PS C:\> Get-Service W32Time | Get-Member -MemberType Property
TypeName: System.ServiceProcess.ServiceController
Name MemberType Definition
---- ---------- ----------
CanPauseAndContinue Property bool CanPauseAndContinue {get;}
CanShutdown Property bool CanShutdown {get;}
CanStop Property bool CanStop {get;}
DependentServices Property System.ServiceProcess.ServiceController[] DependentServices {get;}
DisplayName Property string DisplayName {get;set;}
...
StartType Property System.ServiceProcess.ServiceStartMode StartType {get;}
Status Property System.ServiceProcess.ServiceControllerStatus Status {get;}
The default table shows three properties, while the object has about fifteen. The habit of checking Get-Member and Format-List * saves hours: the property you need is almost always already there, it just isn't shown.
Commands can be found by name. All cmdlets are named "Verb-Noun", the set of verbs is limited (Get, Set, New, Remove, Add, Install, Enable, Test, Start, Stop, …), and that lets you guess:
PS C:\> Get-Command -Noun NetIPAddress
CommandType Name Version Source
----------- ---- ------- ------
Function Get-NetIPAddress 1.0.0.0 NetTCPIP
Function New-NetIPAddress 1.0.0.0 NetTCPIP
Function Remove-NetIPAddress 1.0.0.0 NetTCPIP
Function Set-NetIPAddress 1.0.0.0 NetTCPIP
PS C:\> Get-Command -Module DnsServer | Measure-Object | Select-Object Count
Count
-----
132
Help: Get-Help New-NetIPAddress -Full or -Online (opens the documentation in a browser on a workstation). A fresh server has no local help; Update-Help downloads it.
Dangerous commands can rehearse. The -WhatIf parameter shows what a command would do without doing it; -Confirm asks before every action. Twenty parts from now, when we remove a controller from the directory, this will come in handy.
Server name
The installer gives the machine a random name like WIN-A1B2C3D4E5F. Let's change it:
PS C:\> Rename-Computer -NewName dc1 -Restart
The name can be up to 15 characters (a NetBIOS limitation that hasn't gone away): Latin letters, digits and hyphens. A reboot is mandatory: the computer name is read at startup.
The name also needs a DNS suffix so that the server knows its full name dc1.corp.example.com. A domain member gets the suffix automatically when it joins the domain, and the first controller gets it when the forest is created, so there is no need to set it here. If for some reason you need to set it by hand on a standalone server, it's a registry value:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' -Name 'NV Domain' -Value 'corp.example.com'
Network
After installation the adapter has an address from DHCP, if there is DHCP on the network. A server, and especially a future domain controller and DNS server, needs a static address: every client on the network will look for it by that address.
Let's see what we have:
PS C:\> Get-NetAdapter
Name InterfaceDescription ifIndex Status MacAddress LinkSpeed
---- -------------------- ------- ------ ---------- ---------
Ethernet Microsoft Hyper-V Network Adapter 4 Up 00-15-5D-01-02-03 10 Gbps
PS C:\> Get-NetIPConfiguration
InterfaceAlias : Ethernet
InterfaceIndex : 4
InterfaceDescription : Microsoft Hyper-V Network Adapter
NetProfile.Name : Network
IPv4Address : 192.168.1.137
IPv6Address : 2001:db8:1::a1b2:c3d4:e5f6:1234
IPv4DefaultGateway : 192.168.1.1
IPv6DefaultGateway : fe80::1
DNSServer : 192.168.1.1
The adapter is called Ethernet, and that is the name we will use in commands. If there are several adapters, it's worth renaming them by purpose: Rename-NetAdapter -Name 'Ethernet 2' -NewName 'Storage'.
Now switch IPv4 to a static configuration. The order matters: first disable DHCP on the interface, otherwise the DHCP client will keep overwriting the settings; then remove the address and route obtained from DHCP; then set your own:
Set-NetIPInterface -InterfaceAlias Ethernet -AddressFamily IPv4 -Dhcp Disabled
Remove-NetIPAddress -InterfaceAlias Ethernet -AddressFamily IPv4 -Confirm:$false
Remove-NetRoute -InterfaceAlias Ethernet -AddressFamily IPv4 -DestinationPrefix 0.0.0.0/0 -Confirm:$false
New-NetIPAddress -InterfaceAlias Ethernet -IPAddress 192.168.1.10 -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 192.168.1.1
Two traps. New-NetIPAddress -DefaultGateway refuses to work if the interface already has a default route, hence the Remove-NetRoute line above it. And for DNS we point to the router for now: when the server becomes a controller, it will also become a DNS server, and we will change this in the part about the first controller — there are rules of their own about where a controller should look for DNS.
One rule about IPv6: don't disable it. Some Windows services (Exchange, failover clusters, parts of RPC) expect IPv6 to be there, at least as a link-local fe80::… address. If there's no IPv6 router on the network, the adapter will only get a link-local address and work over IPv4 without getting in anyone's way. If the network does have IPv6, the address and gateway arrive on their own via Router Advertisement, as in part 15 of the networking series; a static IPv6 address is set with the same New-NetIPAddress and a prefix length of 64.
Let's check:
PS C:\> Test-NetConnection -ComputerName www.vitaliy.org -Port 443
ComputerName : www.vitaliy.org
RemoteAddress : 203.0.113.65
RemotePort : 443
InterfaceAlias : Ethernet
SourceAddress : 192.168.1.10
TcpTestSucceeded : True
Test-NetConnection replaces ping, tracert (with -TraceRoute) and telnet host port in a single command, and it shows which address and interface the connection went out from, which with several adapters matters more than anything else.
The adapter settings we just made with four cmdlets are done in older guides with netsh interface ip set address. That isn't obsolete and is sometimes irreplaceable — more on it in the next part.
Time
The Windows time service is called W32Time. On a standalone server it syncs with time.windows.com once a week by default; on a domain member, with a domain controller; on a controller, with the holder of the PDC emulator role; and that one, with whatever it's told to. Why time in a domain is so important that it gets a part of its own: Kerberos rejects tickets if the client and server clocks differ by more than five minutes. For now the task is simpler — to have the right time on the server.
Time zone:
PS C:\> Get-TimeZone
Id : Pacific Standard Time
DisplayName : (UTC-08:00) Pacific Time (US & Canada)
...
PS C:\> Set-TimeZone -Id 'W. Europe Standard Time'
The list of IDs: Get-TimeZone -ListAvailable. Note that the time zone doesn't affect what the server considers "now": internally everything is stored in UTC, and the zone is only for display and logs.
The time source of a standalone server. W32Time has no cmdlets, only the w32tm utility:
PS C:\> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0312500s
Root Dispersion: 7.7812500s
ReferenceId: 0xC0A80101 (source IP: 192.168.1.1)
Last Successful Sync Time: 15.10.2026 10:42:17
Source: 192.168.1.1
Poll Interval: 10 (1024s)
Here the source came via DHCP (option 42). To set your own NTP servers:
w32tm /config /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8" /syncfromflags:manual /reliable:no /update
w32tm /resync
0x8 after the name is client mode: one request per poll interval rather than a symmetric exchange between peers. Stratum in the output is the distance from the reference clock: atomic clocks are 0, a server taking time from them is 1, we are 4.
If the server is virtual, there is one more source: the hypervisor. Hyper-V adjusts the guest clock to the host clock through an integration service, and VMware does the same through VMware Tools. For a member server this is convenient; for a domain controller it is a source of confusion that we will sort out when we get to time in the domain.
Updates
A freshly installed server is months behind on updates. On Server Core starting with Windows Server 2022, updates can be installed from sconfig (item 6), but we promised commands. There is no built-in cmdlet for Windows Update; there is the PSWindowsUpdate module from the PowerShell Gallery, which has become the de facto standard:
Install-PackageProvider -Name NuGet -Force
Install-Module -Name PSWindowsUpdate -Force
Get-WindowsUpdate
The first command is needed once: PowerShell 5.1 can't work with the gallery without the NuGet provider. If Install-Module complains about TLS (this happens on Windows Server 2016), run [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 before it.
PS C:\> Get-WindowsUpdate
ComputerName Status KB Size Title
------------ ------ -- ---- -----
DC1 -D----- KB5062553 912MB 2026-10 Cumulative Update for Microsoft server operating system version 24H2 for x64-based Systems
DC1 -D----- KB5061101 58MB 2026-10 Servicing Stack Update for Microsoft server operating system version 24H2 for x64-based Systems
PS C:\> Install-WindowsUpdate -AcceptAll -AutoReboot
Since 2016, Windows Server updates are cumulative: each monthly one contains all the previous ones, so "install everything" means one big update and one servicing stack, and two reboots at worst. Get-HotFix shows what is already installed:
PS C:\> Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 3
Source Description HotFixID InstalledBy InstalledOn
------ ----------- -------- ----------- -----------
DC1 Security Update KB5062553 NT AUTHORITY\SYSTEM 15.10.2026 0:00:00
DC1 Update KB5061101 NT AUTHORITY\SYSTEM 15.10.2026 0:00:00
DC1 Update KB5058499 02.09.2026 0:00:00
Automatic updates on a server are a matter of policy. By default the server downloads and installs them itself and reboots outside "active hours", which for a domain controller at three in the morning is usually acceptable, and for a database server is not. The behavior is set by the Windows Update group policy, and we will come back to it in the part about GPOs; on a single server the same is done through sconfig (item 5) or registry values under HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU.
Roles and features
Everything Windows Server can do is split into roles (Active Directory Domain Services, DNS Server, DHCP Server, Web Server, Hyper-V, …) and features (.NET Framework, Failover Clustering, Telnet Client, management tools). After installation only the minimum is present, and that's right: every role means services, ports and updates.
PS C:\> Get-WindowsFeature | Where-Object InstallState -eq Installed
Display Name Name Install State
------------ ---- -------------
[X] File and Storage Services FileAndStorage-Services Installed
[X] Storage Services Storage-Services Installed
[X] .NET Framework 4.8 Features NET-Framework-45-Fea... Installed
[X] .NET Framework 4.8 NET-Framework-45-Core Installed
[X] WCF Services NET-WCF-Services45 Installed
[X] TCP Port Sharing NET-WCF-TCP-PortSharing45 Installed
[X] Windows Defender Antivirus Windows-Defender Installed
[X] Windows PowerShell PowerShellRoot Installed
[X] Windows PowerShell 5.1 PowerShell Installed
[X] WoW64 Support WoW64-Support Installed
A role is installed like this (don't run it yet, that's the topic of the next parts):
Install-WindowsFeature -Name AD-Domain-Services, DNS -IncludeManagementTools
-IncludeManagementTools adds the PowerShell modules and snap-ins for the role. On Server Core the snap-ins won't be installed (they need graphics), but the modules will. A role is removed with Uninstall-WindowsFeature, and some features (Desktop Experience, for example) can't be removed, as mentioned earlier.
A separate category is Features on Demand: components that aren't in the image and are downloaded from Windows Update or taken from a separate ISO. This includes the App Compatibility FOD for Server Core — a set of libraries and tools from Desktop Experience (Event Viewer, Performance Monitor, Disk Management, some snap-ins) that can be added to Core without installing the whole shell:
Add-WindowsCapability -Online -Name ServerCore.AppCompatibility~~~~0.0.1.0
Handy when you need to open eventvwr or diskmgmt locally on Core, but in this series we'll try to do without it.
Remote access
The last thing done at the server console: enable whatever will be used to connect to it from now on.
PowerShell Remoting over WinRM is enabled on Windows Server from the moment of installation: the WinRM service listens on TCP 5985, and the firewall rule for it is open to the local subnet. While the server isn't in a domain, you can connect to it from a workstation only with a password and with caveats (TrustedHosts, covered in the part about WinRM); as soon as there's a domain, the connection will work over Kerberos without any caveats. To check that the service is listening:
PS C:\> Test-WSMan
wsmid : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor : Microsoft Corporation
ProductVersion : OS: 0.0.0 SP: 0.0 Stack: 3.0
Remote Desktop is disabled by default. It works on Server Core too: in an RDP session you'll see the same console, just over the network. Enable it:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0
Enable-NetFirewallRule -DisplayGroup 'Remote Desktop'
The first line is the very registry value behind the checkbox in System Properties; the second opens TCP 3389 in the firewall. By default RDP requires Network Level Authentication (the client authenticates before the session is created), and that's right — don't turn it off.
The Windows firewall is on, with three profiles — Domain, Private, Public — and rules tied to a profile. Right now the server isn't in a domain, so the network profile is Private or Public depending on what the network reported about itself; after joining the domain, the interface that sees a controller will switch to the Domain profile, and some rules (including those for management) will open by themselves. To see what is open:
PS C:\> Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction
Name Enabled DefaultInboundAction
---- ------- --------------------
Domain True Block
Private True Block
Public True Block
PS C:\> Get-NetFirewallRule -Enabled True -Direction Inbound | Where-Object DisplayGroup -like '*Remote*' | Select-Object DisplayName, Profile
A hands-on look
What a freshly installed server knows about itself:
PS C:\> Get-ComputerInfo | Select-Object CsName, OsName, OsVersion, OsBuildNumber, WindowsInstallationType, CsDomainRole, OsUptime
CsName : DC1
OsName : Microsoft Windows Server 2025 Standard Evaluation
OsVersion : 10.0.26100
OsBuildNumber : 26100
WindowsInstallationType : Server Core
CsDomainRole : StandaloneServer
OsUptime : 00:12:41.0831245
WindowsInstallationType is Server Core or Server; CsDomainRole is StandaloneServer now, becomes MemberServer after joining a domain, and BackupDomainController or PrimaryDomainController after promotion (that is what the API still calls controllers: with and without the PDC emulator role).
Logs. Core has no graphical Event Viewer, and that's no loss: Get-WinEvent can do more.
PS C:\> Get-WinEvent -LogName System -MaxEvents 5 | Format-Table TimeCreated, Id, ProviderName, LevelDisplayName -AutoSize
TimeCreated Id ProviderName LevelDisplayName
----------- -- ------------ ----------------
15.10.2026 10:51:03 7040 Service Control Manager Information
15.10.2026 10:50:12 1500 Microsoft-Windows-GroupPolicy Information
15.10.2026 10:49:58 129 Microsoft-Windows-Time-Service Warning
15.10.2026 10:49:57 37 Microsoft-Windows-Time-Service Information
15.10.2026 10:49:30 6013 EventLog Information
PS C:\> Get-WinEvent -FilterHashtable @{LogName='System'; Level=2,3; StartTime=(Get-Date).AddDays(-1)} |
Group-Object ProviderName | Sort-Object Count -Descending | Select-Object Count, Name
The second command is a template we will use throughout the series: errors and warnings for the past day, grouped by source. Five minutes reading this output after every reboot saves you from most surprises.
Activation. The evaluation version has 180 days; the remainder is shown by slmgr /dlv (it's a VBScript, with output in a message box on Desktop Experience and in the console on Core) or:
PS C:\> Get-CimInstance SoftwareLicensingProduct -Filter "PartialProductKey IS NOT NULL" | Select-Object Name, LicenseStatus, GracePeriodRemaining
Name LicenseStatus GracePeriodRemaining
---- ------------- --------------------
Windows(R), ServerStandardEval edition 1 258912
GracePeriodRemaining is in minutes: 258,912 minutes are exactly those 180 days. When the time comes, the evaluation edition turns into the full one without reinstalling: DISM /Online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula, two reboots, and the server is licensed. The key is activated with slmgr /ato.
We have a server with a name, an address, the correct time and updates, and it can be reached over the network. Before turning it into a domain controller, it's worth dealing with two things no installation can do without: disks and the network stack at a level below the cmdlets.
Next — Part 2: disks and network with diskpart and netsh. What these utilities do, what PowerShell replaces them with (the Storage, NetTCPIP and NetSecurity modules), and what only they can still do: from wiping a disk to port forwarding and capturing traffic without Wireshark.
Only registered users can leave a comment.
Sign in or register to leave a comment.