Asset lifecycle, licensing and secure storage

Why this matters

A server is not just installed and forgotten. It is bought, deployed, kept running, and eventually retired, and at every stage there are costs, contracts and risks that someone must manage. A server whose support contract lapsed unnoticed cannot get a replacement part quickly. Software run beyond what its licences allow exposes the organisation to an audit bill. A box of old disks in an unlocked cupboard is a data breach waiting to be found.

This lesson covers the lifecycle of server hardware, the contracts that support it, the ways server software is licensed, where spares and sensitive material are kept, and how organisations plan for replacing servers before they fail.

The lesson

Procure, deploy, maintain and retire

Server hardware passes through four broad stages.

Procure. Buying begins with requirements: the workload, its growth over the server's expected life, compatibility with existing systems, and support. The purchase includes the warranty and support level, and the new asset is recorded in the inventory, with its asset tag, before it goes anywhere.

Deploy. The server is installed, configured to its baseline, tested and documented as built, as the previous lesson described, then put into service through the change process.

Maintain. Through most of its life the server is patched, monitored, repaired and occasionally upgraded. Records of repairs and parts replaced are kept against its asset record, which also shows when a machine is costing more in failures than it is worth.

Retire. At the end of its life the server is decommissioned: its workload migrated, its services and DNS records removed, its entries in monitoring and backups cleared, its licences recovered for reuse where the terms allow, and its data destroyed so it cannot be recovered, a subject the security domain covers later. Finally, the hardware is disposed of, often through a specialist recycling or asset disposal company that provides certificates of destruction, and the inventory is updated to show it is gone.

Warranty and support contracts, and tracking when they end

A new server comes with a manufacturer's warranty, typically covering parts and repairs for a set number of years. Organisations usually extend this with a support contract, which defines what help they get and how quickly.

The key terms are the service level and response time. Next business day cover means a replacement part or engineer arrives on the next working day. Four-hour or 24x7 cover means help arrives within hours, at any time, for a much higher price. The level should match the server's importance: next business day is fine for a server in a cluster that can run without it, and unacceptable for one whose failure stops the business.

Support contracts often also give access to firmware updates and technical support, so a server out of support may lose more than repairs.

The practical risk is lapsing unnoticed. Contracts end on dates buried in purchase records, and nobody notices until a part fails and the vendor declines to help. Track expiry dates in the inventory or CMDB, set reminders well in advance, and decide deliberately whether to renew, replace, or accept the risk for older equipment. Operating systems and applications have the equivalent, an end of support date after which no security updates are released, which is just as important to track.

Licensing models: per core, per socket, client access licences and subscriptions

Server software is licensed in several ways, and the model determines the cost.

• Per socket or per processor licensing charges for each physical processor in the server, however many cores it has. It was common for older server software and some hypervisors.
• Per core licensing charges for each physical processor core. It is now the most common model for server operating systems and databases, often with a minimum number of cores per processor and per server, so a small server still pays for a minimum. Windows Server is licensed this way, as the virtualisation lesson described for its Standard and Datacenter editions.
• Client access licences (CALs) cover the users or devices that connect to a server, on top of the server's own licence. They come as per user, covering one person on any number of devices, or per device, covering one device used by any number of people. Shift workers sharing a few computers suit per-device licences; staff with several devices each suit per-user licences.
• Subscriptions are paid monthly or yearly and must be renewed to keep using the software, usually including updates and support. Cloud and SaaS services are nearly always licensed this way.
• Perpetual licences are bought once and used indefinitely, though updates and support often need a separate maintenance agreement.

Open-source software such as most Linux distributions has no licence fee, but may still carry terms about redistribution, and commercial support for it is sold as a subscription.

Whatever the model, keep records of what has been bought and compare them with what is installed. Vendors audit their customers, and running more copies, cores or users than licensed produces a bill for the difference, often with penalties.

Secure storage for spares, media and documentation

Some things kept around servers need locking away.

Spare parts, such as disks, power supplies, memory and whole servers kept for fast replacement, are valuable and easy to steal. Store them in a locked room or cabinet, record them in the inventory, and keep them in suitable conditions, with disks in antistatic packaging, as the hardware lessons described.

Media is the greater risk, because it holds data: backup tapes and disks, and failed or replaced drives waiting to be destroyed. A drive pulled from a RAID array still holds its data. Keep media in locked storage with controlled access, record where each item is, and do not leave replaced drives on a desk or in a returns box to the vendor without first considering whether the data on them must be destroyed. Many support contracts offer a keep your drive option for exactly this reason.

Documentation describes how to get into every system, so printed runbooks, configuration records and password recovery material need the same protection: stored securely, with access limited to the people who need it.

Planning and budgeting a hardware refresh

Servers are usually replaced on a refresh cycle, commonly every three to five years. Waiting until a server fails is almost always more expensive: failures come at bad times, parts for old models become scarce, support contracts become costly or unavailable, and old hardware may not run supported operating system versions.

Planning a refresh involves:

• Knowing the fleet: the inventory shows each server's age, warranty expiry and support status, so replacements can be scheduled years ahead.
• Budgeting: server purchases are usually capital expenditure, so they are planned into budgets in advance, and spreading refreshes across years avoids a single huge bill.
• Capacity planning: using performance baselines and growth trends to size replacements for the load they will carry, not the load the old server had.
• Considering alternatives: consolidating several old servers into virtual machines on fewer new hosts, or moving a workload to the cloud, as the cloud lesson discussed.
• Scheduling the migration, with the planning and verification the migration lesson described, so data moves safely before the old hardware is retired.