azcomputerguru/claudetools
1
0
Fork 0
Code Issues 58 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1c038c7c2c7a250c087fb8e4235e0db6dc352c43
claudetools/clients/stamback-septic/session-logs/2026-05-05-howard-onboarding-and-joe-laptop-onedrive-fix.md
Howard Enos fd8361d0a6 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

6.9 KiB
Raw Blame History

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
Reference in New Issue View Git Blame Copy Permalink