4.4 Server Roles, Storage Management, and Performance Monitoring

Why Roles Drive Every Other Decision

A server is defined by the role it runs. The role sets the resource profile, the storage layout, the ports that must be open, the backup method, and the thresholds that count as abnormal. SK0-005 tests this as applied reasoning: given a role and a symptom, identify the requirement that was not met.

Core Server Roles and Their Requirements

The exam's favorite version of this is the database server that is "slow" with plenty of free CPU. A relational engine caches working data in RAM; when the buffer pool cannot hold the working set, every query falls through to disk, and the visible symptom is storage latency caused by a memory shortfall. Adding cores does nothing.

Directory Connectivity

Most roles depend on a directory for authentication and authorization. Joining a server to Active Directory Domain Services replaces local accounts with centrally managed identities, applies Group Policy, and enables Kerberos single sign-on for file shares and databases. Linux hosts integrate through realmd/SSSD against AD, or through LDAP/LDAPS to a directory such as 389 Directory Server or OpenLDAP.

Two operational requirements are non-negotiable and both appear as scenario faults. First, time must be synchronized — Kerberos rejects tickets outside a five-minute skew, so a drifting clock breaks domain authentication while ping and DNS still work perfectly. Second, DNS must resolve the directory's SRV records; a server pointed at a public resolver instead of the domain controllers cannot locate a domain controller at all, which presents as a join failure or intermittent logon failures rather than as a DNS problem.

Storage Management for Server Roles

Formatting, Provisioning, and Partitioning

Provisioning is the decision that most often needs revisiting:

• Thick provisioning allocates the full capacity up front. It delivers deterministic performance and cannot be over-subscribed, at the cost of stranded capacity.
• Thin provisioning allocates on write. It dramatically improves utilization but creates an over-subscription risk: the sum of provisioned volumes exceeds the physical pool, and when the pool fills, every workload on it stalls simultaneously. Thin pools therefore require hard capacity alerting well below 100%.

Formatting selects the filesystem and the allocation unit size. The default 4 KB cluster is right for general file service; large sequential workloads (backup targets, video, some database files) benefit from 64 KB. The allocation unit cannot be changed without reformatting, so it is a build-time decision.

Partitioning separates concerns so that one workload cannot consume another's space: the OS on its own volume, application data on a second, logs on a third, and — critically — transaction logs on their own volume so that runaway log growth cannot fill the system disk and halt the server.

Page, Swap, and Scratch Placement and Sizing

Virtual memory placement is an explicit blueprint item. The Windows pagefile and the Linux swap area should live on fast, local, non-redundant-parity storage and, on a physical server with contention, on a spindle separate from the workload's data. Sizing follows the platform's guidance rather than folklore: Windows defaults to system-managed sizing and requires enough space on some volume to capture the configured crash dump type, while Linux swap sizing depends on RAM size and whether hibernation is required. Scratch/temp space (SQL Server tempdb, application working directories, /tmp) is high-churn and is deliberately isolated onto its own fast volume, because a full temp volume fails jobs in ways that look like application defects.

Disk Quotas, Compression, and Deduplication

Quotas are the control that most often surfaces as an incident: a soft quota warns and permits the write, while a hard quota refuses it, and a hard quota reached by a service account produces an application failure with no obvious storage error. Note also that Windows deduplication is post-process, not inline — savings appear on a schedule after the data lands, so the volume must have enough free space to absorb the un-deduplicated write in the first place.

Monitoring, Baselining, Alerting, and Reporting

What to Measure

Baselining Is What Makes a Number Meaningful

A baseline is a recorded set of these counters captured under representative production load, and it is the reference that converts an observation into a diagnosis. "CPU at 70%" is neither good nor bad; "CPU at 70% where the baseline is 25% for this hour of this weekday" is a finding. Baselines are re-captured after any material change — a hardware refresh, a version upgrade, a workload migration — and stored with the server's documentation.

Capacity vs. utilization is the related distinction the blueprint names: capacity is what the system can do, utilization is what it is currently doing, and trending utilization against capacity is what produces a defensible forecast of when more capacity is needed. A volume at 60% utilization growing 5% per month is a scheduled procurement; the same volume discovered at 98% is an incident.

Thresholds, Alerting, Reporting, Retention, and Rotation

Thresholds should be tiered (warning well before critical) and duration-qualified — alert on "CPU above 90% for 15 minutes," not on an instantaneous spike — because untuned alerting produces the fatigue that causes real alerts to be ignored. Alerts route by severity and time of day; reports aggregate the same data for trend review, capacity planning, and SLA evidence.

Log handling has three separate controls that are easy to conflate:

• Retention — how long records are kept, driven by operational need and by regulatory or legal requirements.
• Rotation — how files are cycled and compressed (logrotate, Windows event log maximum size and overwrite policy) so logs cannot fill the volume. Note that a Windows event log set to do not overwrite stops recording once full, which trades availability of the service for completeness of the log.
• Shipping / forwarding — copying events off the host to a central collector or SIEM (Windows Event Forwarding, rsyslog, Fluent Bit). Only the shipped copy survives if the source host is wiped, rebuilt, or compromised, which is why forwarding is a security control and not merely a convenience.

Data Migration and Transfer

Moving data between servers has to preserve more than bytes — permissions, timestamps, and ownership all carry meaning.

Disparate-OS data transfer — Windows to Linux or the reverse — is the case with the sharpest trap: SCP, SFTP, and rsync move file content but do not carry NTFS ACLs, so permissions must be re-established on the destination. The common production pattern is to stage through an SMB or NFS share that both platforms mount, or to accept that ACLs will be rebuilt from the directory groups on arrival.

The blueprint also frames data movement as a security concern. Infiltration is unauthorized data entering the environment (malicious uploads, unvetted third-party datasets, shadow-IT imports); exfiltration is authorized-looking data leaving it. Because a bulk migration and a bulk theft generate nearly identical telemetry, large transfers are scheduled through change management, run from known hosts, and logged — so that data-loss-prevention and monitoring systems can distinguish the planned migration from the incident.

Administrative Interfaces

The consistent principle across all four is that management interfaces belong on a restricted management network, never on a public interface. Telnet and unencrypted HTTP management have no place on a production server — both transmit credentials in cleartext, and their presence is a finding in every server hardening standard.