1.8 KiB
1.8 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback_screenconnect_cleanup_wiki_source | ScreenConnect/RMM machine-metadata cleanup uses the client wiki as source of truth; enrich the wiki when info is missing |
|
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:
- 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. - 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.
- 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").
- 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.