# Session 2026-06-13 — VWP SERVER3 retirement, G: migration to VWP-FILES, Orders VB6 source recovery (+ GuruRMM NT 6.0 legacy agent)

## User
- **User:** Mike Swanson (mike)
- **Machine:** GURU-5070
- **Role:** admin

## Session Summary

Started on the GuruRMM legacy-agent floor: SERVER3 rejected the legacy agent with "not a valid
Win32 application." Confirmed the cause is the PE OS/subsystem version stamp (6.1 = Win7/2008 R2)
vs the box's NT version. Built a **6.0-stamped** legacy agent on Pluto (the office Windows builder)
so the agent loads on Server 2008 / NT 6.0 — needed for Glaztech's pre-R2 2008 servers. Two real
fixes were required: pin `zeroize = =1.8.1` (1.9.0 needs edition2024, which Rust 1.77 can't parse —
a latent break in the production legacy pipeline) and add `-C link-arg=/SUBSYSTEM:CONSOLE,6.00`.
Header verified 6.0/6.0, console subsystem preserved.

SERVER3 (the VWP XenServer "server 2003" VM) was upgraded in-place to Server 2008 by Mike. That
broke networking (PV NIC gone) and then bricked with 0x7B INACCESSIBLE_BOOT_DEVICE after a XenTools
install. Recovered it: safe-mode XenTools uninstall, then a clean reinstall with the **xenbus/
xenfilt/xenvbd boot-start** fix applied before reboot. Came up healthy (PV 7.1 build 1270, NIC up
on 192.168.0.20). Snapshots taken at each safe point.

The main work: **migrated the G: file share off SERVER3 onto a new Hyper-V file server, VWP-FILES**
(pre-staged Gen2 Server 2019 VM on VWP-HYPERV1). Block-migrated the 100 GB G: VDI (XenServer
`vdi-export` streamed straight to HYPERV1 over HTTPS, converted to VHDX), attached, brought online,
recreated all 19 SMB shares with exact perms (via WMI ACL extraction — the registry-import route
was blocked by SMB admin-share refusal), repointed the **MappedDrives GPO** G: → `\\VWP-FILES\G-drive`
(and cleaned two stale G: maps), and did the **IP takeover** so VWP-FILES holds `192.168.0.20`
(VLAN 2 "Old Net") for IP-based stragglers while serving the new net on 172.16.9.132. Verified,
billed 3.5 h remote on #32418, prepay 24.0 → 20.5.

Finally, hunted for the **lost VWP "Orders" VB6 source** (#32280). It was not loose on any server —
but Darv's full machine backup (`F:\Darv\Darv.rar`, 51 GB, on WINFileSvr) contained the complete
Orders project tree. Staged 12.2 MB of pure source (147 .frm, 4 .bas, 5 .vbp; newest ORDERS_C.vbp
2020-06-09) into the repo. **The source is fully recovered — VB Decompiler is no longer needed.**

## Key Decisions

- **6.0 PE stamp, not a separate agent SKU.** A 6.0-stamped image still loads on Win7→11, so one
  legacy binary covers 2008 → 11 — just lower the floor. Pin `zeroize=1.8.1` to clear the
  edition2024 wall on Rust 1.77 (mirrors the existing uuid/url pins).
- **Block-migrate G:, not file-copy.** ~100 GB of many small files → a whole-volume image move
  (VDI export → VHDX) is far faster and preserves NTFS/perms/timestamps. Streamed the export
  directly XenServer→HYPERV1 (dom0 has only ~15 GB scratch; can't stage 100 GB locally).
- **WMI ACL extraction for shares, not registry import.** SERVER3's admin share (C$) refused
  (error 67) and `reg export` via WMI didn't land, so recreated all 19 shares with `New-SmbShare`
  + the exact share-level ACLs pulled via `Win32_LogicalShareSecuritySetting`. Result identical
  (mostly Everyone Full; Shelly read-only; G-drive +Domain Users).
- **GPO points G: at `\\VWP-FILES` by name**, decoupled from the .20 IP takeover, so it survives
  regardless. Disabled DNS registration on the .20 NIC so the name resolves only to 172.16.9.132
  (avoids new-net clients hitting the asymmetric-route dead end on .20).
- **IP takeover via VLAN tag, no cabling.** UDM "Old Net" = VLAN 2; HYPERV1's uplink already trunks
  it (UniFi default), so a tagged 2nd vNIC + .20 was fully remote — no on-site patch needed.
- **Don't decompile — recover the source.** Pursued Darv.rar over the VB-Decompiler path once the
  full .vbp tree turned up; we now have real, buildable 2020 source.

## Problems Encountered

- **"not a valid Win32 application" on SERVER3** — PE stamped NT 6.1; box was below the floor.
  Fixed by building a 6.0-stamped agent (and SERVER3 was upgraded to 2008 anyway).
- **0x7B INACCESSIBLE_BOOT_DEVICE after XenTools** on the 2008 guest — xenvbd took the boot disk
  without being boot-critical. Fixed by setting xenbus/xenfilt/xenvbd `Start=0` before reboot.
- **zeroize 1.9.0 edition2024** broke the 1.77 legacy build — pinned `=1.8.1`. (Production legacy
  pipeline will hit the same; the pin should be committed to `agent/Cargo.toml`.)
- **RMM JSON transport eats one backslash** from UNC literals — bit me 3× (GPO path stored as
  `\VWP-FILES`, Test-Path failures). Worked around by building backslashes from `[char]92`.
- **Asymmetric routing to .20** — dual-homed VWP-FILES replies via its 172.16.9 NIC, so cross-subnet
  (DC, my VPN) can't reach .20; only same-subnet Old-Net clients can. Acceptable: stragglers are
  Old-Net, new-net uses the GPO `\\VWP-FILES`. Used 172.16.9.132 for my own file pulls.
- **SMB admin-share (C$) refusal + reg-export-via-WMI not landing** on SERVER3 → pivoted to WMI
  ACL extraction for the share migration.
- **Per-site MSI installer endpoint 500/"Missing authorization"** when enrolling VWP-FILES — Mike
  pushed the agent via ScreenConnect instead (now online, site Main Office).

## Configuration Changes

- **VWP-FILES (Hyper-V VM on VWP-HYPERV1):** checkpoint merged (flat VHDX), AutomaticCheckpoints
  disabled, RAM 4→16 GB, install ISO ejected. Added 2nd vNIC `OldNet-VLAN2` (AccessVlanId 2),
  static `192.168.0.20/24` (no gateway), DNS registration disabled on that NIC. Attached migrated
  `C:\VHD\server3-g.vhdx` (SCSI0:2) as G:. 19 SMB shares created. GuruRMM agent installed (via SC).
- **GPO `MappedDrives` (VWP.US):** G: drive map `\\192.168.0.20\G-drive` → `\\VWP-FILES\G-drive`;
  version bumped (gpt.ini + AD) to 4980736.
- **GPO `Default Domain Policy`:** removed stale G: map (`\\192.168.0.96\g$`); version → 1114165.
- **Orphaned SYSVOL policy `{FCB17CA3-155F-4BD3-B633-4E1F5CF01679}`** (no AD object) deleted
  (backed up to `C:\GPO-backup-Gmig-20260613-170451` on VWP-DC1).
- **SERVER3 (XenServer VM `0c73ce00-...`):** clean-shutdown (retired). Snapshots created:
  `server2008-clean-noTools-20260613` (45d56386), `server2008-working-pvtools-20260613` (b2f50da4).
- **Repo:** staged `clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/`
  (12.2 MB recovered VB6 source); `darv-G-finds/` (ORDERS0727-2015.exe, ORDERS-2005.exe,
  frmPayroll, Package1508); updated `app-modernization/CONTEXT.md` (G: finds + source recovery).
- **Vault:** created `clients/vwp/domain-sysadmin` (VWP\sysadmin).

## Credentials & Secrets

- **VWP\sysadmin** (VWP.US domain admin) — `r3tr0gradE99#` — vaulted at `clients/vwp/domain-sysadmin`.
  Used for PowerShell Direct into VWP-FILES + WMI/SMB to VWP servers.
- **VWP XenServer** root — `r3tr0gradE99!` — vault `clients/vwp/xenserver` (host 192.168.0.104).
- **VWP UDM** root — `Gptf*77ttb123!@#-vwp` — vault `clients/vwp/udm` (host 172.16.9.1).

## Infrastructure & Servers

- **VWP-HYPERV1** 172.16.9.184 — Dell R740, Server 2025, 112 vCPU / 255 GB RAM, C: 10.7 TB (10.37
  free), Hyper-V, one External vSwitch on Intel 10G NIC (NIC1 linked 1 Gbps; NIC2/3/4 spare).
  VHDs in `C:\VHD`. RMM agent bdc3e142-1eb3-4034-8ac2-300f46dbc1d9.
- **VWP-FILES** — Hyper-V Gen2, Server 2019, now 16 GB RAM; IPs 172.16.9.132 (primary) + 192.168.0.20
  (VLAN 2). Serves G: (NTFS "G Drive", ~88 GB used). RMM site Main Office.
- **VWP XenServer** 192.168.0.104 — XenServer 7.6, PowerEdge R720. SERVER3 VM `0c73ce00-c4cc-c549-5f55-98657a66b203`
  (now off). G: VDI `828ea0ff-...` (100 GB), snapshot for export `9ee0e831-...`.
- **DC 192.168.0.25 (VWP_ADSRVR)** — Old Net DC, Server 2019, healthy (LDAP/SMB/DNS up).
- **VWP-DC1** 172.16.9.x — Server 2019 DC (RMM 8eefbba6-...).
- **WINFileSvr** 192.168.0.35 — Server 2019 file server; holds O:/P: shares AND `F:\Darv\Darv.rar`
  (the source backup) + `F:\Darv\Darv-rar` (135 GB extract). RMM 62db0264-88c2-44db-996d-84996afe8706.
- **UDM** 172.16.9.1 — networks: Default 172.16.9.0/24 (untagged), **Old Net 192.168.0.0/24 = VLAN 2**
  (gw .1, DHCP .100-.199, DNS=192.168.0.25 + 8.8.8.8), Management 192.168.3.0/24 VLAN 99, OpenVPN .4.0/24.
- **Pluto** 172.16.3.36 — office Windows builder (Rust 1.77 + i686; `C:\gururmm`). GURU-5070 SSH key
  added to its `administrators_authorized_keys` this session.

## Commands & Outputs

- 6.0 legacy build (Pluto): `cargo +1.77 build --ignore-rust-version --release --features legacy
  --target i686-pc-windows-msvc` with `$env:RUSTFLAGS='-C link-arg=/SUBSYSTEM:CONSOLE,6.00'`, after
  `cargo +stable add zeroize@=1.8.1` and moving `agent\Cargo.lock` aside. Artifact:
  `C:\Users\guru\Downloads\gururmm-agent-legacy-pre2008-x86.exe` (SHA256 0BB363E2…), header 6.0/6.0.
- xenvbd boot-start fix (in-guest, pre-reboot): `reg add HKLM\SYSTEM\CurrentControlSet\Services\
  {xenbus,xenfilt,xenvbd} /v Start /t REG_DWORD /d 0 /f`.
- G: export (HYPERV1 pulls from Xen): `curl.exe -sk -o C:\VHD\server3-g.vhd
  "https://192.168.0.104/export_raw_vdi?session_id=<OpaqueRef>&vdi=9ee0e831-...&format=vhd"`
  (~100 MB/s, final 99.33 GB), then `Convert-VHD … -VHDType Dynamic` → server3-g.vhdx (99.38 GB).
- Share ACLs via `Get-WmiObject Win32_LogicalShareSecuritySetting … .GetSecurityDescriptor()`.
- Source recovery sweep found `…\Kingston\Project\VWP_Current\ORDERS_C.vbp` (2020-06-09); project
  references 80 forms + 10 OCX (TABCTL32, Crystl32, True DBGrid, FarPoint Spread).

## Pending / Incomplete Tasks

- **Commit `zeroize = "=1.8.1"`** to `guru-rmm/agent/Cargo.toml` (production legacy build will break
  on next run without it). Open as its own fix.
- **Validate the 6.0 legacy agent on a real NT 6.0 box** (Glaztech 2008 server, or a lab VM). Then
  correct SPEC-029 §12 / `installer/legacy/README.md` ("blocked / NSIS+NSSM") and pursue unified
  x86-MSI + native-SCM.
- **Modernization (#32280):** stand up a VB6 build env, confirm `ORDERS_C.vbp` compiles from the
  recovered tree, then scope the modernization from source. Optionally stage `VWP_Inv` / `VWP_Update`
  projects too. Bill #32280 for the recovery search.
- **Cleanup (on sign-off):** delete `C:\VHD\server3-g.vhd` (99 GB intermediate) on HYPERV1, the
  XenServer G: snapshot, and `F:\Darv\Darv-rar` (135 GB) once source verified; SERVER3 VM stays
  off-but-intact as deepest rollback.
- **Commit** the staged source + darv-G-finds (this `/save` syncs them).
- Beast `C:\Temp\gururmm-nsvc*` leftovers from the prior native-SCM probe still pending cleanup.
- Old-Net DHCP secondary DNS = 8.8.8.8 → consider changing to a second internal DC.

## Reference Information

- **Tickets:** #32418 G-Drive Migration (Invoiced, 3.5 h remote, $0 prepaid; id 112613439).
  #32280 Source Code Data Recovery (New; id 110305931) — recovery write-up posted.
- **Repo paths:** `clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/`,
  `…/source-analysis/darv-G-finds/`, `…/CONTEXT.md`.
- **Source of record:** WINFileSvr `F:\Darv\Darv-rar` (extract) + `F:\Darv\Darv.rar` (51 GB archive).
- **RMM:** http://172.16.3.30:3001 — VWP site "Main Office" 7c18fe2c-38fe-4ebf-8a26-b47745db2d19
  (code INNER-TIGER-8330).
- **VWP Syncro customer:** 31694734.

## Update: 05:40 PT — Orders modernization: research + wiki

- Inventoried the recovered source (`ORDERS_C.vbp`): ~40 active forms + `modADO` (ADO.bas/ADO2.bas
  data layer); confirmed full construction-ERP domain (Projects/Lots, Takeoffs, Crew/Payroll incl.
  Certified Payroll, Scaffold, Inventory/PO/Suppliers, AR/AP/Billing/Job-Cost, Positive Pay 3 banks,
  Repairs, Texture/Foam). Stack from .vbp refs: VB6 + ADO 2.6/Jet, Crystal 7 (craxdrt/Crystl32),
  True DBGrid Pro 7 (todg7), FarPoint Spread (Flp32a30), TABCTL32/MSCOMCTL/EasyP, MSXML4.
- Researched modernization paths: VBUC (Mobilize.Net / gapvelocity AI Migrator) VB6->C#/.NET8;
  Jet->SQL Server; OCX successors all in MESCIUS/GrapeCity family (True DBGrid->FlexGrid w/ migration
  utility; FarPoint Spread->Spread for WinForms, .ss2->XML; Crystal->Crystal for VS auto-convert).
- **Created wiki article:** `wiki/projects/valleywide-orders-modernization.md` (app domain, stack,
  recovered-source status + locations, modernization assessment + first concrete steps, sources).
- Linked from `wiki/index.md` (Projects table) and `wiki/clients/valleywide.md` (app-mod section
  pointer + "source RECOVERED" note superseding the old "lost" text).

## Update: 06:16 PT — VWP-FILES RMM enrollment, fleet check, MSP360 backup verified

- **VWP-FILES enrolled in GuruRMM** (Mike pushed the agent via ScreenConnect after the per-site MSI
  endpoint 500'd). Agent id `8e02fbbc-0db1-4044-b4c2-b0732d64f029`, online, site "Main Office", v0.6.66.
- **VWP server fleet check (RMM):** all 11 enrolled Windows servers online/healthy (VWP-HYPERV1 2025,
  VWP-QBS/VWP-SERVER 2022, VWP-DC1/VWP_ADSRVR/VWP-FIN/WIN-Server97/WINFileSvr/WIN-AD-SRVR-2/
  WIN-Backup-SRV 2019, SERVER19 2012 R2). VWP-FILES had been the only unmonitored server until enrolled.
- **MSP360 backup verified** on VWP-FILES via `GET /api/agents/<id>/backup-status`:
  provider msp360, plan "Files Backup Plan VWP-FILES", **status=success**, 103,849 files / 0 failed,
  ~63.7 GB of ~91 GB copied to Cloud (B2), build 8.6.0.338, last 2026-06-13 18:18 PT, next Jun 15 07:00 UTC.
  (Only message is Info-level "987 system/hidden files skipped" — normal.)
- **Tagged Winter** (`<@624666486362996755>`) in Discord **#bot-alerts** re: the new VWP-FILES
  backup, for her backup monitoring/billing.
- New RMM API note: **`GET /api/agents/<id>/backup-status`** returns the MSP360/CloudBerry backup
  result (provider, plan_name, status, files_copied/failed, data_copied/total_bytes, last/next_backup_at).