Windows and Linux Systems Administration Labs

Working across a small managed environment

SYS-255 used a VMware and vSphere teaching environment with Windows Server, Windows workstations, and Linux hosts. The weekly labs covered the routine work that keeps a small network operating: naming, addressing, identity, policy, remote access, service configuration, logging, and permissions.

The larger Kubernetes and Elastic build is documented separately. This page covers the administration exercises around it.

The retained submissions are short weekly reports built around screenshots and spot checks. Taken together, they show a managed environment rather than isolated product exercises: a Windows workstation named wks01, domain accounts, internal DNS and DHCP services, Linux web servers, vSphere-hosted virtual machines, and remote management from the college access portal.

DNS records and troubleshooting

I used packet captures and command-line queries to examine how DNS clients and servers exchange requests. One capture showed the client sending its query to the lab DNS server at 10.0.5.5 on port 53.

The exercises covered:

• A records for IPv4 host addresses
• CNAME aliases that point one name towards another
• MX records for mail routing
• PTR records for reverse lookup
• NS records identifying authoritative name servers
• successful answers, non-authoritative responses, and NXDOMAIN

The exercises included a referral involving a.edu-servers.net, an NXDOMAIN response for a deliberately missing ciaranbyrne.edu name, and a non-authoritative answer for champlain.edu. Capturing both the query and reply made it possible to identify:

• the client and resolver addresses
• source and destination ports
• transaction identifier
• requested name and record type
• response code
• authoritative-answer flag
• returned answers or referral records

Most ordinary queries used UDP port 53. TCP is also used by DNS, including when a response is truncated, for some larger exchanges, and for zone transfer where permitted. The historical lab described a fixed 512-byte threshold; EDNS has long allowed larger UDP payloads, so transport selection is more nuanced than that early rule.

The record comparison connected protocol fields to administration:

• an A record maps a hostname to an IPv4 address
• a CNAME makes one name an alias of another canonical name
• an MX record identifies mail exchangers and their priority
• a PTR record supports reverse mapping from an address to a name
• an NS record identifies authoritative name servers for a zone

A hostname can have more than one A record, and an MX record normally names a mail host rather than directly containing its IP address. Those corrections are part of cleaning up the original study notes without losing the packet-analysis work.

In the Active Directory exercises, DNS was also part of domain operation. I queried wks01 with nslookup after joining it to the environment and confirmed that the workstation could be resolved through the internal service.

Workstations had to use the domain DNS service to locate controllers and join the domain. A machine could have working internet resolution and still fail domain discovery if it pointed at the wrong resolver, because Active Directory publishes controller and service information through its own DNS records.

DHCP leases and the four-message exchange

The DHCP lab used a Linux server and Windows workstation. ipconfig /all on wks01 identified 10.0.5.3 as the DHCP server. I then reviewed the corresponding server messages in /var/log/messages and compared them with a packet capture from the client.

The capture contained the normal four-message exchange:

1. discover
2. offer
3. request
4. acknowledge

Changing default-lease-time and max-lease-time in the server configuration, then restarting the service, altered the lease issued to the client.

Each message had a separate role:

• Discover broadcast the client’s need for configuration
• Offer proposed an address and options from a server
• Request identified the offer the client wanted to accept
• Acknowledge committed the lease and supplied the final configuration

The exchange also carries options such as subnet mask, router, DNS server, and lease duration. A client can receive an address and still have unusable connectivity if one of those options is wrong.

Troubleshooting required checking more than whether the package was installed. The service needed a valid subnet declaration, the correct interface, an available address range, firewall access, and a client on the expected broadcast domain. Server logs and the packet exchange showed where the process stopped.

The separate “DHCP Is Down” exercise was built around diagnosing a failed service rather than following a successful setup. The retained report is largely screenshots, but the troubleshooting method was the same: check the client state, service state, configuration syntax, logs, network path, and then renew the client lease after correcting the server.

Active Directory objects and policy

I created a Windows domain, added wks01, and worked with a standard user and a Domain Admin account. The detailed domain build is covered in the separate Active Directory lab page; SYS-255 extended that work into policy application.

I used:

• gpresult /r to inspect policies applied to a client
• gpupdate /force to request a policy refresh
• organisational units to scope users and computers
• a test account and workstation before applying a policy more widely

The labs distinguished computer policy, which is applied to the machine, from user policy, which follows the signed-in account. Some computer settings take effect during startup and some user settings during sign-in, although gpupdate /force can request reapplication of both policy sections.

One test policy removed the Recycle Bin interface for the account named alice. Another, labelled DisableLastLogin, prevented the previous user’s identity from being displayed on the Windows sign-in screen.

The visible desktop change was only the result. The administration work was in linking the policy to the correct container, confirming inheritance and scope, refreshing the client, and checking the resultant policy.

The lab guidance recommended a dedicated test organisational unit and test workstation before linking a policy more broadly. That creates a controlled place to confirm effect, security filtering, and unintended side effects. In a larger domain I would also check replication state, use Group Policy modelling or results, and retain a rollback plan for settings that affect sign-in or remote administration.

Apache services and logs

On Linux I installed Apache, opened the required firewall service, and tested the web server from another machine. A domain-join exercise placed a Linux host into the managed environment so identity and name resolution could be tested across operating systems.

The logging exercise compared a successful request carrying a query parameter with a request for a missing resource. I identified the remote host, timestamp, request line, HTTP status, user agent, and response timing in the Apache log.

Both requests came from the lab client 10.0.5.150. The successful request was:

GET /?test=1 HTTP/1.1

It returned HTTP 200 at 29/Oct/2021:12:25:47 -0400. The second requested a missing resource and returned 404 at approximately 12:23:55. The captured user agent identified Internet Explorer compatibility mode on Windows 10.

The report labelled the final numeric fields 178 and 216 as response time. In a standard Apache combined log, that position normally records response bytes rather than duration. Correct field interpretation requires checking the configured LogFormat, especially when a custom format adds timing, forwarding, or virtual-host fields.

That was a practical introduction to logs as structured operational data. A 200 and a 404 tell different stories, but both need the request path, client, time, user agent, response size, and surrounding activity before they can be interpreted. A query string such as test=1 is not suspicious on its own; it becomes useful when correlated with application behaviour and other requests from the same client.

Remote administration

The lab environment was accessed through the college View portal and a vSphere ESXi console. The spot check documented that I could reach the portal, open the virtualisation console, and see the assigned virtual machines. Inside the environment, I used SSH for Linux administration and PowerShell remoting for Windows.

Remote management depends on several connected controls:

• the service must be enabled and listening
• host and network firewalls must allow only the required path
• DNS and routing must resolve the target correctly
• the account must have the intended rights
• the session should be authenticated, encrypted, and logged

The PowerShell exercise confirmed that the remoting path was not blocked by the host firewall. In a Windows domain, the complete path also depends on WinRM configuration, listener state, authentication method, trusted hosts or domain trust, account rights, and the relevant firewall profile.

Comparing PowerShell remoting with SSH showed the same control layers through different implementations: listener, routing, firewall, identity, authorisation, encryption, and logs. Testing only that a port is reachable does not establish that the management path is correctly restricted.

Linux ownership and permissions

The Linux exercises covered users, groups, ownership, and the read, write, and execute bits for owner, group, and others. I used chmod, chown, and group membership to change who could access files and directories.

Directory execute permission controls traversal, while file execute permission controls whether the file can be run. Numeric modes are concise, but symbolic changes often make an administrative intention easier to review.

The distinction affects service troubleshooting. A user may be able to read a file but not reach it because one parent directory lacks execute permission. A service may own its configuration but be unable to write its log directory. A group change may not affect an existing session until group membership is refreshed.

Permissions were examined alongside service accounts and remote access. A correctly configured service can still expose data if its files are broadly readable, while restrictive ownership can stop the service from starting even when the network and package configuration are correct.

Currentness

This is a historical 2021 lab series. Product versions, Linux distributions, service defaults, PowerShell remoting, cryptographic guidance, and Windows administration interfaces have moved on. The page records the systems work I completed and the troubleshooting relationships between identity, DNS, addressing, policy, services, logs, and permissions.

The series built a repeatable diagnostic order that I later used in security work: identify the expected state, inspect the client, inspect the service, check name resolution and routing, check policy and permissions, read the logs, and verify the result from another system. That same order applies whether the problem is an unavailable service, a failed domain join, or an investigation into why an unexpected connection succeeded.