Files
claudetools/clients/stamback-septic/session-logs/2026-05-05-howard-onboarding-and-joe-laptop-onedrive-fix.md
Howard Enos a3c15f4c2e sync: auto-sync from HOWARD-HOME at 2026-05-05 16:31:33
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-05-05 16:31:33
2026-05-05 16:31:34 -07:00

99 lines
6.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Stamback Septic — Onboarding to GuruRMM + Joe's laptop OneDrive fix (Ticket #32234)
**Date:** 2026-05-05
## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech
## Summary
First Stamback Septic engagement under the new GuruRMM tenant. Created the GuruRMM client + site for Stamback, scaffolded the in-repo client folder, and resolved a OneDrive sign-in failure on Joe Schmuker's newly-cloned laptop. Billed Syncro ticket #32234 at 2 hours; Syncro auto-applied 2 prepay hours so invoice #67562 posted at $0.00.
## What was done
### 1. GuruRMM client + site provisioning
| Resource | Value |
|---|---|
| Client | Stamback Septic — id `b3ba0e60-6132-4403-888b-601054ed4a9a`, code `STAM` |
| Site | StambackSeptic — id `0f3abe88-834f-4943-b28f-e97c236a0fea`, site_code `SOUTH-PHOENIX-4306` |
| Agent enrollment API key | encrypted at `clients/stamback-septic/gururmm-site-main.sops.yaml` (vault) |
Notes added to client: business address, phones, primary contact (Joe Schmuker), Syncro customer ID `11513046`, Emsisoft license `PAK-MIV-BAN-843`, customer-since 2018-01-09.
Possible Syncro duplicate `34021422` (Joseph Schmuker / `js.stambackseptic@gmail.com`, no business linked) flagged in CONTEXT.md but not merged.
Also created in-repo `clients/stamback-septic/` scaffold: CONTEXT.md plus `session-logs/`, `reports/`, `scripts/`, `docs/`.
### 2. Diagnosed OneDrive failure on cloned laptop
Agent: `StambackLaptopNew` (id `4b6e9b9e-b7bb-4a91-836d-c3ce11fbb9c3`), Windows 11 26200, single local profile `Owner` SID `S-1-5-21-3261765575-2461346130-2085639809-1001`. Not joined to anything (`dsregcmd /status` showed AzureAdJoined/EnterpriseJoined/DomainJoined/WorkplaceJoined all NO).
OneDrive HKCU was configured for `joe.schmuker@fusionsite.com` (FusionSite tenant `3dd7fc1e-7d46-4e83-931a-8abe57a8bc73`) but the supporting auth caches were tangled across **three identities and four tenants**:
- OneAuth `_identity_provider` blobs for `joe@stambackservices.com`, `info@stambackservices.com`, `JSchmuker@fusionsiteservices.com`
- HRD blobs for tenants `3dd7fc1e-...` (FusionSite), `71f04345-...` (unknown legacy), `9188040d-...` (consumer), plus domain HRD for fusionsiteservices.com and stambackservices.com
- Office Identity trusted-site cache held azcomputerguru.sharepoint.com, stambackseptic{,-my}.sharepoint.com, fusionsite{,-my}.sharepoint.com
- Office WAM `ConnectedAccountWamAad = 8f71d2f7-...` while OneDrive Business1 expected `6c79ea7f-...` — different identities
- `OneAuth\credentials\` only had a refresh token for the personal MSA (`72b39fa78d22f824_RefreshToken`); the work-account refresh token was missing — DPAPI-bound state from the source machine couldn't be decrypted post-clone, so OneDrive couldn't sign in silently
### 3. Identity wipe (OneDrive + Office) on Owner profile
Backups taken first, on-laptop at `C:\Windows\Temp\onedrive_cleanup_backup\`:
- `HKCU_OneDrive.reg` (18.5 KB)
- `HKCU_Office_Identity.reg` (50 KB)
Then wiped:
- HKCU `\Software\Microsoft\OneDrive\Accounts` (full subkey)
- HKCU `\Software\Microsoft\Office\16.0\Common\Identity\{Identities,Profiles,OneAuthConfigCache,ServiceAuthInfoCache,SPOCookieCache,DocToIdMapping}`
- HKCU Identity values: `ConnectedWAMIdentity`, `ConnectedAccountWamAad`, `SignedOutWAMUsers`, `TrustedSiteUrlForUserAgentVersionInfo`
- `C:\Users\Owner\AppData\Local\Microsoft\OneAuth\` (whole tree)
- `C:\Users\Owner\AppData\Local\Microsoft\OneDrive\settings\Business1\` and `\Personal\`
- 19 `.tbres` files in `\Microsoft\TokenBroker\Cache\`
Killed OneDrive (PID 9916) and FileCoAuth (PID 12416) before file ops; ran `OneDrive.exe /reset`. The `/reset` left the agent's command processor wedged for ~15 min — recovered on laptop reboot.
### 4. First sign-in attempt failed → root cause
After cleanup, Joe got `[657rx] / 0x8029040E` ("something went wrong") on sign-in. Cause: he checked **"Allow my organization to manage my device"** at the prompt, which triggered a full Azure AD device-join attempt against FusionSite. FusionSite's tenant rejected the join (likely Conditional Access requiring compliant/Hybrid-joined device, which a freshly cloned untrusted laptop fails).
**Fix:** Joe signed out from the prior failed attempt under Settings → Accounts → Access work or school, then re-signed into OneDrive **without** the manage-device checkbox (i.e. "OneDrive app only"). Sync started normally.
### 5. Billing — Syncro ticket #32234
| Field | Value |
|---|---|
| Customer | Stamback Septic (11513046) |
| Tech (timer attribution) | Howard Enos (1750) |
| Product | `1190473` Labor - Remote Business |
| Quantity | 2.0 hrs |
| Rate | $150.00/hr |
| Timer interval | 2026-05-05 12:00 14:00 PT (billable=true) |
| Invoice | #67562, total **$0.00** |
| Prepay applied | **2.0 hrs** auto-debited |
| Stamback prepay balance | 5.5 → **3.5 hrs** |
| Ticket status | Invoiced |
Mike initially thought Stamback had no prepaid hours (didn't see them in the GUI) and authorized regular remote billing. Syncro auto-applied prepay at invoice creation, dropping the line to $0. After review Mike confirmed the prepay was correct and the invoice was left as-is.
## Lessons / follow-ups
- **GuruRMM agent task queue can wedge** when a child process spawned by a remote command (e.g. `OneDrive.exe /reset`) doesn't exit cleanly. Symptom: agent stays "online" but new commands sit pending forever. Resolution: laptop reboot. Worth tracking — if this is a common pattern, it deserves a check-and-clear hook in the agent.
- **Cloning + multi-tenant identity history is messy.** Joe's source machine had identity caches across at least three tenants that never got cleaned up over time. Future clones for users with M365 history should plan for an OneDrive/Office identity reset as a routine post-clone step, not a troubleshooting one.
- **Prepay visibility in Syncro:** the customer page sometimes hides the prepay block depending on view. Always verify via API (`GET /customers/{id}``.customer.prepay_hours`) before billing. Trust the API field over the GUI eyeball.
- **Billing prepay customers:** even when using `1190473` (Remote @ $150), Syncro will auto-apply prepay at invoice-time as a flat hour-for-hour debit. To bill at full rate without touching prepay you have to either zero out the prepay first or use a non-applicable product.
## Note for Mike
I left the invoice and ticket as Invoiced per your call. Stamback's prepay block now reads 3.5 hrs in Syncro — confirm visibility next time you're on the customer page so we both know where to look. Backups for the registry wipe are at `C:\Windows\Temp\onedrive_cleanup_backup\` on Joe's laptop if you ever need to roll back the identity cleanup; suggest leaving them in place for ~30 days then clearing.
## References
- Ticket: https://computerguru.syncromsp.com/tickets/109750752
- Invoice: #67562 (id 1650206182)
- GuruRMM client: `b3ba0e60-6132-4403-888b-601054ed4a9a`
- GuruRMM site: `0f3abe88-834f-4943-b28f-e97c236a0fea`
- Vault entry: `clients/stamback-septic/gururmm-site-main.sops.yaml`