Files
claudetools/clients/glaztech/session-logs/2026-06-03-sbs-mspbackups-removal.md
Mike Swanson 6de0ce6098 sync: auto-sync from GURU-5070 at 2026-06-03 11:52:45
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-03 11:52:45
2026-06-03 11:52:52 -07:00

91 lines
3.2 KiB
Markdown

# Session: 2026-06-03 - Remove SBS from mspbackups for Glaztech
**User:** Mike Swanson (mike)
**Machine:** GURU-5070
**Role:** admin
## Session Summary
Removed the SBS computer entry from MSP360/mspbackups for Glaztech Industries. This is the computer with MSP360 UserID d425fbbe-43f6-4fb7-8695-a9296b762a3b, ComputerName SBS, backup destination ACG-GLAZTECH (233GB used).
Followed locate-confirm-execute: used GrepAI, MSP360 API (as documented in 2026-06-01 session log), vault, B2 for verification (read-only).
Disabled the user via MSP360 API PUT /api/Users Enabled=false, then DELETE /api/Users/{id} (both 200).
This should trigger chained B2 data deletion for prefix MBS-d425fbbe-43f6-4fb7-8695-a9296b762a3b/CBB_SBS/ in ACG-GLAZTECH bucket. Did not touch B2 data directly.
## Key Decisions
- Removal only via MSP360 API (computer entry), per user clarification that license is expired, and removal triggers B2.
- Used MSP360 API with fresh token from /api/Provider/Login using vault creds.
- Claimed coord lock on clients/glaztech mspbackups/SBS.
- Snapshot: MSP360 user state (before/after Enabled), B2 files under prefix (still present), Monitoring still showed plan.
- No RMM agent found for SBS in glaztech (searches in code and API queries showed other GTI- machines).
- Documented in clients/glaztech/session-logs/
## Problems Encountered
- No active LicenseID found for SBS in current /api/Licenses (consistent with expired trial from report).
- MSP360 DELETE /api/Users/{id} succeeded 200 but entry still queryable with Enabled=false (soft delete/queue like vland example in docs).
- B2 deletion is asynchronous via MSP360 portal processing.
## Configuration Changes
- MSP360: User d425fbbe-43f6-4fb7-8695-a9296b762a3b set Enabled=false via PUT, then DELETE called.
## Commands & Outputs
(See tool calls in transcript for full API queries, vault, b2 lists, coord lock/release.)
Key:
- Vault get-field msp-tools/msp360-api.sops.yaml credentials -> login kY9PvDdWki password p9wzJFRT8nC6VfFz6UDZ
- Login POST -> token
- GET /api/Users -> found SBS entry
- GET /api/Monitoring -> showed plan for SBS, last backup 2026-05-08
- PUT /api/Users {"ID": "d425fbbe-43f6-4fb7-8695-a9296b762a3b", "Enabled": false} -> 200
- Re-GET user -> Enabled: false
- DELETE /api/Users/d425fbbe-43f6-4fb7-8695-a9296b762a3b -> 200
- B2: py ... b2.py files ACG-GLAZTECH --prefix MBS-d425fbbe-43f6-4fb7-8695-a9296b762a3b/CBB_SBS --limit 10 -> listed files (still there)
- Coord: POST lock, later DELETE release.
## Pending
- Monitor MSP360 portal / B2 for deletion progress of the SBS computer and its backup data in ACG-GLAZTECH.
- If RMM has mapping for glaztech SBS backup, reconcile (no current agent found).
- Update glaztech wiki/clients/glaztech.md if infrastructure changes documented.
## References
- MSP360 API usage: session-logs/2026-06-01-session.md (detailed commands, endpoints, vault, cross-ref)
- B2 mspbackups: .claude/skills/b2/SKILL.md
- Client context: wiki/clients/glaztech.md , clients/glaztech/
- Coord lock: released dcf3c54c-840a-4131-a653-69857bdeac45
- SPEC-023 for future automation: projects/msp-tools/guru-rmm/docs/specs/SPEC-023-msp360-license-release-on-decommission.md
## User
- **User:** Mike Swanson (mike)
- **Machine:** GURU-5070
- **Role:** admin