ICTNWK422 Install and manage servers

Strip away the mystique and a server is just a computer that spends its life answering other computers. The machine that answers is the server; the machine that asks is the client; the arrangement is the client-server model that almost the whole internet runs on. Your laptop asking a website for a page is a client talking to a web server. Your work login being checked against the company directory is a client talking to a domain controller.

The word "server" does double duty, and it helps to keep the two meanings apart.

Server (hardware): a physical computer built to run continuously and serve many clients at once; typically more CPU, more memory, redundant power and network, and no interest in a nice screen.

Server (software or role): an operating system instance, or a service running on it, that provides something to clients; a "web server", a "file server", a "DNS server". One physical box can run several of these roles at once.

Physical, virtual, cloud

The unit was written for the first meaning: a physical box you rack, cable and install an operating system onto. That still exists, but it is now the minority case. Three shapes of server sit in front of you today.

A physical, or bare-metal, server runs its operating system directly on the hardware. A virtual server is an operating system running on virtualised hardware that a hypervisor presents to it; one physical host carries many virtual machines, each thinking it has its own computer. A cloud server is a virtual machine you rent from a provider by the hour and never physically touch. The skills in this unit, partitioning, installing the operating system, configuring roles, patching, backing up, are the same across all three; what changes is who owns the metal underneath and where the line of responsibility falls. That line is the single most important idea for the cyber security side of this unit, and it gets its own section further down.

Did you know? The reason a server rarely has a fancy graphics card or a nice monitor is that most are administered "headless", with no screen attached at all, over a remote connection from the admin's own desk. A server that no one ever sits in front of is doing its job.

A server earns its name by the role it plays. In a small organisation one machine might wear several hats; in a large one each role gets its own dedicated server, or its own cluster of them, for performance and for blast-radius control when something fails. These are the roles worth knowing.

Directory and identity: AD DS and the domain controller

Active Directory Domain Services (AD DS) is Microsoft's directory: the central database of users, computers, groups and the policies that apply to them. A server running AD DS is a domain controller. When you log in to a work computer, a domain controller is what checks your password and decides what you are allowed to touch. Identity is the heart of a Windows network, which is exactly why domain controllers are the prize attackers go for; compromise the directory and you own everything that trusts it.

Name and address services: DNS and DHCP

DNS (Domain Name System) is the phone book that turns a name people can remember, such as cybersecurityink.com, into the IP address machines actually use. DHCP (Dynamic Host Configuration Protocol) is the service that hands out IP addresses automatically as devices join the network, so no one has to configure each one by hand. Almost nothing works if these two are down, which is why they are usually made redundant.

File and print

A file server provides shared storage; on Windows this rides on the SMB protocol, on Linux on NFS or Samba. A print server manages shared printers and their queues. Unglamorous, universal, and still examinable: printer management is named directly in this unit's knowledge evidence.

Web, database, application and mail

A web server answers HTTP and HTTPS requests (Microsoft IIS, or the cross-platform nginx and Apache). A database server holds structured data and answers queries (Microsoft SQL Server, MySQL or MariaDB, PostgreSQL, Oracle). An application server runs the back-end logic of business software. A mail server sends and receives email (Microsoft Exchange, or Postfix on Linux). Most real services are several of these stacked together; a web application is typically a web server, an application server and a database server working as one.

graph LR
 C["Client<br/>(laptop, phone, another server)"] -->|request| S{"Which service?"}
 S -->|"who are you?"| AD["Domain controller<br/>AD DS"]
 S -->|"what is this name?"| DNS["DNS server"]
 S -->|"give me a page"| WEB["Web server"]
 S -->|"open this share"| FILE["File server"]
 WEB -->|"fetch the data"| DB["Database server"]

Every server needs a network operating system, and in practice the choice is Windows Server or one of the Linux distributions. They are not really competitors so much as specialists.

Windows Server is a single commercial product with a version line (2016, 2019, 2022, 2025). It is the natural home of Active Directory, IIS, Hyper-V and the Microsoft application stack, and it can be run with a full graphical desktop or from the command line. Organisations reach for it when identity and Microsoft applications are the centre of gravity.

Linux is not one product but a category, with many distributions (Ubuntu Server, Red Hat Enterprise Linux, Debian, SUSE, Rocky and Alma). It dominates web hosting, cloud instances and anything to do with containers, and it is effectively the default operating system of the public cloud. Where Windows leans on a graphical console, Linux servers are administered almost entirely from the command line and through configuration files.

A competent server administrator is now expected to be comfortable in both, because a typical organisation runs a mixture: Windows for the directory and staff applications, Linux for the websites and the cloud workloads.

The unit does not name a version, and the material it was built on is a couple of releases behind. Here is where Windows Server actually sits.

Windows Server 2025 reached general availability on 4 November 2024 (Microsoft Windows Server Blog, 4 November 2024). It is the version to learn against. The previous common versions, 2019 and 2022, are still everywhere in production, and Windows Server 2016 reaches end of support on 12 January 2027, after which security fixes come only through paid Extended Security Updates (Microsoft Windows Server Blog, 25 February 2026). Tracking end-of-support dates is part of the job, not a footnote; an unpatched, out-of-support server is one of the cleanest ways into an organisation.

Editions and install options

Windows Server ships in two main on-premises editions. Standard suits most physical or lightly virtualised roles. Datacenter adds broader virtualisation rights and features such as Storage Spaces Direct and software-defined networking, and is priced for organisations running many virtual machines on each host. There is also a Datacenter: Azure Edition that runs only on Azure or Azure Local and tends to receive new features first (general Microsoft licensing knowledge).

At install time you choose between two very different faces of the same operating system.

Desktop Experience: the full graphical interface. Easier to learn, larger on disk, more components to patch, larger attack surface. In Windows Server 2025 the desktop matches the Windows 11 look (Microsoft Learn, "What's new in Windows Server 2025").

Server Core: no desktop, managed remotely by PowerShell and tools such as Windows Admin Center. Smaller footprint, fewer patches, smaller attack surface. This is the recommended choice for hardened infrastructure roles.

The security point sits inside that choice: every component you install is something you then have to patch and defend, so the leaner Server Core is not just tidier, it is safer.

What is new in 2025, and why the security features matter

Windows Server 2025 is unusually security-led, and several of its changes are worth teaching because they show where the industry is heading (Microsoft Learn and the Windows Server Blog, 2024 to 2025).

Hotpatching applies operating-system security updates in memory without a reboot, cutting planned restarts from roughly twelve a year to about four. It is now generally available; on Azure or Azure Local it is included, but for on-premises servers it requires the machine to be connected to Azure Arc and a paid subscription of about US$1.50 per CPU core per month, with billing having started on 1 July 2025 (Microsoft Windows Server Blog, 24 April 2025). Fewer reboots means less temptation to defer a patch, which is the whole point.

SMB over QUIC is now available in all editions of 2025, not just the Azure edition as before. It carries SMB file-share traffic over an encrypted TLS 1.3 tunnel on UDP port 443, so staff can reach a file share securely over the internet without a VPN. SMB signing is now required by default on all connections, which blocks a class of relay and man-in-the-middle attacks, and the insecure guest fallback is off. Credential Guard is enabled by default on capable hardware, which protects stored credentials against pass-the-hash attacks. Active Directory gains delegated managed service accounts (dMSA) that remove the old chore of manually rotating service-account passwords.

Managing it

The modern console is Windows Admin Center, a free browser-based tool for managing one server or a fleet of them: roles, certificates, updates, virtual machines, even a PowerShell window, without the scatter of the old management consoles (capability description from Microsoft general documentation). Under it all sits PowerShell, which is how servers are really administered at scale; a role that took ten clicks in a wizard is one line of PowerShell you can run against a hundred machines at once.

If Windows Server is one product, Linux is a family, and knowing the main members matters when you inherit someone else's system.

Did you know? A large share of the world's servers run Linux even in organisations that think of themselves as Microsoft shops, because the websites, the cloud virtual machines and the network appliances underneath are quietly Linux. Learning it is not optional for a cyber security role; the machines you most need to secure are often the ones with no graphical desktop at all.

Ubuntu Server 24.04 LTS, released April 2024, carries five years of standard security maintenance to 31 May 2029, extendable further with an Ubuntu Pro subscription (Ubuntu release notes, page updated April 2026). Red Hat Enterprise Linux 10 reached general availability on 20 May 2025 and introduced an "image mode" that lets you build and deploy the operating system as a container image for consistency, along with early post-quantum cryptography and an AI command-line assistant called RHEL Lightspeed (Red Hat and Linuxiac, May 2025). Debian remains the stable, community-built base that Ubuntu itself is derived from (general knowledge).

The pieces you actually touch

Package managers install and update software. Debian and Ubuntu use apt (sudo apt update && sudo apt upgrade); Red Hat and Fedora use dnf (sudo dnf install, sudo dnf update). systemd is the service manager on every major distribution; you start, stop and enable services with systemctl, and you read logs with journalctl. The common server software is worth recognising by name: nginx and Apache for web, MySQL or MariaDB and PostgreSQL for databases, often assembled into the LAMP or LEMP stack pattern.

Securing SSH, the front door

Almost every Linux server is reached over SSH, so hardening SSH is the first real defensive task on one. The standard steps, all set in /etc/ssh/sshd_config: turn off direct root login (PermitRootLogin no); use key-based authentication and turn off password authentication entirely (PasswordAuthentication no), so there is no password to guess; limit which accounts may connect (AllowUsers); add fail2ban to lock out repeated failures; and keep the service behind the firewall rather than open to the whole internet. A server with password SSH exposed to the internet will be under automated attack within minutes of coming online.

Virtualisation is the reason one physical host can pretend to be a dozen servers. The software that performs the trick is a hypervisor, and there are two kinds.

Type 1 (bare-metal): the hypervisor runs directly on the hardware, with the virtual machines on top. This is what data centres use: VMware ESXi, Microsoft Hyper-V, KVM, Proxmox VE, Xen.

Type 2 (hosted): the hypervisor runs as an application inside an ordinary desktop operating system. This is for development and testing on your own laptop: VMware Workstation, Oracle VirtualBox.

Hyper-V is Microsoft's Type 1 hypervisor, available as a role inside Windows Server. KVM is the hypervisor built into the Linux kernel itself, and it quietly powers most Linux-based and cloud virtualisation, including Proxmox VE, an open-source platform that has become a common landing place for organisations leaving VMware.

That exodus is worth explaining, because it is reshaping the market. Broadcom completed its acquisition of VMware in November 2023, then ended perpetual licences and moved VMware to subscription-only bundles; the free version of ESXi was discontinued in early 2024 and a free offering was quietly reintroduced around April 2025 (corroborated across BleepingComputer, The Register and vInfrastructure through 2024 and 2025). The lesson for a server administrator is that the platform your virtual machines sit on is a commercial dependency, and licensing changes can force a migration as surely as any technical fault.

Two virtualisation features carry their weight in day-to-day work. A snapshot captures a virtual machine's state at a point in time so you can roll back quickly if a change goes wrong; useful, but not a substitute for a backup, because it lives on the same host. Live migration (VMware calls it vMotion) moves a running virtual machine from one host to another with no downtime, which is how you patch or service a physical host without anyone noticing.

The biggest shift since this unit was written is that a great many servers no longer live in the building. Infrastructure as a Service (IaaS) is renting virtual machines and the network around them from a provider: Azure Virtual Machines, Amazon EC2, Google Compute Engine. You choose the operating system, the size, the disks and the networking, and you pay for what you use. The appeal is real: no capital outlay on hardware, capacity you can grow or shrink on demand, and the physical security of the data centre handled by someone else.

But "handled by someone else" is precisely where administrators come unstuck, so this is the idea to fix firmly.

Who is responsible for what

The shared responsibility model defines the line between what the cloud provider secures and what you secure, and the line moves depending on the service model. For servers, the case that matters is IaaS, and the rule is blunt: in IaaS the provider secures the physical hosts, the physical network, the data centre and the hypervisor, and you are responsible for everything from the guest operating system upwards; the operating system, its patches, the applications, the network controls, the identities and the data (Microsoft Learn, "Shared responsibility in the cloud").

Read that again, because it catches people out. Patching and hardening the operating system of a cloud virtual machine is your job, not the provider's. Renting the machine from Azure or AWS does not mean Azure or AWS is patching Windows or Ubuntu inside it. Some responsibilities never shift no matter the model: your data, your accounts, and your identity and access management are always yours to protect.

graph TB
 subgraph Onprem["On-premises (you run it all)"]
 A1["Data, apps, OS,<br/>virtualisation, hardware, network"]
 end
 subgraph IaaS["IaaS (rented server)"]
 B1["You: data, apps, OS, identity"]
 B2["Provider: hypervisor, hardware, datacentre"]
 end
 subgraph SaaS["SaaS (finished app)"]
 C1["You: data, accounts, access"]
 C2["Provider: everything else"]
 end

The three models in that picture form a spectrum. On-premises, you own the whole stack. With IaaS you hand over the hardware and hypervisor but keep the operating system and up. With Software as a Service, a finished application such as Microsoft 365, you keep only your data, your accounts and who has access. Servers, the subject of this unit, live squarely in the IaaS column, which is the one where the most operating-system security work stays with you.

Worth knowing alongside this: infrastructure as code (tools such as Terraform, Bicep or Ansible) lets you define servers and networks in version-controlled files rather than clicking them into being, so a hardened, documented baseline can be deployed identically every time and audited like any other code.

A moment to think

Before moving on, sit with the trap in this section. If a small business "moves its server to the cloud" and assumes the cloud provider is now handling security, which specific jobs have quietly become nobody's responsibility? Who patches the operating system? Who configures the firewall rules? Who tests the backups? The shared responsibility model is not a technical diagram so much as a contract about accountability, and the gaps in it are where breaches happen.

You cannot manage modern servers for long without meeting containers, so it is worth placing them against what you already know. A virtual machine virtualises the hardware: each one carries a full guest operating system on top of the hypervisor. A container virtualises the operating system instead: it shares the host's kernel and packages only the application and the libraries it needs, so it is far smaller, starts in seconds, and packs far more densely onto a host.

Docker is the standard tool for building and running containers. Kubernetes is the dominant system for orchestrating them at scale, scheduling containers across a cluster and restarting them when they fail (the Kubernetes project ships roughly three releases a year, so the version number moves every few months; v1.36 arrived in April 2026). For a server administrator the trade-off is the thing to hold on to: containers give speed, efficiency and portability, while virtual machines give stronger isolation because each has its own kernel. A container that is broken out of reaches the shared host kernel, so image scanning, least privilege and kernel patching still matter. It is common to run containers inside virtual machines to get both the density and the isolation.

The unit's first two elements, prepare and install, are really a single discipline: think before you build, then build in a repeatable way. The knowledge evidence names the boot process, partitioning, file systems and the various install methods, so this section walks the ground from planning to a running operating system.

Planning and sizing

Match the machine to the work: enough CPU, memory, storage and network for the workload, plus headroom for growth and for peak load rather than average. Design redundancy in from the start where the role justifies it; dual power supplies, dual network cards, spare disk capacity, so that a single component failing does not take the service down. Part of preparing to install, in the unit's own words, is backing up local data first and telling users when the service will be down; a server rebuild that surprises the people who depend on it is a failure even if the technical work is perfect.

Storage and RAID

RAID (Redundant Array of Independent Disks) combines several physical disks so they behave as one, for speed, for resilience, or both. The levels worth knowing:

RAID 0 stripes data across disks for speed but has no redundancy; lose one disk and you lose everything. RAID 1 mirrors the same data on two disks, so one can fail; you get the capacity of one disk from two. RAID 5 stripes with a parity block and survives one disk failing. RAID 6 keeps two parity blocks and survives two. RAID 10 combines mirroring and striping for both performance and resilience, and is common under databases.

The line to underline, because the unit lists RAID under high availability and not under backup: RAID protects against a disk dying, not against a file being deleted, encrypted by ransomware, or corrupted. RAID is availability; it is not a backup. Beyond a single server, storage may live on shared systems; a SAN presents block storage over a network, a NAS presents file storage.

Partitioning and file systems

Installing the operating system means laying out the disk first: a partitioning scheme that separates the operating system from data where it helps, the file systems that structure each partition (NTFS on Windows; ext4 or XFS on Linux), and virtual memory, the page or swap space the system uses to extend RAM. The unit names all three in element two. Partitioning earns its place for good reasons: separating the operating system from data limits the damage when one volume is corrupted or fills up, lets you apply different backup, quota and security policies to each area, and keeps a runaway log or a full data drive from taking the operating system down with it. Virtual memory is the safety valve underneath; the page file on Windows, or swap on Linux, lets a server keep running when physical memory is exhausted, but paging to disk is far slower than real RAM, so it is sizing insurance rather than a substitute for enough memory, and leaning on it heavily is itself a performance problem to tune out. Right-sizing memory and the page file, adjusting processor scheduling, and trimming roles and services the server does not need are the everyday performance-tuning levers. Modern disks use the GPT partitioning scheme rather than the old MBR, which is what allows large disks and the UEFI boot described next.

The boot process, and how to place a fault in it

The boot process is examinable, and being able to narrate it is what turns "the server will not start" from a panic into a diagnosis. The shape is the same on both platforms: firmware wakes the hardware, a boot loader finds and loads the operating system kernel, and the kernel starts the services. The detail is where the fault-finding lives.

graph LR
 PWR["Power on"] --> FW["Firmware<br/>UEFI or BIOS<br/>(POST, Secure Boot)"]
 FW --> BL["Boot loader<br/>Windows Boot Manager / GRUB2"]
 BL --> K["Kernel loads<br/>+ initial drivers"]
 K --> INIT["Service manager starts<br/>services / logon"]

Firmware runs first. On modern servers this is UEFI (the older BIOS survives only on legacy hardware). It performs the power-on self test (POST), checks the hardware is present and healthy, and then, if Secure Boot is on, verifies that the boot loader is digitally signed and trusted before handing control to it. A fault here looks like no operating system at all: POST beeps or codes, a missing boot device, a firmware screen. This is hardware and firmware territory, not operating-system territory.

On Windows the firmware hands control to the Windows Boot Manager (bootmgr), which reads the boot configuration data and loads the Windows loader (winload.efi), which loads the kernel (ntoskrnl.exe) and the drivers marked to start at boot; the kernel then starts the Session Manager and the services. A fault between here and the logon screen, a missing or corrupt boot configuration, a bad driver, presents as a stop error or a boot loop, and the tool for it is the Windows Recovery Environment (WinRE): Startup Repair, Safe Mode to get in with minimal drivers, or bootrec to rebuild the boot records.

On Linux the firmware loads GRUB2, the boot loader, which loads the kernel together with an initramfs (a small temporary root filesystem holding the drivers needed to reach the real disk); the kernel then hands control to systemd, process ID 1, which brings the system up to its target (the modern replacement for the old runlevels) by starting services in dependency order. A fault shows as a GRUB rescue prompt, a kernel panic, or a hang partway through the service start; the recovery paths are booting an earlier kernel from the GRUB menu, editing the boot line to reach single-user or emergency mode, or reading how far it got with journalctl -b.

The security angle is real and current. Secure Boot, and the TPM (Trusted Platform Module) chip that backs measured boot and disk encryption such as BitLocker, exist because the boot path is a prize target: malware that installs itself as a bootkit below the operating system runs before any antivirus and is extremely hard to detect or remove. Verifying the boot chain is how that is shut down, which is also why turning Secure Boot off to work around a problem is a decision to make deliberately, not a reflex.

Install methods

The knowledge evidence lists the ways an operating system gets onto a machine, and they range from the manual to the fully automated: from optical media (CD or DVD), from a bootable USB drive, over the network (Windows deployment services, or PXE boot), and by script, an unattended installation driven by an answer file so that a hundred servers install identically with no one watching. The direction of travel is unmistakable; away from a technician feeding in a disc, towards an image or a script that builds a known-good server the same way every time.

A server install in the lab, start to finish

The quickest way to make the install element concrete is to build one in a virtual machine, which is how most people meet a server operating system for the first time and how a lab exercise is usually run. The steps below install Windows Server in a Type 2 hypervisor such as Oracle VirtualBox or Hyper-V; the same shape applies to a physical box or a cloud instance, with the hardware or the provider standing in for the hypervisor.

Create the virtual machine and name it, then give it resources that match the role: a couple of virtual processors and enough memory for the workload, remembering that a domain controller or a database wants considerably more than a bare file server. Create a virtual hard disk with room to grow. Attach the Windows Server installation image, the ISO file, to the machine's optical drive so it will boot from it. Start the machine and begin the installation: choose the language and keyboard, then, at the version screen, make the decision that matters most for security, Desktop Experience for a full graphical interface or Server Core for the leaner, harder-to-attack command-line build described earlier. Choose a custom (clean) installation, select the disk, and let it lay down the files and reboot. Set the built-in administrator password to something long and unique, which on a real server is the account you then bring under Windows LAPS so it is rotated and never shared. Once the desktop or the command prompt appears, remove the installation ISO so the machine boots from its own disk, and install the hypervisor's guest additions or integration tools for proper display, networking and mouse handling.

At that point you have a running but generic server, and the real work of this unit begins: give it a static IP address rather than a DHCP lease, because a server other machines have to find should not move; set the hostname and time zone; patch it fully before it does anything else; and only then add the roles it exists to provide. A server is not finished when the operating system boots; it is finished when it is addressed, patched, hardened and documented.

The unit's third element, configure and administer, is mostly about people: who exists, what they may touch, and the shape of the space they work in. On a Windows network this is Active Directory work.

Active Directory, from the top down

Configuring the network directory service means standing up and organising Active Directory Domain Services (AD DS), and it helps to hold the whole structure in your head, because almost every administrative task is really a task somewhere inside it. The pieces nest from largest to smallest.

Forest: the top-level security boundary; everything inside it shares one schema and trusts one another. A small organisation is a single forest.

Tree and domain: a domain is the main unit of administration and replication, named in DNS style, such as corp.example.com. One or more domains that share a contiguous name form a tree; a forest can hold several trees.

Organisational unit (OU): a container inside a domain that groups users, computers and groups so that policy can be applied and administration delegated to just that slice. OUs are how you carve a domain into "the Sydney office", "servers", "service accounts".

Object: the individual entries, users, computers, groups, printers, each with attributes (a user has a name, a password, group memberships, and so on).

Two supporting concepts make sense of how the directory holds together. The schema is the blueprint that defines what kinds of object and attribute can exist; it is shared across the whole forest, which is why extending it (as some applications do at install) is a forest-wide event to plan carefully. SYSVOL is a replicated folder on every domain controller that holds Group Policy and logon scripts, so that policy reaches every machine.

Domain controllers, replication and the operations masters

A domain controller is a server running AD DS, and you run more than one, because it is the one service you cannot afford to lose. Domain controllers hold a full read-write copy of the directory and keep each other current through multi-master replication: a change made on any one, adding a user, resetting a password, flows out to the others. A read-only domain controller (RODC) is a hardened variant for branch sites or exposed locations, holding a filtered copy and no writable secrets.

Not everything can be multi-master, though, and this is examinable. Five roles must sit on one nominated domain controller at a time to avoid conflicts; they are the FSMO roles (Flexible Single Master Operations). Two are per-forest: the Schema Master and the Domain Naming Master. Three are per-domain: the RID Master (which hands out the pools of identifiers used to make each account's unique security identifier), the PDC Emulator (the reference for time and the front line for password changes and account lockouts), and the Infrastructure Master. Knowing these exist matters the day one is unreachable, because odd, hard-to-place failures, time drift, password changes not taking, new accounts failing, often trace back to a missing FSMO role holder.

Two more terms round it out. The global catalogue is a partial, forest-wide index that lets a login or a search find objects in any domain without walking the whole forest. Sites and their replication links model your physical network so that replication and logon prefer local, fast connections. And underneath all of it sits a hard dependency worth stating plainly: Active Directory will not function without healthy DNS. Clients find domain controllers through DNS service records, so a DNS fault presents as an Active Directory fault. When "the domain is broken", check DNS first.

Users, groups and least privilege

Create and manage user accounts, then grant access through groups rather than to individuals one at a time, because a group is something you can reason about and audit. Active Directory has two kinds of group: security groups, which carry permissions, and distribution groups, which are only email lists. Security groups also have a scope, domain local, global and universal, and the classic Microsoft pattern for using them cleanly is remembered as AGDLP: put Accounts into Global groups, place those into Domain Local groups, and grant the Permission to the domain local group. It sounds fussy, but it is what keeps access tidy enough to audit as the organisation grows, instead of a tangle of one-off permissions no one can reason about.

The security principle that governs all of it is least privilege: each account gets the minimum access its job needs, and no more. Administrative rights in particular are kept separate from everyday accounts, so that an admin reads email and browses the web as an ordinary user and only puts on the admin identity to do admin work. Two groups deserve real caution because they are the keys to the kingdom: Domain Admins and Enterprise Admins. Membership should be tiny, watched, and protected by multi-factor authentication, because an attacker's whole goal, once inside, is to reach one of them. This single habit of separating and limiting admin rights closes off a large share of how attacks spread once inside a network.

Increasingly the directory is not only on-premises. Many organisations now run a hybrid identity: on-premises Active Directory synchronised to Microsoft Entra ID (the cloud directory behind Microsoft 365 and Azure) so that one account works both places. It is worth knowing that Entra ID is not simply "Active Directory in the cloud"; it uses different protocols and its own model, and securing the synchronisation link between the two is a task in its own right (general current Microsoft practice). For this unit the on-premises directory is the core skill, but the hybrid picture is where the work actually sits now.

The user environment, and quotas

Group Policy (and scripts run through it) shapes the user environment centrally: mapped drives, security settings, what runs at logon, all defined once and applied across the domain. Directory structure and quotas round out the element; a sensible folder layout for shared data, and disk quotas that stop one user or one runaway process from filling a shared volume and starving everyone else.

Authentication, the thread through all of it

User authentication, named in the knowledge evidence, is what ties the directory together: proving a user is who they claim before anything else happens. On a Windows domain the mechanism is usually Kerberos, which issues a user a time-limited ticket after login so their identity can be proven to other services without sending the password around again; the older, weaker NTLM lingers for compatibility and is a frequent target, which is why the newer Windows Server defaults work to block it. Access then follows authentication: authentication answers "who are you", authorisation answers "what are you allowed to do", and the two are separate steps that people often blur. What has changed since the unit was written is that a password alone is no longer treated as proof; multi-factor authentication, a second factor such as an authenticator app or a hardware key, is now the baseline for any account that matters, and the hardening section takes that up next.

This is the section the certificate is really for. Installing a server is the easy half; installing one that resists attack is the craft. A freshly installed server is not a secure server; it is a server with default settings, every role switched on, and a large attack surface waiting to be reduced.

The Essential Eight, applied to servers

The Australian Signals Directorate publishes the Essential Eight, the baseline set of mitigation strategies that Australian organisations are measured against (the Essential Eight is published by the ASD on cyber.gov.au, the authoritative Australian source, with the maturity model set out separately; confirm current per-control wording there). The eight are application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, multi-factor authentication, regular backups, and patch operating systems. Organisations rate themselves from Maturity Level Zero, the weakest, up to Maturity Level Three, and are advised to reach the same level across all eight before climbing higher.

Several of the eight land directly on a server administrator's desk. Patching the operating system and patching applications is the single largest risk reducer; unpatched, internet-facing services are the most reliably exploited way in, so patches for exploited flaws go on fast, not at leisure. Restricting administrative privileges is the least-privilege habit from the previous section, enforced. Application control means only approved programs and scripts run on the server, using tools such as Windows Defender Application Control or AppLocker, so that an attacker's tool will not execute even if it lands. Multi-factor authentication guards every remote and administrative path onto the server. Regular, tested backups are the floor you fall back to when everything else fails, and they are covered next.

Reducing the attack surface

Every role, feature and service you leave running is something that can be attacked and must be patched, so the discipline is to install only what the server needs and switch off the rest. Prefer Server Core over the full desktop for infrastructure roles. Remove or disable legacy protocols that exist only to bite you; the ancient SMBv1, NetBIOS, Telnet. Close ports nothing is listening on for a good reason. Strip default sample content and demo sites. A server that does one job well and nothing else is far easier to defend than one that quietly offers ten services, nine of which no one remembers turning on.

Secure baselines and the shared local admin problem

Rather than harden each server by hand and hope you remembered everything, work from a documented secure baseline. The CIS Benchmarks are consensus hardening guides with specific, checkable settings for Windows Server, Ubuntu, RHEL, IIS, SQL Server and more, and CIS Hardened Images are pre-hardened virtual machines available in the cloud marketplaces (from CIS). Microsoft ships its own security baselines in the Security Compliance Toolkit, enforced through Group Policy or Intune and then monitored for drift.

One specific control is worth calling out because it closes such a common attack path. Windows LAPS (Local Administrator Password Solution) is now built into Windows and Windows Server, including 2025; it automatically sets a different, random local administrator password on every machine and rotates it, storing the current one securely in Active Directory or Microsoft Entra ID (Microsoft Learn, "Windows LAPS overview"). It exists to defeat lateral movement: without it, one shared local-admin password reused across every machine means that cracking it once opens all of them.

Patching earned its own place in the Essential Eight twice over, for operating systems and for applications, so it deserves its own section rather than a line. The knowledge evidence frames it as "software distribution and updates", which is the same discipline seen from the management side.

Why it matters is simple: the gap between a vulnerability becoming known and a server being patched is the window attackers work in, and they work fast. The cadence to know is Microsoft's monthly Patch Tuesday, the second Tuesday of each month, with out-of-band fixes for anything urgent; the ASD advice is to accelerate patching for actively exploited and critical flaws rather than wait for the cycle.

The tooling is mid-transition. WSUS (Windows Server Update Services), the long-standing on-premises patch distributor, was deprecated by Microsoft in September 2024; it still ships and is supported for now but gets no new features (Microsoft Windows IT Pro blog, September 2024). Microsoft steers hybrid and cloud estates towards Azure Update Manager, which patches Azure, on-premises and multi-cloud servers through Azure Arc (Microsoft documentation). On Windows Server 2025, hotpatching removes most of the reboots that make administrators defer patches in the first place. On Linux, unattended-upgrades on Debian and Ubuntu, and dnf-automatic on RHEL, apply security updates automatically, and live kernel patching (Ubuntu Livepatch, RHEL kpatch) can even patch the running kernel without a restart (confirm exact scope for your subscription).

The unit asks for backup and recovery and for high availability, and it is worth keeping the two ideas apart because they solve different problems. High availability keeps a service running when a component fails. Backup gets your data back when it is lost or destroyed. You need both, and neither substitutes for the other.

Backup, and the rule that survives ransomware

The durable guidance is the 3-2-1 rule: keep three copies of your data, on two different kinds of media, with one copy off-site. The modern extension, sometimes written 3-2-1-1-0, adds one copy that is offline, air-gapped or immutable, and zero errors, meaning you have actually tested a restore rather than assuming it works.

That extra immutable copy is not decoration; it is a response to how ransomware now behaves. Attackers deliberately find and destroy backups before triggering the encryption, so that paying the ransom is the only way back. An immutable backup, written so that it cannot be altered or deleted even with valid admin credentials (Azure Blob immutable storage, Amazon S3 Object Lock, a hardened Linux repository), is what defeats that. A backup your domain admin account can delete is a backup the attacker can delete, because by the time it matters they are your domain admin.

RTO and RPO, the two numbers that drive backup design. The Recovery Time Objective is how quickly a service must be back after an outage. The Recovery Point Objective is how much data, measured in time, you can afford to lose; an RPO of one hour means backups at least hourly. Lower numbers cost more, so they are a business decision, not purely a technical one.

Redundancy and high availability

RAID, from the storage section, is redundancy at the disk level. Above that, clustering provides failover: Windows Failover Clustering, or Pacemaker and Corosync on Linux, move a role or a virtual machine automatically to a surviving node when one dies. Load balancing spreads traffic across several servers so that no single one is a bottleneck or a single point of failure, and so that you can take one out of service without an outage. Together these are how a service stays up through a failure that, on a single unclustered server, would have been an outage.

Replication is the file-level companion to all of this, and the unit names it alongside RAID as a high-availability option for file systems. On Windows, DFS Namespaces present shared folders from several servers under one logical path, and DFS Replication (DFSR) keeps copies of a folder in sync between servers using remote differential compression, so it sends only the changed parts of a file rather than the whole thing; DFSR is also what replicates the SYSVOL folder between domain controllers. For disaster recovery rather than day-to-day sharing, Storage Replica, introduced in Windows Server 2016, replicates whole volumes at the block level between sites, synchronously for zero data loss or asynchronously over longer distances. Replication copies data to somewhere else, so, like RAID, it guards against a server or a site being lost, not against a file being deleted or encrypted; it sits beside backup rather than replacing it.

A server you are not watching is a server you will hear about from your users first, which is the wrong way round. The unit's testing and troubleshooting elements assume you can see what a server is doing.

Logging is the record. Windows keeps its Event Viewer logs (Application, System and Security); Linux keeps journald, read with journalctl, alongside the text logs under /var/log. Security-relevant events, logons, use of privilege, service changes, should be kept and, better, forwarded off the machine, because a local log is one an attacker can wipe. Forwarding them into a SIEM (Security Information and Event Management) platform such as Microsoft Sentinel, Splunk or Elastic lets you correlate events across many servers and alert on the patterns that matter; it is also what stops log tampering hiding an intrusion.

Performance monitoring is the other half of watching: Performance Monitor and Resource Monitor on Windows, top or htop and friends on Linux, and infrastructure tools such as Prometheus with Grafana, Zabbix, or the cloud-native Azure Monitor and Amazon CloudWatch for a whole fleet. Remote management is how you touch a server without walking to it: RDP for a Windows desktop (kept off the open internet and behind multi-factor authentication), SSH for Linux and now Windows too, PowerShell remoting for scripted control, and Windows Admin Center for a browser-based view of many machines at once.

Element four is testing, and the knowledge evidence names the troubleshooting tools that back it up. Testing a server means checking it against the task requirements it was built for, then seeking feedback from the people who use it and validating any change before it is called done. The mindset is to prove the server works rather than assume it, and to change one thing at a time so that when something breaks you know what did it.

A method before the tools

Reaching for commands before you have framed the problem is how hours get lost. A workable order: state the problem precisely (what, when it started, what changed), reproduce it if you can, then work up the layers rather than guessing, physical and power, then network, then the operating system, then the service, then the application. Change one thing at a time and note what you changed, so that a fix is repeatable and a dead end is not repeated. Check the logs early rather than last, because the server has usually already written down what went wrong. The point of knowing the boot process and the network stack is exactly this: they tell you which layer to look at first.

Network diagnostic utilities

When a server is unreachable or a service will not answer, these are the first reach. Most have a Windows form and a Linux form that do the same job.

Job	Windows	Linux	What it tells you
Test basic reachability	ping	ping	Is the host up and reachable at the IP layer
Check this machine's addressing	ipconfig /all	ip addr, ip route	Own IP, subnet, gateway, DNS servers
Test name resolution	nslookup, Resolve-DnsName	dig, nslookup	Whether DNS returns the right address
Trace the path	tracert, pathping	traceroute, mtr	Where along the route traffic stops
See listening ports and connections	netstat -ano, Get-NetTCPConnection	ss -tulpn, netstat	What the server is listening on and connected to
Test one port is open	Test-NetConnection -Port	nc -vz, curl	Whether a specific service port answers

A worked example makes the order concrete: a user cannot reach a web application. ping the server by IP (is it up?); if that works, nslookup the name (is DNS resolving?); if that works, Test-NetConnection to port 443 (is the web service listening?); if that fails, you are now on the server looking at the service, not the network. Each step rules out a layer.

Process and task management

The knowledge evidence names process termination and task scheduling, so know both.

Job	Windows	Linux
List running processes	tasklist, Get-Process	ps aux, top, htop
End a stuck process	taskkill /PID, Stop-Process	kill, kill -9, pkill
Watch live resource use	Task Manager, Resource Monitor	top, htop, vmstat, iostat
Manage a service	Get-Service, Restart-Service, sc	systemctl status|restart|enable
Schedule a job	Task Scheduler, schtasks	cron (crontab -e), systemd timers
Read the logs	Event Viewer, Get-WinEvent	journalctl, files under /var/log

Terminating a process is a small act with a sharp edge: kill -9 (or ending a process tree) stops it without letting it clean up, which can leave a database or a file half-written, so it is the last resort, not the first. Prefer a graceful stop, then force only if it will not go.

User account and password management

This group is as much a security task as a fix, which is why it sits in both this section and the hardening one. Resetting a locked or forgotten account, checking group membership when someone cannot reach what they should, and revoking access cleanly when someone leaves are daily work.

Job	Windows	Linux
Create or view a user	net user, New-ADUser, Get-ADUser	useradd, id, getent passwd
Reset a password	Set-ADAccountPassword	passwd <user>
Unlock an account	Unlock-ADAccount	faillock --reset, pam_tally2
Check or change group membership	Get-ADGroupMember, Add-ADGroupMember	groups, usermod -aG
Disable rather than delete on exit	Disable-ADAccount	usermod -L, chage -E

Note the last row. When someone leaves, the safe first step is to disable the account, not delete it: disabling cuts access immediately while preserving the mailbox, the file ownership and the audit trail, which a deletion would destroy. It is the reversible move, and reversibility is a virtue when you are acting quickly.

A moment to think. Notice how often the troubleshooting tools and the security tools are the same tools. netstat or ss showing an unexpected listening port is a fault to some administrators and an intrusion to others; the difference is only whether you were expecting it. Watching a server well and defending it well are close to the same skill.

The last element is the one people skip, and it is examinable precisely because people skip it. Document the configuration and the operational changes you made, so that the next person, who may be you in a year, can understand and reverse them. Record the server's status. And when hardware is retired, dispose of it under the organisation's e-waste policy, which for a server carries a security sting in the tail: the disks hold data, so decommissioning means securely wiping or physically destroying the drives before the box leaves the building, not just unplugging it and putting it on a pallet. A server that leaves the organisation with readable disks is a data breach dressed up as a clean-up.

This sits beyond anything the unit imagined, and it is where the job is actually moving, so it belongs on the page.

AI assistants are now embedded in the platforms administrators use. Microsoft Copilot in Azure reached general availability on 8 April 2025; it helps design, operate and troubleshoot Azure infrastructure and will generate scripts in the CLI, PowerShell or Terraform from a plain-language request (Microsoft Azure Infrastructure Blog, 8 April 2025). On the security side, Microsoft Security Copilot has been generally available since 1 April 2024, and in March 2025 Microsoft announced autonomous Security Copilot agents for tasks such as phishing triage and vulnerability remediation (Microsoft Security Blog, March 2024 and March 2025). Red Hat's RHEL Lightspeed brings the same idea to the Linux command line. Generating PowerShell or Bash, explaining an error or a log extract, drafting infrastructure-as-code and summarising alerts are now ordinary parts of the work.

The cyber security lens does not soften here; it sharpens. An AI agent given credentials or API access to your servers is a privileged identity, and it should be treated like one: scoped to least privilege, its actions logged, human approval required before it changes anything, and guarded against prompt injection, where hostile input tricks the assistant into acting against you. Microsoft's own shared-responsibility guidance now carries an AI section making the point that the customer remains accountable for prompt security and for protecting sensitive data when using these services (Microsoft Learn, shared-responsibility documentation). And a practical caution worth passing to any new administrator: many of these agent and autonomous features are in preview or changing quickly, so confirm what is generally available before you trust it with a production server.

A question to close on. If an AI assistant can now write the PowerShell, install the roles and read the logs, what is left that is distinctly the administrator's? The answer this unit keeps circling back to is judgment: knowing which server to build, where the responsibility line falls, what "secure" means for this organisation, and whether the confident script the assistant just handed you is actually safe to run. The tools change every year; that judgment is the thing worth building.

The official scope, the elements, performance criteria, knowledge evidence and assessment conditions, is verbatim from the training.gov.au unit of competency and assessment-requirements documents for ICTNWK422 (documents generated 18 December 2024), with nominal hours of 40 confirmed against the Victorian Purchasing Guide for the ICT Training Package. Coverage also draws on the delivered ICTNWK422 assessor guide (version 4.4, May 2024) and its topic materials; the lab install walkthrough generalises the delivered VirtualBox install steps to current Windows Server. The current-practice material is drawn from primary vendor and government sources, read in August 2026 and re-verified in September 2026: Microsoft Learn and the Microsoft Windows Server, Azure Infrastructure and Security blogs for Windows Server 2025 general availability on 4 November 2024, hotpatching (24 April 2025), SMB and security hardening, Windows LAPS, WSUS deprecation (September 2024), the Windows Server 2016 end-of-support notice (25 February 2026), the shared responsibility model, the Microsoft Learn documentation for DFS Replication and Storage Replica, Microsoft Copilot in Azure general availability (8 April 2025) and Security Copilot (April 2024 and March 2025); the Ubuntu 24.04 LTS release notes (page updated April 2026) and Red Hat and Linuxiac for RHEL 10 general availability (20 May 2025); the Kubernetes project blog for the release cadence, with v1.36 released in April 2026; and the Australian Signals Directorate's Essential Eight on cyber.gov.au for the mitigation strategies and maturity model. The VMware and Broadcom licensing timeline is corroborated across reputable technology press (BleepingComputer, The Register, vInfrastructure, 2024 to 2025) rather than Broadcom's own pages; the CIS Benchmarks description is from general knowledge.