PC fleets vs server estates: operational practices that differ in GLPI

"Endpoint" and "server" both fit the Computer object in GLPI, but treating them the same way operationally is a mistake. They have different refresh cycles, different patch windows, different criticality, different audit needs. This article is the practical split — what to configure differently in GLPI when you manage 200 office workstations vs. 15 production servers.

Refresh cadence and lifecycle states

PCs typically refresh on a 3 – 4 year cycle (laptops faster than desktops). Servers run 5 – 7 years before refresh, sometimes longer for stable workloads. In GLPI this maps to different state machines:

PC lifecycle (faster)
  Procured → In Stock → Assigned → In Use → End-of-Lease/Refresh → Retired
  Typical duration in "In Use": 3 – 4 years

Server lifecycle (slower, more states)
  Procured → Racked → Burn-in → Production → Maintenance Window →
  End-of-Support → Decommissioning → Decommissioned (data wiped) → Retired
  Typical duration in "Production": 5 – 7 years

Configure these as separate state sets per Item type (Setup → Dropdowns → States with type-specific filtering). Don't try to use one set of states for both — the server "Burn-in" and "End-of-Support" states are noise on a PC, and PC "End-of-Lease" doesn't apply to most servers.

Naming conventions

PCs are typically named for their user (NB-NOVAK, DESK-FINANCE-12). Servers need a different scheme that encodes role, environment, and instance:

PCs (user-anchored)
  Format: <type>-<user-shortcut>
  Examples: NB-NOVAK01, DESK-RECEPTION01

Servers (role-anchored)
  Format: <env>-<role>-<NN>
  Examples: PROD-DB-01, STAGE-WEB-02, DR-FILE-01
  Encodes: environment (PROD/STAGE/DR), role, instance number

In GLPI, configure the Auto-naming rules under Setup → General → Inventory with separate templates per object subtype if available, or via business rules that warn on naming-pattern violations.

Patch windows and change control

PCs patch via a Windows Update / Intune / WSUS cycle — typically Tuesday-Wednesday rolling reboot. Patches are mostly low-risk; if one breaks, blow it away and reimage. Servers patch on a planned change window, with rollback plans, validation steps, and blackout periods.

In GLPI:

• For PCs: don't gate updates through the Change module. Patches are too frequent (monthly) and low-risk. Track via Tickets if a specific patch causes incidents.
• For servers: every patch beyond critical security updates goes through a Change object with CAB validation. Link the Change to the affected server assets via the Items tab; the Change history becomes the audit trail.

GLPI Agent intervals

GLPI Agent inventory frequency should differ:

• PCs: every 24 hours is fine. People install software, change peripherals, get reassigned. The agent picks up changes overnight.
• Servers: every 4 – 12 hours, sometimes shorter. Servers' configurations are tightly controlled and unexpected changes (a new package, a config drift) are an incident signal worth catching faster.

Configure separately via the agent's --delaytime or in the agent config file pushed via Ansible/Puppet to the server fleet.

Monitoring expectations

GLPI itself isn't a monitoring system, but it's the central record that integrates with one. Patterns:

• PCs: monitoring is opportunistic — agent inventory once a day, ticket created if a user reports a problem. No proactive 24/7 watch.
• Servers: monitoring is continuous. Zabbix/Prometheus/whatever sends webhook into GLPI on threshold breach, auto-creating an incident with the affected server linked. See the REST API + webhooks guide for the mechanics.

Audit cadence

Physical audits — walking around with a barcode scanner — happen on different cadences:

• PCs: annually, ideally during a low-activity period (summer, between fiscal year-end and budget kick-off). Aim for 95%+ reconciliation rate. Use the barcode/QR workflow.
• Servers: continuous. Servers don't move; the rack location in GLPI should always match physical reality. A walk-around every six months catches the rare case (decommissioned but not yet removed, replacement that wasn't recorded).

Decommissioning rigor

The end-of-life process differs sharply:

• PC retirement: data wipe (DBAN or vendor tool), asset state to "Retired", financial asset register update, donation/disposal route logged. 30 minutes of process per device.
• Server decommissioning: a project. Stakeholder sign-off (who depends on this server?), grace period (1 – 4 weeks of "shutdown but not unracked" so dependencies surface), dependent services migrated, configs archived, certificates revoked, DNS records cleaned, then physical removal and disposal. Several days to weeks of process per server.

In GLPI, server decommissioning warrants its own Change object with a checklist and validations. PC retirement is fine as a Ticket of type Request.

What stays the same

Despite the differences, both categories benefit from common GLPI hygiene: accurate inventory via the agent, contracts attached to assets, ticket history linked to specific items, audit logs preserved. The differences are in the cadence and rigor, not the underlying data model. One GLPI instance handles both — the configuration is what splits them. For specifics on getting started see the inventory bootstrap guide.