azcomputerguru/claudetools
1
0
Fork 0
Code Issues 58 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0ed8f1413efe92c48603a2a08f3ed412e142ad1d
claudetools/clients/valleywide/session-logs/2026-06/2026-06-23-mike-vwp-smb1-orders-xp-g-drive.md
Mike Swanson 045b50fefa 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
2026-06-23 10:00:22 -07:00

7.5 KiB
Raw Blame History

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

Reference in New Issue View Git Blame Copy Permalink