diff --git a/clients/stamback-septic/session-logs/2026-05-05-howard-onboarding-and-joe-laptop-onedrive-fix.md b/clients/stamback-septic/session-logs/2026-05-05-howard-onboarding-and-joe-laptop-onedrive-fix.md
new file mode 100644
index 0000000..1ffb871
--- /dev/null
+++ b/clients/stamback-septic/session-logs/2026-05-05-howard-onboarding-and-joe-laptop-onedrive-fix.md
@@ -0,0 +1,98 @@
+# 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`