# 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`