sync: auto-sync from GURU-5070 at 2026-06-23 09:59:34

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-23 09:59:34

clients/valleywide/session-logs/2026-06/2026-06-23-mike-vwp-smb1-orders-xp-g-drive.md

@@ -0,0 +1,112 @@
+# VWP — Orders/G: access restored for legacy XP app VM (enabled SMB1 on VWP-FILES) — #32448
+
+## User
+- **User:** Mike Swanson (mike)
+- **Machine:** GURU-5070
+- **Role:** admin
+
+## Session Summary
+
+Reported issue: "Teresa on the payroll machine can't access G:" (Syncro #32448 — "Teresa can not
+access Orders. This seemed to have started when the G drive was moved. Also, excel spread sheets
+load slowly."). Worked the diagnosis through GuruRMM (all VWP servers/workstations are enrolled
+except the legacy VMs).
+
+Identified the payroll machine as **DESKTOP-2R13CC4** (Syncro asset tagged "payroll"; the
+logged-in account is literally `VWP\payroll`; Teresa = **Teresa Capio / Tcapio** per Mike). On
+that desktop the G: drive was actually healthy — `net use` showed `G: -> \\VWP-FILES\G-drive` OK,
+`G:\` and `G:\VWP2` accessible as the user, Orders_10A.exe present, share + NTFS permissions wide
+open (Everyone/Domain Users Full). So the payroll desktop was a red herring.
+
+Mike clarified Orders does not run on the desktop — it runs on a **legacy Windows XP VM** that
+Theresa RDPs into (her RDP MRU pointed at several Old-Net hosts). The XP VM is **`V-XP`** (in AD;
+not GuruRMM-enrollable). Root cause: the new file server **VWP-FILES** (Server 2019, stood up in
+the 2026-06-13 G: migration off the retired SERVER3) ships with **SMB1 disabled**, and Windows XP
+speaks only SMB1 — so the XP Orders VM could no longer reach `\\VWP-FILES\G-drive` (the old
+SERVER3 had SMB1). Excel-loads-slowly was the same dead-old-server timeout.
+
+Fix (Mike + client approved, done now): enabled the **SMB1 server** optional feature on VWP-FILES
+(server-only intent; `-All` also pulled in the client sub-feature), rebooted (fast bounce,
+~uptime 0.3 min), and confirmed `EnableSMB1Protocol=True`, `srv` driver Running, G-drive share
+present. Mike confirmed the XP VM then authenticated and Orders tested working. Billed 1 hr
+emergency remote (prepaid emergency = product 26184 @ qty 1.5), invoice $0, prepaid block
+19.0 -> 17.5, resolution comment posted, ticket Resolved, #bot-alerts posted.
+
+## Key Decisions
+- **Enable SMB1 on VWP-FILES** to support the legacy XP Orders VM — explicit Mike + client
+  approval. Accepted security tradeoff: SMB1 is the EternalBlue/WannaCry protocol; scoped to the
+  internal Old-Net (VLAN 2) for one legacy app. Tracked as tech-debt to remove once Orders is off
+  XP (the ORDERS modernization project).
+- **Diagnosis via GuruRMM agents** (DC for AD lookups, VWP-FILES for share/ACL, payroll desktop in
+  user_session for the real user view) rather than assuming — proved the desktop G: was fine and
+  the failure was the XP VM's SMB1 dependency.
+- **Billing product 26184 (not the VWP wiki's 1190473 ×2):** per the `/syncro` command (newer,
+  authoritative; updated 2026-05-27) prepaid emergency = 26184 @ qty actual×1.5. Same 1.5 hr block
+  deduction either way; 26184 keeps the QuickBooks line labeled "Emergency." The VWP wiki's
+  emergency-billing note is stale and should be corrected on the next wiki compile.
+
+## Problems Encountered
+- **Wrong initial target.** "Machine with payroll in it" + "can't access G:" first pointed at the
+  payroll desktop, where G: was healthy. Mike's correction (Orders runs on a Win7 VM -> actually an
+  XP VM) redirected to V-XP. Lesson: for "can't access Orders," confirm WHERE Orders executes
+  before diagnosing the user's desktop.
+- **SMB1 component not installed (not just disabled).** `FS-SMB1` was "Available", `srv` driver
+  absent — so enabling required installing the optional feature, which needs a reboot of the main
+  file server (scheduled/approved, fast bounce). `Enable-WindowsOptionalFeature SMB1Protocol-Server`
+  failed until `-All` was added (parent `SMB1Protocol` was disabled).
+- **`-All` enabled the SMB1 client sub-feature too** (wanted server-only). Minor extra exposure;
+  hardening follow-up: disable `SMB1Protocol-Client` on VWP-FILES.
+
+## Configuration Changes
+- **VWP-FILES (192.168.0.20, Server 2019):** enabled Windows optional feature
+  `SMB1Protocol-Server` (+ parent `SMB1Protocol`; `-All` also enabled `SMB1Protocol-Client`),
+  rebooted, `Set-SmbServerConfiguration -EnableSMB1Protocol $true`. Now: EnableSMB1Protocol=True,
+  srv driver Running. (Reversible: `Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol`.)
+- No changes to shares/permissions (already correct: G-drive share = G:\, Everyone + Domain Users
+  Full at share and NTFS).
+- Syncro #32448: line item 42980555 (26184, qty 1.5, $225 cosmetic), invoice 1650772624 ($0),
+  invoice note "Block hours remaining: 17.5.", resolution comment 420351873, status Resolved.
+
+## Credentials & Secrets
+- None created. Read-only vault use: `services/gitea` token (unrelated, prior task). No VWP creds
+  changed. SMB1 work + diagnostics done via the GuruRMM agents (SYSTEM) — no interactive creds used.
+
+## Infrastructure & Servers
+- **VWP-FILES** 192.168.0.20 (Server 2019 VM on VWP-HYPERV1) — G: file server, GuruRMM agent
+  `8e02fbbc-0db1-4044-b4c2-b0732d64f029`. SMB1 server NOW ENABLED (for legacy XP).
+- **V-XP** — legacy Windows XP VM running the Orders (VB6/Jet) app; in AD (`VWP.US`), NOT in
+  GuruRMM. Theresa RDPs to it as VWP\Payroll. Orders lives at `G:\VWP2\Orders_10A.exe`.
+- **DESKTOP-2R13CC4** — the "payroll" desktop (Syncro asset 9737646), logged-in user VWP\payroll
+  (SID ...-1140), GuruRMM `5b785378-8ec2-43f2-98ad-17cf770afc5f`. G: healthy.
+- VWP-FILES G: shares: G-drive(G:\), Orderss(G:\), HD2(G:\), VWP2(G:\VWP2), SCANS + per-user SCANS
+  subshares. Old Net = VLAN 2 192.168.0.0/24.
+- VWP Syncro customer 31694734 (prepaid block now 17.5 hrs). DC used for lookups: VWP_ADSRVR
+  (192.168.0.25) GuruRMM `bd2f2f86-ea33-4202-828f-b378e459e891`.
+
+## Commands & Outputs
+- SMB1 enable (VWP-FILES, via RMM): `Enable-WindowsOptionalFeature -Online -FeatureName
+  SMB1Protocol-Server -All -NoRestart` -> RestartNeeded True; reboot; verify
+  `(Get-SmbServerConfiguration).EnableSMB1Protocol` = True, `Get-Service srv` Running.
+- User-context proof on payroll desktop: `query user` -> payroll active; `net use` -> G: OK;
+  Test-Path G:\VWP2 True.
+- XP fix (handed to client / done on V-XP): `net use G: /delete` then
+  `net use G: \\VWP-FILES\G-drive /persistent:yes` (or `\\192.168.0.20\G-drive`).
+- Billing: add_line_item 26184 qty 1.5; POST /invoices -> $0; prepay 19.0->17.5; PUT status Resolved.
+
+## Pending / Incomplete Tasks
+- **Hardening:** disable `SMB1Protocol-Client` on VWP-FILES (server-only was the intent; `-All`
+  enabled client). Needs another reboot — batch with a future maintenance window.
+- **Tech-debt / strategic:** SMB1 is only needed because Orders runs on XP. Removing SMB1 depends
+  on the **ORDERS modernization** (get Orders off the XP VM) — see
+  [[projects/valleywide-orders-modernization]]. Track SMB1 removal as the exit criterion.
+- **Wiki correction:** VWP wiki "Emergency surcharge pattern" note says 1190473 ×1.0+×0.5; the
+  authoritative `/syncro` rule is 26184 @ qty×1.5 (same 1.5 hr deduction). Fix on wiki compile.
+- Confirm the XP VM's G: mapping is persistent across reboot (set /persistent:yes).
+
+## Reference Information
+- Ticket: Syncro #32448 (id 112976149), https://computerguru.syncromsp.com/tickets/112976149.
+  Invoice #1650772624. Line item 42980555. Comment 420351873.
+- Related history: G: migration #32418 (2026-06-13, SERVER3 -> VWP-FILES); folder-access #32208.
+- VWP wiki: [[clients/valleywide]]; modernization: [[projects/valleywide-orders-modernization]].
+- Emergency prepaid billing rule: `/syncro` command (26184 @ qty actual×1.5; invoice $0; block
+  debits by quantity).