Systems administration

That is the normal starting point rather than the exception. The first phase is discovery: sweeping the network, exporting configurations, tracking down passwords that live in a spreadsheet or in somebody's memory, and recording which service leans on which. Twenty users and a couple of servers might take three or four days. A dozen machines with legacy applications can run to several weeks. After that, decisions stop being guesses.

The fault is identified from here, usually down to the slot number, and we raise the case under your hardware warranty. The hands belong to somebody else: a colleague of yours working through numbered steps and photographs, the vendor engineer your support contract pays for, or the remote hands service in the data centre. We stay on a call while it happens and confirm the rebuild once the part is in.

Both, because hardly anyone runs only one. A typical estate keeps identity and endpoint policy on the Microsoft side, while the public website, the shop and their databases sit on Debian or Ubuntu. Holding both in a single team matters most when a fault lives on the border between them, which happens to be where the blame usually starts flying.

Often yes, and the two roles overlap less than people expect. An internal colleague holds context that cannot be bought: who does what, which spreadsheet finance genuinely depends on, what the warehouse needs at six on Monday. Infrastructure, alerting, patch discipline and the specialist jobs that come round twice a year sit more naturally with us. Firms of thirty to a hundred staff usually land on that division.

We act as a processor under the agreement Article 28 requires: which activities are covered, how long logs are retained, a confidentiality undertaking and the rules for reporting an incident to you. Access is personal rather than shared, every remote session is attached to a ticket, and we help keep your record of processing current whenever a server or a service changes hands.