Decommissioning a server, and recycling the hardware

Why this matters

Switching a server off is easy. Retiring it properly is not. A server leaves traces everywhere: DNS records that now point at nothing, or at whatever machine is given its address next; monitoring that alerts every five minutes because it is down; backup jobs that fail nightly; licences still counted against the organisation; firewall rules that allow traffic to an address that may be reused; and, most importantly, disks full of data.

Decommissioning is the reverse of deployment, and it deserves the same care. The asset lifecycle lesson introduced retirement as the last stage; the previous lesson covered destroying the data. This lesson covers the complete process: the checklist, the records, the environmental rules for what happens to the hardware, the choice between reuse, resale and disposal, and the final record that the job was done.

The lesson

A decommission checklist: data, DNS, monitoring, backups and licences

A decommission follows a checklist, so that nothing depends on memory. It begins, like any other change, with a change record and a confirmation from the server's owner that its workload has been migrated and is no longer needed.

A typical checklist:

1. Confirm nothing still uses it. Check its logs and network connections for recent activity, since forgotten dependencies are common: a scheduled job on another server, an application with its address hard-coded. A useful practice is to shut the server down and leave it off for an agreed period before removing it, so anything that still depended on it shows up while it can be switched back on.
2. Data. Make sure data that must be retained has been migrated or archived, in line with the retention policy and any legal holds.
3. Final backup. Take and keep a final backup, per policy, in case something is later found to be missing.
4. DNS and addresses. Remove its DNS records, forward and reverse, and any aliases; release DHCP reservations and mark its IP addresses free in the address records.
5. Directory. Remove its computer account from Active Directory, and disable service accounts used only by it.
6. Monitoring and backups. Remove it from monitoring, so it does not generate false alerts, and from backup schedules, so its failed jobs do not hide real failures.
7. Security and access. Remove firewall rules, load balancer pool entries and access permissions that referred to it, and revoke its certificates.
8. Licences. Recover software licences for reuse where the terms allow, and cancel support contracts and subscriptions tied to it.
9. Hardware. Remove it from the rack and cabling records, then sanitise or destroy its storage, as the previous lesson described.

Removing the server from inventory and the CMDB

The documentation lesson described the inventory and CMDB as useful only if they are accurate. A decommissioned server that remains in them causes quiet problems: licence counts are wrong, capacity plans include hardware that does not exist, audits find discrepancies, and the next person to investigate an outage may waste time on a server that is gone.

So the records are updated, but not simply deleted. The server's record is set to a retired or disposed status, keeping its history: when it was bought, what it ran, what was repaired, and when and how it was retired. In the CMDB, its relationships are removed, so that no application or service still shows it as a dependency. If the CMDB shows something still depending on the server, that is a warning that the first checklist item was not complete.

Other records need the same attention: network and rack diagrams, the IP address records, and runbooks or documentation that name the server.

Environmental rules for recycling hardware

Servers contain materials that are harmful if they end up in ordinary waste: lead in solder, mercury, cadmium, flame retardants in plastics, and batteries, including the lithium and lead-acid batteries in UPS units and RAID controller cache modules. They also contain valuable materials, such as copper, gold and other metals, that can be recovered.

Most countries therefore regulate the disposal of electronic waste, or e-waste. In the UK and EU, the WEEE (waste electrical and electronic equipment) regulations require it to be collected and treated separately, and other countries and regions have their own rules. The common requirements are:

• electronic equipment must not go into general waste or landfill;
• it must be handed to licensed or certified recyclers, who treat hazardous components properly;
• batteries are handled separately, under their own rules;
• organisations should keep records showing that equipment was disposed of through proper channels.

Choose recyclers with recognised certifications, and remember the data rule from the previous lesson: a recycler's environmental certification says nothing about data security, so storage is sanitised or destroyed first, with a certificate of destruction, before hardware is handed over.

Reuse, resale or disposal

A retired server is not necessarily scrap. There are three outcomes, in order of preference from both a cost and an environmental point of view.

• Reuse internally. An older server may be perfectly good for a lab, as in the first lesson, for a test environment, or for a less demanding role. Its parts, such as memory, disks and power supplies, may serve as spares for identical servers still in service.
• Resale or donation. Working equipment has value on the second-hand market, and specialist IT asset disposition (ITAD) companies buy it, refurbish it and resell it, often handling data sanitisation and certificates as part of the service. Donation to schools or charities is another option.
• Disposal through certified recycling, for equipment that is broken, obsolete or not worth reselling.

Whichever route is taken, the rule does not change: data is dealt with first. Equipment being reused or resold still needs its storage sanitised, to a level that allows the drives to be used again, such as overwriting or cryptographic erase, or has its drives removed and destroyed, with the equipment sold without them. Licences and support contracts usually do not transfer with resold hardware, so check the terms before promising either to a buyer.

Recording the retirement

The final step is a record that the decommission was completed, which closes the change record opened at the start. It pulls together:

• the checklist, with each item signed off, and by whom;
• the date the server was shut down and the date it was removed;
• confirmation that retained data was migrated or archived, and where the final backup is kept;
• the sanitisation or destruction method for each drive, with serial numbers and the certificate of destruction;
• the chain of custody records for anything that left the building;
• what happened to the hardware: reused where, sold to whom, or recycled by whom, with the recycler's documentation;
• the updated inventory and CMDB status.

This record answers questions that may come months or years later: from auditors, from a regulator investigating a data breach, or from a colleague wondering where a server went. With it, the organisation can show that the server, its data and its hardware were each dealt with properly. Without it, even a perfectly executed decommission cannot be proved.