Leaving the server room, the engineer runs the checklist's final sweep: service tags recorded, photographs taken, serials listed. A colleague suggests doing that later from the shipping paperwork at the hotel. Why does the checklist make it an on-site sweep?
Select an answer to reveal the explanation.
Short Explanation
There's a moment in every install when the units are powered, labeled and right in front of you—and it never comes back. Capture those tags while you're standing there, because a missing serial after handover costs someone an extra trip to the site.
Full Explanation
Identification records—service tag and serial for each chassis, head and every expansion shelf—anchor every future support case, part claim and warranty check; the checklist captures them on site because that is the last moment labels and record are guaranteed to coexist. Shipping paperwork travels separately and can misdescribe what was actually racked after substitutions or partial deliveries; reading the label at the rack ties the paper to the metal. The vendor-tooling objection fails by concept: service tags are human-readable labels designed exactly for transcription—tooling is an optional aid, never a gatekeeper. 'DD OS makes physical tags obsolete' fails because a unit that will not boot, or a shelf with no live network path, still needs a support case, and the only identifier then is the photographed label; hardware paperwork is keyed to the tag, not the console. The paint-scan theory fails because the sweep collects evidence the record needs—tags, rack-position and cabling photos—not decoration. Exam caveat: configuration output does display system identifiers once the system is reachable, which supplements but never replaces the physical record. Operational check: photograph each label together with its rack position, transcribe into the checklist's table, reconcile against the receiving paperwork, and resolve any mismatch before leaving the site.