The office server will not boot: what to do first

Our server will not turn on: what do you do first?

Work this list in order and resist the urge to skip ahead. Steps one to five cost you nothing and prevent the two mistakes that cause most permanent data loss in small offices.

1. Photograph everything before you touch it. The screen, any error text, the front panel, the drive lights, the back of the chassis. Use your phone. This costs thirty seconds and it is often the difference between a diagnosis on the phone and a visit.
2. Stop other people from making changes. Tell staff the server is down, ask them not to keep retrying, and make sure no one is power-cycling it while you work.
3. Check the power path. Is the wall outlet live? Is the UPS on, or beeping, or showing a fault? Are both power cables seated? Many business servers have two power supplies and one can fail silently while the other carries the load, so check that both show power.
4. Bypass the UPS as a test only. If the UPS is dead or in fault, plug the server straight into a good wall outlet briefly to see whether it powers on. A UPS at the end of its battery life is a very common cause of a server that will not start.
5. Read the front panel and the drive lights. Amber or red usually means a fault, and most business servers display an error code or a health message on a small panel or through their management interface. Write down exactly what it says.
6. Check whether the management interface is reachable. Dell servers have iDRAC, HP has iLO, Lenovo has XClarity. If that has its own network cable and address, it often works even when the server itself will not boot, and it will tell you what failed. Being able to reach it is worth its weight during an outage.
7. Do not pull any drives. Not to look at them, not to reseat them, not to swap them around. If you have already removed one, note exactly which bay it came from and put it back in the same bay.
8. Do not press anything that offers to rebuild, initialize or import a configuration on a RAID controller screen. Those prompts can be irreversible.
9. Do not start a restore yet. Restoring over live data before you know what failed can destroy the last good copy you have.
10. Call for help with your photos to hand. Reach me on (214) 612-7080 and start with what the lights and the screen say.

If the server is running but the office simply cannot reach it, that is a different problem and usually a smaller one. The network-first triage in emergency IT support when a server is down covers that case.

Is it the power, the UPS or the server itself?

Distinguish these three before assuming the server is broken, because two of them are cheap and one of them is not.

The circuit. Server closets often share a circuit with something that should not be on it: a space heater, a vacuum outlet, a copier. A tripped breaker takes everything down and looks exactly like a dead server. Check the breaker panel and test the outlet with something simple.

The UPS. An uninterruptible power supply has batteries that wear out on a predictable schedule, and a great many small offices never replace them. A UPS with failed batteries can refuse to pass power at all, or pass it and then cut out under load. Signs include a continuous beep, a red fault light, a battery-replace indicator, or a unit that feels hot. North Texas gives these units a hard life: spring storms and summer grid stress mean plenty of transfer events, and each one uses battery life. Keeping ahead of that is the whole point of protecting office IT against North Texas storms and outages.

The power supply. Business servers commonly have two, precisely so one can fail without an outage. That redundancy hides failures: a supply can die months before anyone notices, and then the second one fails and the server stops. Look at the small light on each supply at the back of the chassis. Amber, red or dark on one of them explains a lot.

If the server powers on but shuts down again within seconds, that points at power delivery or overheating rather than a disk or the operating system. Check the closet temperature while you are there. A server room that is really a storage closet with the door closed and no airflow will cook hardware, and thermal shutdown is a self-protective behavior, not a fault.

What are the drive and RAID lights telling you?

They are telling you whether this is a disk problem, and disk problems are where irreversible mistakes happen. Learn to read them before you touch anything.

Most business servers put an indicator on each drive bay. Green or blue, steady or flickering with activity, means the disk is present and in use. Amber usually means predicted failure or a fault. A dark drive in a populated bay usually means the controller cannot see it at all. Some controllers also flash a pattern during a rebuild, which is important to recognize because a rebuild in progress must not be interrupted.

RAID exists to survive a disk failure, and it usually does. A common array can lose one disk and keep running, and some configurations can lose two. What RAID cannot survive is a second failure during the rebuild after the first, which is precisely when the remaining disks are under the heaviest load they will ever see. That is why a degraded array is an urgent situation even though everything still works.

The dangerous moves are all well intentioned. Pulling a drive to read its label, and putting it back in a different bay, can confuse the controller about the array order. Replacing what looks like the failed disk when it is actually the healthy one takes the array from degraded to failed. Accepting a prompt to initialize or create a new configuration writes new metadata over the old array. Each of those has cost a small business its data, and each takes one confident click.

The safe action is to change nothing and record everything: which bay, which color, which pattern. If the controller has a management page, take a photo of the array status screen. That is what somebody who does this for a living needs in order to tell you whether the array is degraded, failed or fine.

What do the common boot errors actually mean?

Match the message on screen against this table before anyone starts reinstalling anything. Several of these look catastrophic and are not.

That last row is the one to take seriously. Repeatedly powering on a drive that is making noise reduces what a laboratory can recover from it, and the same rules apply as in recovering deleted or lost business files.

Is your data separate from the operating system?

This is the question that decides whether recovery takes an afternoon or a week, and most owners do not know the answer until they need it. Ask it today rather than during the outage.

A well-built server keeps the operating system on one volume and the business data on another, often on a physically separate set of disks. When the operating system fails, and it is usually the operating system that fails, the data volume is untouched. You can rebuild or restore the system, reattach the data, and be running again quickly. If the whole thing lives on one volume, an operating-system failure and a data failure are the same event.

The same logic applies to virtual machines. If your server runs a hypervisor with the business systems inside virtual machines, and those virtual machines live on separate storage, the host can be rebuilt and the machines reattached. This is one of the quiet reasons virtualization is worth it in a small office even when there is only one physical box.

Three other things belong on the same checklist, and each has caught someone out during an outage:

• Where does the line-of-business database live? A practice management, case management or agency system may keep its data somewhere other than the obvious shared folder.
• What is not on the server at all? Scans on a workstation desktop, a spreadsheet somebody keeps locally, a folder on a NAS. Those are not covered by a server restore.
• Is the backup stored on the same machine? A backup on an internal drive or a directly attached USB disk goes down with the server, and in some failures it goes away with it too.

If you cannot answer these, write the questions down and get them answered while everything is working. Documenting exactly this is part of what I do when I take over an environment under managed IT services, because it is the difference between a calm recovery and a guessing game.

What does a restore actually need?

More than a backup file. People discover during an outage that they have the data and nothing to put it on. A restore needs four things, and only one of them is the backup.

1. A verified backup that predates the failure. Find out its date and what it covers. A backup of the file share that does not include the database is a partial restore, and you will not know until you try.
2. Somewhere to restore to. Spare hardware, another host with capacity, or a cloud environment. If the physical server is dead and there is no second box, sourcing and configuring a replacement takes days, not hours. Some backup products can boot a copy of your server temporarily on the backup appliance or in the cloud, and if yours can, that is the feature that saves the week.
3. Keys, licenses and credentials. Windows Server and application licenses, the BitLocker recovery key if volumes are encrypted, the local administrator password, the RAID controller and management passwords, and access to the domain if the failed server was the domain controller. Missing credentials extend outages more than missing hardware does.
4. Time and bandwidth. Restoring a large data set over an internet connection takes as long as the smaller of your download speed and the service's throughput allows. Several hundred gigabytes over a typical small-office circuit is an overnight job at best, and it competes with everyone trying to work.

Order matters during the restore too. Bring back the systems people cannot work without first, and get the data mounted read-only to verify it before pointing applications at it. Restore to a separate location rather than over the top of the original, so a bad restore does not consume your last good copy.

If any of the four items above made you uncomfortable, that is worth fixing on a quiet day. Sizing backups, testing restores and deciding in advance where a failed server would come back are the whole substance of backup and disaster recovery planning, and it costs a fraction of an unplanned week.

What should you have ready when you call?

Have these eight things to hand and the diagnosis starts on the first call instead of the second. None of them require you to be technical.

• Photos of the screen, the front panel and the drive lights. The single most useful thing you can produce.
• What people cannot do. No shared drive, no practice software, no email, or nothing at all. Symptoms from the user side narrow it quickly.
• When it started and what changed. A storm, a power flicker, an update, a new device, work in the building, someone in the closet.
• Whether anything still works. If any computer in the office still has internet, remote access is possible and that changes everything about how fast this goes.
• Who holds the passwords. Server administrator, RAID or management interface, backup software, Microsoft 365, the firewall. If a previous provider held them and you do not, say so early.
• What backup exists and where it goes. Even "there is a black box in the closet with a blinking light" is useful.
• The make and model of the server, from the label on the front, and roughly how old it is. Warranty status matters: a server still under a hardware contract may get a part delivered faster than anyone can buy one.
• Building access details if an evening or weekend visit is likely, including who can let someone in.

Anything you cannot answer is not a problem, it is just information I will have to find. But every item on that list you can answer takes time out of the outage.

Server down at our Dallas office, who can help today?

Call me and we can start immediately. My name is Anthony Omini and I run Cross River Tech, a small, owner-led managed IT company based in Dallas. I have over fifteen years of IT experience across many industries and global organizations, with MCSA and CCNA listed on my LinkedIn, and server outages are ordinary work rather than an unusual event.

Here is how a call goes. I ask what the lights and the screen say, and I look at your photos. If anything in the office still has internet, I connect remotely and check whether the server is reachable at all, what the management interface reports, and whether this is really the server or the network in front of it. A meaningful share of calls that begin with "the server is down" end in that first remote session, because it was the switch, the firewall or the circuit. If it is genuinely the hardware, I come to the office. I cover the Dallas–Fort Worth metroplex onsite, and same-day visits are often possible depending on what is already booked. I will not give you an arrival promise on the phone, and I would treat one from anybody else with suspicion during an outage.

You do not need to be an existing client and there is no contract. Emergency work runs through my hourly IT support and break/fix service: $100 per hour remote and $150 onsite during business hours, Monday to Friday, and $150 remote and $225 onsite after hours, weekends and holidays, with a one-hour minimum billed by the hour. Remote support is available around the clock at the after-hours rate, which is usually the right way to start a server outage at nine at night.

One honest point: no phone number brings hardware back faster than parts and a plan allow. If your business genuinely cannot tolerate a server being down for a day, the answer is not a faster phone call, it is a design that does not depend on one box in a closet. That is a conversation worth having before the outage rather than during it. Reach me through the contact page or on (214) 612-7080.

Questions people ask

Written and reviewed by

Anthony Omini, founder of Cross River Tech

Over 15 years in IT across many industries, now running Cross River Tech, a small owner-led managed IT company in Dallas. Every article is written from his own client work and checked by him before it is published.

Server down right now? Photograph the screen and the drive lights, then call (214) 612-7080. Most outages start with a remote session, not a drive over.

Ask Anthony(214) 612-7080About Anthony