Naming, tagging and recording a new server: a methodology for hostnames and inventory

Goal

Give a newly provisioned server a name that follows a documented convention, and record enough metadata that someone other than its builder can identify its owner and purpose later.

Prerequisites

A naming convention agreed on in advance, for example <environment>-<role>-<sequence> such as prod-web-03 (keep Windows names to 15 characters for NetBIOS); an inventory system to record the result — a configuration management database, a spreadsheet, or tags on the cloud resource itself all satisfy this as long as one of them is authoritative.

Steps

1. Decide the hostname before first boot where possible; changing it after services and certificates reference the old name is more disruptive than setting it correctly up front.
2. On Linux, run hostnamectl set-hostname <new-name> as root. This works on every systemd version. systemd's v249 release notes replaced the get-xyz/set-xyz verbs with single verbs such as hostnamectl hostname, and "the old names continue to be supported for compatibility", but the new form fails on systemd older than 249 (for example RHEL 8, Debian 11, Ubuntu 20.04). Both forms set the static, transient and pretty names. Update the /etc/hosts entry for the old name yourself (Debian/Ubuntu map it to 127.0.1.1). On cloud-init images, set preserve_hostname: true or supply the name in user-data, otherwise cloud-init may reset it at boot. Confirm with hostnamectl status.
3. On Windows, set it with Rename-Computer -NewName "<new-name>" -Restart. The cmdlet "renames the local computer or a remote computer," is available from PowerShell 3.0 onward, and needs a restart to take effect; -Restart restarts the computer immediately after the rename.
4. Record, in the authoritative inventory, at minimum: hostname, owner (a team or a named individual, not "whoever built it"), purpose/role, environment, creation date, and the provisioning method used (image name/version, or the automation run that created it).
5. Tag the underlying resource itself where the platform supports it (cloud provider tags, hypervisor annotations, DNS record comments) so the metadata travels with the resource even if the separate inventory system falls out of sync.
6. Verify the name is resolvable where it needs to be: forward and reverse DNS for network-facing conventions, or at minimum that monitoring and configuration management systems pick up the new name rather than a stale one cached from provisioning.

Expected result

hostnamectl status (Linux) or $env:COMPUTERNAME / Get-ComputerInfo (Windows) shows the intended name after any required restart; the inventory record for that hostname exists and names an owner and purpose without needing to ask anyone.

Limits and test basis

Renaming a domain-joined Windows computer requires appropriate Active Directory permissions and, per Microsoft's documentation, accepts domain credentials via -DomainCredential when the account running the command differs from one with rights to update the computer object; renaming after domain join is supported but should be paired with the same verification of DNS and Kerberos SPNs used for any domain computer object change. On Linux, hostnamectl changes the running (transient) hostname immediately along with the static one, but already-running services that cached the old name at their own startup may need a restart to notice the change — a reboot guarantees consistency but is not strictly required for the hostname change itself.