# 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).