Assigning endpoints to clients, sites and owners

Endpoints normally land in the right place at enrolment because the install token carries the client and site. Reassignment is for the cases enrolment cannot anticipate: a machine moving office, a department reorganising, a device reassigned to a new owner, or a client acquiring another.

Reassign in the console rather than by re-enrolling. Re-enrolment with a different token creates a discontinuity — you keep the machine but lose the continuity of its record, which is precisely the thing that made the record worth keeping.

When you move a machine between clients, think about what should move with it. Inventory and health history describe the machine and travel naturally. Ticket history describes a relationship with the previous client and generally should not be surfaced to the new one. Contract and licence associations almost never survive a client move intact and should be reviewed explicitly.

Bulk moves are the right tool for an office relocation or a departmental restructure, and the wrong tool for tidying. If you find yourself bulk-moving endpoints regularly, the structure is probably modelled at the wrong granularity — usually too fine — and the fix is to simplify the structure rather than to keep correcting its contents.

Owner assignment matters more than it appears to. An endpoint with a named owner is one you can ask about; an unowned endpoint accumulates uncertainty until someone eventually proposes decommissioning it and nobody is confident enough to agree. Keeping ownership current is cheap; reconstructing it later is not.