Decommissioning a server safely: removing it from every system that still trusts it

Goal

Retire a server without leaving stale references in DNS, monitoring, backups or a directory service, and sanitize its storage appropriately for the media type before reuse or disposal.

Prerequisites

The inventory record listing every system that references this host; rights to remove entries in DNS, monitoring, backup and directory systems; and a media-sanitization plan if disks will be reused or leave organizational control.

Steps

1. Confirm nothing still depends on the host (active connections, jobs targeting it, load-balancer entries) and drain traffic first.
2. Remove or update DNS records (forward and reverse) so the name and IP no longer resolve to a live service.
3. Remove the host from monitoring, dashboards and runbooks.
4. Disable its backup jobs; keep or purge existing backups per retention policy.
5. Revoke credentials issued to this host: known_hosts trust entries, service-account and API credentials, and TLS certificates naming it (revoke, do not wait for expiry).
6. If the host is domain-joined, remove its computer object with Remove-ADComputer -Identity <name>, documented as a cmdlet that "Removes an Active Directory computer". Preview with -WhatIf; undoing it needs the AD Recycle Bin or an authoritative restore. Objects with child objects (such as cluster nodes) need Remove-ADObject -Recursive.
7. Sanitize storage before reuse or disposal, matching the method to the media. NIST SP 800-88 Rev. 2 defines sanitization as rendering "access to target data on the media infeasible for a given level of effort", through Clear, Purge or Destroy:
   • SSD/NVMe: overwriting is unreliable because of wear-leveling, so use the drive's own erase. For NVMe, nvme format <device> --ses=1 (user data erase) or --ses=2 (cryptographic erase) works; plain nvme format defaults to --ses=0, "No secure erase operation requested". nvme sanitize and ATA secure-erase/sanitize are alternatives where supported. blkdiscard only TRIMs sectors ("is used to discard device sectors") and does not guarantee that the flash cells are erased, so it is not a sanitization method.
   • LUKS volumes: cryptsetup luksErase <device> (newer syntax cryptsetup erase) wipes all keyslots and makes the container "permanently inaccessible". This counts as a cryptographic erase only if all data was encrypted from the first write and no LUKS header backup or copy of the volume key survives.
   • HDDs: a full overwrite of the device is a Clear technique, but it does not reach reallocated sectors. Purge uses the drive's sanitize/secure-erase command or degaussing, and Destroy means physical destruction.
   • Cloud volumes: delete the volume and destroy its customer-managed key if you use one.
8. Mark the inventory record retired rather than deleting it.

Expected result

No DNS, monitoring, backup or directory entry references the host, its credentials are revoked, and storage is sanitized for its media type.

Limits and test basis

NIST SP 800-88 treats Clear, Purge and Destroy as different assurance levels, not interchangeable options; the choice depends on data sensitivity and whether the media leaves organizational control, and the result should be verified and recorded. Depending on the drive's capabilities, nvme format can erase every namespace on the controller; none of these commands can be undone, so check the device path (lsblk, nvme list) first. Removing an AD computer object does not invalidate Kerberos tickets already issued, which remain valid until they expire; handle related service accounts and delegations in step 5.