Files

Mike Swanson 9a2a05e3cb feat(valleywide): drive 3 deep dive - VWP1.VHDX mount + 97-Server\VWP2 grab

Drive 3 yielded the biggest finds in the project so far.

VHDX mount + scan (D:\WIN7-Orders\Darv-2\VWP1.VHDX, 117 GB Hyper-V disk):
- Mounted read-only as F:, scanned in 85s, dismounted
- NOT Darv's dev box - it's the office "owner" admin workstation
- No newer source code found inside, but:
  - Vwp11.mdb (2023-07-27, 369 MB) - NEWEST DB snapshot anywhere
  - Vwp.mdb (2022-12-23, 769 MB) - on Desktop\Darv VWP
  - Orders Versions/ desktop folder with 2 EXEs + 7 shortcuts
  - The .lnk shortcuts all pointed to G:\VWP2\Orders*.exe - the
    "Aha!" that revealed where Darv's iteration happened
- Saved to source-code/from-VHDX-VWP1/

The VWP2 grab (D:\97-Server-G-Drive\g$ 2024-04-10\VWP2\):
- This is Darv's actual iteration workspace on the production
  Orders server (G: drive)
- 16.36 GB total, 1,061 files. Grabbed 886 files (~893 MB) filtered to
  *.exe, *.rpt, *.ocx, and VB6 source extensions:
  - 64 Orders*.exe versions - complete iteration history (includes the
    production Orders_10A.exe + Orders_10Z.exe variant + dozens more
    with Darv's "iterate-and-rename" naming pattern)
  - 820 Crystal Reports (.rpt)
  - 2 .ocx supporting controls
- Skipped 23 historical .mdb backups (15.8 GB) - we already have
  newer snapshots from 000_ASource and VHDX
- Skipped 6 large subfolders (HOLD, HHOLD, Pay_2021_0325, GWAC,
  20220205, 20211010 RPT) - mostly more MDBs
- Saved to source-code/from-VWP2-97server/

What we learned about the 4-year gap:
- No source code newer than 2020-06-09 ORDERS_C.vbp baseline found
  on any of the three rotation drives
- The 64 EXE versions in VWP2 go through 2022 - Darv was iterating
  and rebuilding compiled output but not updating his .vbp source
  control. This is consistent with his "rename and try" workflow
- The production exe (Orders_10A.exe) is in this batch - now we can
  use VB Decompiler Pro on it without needing the original drive

Helper scripts:
- scan_vhdx.ps1 - fast PowerShell scan of a mounted VHDX for source/DB
- find_vwp2.py - cross-CSV search for the VWP2 path
- vwp2_summary.py - size+type breakdown of the VWP2 folder
- debug_vwp2.py - one-off debug helper

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-16 18:02:47 -07:00

app-modernization

feat(valleywide): drive 3 deep dive - VWP1.VHDX mount + 97-Server\VWP2 grab

2026-05-16 18:02:47 -07:00

docs

sync: auto-sync from HOWARD-HOME at 2026-04-23 11:09:16

2026-04-23 11:09:18 -07:00

session-logs

sync: auto-sync from DESKTOP-0O8A1RL at 2026-05-12 07:50:21

2026-05-12 07:50:21 -07:00

.gitignore

feat(valleywide): drive 3 analysis - 117 GB Hyper-V VHDX lead identified

2026-05-16 17:46:38 -07:00

PROJECT_STATE.md

chore: add PROJECT_STATE.md to all active projects and clients

2026-04-19 18:53:34 -07:00

README.md

sync: auto-sync from HOWARD-HOME at 2026-04-22 15:41:54

2026-04-22 15:41:55 -07:00

README.md

Valleywide (VWP)

Infrastructure

Servers

HP ProLiant Server (SN: MXQ80400X4)

VM Host / Hypervisor
iLO IP: [TO BE DOCUMENTED]
All VMs running on this host
[WARNING] 2026-04-22: NVRAM corruption from power outage - BIOS/iLO reset to factory, reconfigured
[ACTION REQUIRED] iLO needs reconfiguration after factory reset

VWP_ADSRVR (192.168.0.25)

Windows Server 2019 Standard (build 17763)
Domain Controller for vwp.local
SSH enabled (OpenSSH Server), key auth working for vwp\guru
Likely runs as VM on HP ProLiant host

VWP-QBS (172.16.9.169) - Dell Server with DRAC

Windows Server 2022 Standard
Physical Dell server (NOT a VM)
Internal network only (172.16.9.0/24 reachable via VWP site VPN)
Runs QuickBooks + IIS with RD Gateway / RD Web Access (/RDWeb, /RDWeb/Pages, /RDWeb/Feed, /Rpc, /RpcWithCert)
WinRM available on 5985 (used for remote admin via Invoke-Command)
DRAC available for remote management
[NOTE] 2026-04-22: Boot retry issue after power outage, resolved via DRAC manual boot to Windows Boot Manager

Networks

Internal: 172.16.9.0/24
One subnet also numbered 192.168.0.0/24 (conflicts with IMC's LAN if VPNs overlap — be careful switching contexts)

Access

SSH to VWP_ADSRVR: ssh vwp\guru@192.168.0.25 (ed25519 key, added 2026-04-13)
Double-hop to VWP-QBS: SSH won't forward Kerberos; use Invoke-Command -ComputerName VWP-QBS -Credential $cred with vwp\sysadmin PSCredential

Security posture

2026-04-13 incident

RDWeb (https://VWP-QBS/RDWeb/Pages/login.aspx) was exposed to the public internet via UDM port forward. Distributed brute-force attack was in progress (multiple external IPs, ~6 POSTs/min, hitting usernames like scanner, Guest, etc.). This was discovered while investigating repeated scanner account lockouts (event 4740) which originally looked like a stale service credential.

Actions taken:

UDM port forward removed (user action)
IIS reset on VWP-QBS to drain in-flight attacker sessions
Domain lockout policy restored (threshold 5, 16-min duration/window) after being temporarily disabled during diagnosis
30-day audit: no successful external logons — no compromise

Current state

RDWeb no longer reachable from public internet
Internal access still works on port 443 from within 172.16.9.0/24
Account lockout policy active

Recommendations (outstanding)

If RDWeb must be public again: deploy IPBan (https://github.com/DigitalRuby/IPBan) + firewall restriction to known client IPs
Audit UDM for UPnP (prevents the server from re-punching its own hole)
Consider 2FA / Conditional Access on any externally-reachable Windows service
Rotate scanner AD account password (last set 2024-10-17) as hygiene

2026-04-16: RemoteApp over VPN (post-gateway) + RDS licensing fix

After the 2026-04-13 public RDWeb port-forward removal, users launching the QuickBooks RemoteApp via VPN hit 0x3000008 (RD Gateway unreachable) because the RDP manifest still routed through the gateway at the (now-firewalled) public IP.

Changes made

RDS Deployment (on VWP-QBS, via Server Manager -> RDS -> Edit Deployment Properties -> RD Gateway) set to "Do not use an RD Gateway server". New RDP manifests now write gatewayusagemethod:i:0 and full address:s:VWP-QBS.VWP.US — direct connect, no gateway.
UDM static DNS record fixed typo qwp-qbs.vwp.us -> vwp-qbs.vwp.us (UniFi UI: Settings -> Routing -> DNS -> Static DNS Records), still pointing to 172.16.9.169. Required because vwp.us is a real registered domain (resolves publicly to the website) but vwp-qbs.vwp.us is only valid internally. VPN clients receive DNS=192.168.4.1 (the UDM) via OpenVPN push, so this override is what lets them find the session host.
RDS licensing configuration (on VWP-QBS, via Win32_TerminalServiceSetting WMI):
- Mode: Per User (LicensingType=4)
- Specified license server: vwp-qbs.vwp.us (the same box — RDS-Licensing role was installed and activated but the RDSH was never pointed at it, so users hit "no license servers available")

Rationale

No RD Gateway needed: VWP users are either on-LAN or VPN-connected. OpenVPN pushes routes for 172.16.9.0/24, 192.168.0.0/24, 192.168.3.0/24. VPN -> LAN firewall policy is ACCEPT-all (UBIOS_VPN_LAN_USER). Gateway was only serving the public-access use case which is now intentionally closed.
DNS override avoids split-horizon complexity: rather than pushing internal AD DNS (172.16.9.2) to VPN clients, we use the UDM's dnsmasq for both public and internal names, with overrides for the handful of internal FQDNs clients actually need.

Current VPN / DNS topology

OpenVPN server on UDM: pushes 192.168.4.0/24 to clients, routes for the three LAN subnets, DNS=192.168.4.1 (UDM)
Site-to-site WireGuard peers visible on UDM (wgsts1001, wgsts1003, wgsts1005) — likely UniFi SiteMagic to ACG / other sites
Static DNS records on UDM (as of 2026-04-16): vwp-qbs.vwp.us -> 172.16.9.169

RDS CAL purchase (outstanding)

VWP-QBS's RDS License Server is activated and running, but has no real CALs installed — only the Windows 2000-era Built-in TS Per Device CAL placeholder pack. Once grace period expires (or after the 2026-04-16 pointer fix re-triggers licensing logic), users will either get a fresh grace window or start seeing "license server has no licenses" errors.

Action item: purchase a pack of Windows Server 2022 RDS Per User CALs sized to the active user count (check VWP-QBS for distinct interactive logon count last 30d to size accurately). Install via licmgr.msc on VWP-QBS. Current licensing mode is Per User, matching this purchase path.

Voice / IP Phones

Yealink SIP-T54W fleet (16 devices) — see docs/yealink-phones.md
YMCS portal: https://us.ymcs.yealink.com/manager/sip-product/sipManage

Open items

[PRIORITY] HP ProLiant iLO reconfiguration (2026-04-22 emergency: factory reset, needs credentials/network setup)
[PRIORITY] Verify all HP server BIOS settings post-corruption recovery
[PRIORITY] UPS assessment for HP server (power outage caused NVRAM corruption)
Confirm UPnP state on UDM (2026-04-13 recommendation — still not verified)
Document intended RDWeb access pattern (who connects from where) — superseded partially by 2026-04-16 VPN-only decision, but formalize
Add Valleywide entry to SOPS vault (SOPS vault now has clients/vwp/* entries: adsrvr, dc1, udm, xenserver, quickbooks-server-idrac — superseded)
RDS CALs purchase (see above)
Rotate scanner AD account password (carried from 2026-04-13)