---
name: feedback_screenconnect_cleanup_wiki_source
description: ScreenConnect/RMM machine-metadata cleanup uses the client wiki as source of truth; enrich the wiki when info is missing
metadata:
  type: feedback
---

For the ScreenConnect session-hygiene + RMM-site cleanup (per client: normalize Company,
set Site/Department/Device Type/Tag, fix RMM sites, dedup) — **the client wiki is the primary
source of truth for machine -> department / person / location.** (Howard, 2026-07-03.)

**Why:** the wiki already carries person->machine->department maps (e.g. Cascades: Ashley
Jensen->Accounting on DESKTOP-U2DHAP0, Shelby Trozzi->MemCare Director on MDIRECTOR-PC), so
department/site can be derived from it rather than guessed.

**How to apply, per client:**
1. Pull the machine metadata from the client wiki FIRST (`wiki/clients/<slug>.md` + its source docs), then hostname role tokens, then UniFi switch/AP building/area names.
2. Where a machine's department/location is NOT in the wiki, **learn it (ask the user / investigate) and UPDATE the wiki** with the finding — so the wiki becomes the durable record and the next pass is easier.
3. Slot mapping = [[reference_screenconnect_custom_property_slots]] (CP1 Company, CP2 Site, CP3 Department, CP4 Device Type, CP8 Tag). Match each client's EXISTING vocabulary (e.g. Cascades uses Device Type "Desktop"/"Laptop"/"Server", not "Workstation"; Dataforth uses "Workstation").
4. UniFi placement: Dataforth = cloud UDM via Site Manager connector; Cascades = UOS controller. AP/switch names are building/area-coded. Related: [[project_av_migration_bitdefender_to_edr]], GPS->RMM audit `projects/gps-rmm-audit/tracker.md`.

Done so far: Dataforth (D1/D2 sites split + tags), Cascades (single-site + departments). Remaining
per-client unknowns get filled from the wiki as we walk each machine; wiki gets updated when it doesn't have it.