sync: auto-sync from GURU-5070 at 2026-06-15 11:20:33

Author: Mike Swanson Machine: GURU-5070 Timestamp: 2026-06-15 11:20:33
2026-06-15 11:20:52 -07:00
parent 5f4a2b1eca
commit 6e1c65877f
14 changed files with 585 additions and 7 deletions
--- a/clients/russo-law/session-logs/2026-06/2026-06-15-mike-russo-sharepoint-storage-eval.md
+++ b/clients/russo-law/session-logs/2026-06/2026-06-15-mike-russo-sharepoint-storage-eval.md
@@ -0,0 +1,77 @@
+## User
+- **User:** Mike Swanson (mike)
+- **Machine:** GURU-5070
+- **Role:** admin
+
+## Session Summary
+
+First documented ClaudeTools record for **Russo Law Firm** (Tucson personal-injury / law
+practice). Triggered by a pre-sales question: the client wants to **move ~6.5 TB of data from
+ACG-hosted Seafile into Microsoft 365 SharePoint**, and Mike needs the cost to quote them. A
+phone meeting is being scheduled; as of 2026-06-15 the client has not responded to the meeting
+request. Pulled their live Syncro record, evaluated the SharePoint storage economics, vaulted a
+plaintext M365 admin credential found in the Syncro notes, and built the initial wiki article.
+
+## Syncro snapshot (customer 23331699)
+
+- **Business:** Russo Law Firm — 3505 N Campbell Ave, Tucson, AZ 85719 — main 520-529-1515
+- **Account contact:** Shannon Trionfo (stever@rrs-law.com on the account; mobile 520-248-0244)
+- **Contacts:** Steve Russo (520-975-9024), Carolyn Russo (520-591-4303),
+  Pat Broom (pebroom@rrs-law.com, 520-850-6832), Shannon Trionfo (520-248-0244)
+- **Prepaid:** 12.0 hrs (notes: moved 13.5 hrs to Syncro 1/16/26; 17.5 hrs to AT 8/15/25)
+- **Recurring billing:**
+  - Sched **509659** "GPS + AV / data backup / Hosting / Office subs" — Monthly, next 2026-06-24,
+    **$543.50/mo** (this is the managed bundle; the "Hosting" line is the ACG-hosted Seafile data store)
+  - Sched **499925** "OIT Phone bill" — Monthly, next 2026-07-01, **$45.44/mo** (OITVOIP/PacketDial)
+- **Email:** Microsoft 365, tenant **rrs-law.com** (~3 seats, Exchange Online)
+- Note: Russo schedule 224454 was deleted during Syncro API research 2026-05-26 and recreated as 509659.
+
+## SharePoint storage cost evaluation (the deliverable for the call)
+
+Client scenario: **3 M365 seats, ~6.5 TB of data, currently in Seafile**, wants to move to SharePoint.
+
+M365 SharePoint pooled storage = 1 TB base + 10 GB/licensed user. At 3 seats that's only ~1.03 TB
+included, so almost all 6.5 TB is billable overage.
+
+Microsoft-only options (per client request to keep the comparison MS-only):
+| Option | Rate | ~Monthly for 6.5 TB (3 seats) | Notes |
+|---|---|---|---|
+| **SharePoint Online "Extra File Storage"** | $0.20/GB/mo | **~$1,120/mo (~$13.4K/yr)** | live storage; ~5.47 TB billable after the ~1.03 TB pool. CSP-monthly +20% => ~$1,345/mo |
+| **Microsoft 365 Archive** | ~$0.05/GB/mo | ~$333/mo + retrieval fees | cold/inactive sites only; not for live working data |
+| **Self-hosted SharePoint Server (Subscription Edition)** | storage = disk (RBS) | licensing + infra + labor | storage escapes the $0.20/GB tax, but SharePoint Server + SQL + Windows licensing + SA + heavy ongoing ops is wildly disproportionate for 3 users (~$8-15K one-time licensing + hardware + setup + monthly maintenance). Not recommended. |
+
+Context / alternatives (for ACG's internal read, not necessarily quoted MS-only):
+- They already have what they need in **Seafile** (ACG-hosted, part of the $543.50/mo bundle).
+- Backblaze B2 wholesale (~$0.006/GB) = ~$40/mo for 6.5 TB at ACG cost; a managed-archive resell
+  at e.g. $0.03/GB (~$200/mo) is ~5-6x cheaper than Microsoft and still healthy margin.
+
+**Recommendation / talking points for the call:**
+1. Ask **why SharePoint** — a specific feature (Office co-authoring, Teams), or just "we want SharePoint"? Decides everything.
+2. Moving all 6.5 TB live into SharePoint is a **~$1,100/mo new line item (~$13.4K/yr)** — roughly
+   triples their current ACG monthly. Make sure they understand that before committing.
+3. Better path if they want the SharePoint UX: put the **working subset in SharePoint Online**
+   (fits in/near the included pool) and **keep the 6.5 TB bulk in Seafile, linked** from SharePoint.
+4. If they just want files-with-web-access, they already have Seafile — no change needed.
+5. Self-hosting SharePoint Server is not worth it for 3 seats.
+
+## Credentials & Secrets
+
+- **M365 Global Admin (rrs-law.com tenant):** `guru@rrs-law.com` — found in PLAINTEXT in the Russo
+  Syncro customer note. **Vaulted** at `clients/russo-law/m365-admin.sops.yaml` (username/password
+  under `credentials:`; MFA/2FA held by Mike). **TODO: scrub the plaintext password from the Syncro
+  customer note** now that it's vaulted.
+
+## Pending / Incomplete Tasks
+
+- Client has **not responded** to the meeting request (phone meeting being scheduled).
+- Scrub the M365 admin password from the Syncro customer 23331699 note (now vaulted).
+- On the call: confirm the "why SharePoint", present the cost, steer toward the hybrid (SP Online
+  working set + Seafile bulk) unless a hard requirement forces a full move.
+
+## Reference Information
+
+- Syncro customer: https://computerguru.syncromsp.com/customers/23331699
+- Schedules: 509659 (managed $543.50/mo), 499925 (OIT phone $45.44/mo)
+- M365 tenant: rrs-law.com (~3 seats, Exchange Online)
+- Generic MS storage pricing used: SharePoint pool = 1 TB + 10 GB/user; Extra File Storage
+  $0.20/GB/mo (CSP-monthly ~$0.24/GB); M365 Archive ~$0.05/GB + retrieval. Verify current MS pricing.
--- a/clients/valleywide/session-logs/2026-06/2026-06-15-mike-vwp-files-single-home-scan-fix.md
+++ b/clients/valleywide/session-logs/2026-06/2026-06-15-mike-vwp-files-single-home-scan-fix.md
@@ -0,0 +1,69 @@
+## User
+- **User:** Mike Swanson (mike)
+- **Machine:** GURU-5070
+- **Role:** admin
+
+## Session Summary
+
+Fixed Valley Wide Plastering's copier/scanner (Brother MFC-L3780CDW) scan-to-folder, which had
+stopped working after the 2026-06-13 G: file-share migration. Root cause: **VWP-FILES was
+multi-homed** (`192.168.0.20` on VLAN 2 + `172.16.9.132` on the new net), and a Windows host
+realistically supports one default gateway — only the `.132` NIC had one (`172.16.9.1`). So
+cross-VLAN traffic to `.20` arrived on the `.20` NIC but the reply egressed via the `.132`
+default-gateway path, and the UDM dropped the asymmetric return. `.20` was therefore unreachable
+from any other VLAN (proved: `.20` was silent from the VPN pool while `.25`/`.132` answered). The
+copier reaches `\192.168.0.20\<share>` across a VLAN boundary, so it broke.
+
+The previously-documented "VWP-FILES Dual-NIC / asymmetric-routing / same-VLAN-only" note was a
+**flawed workaround, not a real constraint** — the UDM routes every VLAN natively (Mike's
+correction). Fix: **single-home VWP-FILES on `.20`** and drop `.132`.
+
+## What was done
+
+Diagnostics (read-only): from ADSRVR (a VLAN-2 server) confirmed every VLAN was reachable, SMB
+tcp/445 up on `.20`, the `scanner` AD account enabled/unlocked, and all 19 shares present
+(`\.20\SCANS` + per-person scan shares). Confirmed the **real VLAN-2 gateway is `192.168.0.1`**
+(ADSRVR's gateway) — the wiki said `172.16.9.1`, which was wrong.
+
+Attempt 1 (in-guest via RMM): set `.20` gw `192.168.0.1` + DNS, disabled `.132`. Disabling the
+NIC dropped the agent's own connection -> command came back `interrupted`, script killed before
+confirming success, and the 7-minute **auto-rollback** task fired and re-enabled `.132` (box
+healthy, but back to dual-homed). Lesson: an in-guest NIC change self-interrupts the RMM agent.
+
+Final fix (host-side, per Mike's Hyper-V suggestion): via the **VWP-HYPERV1** RMM agent,
+`Disconnect-VMNetworkAdapter` on VWP-FILES's `.132` vNIC (`Network Adapter`, MAC `00155D090501`),
+keeping the `.20` vNIC (`OldNet-VLAN2`, MAC `00155D090502`). Completed cleanly (the host's RMM
+connection is unaffected by the guest's NIC change). Then cleaned the guest's stale `.132`
+IP/route and `ipconfig /registerdns`.
+
+Verified: `.20` now **reachable cross-subnet from the VPN** (was failing pre-fix); single default
+route `.20 -> 192.168.0.1`; `VWP-FILES` resolves to `.20` only; 19 shares intact.
+
+## Key facts / corrections
+
+- **VWP-FILES is now single-homed: `192.168.0.20`, gw `192.168.0.1`, DNS `172.16.9.2` + `192.168.0.25`.**
+- The `.132` vNIC is **DISCONNECTED at the Hyper-V host (reversible), not removed.**
+- **Old Net (VLAN 2, `192.168.0.0/24`) gateway is `192.168.0.1`** — the wiki's `172.16.9.1` was wrong.
+- Scanner = **Brother MFC-L3780CDW** (vault `clients/vwp/brother-mfc-l3780cdw`); scans to
+  `\192.168.0.20\<share>` (shares map under `G:\SCANS\...`).
+- RMM agents: VWP-FILES `8e02fbbc`, VWP-HYPERV1 `bdc3e142`.
+
+## Gotchas learned
+
+- **In-guest RMM NIC changes self-interrupt** (the change drops the agent connection). For VM NIC
+  changes, drive it **host-side** (`Disconnect-VMNetworkAdapter` / PowerShell Direct) so the host
+  connection survives. Keep an auto-rollback timer either way.
+- `/rmm` hostname match `"hyperv"` hit **DF-HYPERV-B** (Dataforth) first — must resolve
+  `VWP-HYPERV1` explicitly. The script's guard aborted safely on the wrong host (no changes).
+
+## Pending / Incomplete
+
+- Have someone **confirm an actual scan** from the Brother copier (only thing not driveable remotely).
+- Decide whether to **fully remove** the disconnected `.132` vNIC or leave it (currently left, reversible).
+- Harmless leftover on VWP-FILES: `C:\Windows\Temp\vwp-net-rollback.ps1` (from attempt 1).
+
+## Reference
+
+- VWP-FILES: single-homed `192.168.0.20`, gw `192.168.0.1`. RMM agent `8e02fbbc`.
+- VWP-HYPERV1: `172.16.9.184`, RMM agent `bdc3e142`. VWP-FILES vNICs: `Network Adapter`(.132,
+  disconnected) / `OldNet-VLAN2`(.20).