sync: auto-sync from GURU-5070 at 2026-06-14 05:33:01
Author: Mike Swanson Machine: GURU-5070 Timestamp: 2026-06-14 05:33:01
This commit is contained in:
@@ -0,0 +1,160 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user