Linux & Windows Server Support: What Managed Administration Covers

Managed server administration is often reduced to "someone else patches our servers." In practice, a mature engagement covers a lot more than the monthly patch cycle — and the parts that get left out are usually the parts that cause outages.

The pattern is familiar. A managed service is signed on the basis of patching and monitoring. Two years later the servers are patched, the dashboards are green, and nobody can explain why the file server ran out of disk on a Saturday, or why the backup that was supposedly running had not produced a restorable copy since a firmware update in March. Everything in scope was delivered. The scope was the problem.

What follows is what a serious engagement should include, and how to tell whether yours does.

Patching is a process, not an event

Applying updates is the easy part. The work that determines whether patching helps or hurts happens around it: knowing what is installed, knowing what depends on it, having a rollback position, and having a maintenance window that reflects how the business actually runs rather than what was convenient when the contract was signed.

Mixed Linux and Windows estates make this harder than it sounds. Patch cadences differ, reboot behavior differs, and the dependency chains are rarely documented in one place. A Windows cluster node that reboots cleanly in isolation can still break an application that assumes both nodes are available. A kernel update on a database host may require a driver rebuild that nobody accounted for.

Ask your provider what happens when a patch fails. If the answer is "we roll it back," ask how — snapshot, package downgrade, restore from backup — and when that path was last exercised. A rollback plan that has never been tested is an intention, not a plan.

Monitoring only helps if the thresholds mean something

Default thresholds produce two failure modes, and most estates suffer from both simultaneously. Alerts that fire constantly on conditions that are normal for your workload get muted within weeks. Alerts that never fire on conditions that are genuinely dangerous give false confidence.

Disk is the classic example. A generic 90 percent warning is useless on a volume that is permanently 92 percent full because it is dominated by static data, and it is far too late on a log volume that fills in twenty minutes under load. The threshold has to come from the growth rate and the consequence, not from a template.

The same applies to memory, CPU, and service checks. A batch server pinned at 100 percent CPU overnight is working correctly. An application server at 60 percent with climbing response times is in trouble. Monitoring that does not distinguish between them is measuring the wrong thing.

Hardening and drift

Security hardening against a CIS or STIG baseline is a reasonable starting point, and most providers will do the initial pass. The harder question is what happens over the following eighteen months, as troubleshooting sessions loosen a permission here and an emergency change opens a port there.

Configuration drift is not usually malicious or even careless — it is the accumulated residue of legitimate work that nobody reverted. The defense is periodic re-scanning against the baseline with a documented exception list, so that every deviation is either fixed or consciously accepted. An estate with no exception list has not been assessed recently; it has simply not been looked at.

Local administrator and root access deserves the same treatment. Accounts accumulate. People change roles and keep their old permissions. A quarterly review of who holds privileged access on which systems takes an afternoon and routinely turns up accounts that should have been removed a year ago.

Backups you have actually restored

Backup jobs report success far more reliably than backups restore data. A job can complete cleanly while excluding a directory that was added six months ago, or while writing to a target that has silently stopped being replicated offsite.

The only meaningful test is a restore. Not a verification pass, not a checksum — an actual recovery of a real file or a real system into a usable state, performed on a schedule, with the result recorded. It is not glamorous work and it is the first thing cut when a team is busy, which is precisely why it belongs in a managed engagement where it happens whether or not anyone remembers to ask.

While you are at it, confirm where the backups live. Backups reachable with the same credentials that administer the servers they protect are not a defense against the failure mode most people are actually worried about.

Closing the loop

The most valuable providers close the loop between patching, monitoring, and incident response — so a memory-leak alert on Tuesday leads to a patch on Wednesday, not a ticket that ages for weeks. That connection is organizational rather than technical, and it is the hardest thing to verify before signing.

A useful test is to look at how recurring issues are handled. If the same alert has generated the same ticket eleven times with the same resolution, the underlying problem has never been addressed — someone has just been very diligent about clearing symptoms. Ask to see the recurring incident list. If nobody maintains one, that tells you something on its own.

A short scope checklist

• Is there a current inventory of every server, its role, and its dependencies?
• Are patch windows agreed in advance, with a tested rollback path?
• Are alert thresholds derived from your workload rather than vendor defaults?
• Is there a hardening baseline with a documented, reviewed exception list?
• Has a real restore been performed and recorded in the last quarter?
• Is privileged access reviewed on a schedule?
• Do recurring incidents get root-caused, or just closed?
• Are runbooks written where your own engineers can read them?

If several of those are uncertain, the gap is usually not competence — it is scope that was never defined precisely enough to be delivered. That is a fixable problem, and worth fixing before the next Saturday morning.

You can see how we structure this work on our Linux and Windows server support page, and how it connects to 24/7 emergency support and infrastructure automation.