Operating system and patches
Windows Server and Linux: patches, roles, performance and tracking the end-of-support date, so replacing a system is never a sudden December decision.
That is the awkward part of this service: the better it is done, the harder it is to show what you are paying for. The server runs, nobody calls, the invoice arrives every month. So instead of promising continuity, we set out here exactly what happens to the machine in a month when nothing broke, and where our responsibility ends.
We write about servers on four pages and each one takes a different stage of the machine's life, so nothing is repeated. What to buy and how to virtualise is servers for business, choosing components is specification and build, first start-up is server configuration. This page is everything that happens afterwards, for years.
This question comes up sooner or later at every review meeting and we think it is entirely fair. The answer splits into three rhythms.
Monitoring reports disk usage, load, array health and whether the night jobs completed. Most failures announce themselves in advance: a disk in the array reports errors for a week before it drops out, and database logs show growing locks before anyone notices the system slowing down.
System patches in the agreed window, a review of disk space, a check that the backup ran and that anything can actually be pulled out of it, plus a look through logs for things that repeat daily and bother nobody until they do.
Server and array firmware, a review of accounts and permissions, a look at resource usage to see whether memory will still be enough in a year, and updating the documentation. This is the part that disappears first when administration is handled by someone in between other duties.
Once a month you get a report written in plain language, not a dump from the monitoring console: what happened, what was done, what needs a decision and money. There is always a section for things we deliberately did not do and why, because that usually matters more than the list of completed tasks.
Every administrator stands between two risks and there is no escaping both at once. Patching too slowly leaves a hole open, patching too fast can stop the company mid-week.
Security patches go on quickly, because these days only a few days pass between a flaw being published and attempts to exploit it. Feature updates and larger version jumps wait, because they carry a real risk of breaking something and give nothing the company needs today.
We agree the window with you, not the other way round, and we also write down the dates when nothing gets touched: month-end close in accounting, stocktaking in the warehouse, peak season in production. The accounting server on the twenty-fifth of the month is untouchable, whatever the schedule says.
ERP, warehouse and medical systems are often certified for a specific system and database version. Updating outside that list means the vendor will shrug when there is a problem. So before a bigger jump we ask their support and record the answer, rather than assuming it will be fine.
For changes that could break something we take a snapshot of the machine before we start and have the way back written down before we begin. Applying a patch takes fifteen minutes; restoring the state before it without a prepared retreat can take a whole day, and that is the entire difference between planned downtime and an outage.
The most irritating outages come not from a fault but from something quietly expiring. The server keeps running, it simply stops being let in or supported.
Since March 2026 a public TLS certificate may be valid for at most 200 days, from March 2027 for 100, and from March 2029 for forty-seven. Renewing from a calendar stops being realistic, so wherever possible we move it to automation and track the rest on a list of deadlines.
Server warranty, the service contract with its response time, and the end-of-support date for the operating system. A machine without support works perfectly well until the day a power supply fails and it turns out the part has to be sourced privately with a week of waiting.
Virtualisation licences, protection, backup storage and the company domain. The most common scenario we meet is a service paid for on the card of someone who has left the company, and a renewal that failed at an entirely random moment.
We collect all these dates in one place and show them in the report well in advance, not in the week they expire. It is the dull part of this job and it is precisely the part that most often decides whether a company has a quiet quarter. We also compile the full list of deadlines as a one-off during an IT audit, if you need it without an ongoing contract.
Half the companies that ask us about this already have someone in IT and have no intention of replacing them. It is a good arrangement, provided the boundary is written down, because during an outage nobody has time to negotiate it.
The server, operating system, virtualisation, database, backups and monitoring. Everything that calls for rare knowledge and night-time availability while not filling a full post in a company of your size.
Workstations, requests from the team, knowledge of the processes and of who needs what. That knowledge cannot be bought in from outside, and trying to replace it with remote support usually ends in worse service at a higher cost.
Bugs in the ERP or medical software itself, version updates and regulatory compliance belong to its author. We are responsible for the environment meeting their requirements, and we help the two sides talk when each points at the other.
We put this split in the contract along with the list of machines, because the worst outage scenario is three firms each convinced it is not their part. Administrative access here runs on named accounts and the master passwords stay with you, so ending the relationship never means recovering your own servers. Control over who does what on privileged accounts can be added separately through session recording.
Six areas that go into the ongoing contract. Under each one is a link to the page that goes into detail.
Windows Server and Linux: patches, roles, performance and tracking the end-of-support date, so replacing a system is never a sudden December decision.
Virtual machines, memory and processor allocation, snapshots and order among the leftovers from projects that have ended.
Watching backup jobs and periodically restoring a sample with the time measured. We check whether you can come back, not whether the job reported success.
Server alerts come to us, not to a mailbox nobody reads. Cover outside working hours is a separate contract option.
System protection, reducing what is visible from outside and order in remote access, because remote desktop exposed to the internet is still a common way in.
Who holds administrative access, on which accounts and what they do with it, including withdrawing access from firms that have finished their project.
What it does not cover: development and fixes in the business software itself, which belong to its vendor, and ongoing workstation support, which is a separate service under a retainer. The two can be combined and most clients do, but a servers-only contract is a normal option here too.
Taking over someone else's environment is the most delicate moment in this service, so we break it into four stages and skip none of them.
What is running, on what, with which versions, what is connected and what is missing. Out of this comes a list of urgent items and the documentation that most companies simply do not have. This stage looks like an audit and is in fact exactly that.
We set up named accounts, connect monitoring and decide who receives which alert. In parallel we agree maintenance windows and the dates when production is left alone.
Outstanding patches, fixing the backups, tidying the accounts and whatever came out on the urgent list. We spread it over stages so as not to make ten changes at once and to know what caused any problem.
We move into a steady cycle: updates in the window, restore tests, the report and a short conversation about what needs a decision. Once a year we sit down to the plan for the next one, usually alongside the end-of-support dates.
Pages that come up in conversations about server care.
We price it from the number of machines and what runs on them, because a file server needs entirely different attention than a database under an ERP system. We give the quote after recording the state, and if the servers are to come in together with workstations, one retainer for everything is usually cheaper than two separate contracts.
No. We work on named accounts with the permissions the work requires, and the master passwords stay on your side, ideally in a password vault we have no access to. The point is that ending the relationship should be a one-day administrative decision, not an operation to recover your own servers.
In a window agreed with you, usually in the evening or at the weekend, excluding the dates critical for the company that we record at the start. High-severity security patches go on sooner, after a phone call, because waiting two weeks for a window is sometimes a bigger risk than the update itself.
It does, and it is the most common arrangement with this service. One person cannot be equally good at workstations, networks, databases and virtualisation, and cannot be available at night. We take the server layer, your IT person stays with the people and processes nobody from outside knows better than they do.
It depends on the contract option and we say so plainly rather than printing 24/7 everywhere. In the basic one monitoring runs around the clock and we start the morning with whatever it reported; in the on-call option someone picks up the phone at night. On-call costs real money, so we add it where a night outage genuinely costs more.
Yes, but we will tell you honestly where you stand. Hardware without vendor support means that when it fails we hunt for parts on the second-hand market and downtime is counted in days, not hours. With a machine like that we usually start by making sure the backup works and that you could start it up somewhere else.
Yes, cloud machines need the same care as those in the server room: updates, backups, monitoring and watching the accounts. One thing changes, namely a bill charged by the hour of running, so keeping an eye on whether you are paying for resources left on after a forgotten project is added to the list.
We hand over the environment documentation, the list of access and deadlines, and our accounts are removed. We hold nothing that would block a move to another firm, because the master passwords are with you throughout the contract anyway. We think a supplier who is hard to leave simply has no better argument.
The first meeting takes 30 minutes and commits you to nothing. We will tell you straight whether we can help and what we would propose.
2019 - 2024 Interactive Workspace Ltd. - All rights reserved.