---
type: client
name: valleywide
display_name: Valley Wide Plastering
last_compiled: 2026-07-07
compiled_by: GURU-5070/claude-main
sources:
  - clients/valleywide/README.md
  - clients/valleywide/PROJECT_STATE.md
  - clients/valleywide/session-logs/2026-04-13-rdweb-brute-force-incident.md
  - clients/valleywide/session-logs/2026-04-22-hp-server-nvram-corruption-emergency.md
  - clients/valleywide/session-logs/2026-05-12-session.md
  - clients/valleywide/docs/yealink-phones.md
  - clients/valleywide/docs/yealink-t54w-recovery-procedure.md
  - clients/valleywide/app-modernization/CONTEXT.md
  - clients/valleywide/app-modernization/session-logs/2026-04-27-session.md
  - clients/valleywide/app-modernization/research/schema-analysis.md
  - clients/valleywide/app-modernization/source-analysis/D-drive-2026-05-16/SUMMARY.md
  - clients/valleywide/app-modernization/source-analysis/drive2-2026-05-16/SUMMARY.md
  - clients/valleywide/app-modernization/source-analysis/drive3-2026-05-16/SUMMARY.md
  - clients/valleywide/session-logs/2026-05-16-source-code-recovery-from-backup-drives.md
  - clients/valleywide/session-logs/2026-06/2026-06-13-mike-vwp-server3-migration-and-orders-source-recovery.md
  - clients/valleywide/session-logs/2026-06/2026-06-13-mike-vwp-gpo-disable.md
  - clients/valleywide/session-logs/2026-06/2026-06-14-mike-orders-modernization-roadmap.md
  - clients/valleywide/session-logs/2026-06/2026-06-15-mike-vwp-files-single-home-scan-fix.md
  - clients/valleywide/session-logs/2026-06/2026-06-23-mike-vwp-smb1-orders-xp-g-drive.md
  - wiki/projects/valleywide-orders-modernization.md
backlinks:
  - projects/valleywide-orders-modernization
---

# Valley Wide Plastering

Plastering / stucco subcontractor based in Arizona. Active ACG client. Primary work has been incident response (RDWeb brute-force, power outage recovery), infrastructure migration (G: file share off XenServer to new Hyper-V file server), and an ongoing app modernization project for their custom VB6/Access construction ERP.

---

## Profile

- **Company type:** Construction subcontractor (plastering / stucco)
- **Domain / site identifier:** VWP (`VWP.US` AD domain — NetBIOS `VWP`; `valleywideplastering.com` M365 domain; `vwp.us` also registered external domain used for internal FQDNs)
- **Contract type:** Prepaid hour block
- **Hours remaining:** 15.5 hrs as of 2026-06-23. Always live-check Syncro before billing.
- **Managed assets (Syncro):** 28
- **Billing rate:** $150/hr remote labor (product `1190473 — Labor - Remote Business`)
- **Emergency billing pattern (prepaid):** product **26184** (Labor - Emergency or After Hours) at **qty = actual_hours × 1.5** — premium in the quantity (prepaid debits by quantity; invoice nets $0; block debits actual×1.5). Per the authoritative `/syncro` rule (2026-05-27); supersedes the older "1190473 ×1.0 + ×0.5" method (same 1.5 hr deduction, but 26184 keeps the QuickBooks line labeled "Emergency"). e.g. #32448 (2026-06-23): 1 hr → 26184 @ 1.5.
- **Key contact:** Shelly Dooley / Valley Wide P (Syncro display name)
- **Syncro customer ID:** `31694734`
- **M365 tenant ID:** `5c53ae9f-7071-4248-b834-8685b646450f`
- **M365 domain:** `valleywideplastering.com`

---

## Infrastructure

### Servers & Services

| Host | IP | Role | OS | Notes |
|---|---|---|---|---|
| HP ProLiant DL360 Gen10 (SN: MXQ80400X4) | ESXi mgmt **192.168.3.24** (VLAN 99); iLO 172.16.9.125 | **VMware ESXi 8.0.2 host** — runs most of VWP's server fleet (~12 VMs) | ESXi 8.0.2 (build 22380479) | 40 cores / 512 GB RAM; datastore `Tesst` (VMFS-6) ~14 TB, **65% full (~4.9 TB free)** after the 2026-06-14 cleanup. SSH on :22, vault `clients/vwp/esxi` (root). Hosts ADSRVR, VWP-SERVER, VWP-FIN, WIN-Acct, WIN-AD2, Server-97, SERVER19, WINFileSvr, etc. — see VM inventory below. Power outage 2026-04-22 caused NVRAM corruption + factory iLO reset. |
| HP iLO | 172.16.9.125 | Out-of-band management for HP ProLiant | — | SSH port 22. **Requires legacy RSA algorithms** — modern OpenSSH rejects it. Use paramiko with `disabled_algorithms={'pubkeys': ['rsa-sha2-256', 'rsa-sha2-512']}`. Credentials: vault `clients/valleywide/`. |
| VWP_ADSRVR | 192.168.0.25 | Domain Controller for `VWP.US` (secondary DC / SSH entry point) | Windows Server 2019 Standard (build 17763) | VM on HP ProLiant DL360 Gen10. SSH enabled, key auth working for `vwp\guru` (ed25519, added 2026-04-13). Default shell is cmd.exe — use `powershell -NoProfile -Command` wrappers. Old Net (VLAN 2). |
| VWP-DC1 | 172.16.9.2 | PDC emulator for `VWP.US`, NPS/RADIUS | Windows Server 2019 | FQDN `VWP-DC1.VWP.US`. Confirmed up through all sessions. ADWS on this host not reachable over the SSH double-hop from ADSRVR (use LDAP cmdlets instead). |
| VWP-QBS | 172.16.9.169 | QuickBooks server + RDS/RemoteApp host | Windows Server 2022 Standard | **Physical Dell server** (NOT a VM). Has DRAC. Runs IIS (RD Web Access). WinRM on 5985. Reach from ADSRVR via `Invoke-Command -ComputerName VWP-QBS -Credential` with `vwp\sysadmin` PSCredential. |
| Dell DRAC (VWP-QBS) | 192.168.3.189 | Out-of-band management for VWP-QBS Dell | — | iDRAC 9, PowerEdge R640, Service Tag C84TTQ2. HTTPS console. Vault: `clients/vwp/quickbooks-server-idrac`. Documented 2026-07-07. |
| VWP-HYPERV1 | 172.16.9.184; iDRAC **172.16.9.151** | Hyper-V host — primary VM host for new infrastructure | Windows Server 2025 | Dell R740, 112 vCPU / 255 GB RAM, C: 10.7 TB. One external vSwitch on Intel 10G NIC. VHDs in `C:\VHD`. GuruRMM agent `bdc3e142-...`. Added 2026-06-13. **iDRAC 172.16.9.151** (credentials: vault `clients/vwp/quickbooks-server-idrac` — same password). Documented 2026-07-10 during CRITICAL_PROCESS_DIED recovery. |
| VWP-FILES | 192.168.0.20 (single-homed, VLAN 2; gw 192.168.0.1) | G: file share server (19 SMB shares) | Windows Server 2019 Gen2 VM on VWP-HYPERV1 | Block-migrated from SERVER3 G: VDI (100 GB, ~88 GB used). **Single-homed on 192.168.0.20 since 2026-06-15** — the former 172.16.9.132 vNIC was disconnected at the Hyper-V host to fix cross-VLAN scan-to-folder (the Brother copier hard-codes `\\192.168.0.20`; the multi-homed config had a gateway only on the .132 NIC, so replies to off-subnet clients were dropped — see Patterns). The .132 vNIC is DISCONNECTED at the host (reversible), not removed. DNS registers .20 only. GuruRMM enrolled (site Main Office, agent `8e02fbbc-...`). MSP360 backup running green. **SMB1 server ENABLED 2026-06-23** (#32448) so the legacy XP Orders VM (V-XP) can map `\\VWP-FILES\G-drive` — Server 2019 defaults SMB1-off and XP speaks only SMB1; security tech-debt, remove once Orders is off XP. |
| XenServer | 192.168.0.104 | VM hypervisor — hosts remaining VMs | XenServer 7.6 (PowerEdge R720) | SERVER3 VM (the old "server 2003", upgraded in-place to 2008) is now **powered off and retired**; snapshots retained for rollback. Vault: `clients/vwp/xenserver`. |
| WINFileSvr | 192.168.0.35 | File server — serves **O:** (`Office_Archive`, ~570 GB / 138K files) + **P:** (`Estimating Archive` = F: root, ~545 GB / 142K files), both GPO-mapped to all staff; actively used daily | Windows Server 2019 | Old Net (VLAN 2). **VMware VM on the ESXi host (VMID 11, `WINFilrSrvr`)** — see ESXi inventory. ~1.1 TB live data. Holds `F:\Darv\Darv.rar` (51 GB Darv dev-machine backup) + `F:\Darv\Darv-rar` (extract, trimmed 135→26 GB on 2026-06-14). GuruRMM `62db0264-...`. Candidate to consolidate into VWP-FILES (retire the VM). Do not delete `Darv.rar` until VB6 source verified to compile. |

**[WARNING] No UPS on HP ProLiant DL360.** The 2026-04-22 power outage caused NVRAM corruption. UPS assessment is an outstanding priority.

### VMware ESXi Host & VM Inventory (`192.168.3.24`)

The HP ProLiant DL360 Gen10 runs **VMware ESXi 8.0.2** (mgmt `192.168.3.24`, VLAN 99; SSH `:22`;
vault `clients/vwp/esxi`, root). 40 cores / 512 GB RAM. Single datastore **`Tesst`** (VMFS-6,
~14 TB, **65% full / ~4.9 TB free** (after the 2026-06-14 cleanup; was 87% / 1.9 TB free).
Documented 2026-06-14 — the cred had been mis-filed as `infrastructure/vmware-workstation`
("VMware Workstation"); relocated to `clients/vwp/esxi`. (Naming is messy — datastore "Tesst",
typo'd VM names.) 9 VMs remain after cleanup.

| VMID | VM name | State | Guest | Notes |
|---|---|---|---|---|
| 4 | VWP_AD_Srvr | on | 2019 | = VWP_ADSRVR / DC (192.168.0.25) |
| 12 | VWP-SERVER | on | 2019 | |
| 6 | VWP-FIN | on | 2019 | .vmx dir `VWP-AD-Server2` |
| 1 | Server-97 | on | 2019 | |
| 8 | WIN-AD2 | on | 2019 | |
| 7 | WIN-Acct | on | Win10/11 | |
| 2 | SERVER 19 | on | 2012 R2 | |
| 3 | VWIN7-2-PC.VWP.US | on | Win7 | |
| **11** | **WINFilrSrvr** | **on** | 2019 | **The live WINFileSvr** (`WINFileSvr.VWP.US`, 192.168.0.35). 3 disks ~4.4 TB provisioned (C: + O: 570 GB + F:/Estimating 545 GB). Had a 2.5-yr snapshot chain (ROOT "WINFILESERVER" 2023-12-30 → "VWP-FileSvr" 2024-01-13, ~440 GB delta) — **consolidated 2026-06-14** via `vim-cmd vmsvc/snapshot.removeall 11`. |

**2026-06-14 cleanup (Mike's decommission batch).** Three VMs powered off together on 2026-05-18
were confirmed retired and **destroyed** 2026-06-14, reclaiming ~3.05 TB (datastore 87% → 65%):
- `WINFileSrvr` (VMID 10) — old single-disk file server, 1.5 TB (superseded by the live VMID 11).
- `WIN-QB2` (VMID 9) — old virtualized QuickBooks, 1.4 TB (live QB is the physical VWP-QBS Dell).
- `VWP-BackupSVR` (VMID 5) — backup server, 150 GB. Verified **zero AD entanglement** before
  deletion (not a DC, no FSMO, no AD computer object, no DNS record; the two real DCs are
  ADSRVR + VWP-DC1, FSMO split across them).

Then the live WINFileSvr (VMID 11) snapshot chain was consolidated (see its row). Remaining
opportunity: consolidating WINFileSvr → VWP-FILES would move ~1.1 TB of live data off this host
and let the VM be retired.

### Email & Identity

- **M365 tenant:** `valleywideplastering.com` | Tenant ID: `5c53ae9f-7071-4248-b834-8685b646450f`
- **On-prem AD domain:** `VWP.US` (NetBIOS `VWP`, PDC = `VWP-DC1.VWP.US`). [NOTE: earlier notes said `vwp.local` — the actual AD DNS root is `VWP.US`. SYSVOL: `C:\Windows\SYSVOL\sysvol\vwp.us\Policies\`.]
- **MFA status:** [unverified] — No M365 CA or MFA configuration documented.
- **MX / mail flow:** [unverified] — M365 tenant confirmed but mail flow not audited.

### Network

- **ISP / WAN:** Public WAN IP `98.168.18.21` (observed via Yealink YMCS)
- **Firewall / Router:** UniFi Dream Machine at 172.16.9.1
- **VPN:** OpenVPN on UDM. Client pool: `192.168.4.0/24`. Pushes routes for `172.16.9.0/24`, `192.168.0.0/24`, `192.168.3.0/24`. DNS pushed as `192.168.4.1` (UDM).
- **Subnets:**
  - `172.16.9.0/24` — primary internal network (new servers, VWP-QBS, UDM, iLO, HYPERV1); untagged
  - `192.168.0.0/24` — **"Old Net" = VLAN 2 on UDM** (gw 192.168.0.1, DHCP .100-.199, DNS → 192.168.0.25 + 8.8.8.8). Hosts: VWP_ADSRVR (.25), WINFileSvr (.35), XenServer (.104), Yealink phones (.17/.54/.130/.140/.222), VWP-FILES (.20, single-homed 2026-06-15). **[WARNING: conflicts with IMC's LAN — verify client context when switching VPNs.]**
  - `192.168.3.0/24` — Management VLAN 99
  - `192.168.4.0/24` — OpenVPN client pool
- **Static DNS (UDM):** `vwp-qbs.vwp.us` → `172.16.9.169` (typo `qwp-qbs` fixed 2026-04-16)
- **GPOs (domain `VWP.US`, as of 2026-06-13):** `MappedDrives` — G: map → `\\VWP-FILES\G-drive`; `Syncro` + `Datto RMM Agent install by immediate scheduled task` — both **AllSettingsDisabled** (flags=3); `Default Domain Policy`, `Enable SMB1 Client`, `Default Domain Controllers Policy`.

### RDS / RemoteApp

- **Session host:** VWP-QBS (Windows Server 2022)
- **Mode:** VPN-only (direct connect, no RD Gateway since 2026-04-16). RDP manifests write `gatewayusagemethod:i:0`.
- **RDS Licensing:** Per User mode. License server pointed at `vwp-qbs.vwp.us`.
- **[WARNING] RDS CALs not purchased.** Only the `Built-in TS Per Device CAL` placeholder exists. Grace period may have expired. Purchase Windows Server 2022 RDS Per User CALs sized to active user count.
- **Application:** QuickBooks RemoteApp.

### Voice / IP Phones

- **Fleet:** 16x Yealink SIP-T54W (OUIs `805e0c` and `44dbd2`)
- **YMCS portal:** https://us.ymcs.yealink.com/manager/sip-product/sipManage — account: Valleywide Plastering (VWP). Credentials: vault `clients/valleywide/`.
- **Phone subnet:** Old Net (VLAN 2) `192.168.0.0/24`; phones on DHCP, IPs at .17, .54, .130, .140, .222
- **Status as of 2026-04-22:** 5 phones provisioned (Offline in YMCS), 11 pending first boot.
- **[WARNING] Known-bad firmware:** `96.86.0.20` is a documented T54W brick-maker. Confirm YMCS firmware policy is NOT pushing this version before any mass provisioning.
- **Recovery procedure:** TFTP recovery in `clients/valleywide/docs/yealink-t54w-recovery-procedure.md`. Laptop at `192.168.81.100`, phone at `192.168.81.10`.

---

## Access

- **SSH to VWP_ADSRVR:** `ssh vwp\guru@192.168.0.25` (ed25519 key auth — added 2026-04-13). Default shell cmd.exe; wrap PS commands.
- **Double-hop to VWP-QBS:** Via WinRM — `Invoke-Command -ComputerName VWP-QBS -Credential $cred` using `vwp\sysadmin` PSCredential from inside ADSRVR SSH session.
- **HP iLO power management:** Paramiko required (not system OpenSSH). SSH to `172.16.9.125:22`, `disabled_algorithms={'pubkeys': ['rsa-sha2-256', 'rsa-sha2-512']}`. Power-on: `start system1`.
- **VWP-QBS DRAC:** IP undocumented — needs to be recorded. DRAC functional.
- **VPN:** Connect to VWP OpenVPN (UDM) first; provides access to both 172.16.9.0/24 and 192.168.0.0/24.
- **GPO changes over SSH (VWP_ADSRVR):** GPMC (`Get-GPO`/`Set-GPO`) fails with `0x80072020` over SSH double-hop. Use LDAP cmdlets (`Get-ADObject`, `Set-ADObject`) instead.
- **Vault paths:** `clients/valleywide/` (entries: `adsrvr`, `dc1`, `udm`, `xenserver`, `quickbooks-server-idrac`, `domain-sysadmin`). Read via `bash "$VAULT" get-field clients/vwp/<entry> <field>`.

---

## App Modernization Project

> **Dedicated article: [[projects/valleywide-orders-modernization]]** — full stack detail, source locations, modernization strategy, and history.

VWP's core business application is a custom construction ERP called **ORDERS** (`Orders_10A.exe`). The original developer ("Darv") is deceased. The app runs VB6 + Jet/Access and is approaching the 2 GB database file-size limit. ACG engaged to assess modernization feasibility.

**Source recovery status (2026-06-13): COMPLETE.** The full VB6 source (`ORDERS_C.vbp`, 2020-06-09) was recovered from Darv's machine backup (`F:\Darv\Darv.rar` on WINFileSvr `192.168.0.35`). 12.2 MB of pure source (147 `.frm`, 4 `.bas`, 5 `.vbp`) is staged in the repo at `clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/`. VB Decompiler Pro is **no longer needed** — modernization proceeds from real 2020 source. See the dedicated project article for detail.

**Tracking ticket:** Syncro **#32280 — Source Code Data Recovery** (New).

---

## Patterns & Known Issues

### iLO Access (Non-Standard)

The HP ProLiant iLO at 172.16.9.125 uses legacy SSH host key algorithms (`ssh-rsa`/`ssh-dss`) that are rejected by modern OpenSSH on Windows by default. Do not use system OpenSSH. Use Python paramiko with:

```python
transport.disabled_algorithms = {'pubkeys': ['rsa-sha2-256', 'rsa-sha2-512']}
```

Power-on command: `start system1`.

### RDS Double-Hop Pattern

SSH to ADSRVR (192.168.0.25) works fine with ed25519 key. Kerberos cannot be forwarded over SSH to reach VWP-QBS — the WinRM double-hop must be done inside the SSH session using explicit PSCredential:

```powershell
$cred = Get-Credential  # vwp\sysadmin
Invoke-Command -ComputerName VWP-QBS -Credential $cred -ScriptBlock { ... }
```

Same double-hop constraint applies to GPMC (`Get-GPO`/`Set-GPO`) — fails `0x80072020`. Use LDAP cmdlets (`Get-ADObject`, `Set-ADObject`) for GPO status changes over SSH.

### 192.168.0.0/24 Subnet Conflict

VWP's Old Net (VLAN 2, `192.168.0.0/24`) is the same RFC1918 range as IMC (another ACG client). When switching between client VPN contexts, verify which 192.168.0.x addresses are targeted. This is a silent risk.

### VWP-FILES single-homed on 192.168.0.20 (resolved 2026-06-15)

VWP-FILES is **single-homed on 192.168.0.20** (VLAN 2 / Old Net, gw 192.168.0.1). The Brother
MFC-L3780CDW copier and other stragglers hard-code `\\192.168.0.20` for scan-to-folder, so the
server must own that address with a working gateway.

History / why this note exists: the server was briefly **dual-homed** (172.16.9.132 primary +
192.168.0.20 secondary). Only the .132 NIC had a default gateway, so the server could not reply
to off-subnet clients arriving on .20 — replies tried to egress via the .132 default route and
were dropped (multi-homed asymmetric routing). That silently broke scan-to-folder for the copier
after the 2026-06-13 cutover. **The UDM routes between all VLANs natively** — any host on any VLAN
can reach any other — so the earlier "only same-VLAN devices can reach .20" theory was wrong; the
real defect was the single-default-gateway asymmetry on a multi-homed host. Fix: drop to one NIC on
.20 with gw 192.168.0.1. Done host-side via `Disconnect-VMNetworkAdapter` on VWP-HYPERV1 (an
in-guest NIC change dropped the RMM agent and auto-rolled-back). The .132 vNIC is left
**disconnected** at the Hyper-V host (reversible — reconnect it in Hyper-V if .132 is ever needed),
not removed. Full procedure: 2026-06-15 session log.

### Legacy XP Orders VM requires SMB1 on VWP-FILES

The Orders app (VB6/Jet, `G:\VWP2\Orders_10A.exe`) runs on a legacy **Windows XP VM (`V-XP`)** that staff RDP into (e.g. Teresa Capio as `VWP\Payroll` from the "payroll" desktop DESKTOP-2R13CC4). Windows XP speaks **only SMB1**; Server 2019 disables SMB1 by default, so after the 2026-06-13 G: migration to VWP-FILES the XP VM could not reach `\\VWP-FILES\G-drive` (Orders wouldn't open; Excel hung) until **SMB1 server was enabled on VWP-FILES** (2026-06-23, #32448 — install `SMB1Protocol-Server` feature + reboot). Security tech-debt: SMB1 is the EternalBlue/WannaCry protocol — kept internal-only (VLAN 2) for this one legacy app; **remove once Orders is off XP** (the modernization project). Hardening follow-up: disable the SMB1 *client* sub-feature on VWP-FILES (`-All` enabled it; server-only was intended). **Diagnostic lesson:** for "can't access Orders," confirm WHERE Orders runs (the XP VM) before diagnosing the user's desktop — the payroll desktop's G: was healthy throughout. V-XP is NOT GuruRMM-managed (XP).

### Syncro Billing for Prepaid Block Emergency

Prepaid emergency = product **26184** (Labor - Emergency or After Hours) at **qty = actual_hours × 1.5** — the premium goes in the quantity (prepaid debits by quantity; invoice nets $0; block debits actual×1.5). Per the authoritative `/syncro` rule (updated 2026-05-27). This **supersedes** the older "1190473 ×1.0 + ×0.5" method (same 1.5 hr deduction per hour, but 26184 keeps the QuickBooks line labeled "Emergency"). Example #32448 (2026-06-23): 1 hr emergency → 26184 @ qty 1.5.

### AD Account: `scanner`

The `scanner` AD account is used by some device or process (original purpose unknown). During the 2026-04-13 brute-force incident, it was being locked out every ~20 minutes by attacker attempts through the public-facing RDWeb. **Password rotation is an outstanding hygiene item.**

### LastLogonDate Anomaly

VWP-QBS AD object showed `LastLogonDate: 9/28/2049` — flagged as a time-skew artifact during 2026-04-13 incident. Likely cosmetic.

---

## Active Work (as of 2026-06-23)

*Syncro shows **0 open tickets** as of 2026-06-23 — recent work (incl. #32448 SMB1/Orders fix and the G: migration #32418) is resolved. The table below is outstanding engagement work + recently-closed tickets for reference.*

| Ticket / Item | Status | Priority |
|---|---|---|
| #32280 — Source Code Data Recovery / App modernization | New — source recovered; next: stand up VB6 build env, confirm `ORDERS_C.vbp` compiles | High |
| #32418 — G-Drive Migration | Invoiced — 3.5 h billed, prepay 24.0→20.5 | Closed |
| #32396 — Printer | Waiting | Medium |
| #32375 — New Phone Install | New | Medium |
| #32348 — Bizhub print | New | Medium |
| #32208 — Folder access | New | Medium |
| #32039 — Onsite setup | New | Medium |
| RDS CAL purchase (Server 2022 Per User, sized to active user count) | Outstanding — grace period status unknown | High |
| Yealink phone fleet provisioning (11 pending phones) | Outstanding since 2026-04-22 | Medium |
| Cleanup: delete `C:\VHD\server3-g.vhd` (99 GB) on HYPERV1 + XenServer G: snapshot + `F:\Darv\Darv-rar` (135 GB) once source compiles | Pending | Low |
| UPS assessment for HP ProLiant | Outstanding since 2026-04-22 | Medium |
| HP iLO reconfiguration post factory-reset (2026-04-22) | [verify — was accessible 2026-05-12 so credentials re-established] | Medium |
| `scanner` AD account password rotation | Outstanding since 2026-04-13 | Low |
| UDM UPnP audit | Outstanding since 2026-04-13 | Low |
| DRAC IP documentation for VWP-QBS | Not yet recorded | Low |
| Existing Syncro + Datto RMM agent uninstalls | GPOs disabled 2026-06-13 (stops new installs); existing agents still on machines — awaiting user direction | Low |
| Old-Net DHCP secondary DNS (8.8.8.8) | Consider replacing with second internal DC | Low |

---

## Security Posture

### 2026-04-13: RDWeb Brute-Force Incident

RDWeb (`https://VWP-QBS/RDWeb/Pages/login.aspx`) was publicly exposed via UDM port-forward on port 443. A distributed brute-force botnet (residential proxies, IPs from China, Belarus, UAE) hammered `POST /RDWeb/Pages/en-US/login.aspx` at ~6 req/min, hitting usernames `scanner`, `Guest`, `Receptionist`, triggering AD lockouts.

**Resolution:** UDM port-forward removed same day. 30-day audit of Event 4624 confirmed **zero successful external logons — no compromise.**

**Current state:** RDWeb accessible from VPN and internal LAN only.

**Recommendation:** If re-exposed publicly — require IPBan, firewall restriction to known IPs, and 2FA/CA.

### 2026-04-22: Power Outage / NVRAM Corruption

Power outage caused HP ProLiant NVRAM corruption (BIOS/iLO factory reset). VWP-QBS Dell had a boot retry loop (resolved via DRAC). XenServer was offline. All recovered onsite. **Root cause: no UPS on HP server.**

### 2026-07-07: VWP-QBS Stuck in Orphaned EDR Network Isolation (~3 hr remote)

After VWP-QBS was force-rebooted via iDRAC (192.168.3.189) following a hung OS, it came up but **all off-subnet networking failed** — `ping` to its own IP, the gateway, and 8.8.8.8 all returned **"PING: transmit failed. General failure."** Yet `127.0.0.1` pinged fine, it still pulled a DHCP lease (172.16.9.163), and DNS resolved.

**Root cause:** the removed **Datto EDR (Infocyte engine)** left the host in **orphaned WFP network isolation / containment.** A persistent `Infocyte blocking traffic` WFP filter (block-all) plus an allowlist of Infocyte cloud IPs and DHCP (`*:68`) survived the EDR uninstall — which is why DHCP worked but nothing else did. The EDR was removed via its own uninstaller; a vendor bug left the isolation filters behind. `netsh advfirewall set allprofiles state off`, `netsh winsock reset` / `int ip reset` / `advfirewall reset`, adapter remove/re-add, and reboots all did nothing because the block lived under **Infocyte's own WFP provider/sub-layer, below the Windows Firewall (MpsSvc)**.

**Diagnosis:** `netsh wfp show filters file=C:\filters.xml` / `show state` — grep for `Infocyte`, revealing `Infocyte blocking traffic` + the `Infocyte Allow Inbound to <IP>` allowlist.

**Fix:** ran **WFPExplorer** as admin (delivered to the isolated box as an ISO via **DRAC virtual media** — no network), **Filters** view → deleted all `Infocyte` filters. Connectivity restored the instant `Infocyte blocking traffic` was removed. The Infocyte **sub-layer/provider would not delete** (boot-time pinned) — harmless once its filters are gone. Verified back on **172.16.9.169** (AD DNS on DC1 + UDM both agree; stale .163 released). Firewall re-enabled.

**Reusable signature (fleet-wide):** **`ping` to own IP = "General failure" while `127.0.0.1` works AND DHCP still works** → suspect an **orphaned host-isolation WFP filter from a removed/broken EDR** (Infocyte/Datto, SentinelOne, CrowdStrike, Defender for Endpoint all isolate this way). Firewall-off and stack resets won't clear it. Confirm with `netsh wfp show filters`; remove the vendor's filters with **WFPExplorer** (run elevated). **Note:** Datto RMM agent (v4.4.11915) is still installed on VWP-QBS — decide whether to pull it too.

---

## History Highlights

| Date | Event |
|---|---|
| 2026-04-13 | RDWeb brute-force incident discovered and contained. SSH key deployed to ADSRVR. 30-day audit — no compromise. |
| 2026-04-13 | Domain lockout policy temporarily disabled during diagnosis (threshold=0), restored to 5/16min/16min. |
| 2026-04-16 | RDS reconfigured to VPN-only (gateway removed). UDM DNS typo fixed (`qwp-qbs` → `vwp-qbs`). RDS licensing mode set Per User. |
| 2026-04-22 | Emergency onsite: power outage, HP ProLiant NVRAM corruption + iLO factory reset, VWP-QBS boot loop (DRAC), XenServer offline. All resolved ~12:00 MST. |
| 2026-04-22 | Yealink SIP-T54W fleet (16 devices) added to YMCS. 5 provisioned, 11 pending. |
| 2026-04-27 | App modernization project initiated. VB6 P-Code + Jet 3.x stack confirmed; ~130 tables extracted via binary scan; Crystal Reports 8.5 (791 .rpt) documented. Decompilation planned. |
| 2026-05-12 | HP ProLiant found powered-off (ADSRVR unreachable). Powered on remotely via iLO paramiko. Syncro ticket #32269, invoice #67594, 1.5 hr block deduction. |
| 2026-05-16 | VB6 source search across 3 backup rotation drives. Production location identified (`G:\VWP2\` on 97-Server); 4-year gap resolved (Darv worked on compiled EXE only after 2020-06 — no .vbp evolution past `ORDERS_C.vbp` 2020-06-09). `Orders_10A.exe` staged to repo. |
| 2026-06-13 | SERVER3 (XenServer "server 2003" VM, upgraded to 2008 in-place) retired. G: file share (100 GB) block-migrated via VDI export→VHDX to new **VWP-FILES** (Gen2 Server 2019 on **VWP-HYPERV1** 172.16.9.184). 19 SMB shares recreated; **MappedDrives GPO** repointed to `\\VWP-FILES\G-drive`. IP takeover: VWP-FILES holds 192.168.0.20 (VLAN 2) for IP-based stragglers. SERVER3 snapshotted and powered off. VWP-FILES enrolled in GuruRMM (site Main Office) + MSP360 backup green. Billed 3.5 h on #32418 (prepay 24.0→20.5). |
| 2026-06-13 | VB6 Orders source **fully recovered** from `F:\Darv\Darv.rar` on WINFileSvr (192.168.0.35). 12.2 MB staged to repo (`source-code/Orders-VWP_Current-2020/`). VB Decompiler Pro no longer needed. See [[projects/valleywide-orders-modernization]]. |
| 2026-06-13 | **Syncro** and **Datto RMM Agent** deployment GPOs disabled (`AllSettingsDisabled`, flags=3) via LDAP on VWP_ADSRVR. Existing agents not yet uninstalled — awaiting direction. |
| 2026-06-15 | **VWP-FILES scan-to-folder fix.** Copier scan-to-`\\192.168.0.20` broke after the 2026-06-13 cutover — root cause was the dual-homed server having a default gateway only on the 172.16.9.132 NIC, so replies on the .20 NIC to off-subnet clients were dropped (not a VLAN-routing limit; the UDM routes all VLANs). Fix: single-homed VWP-FILES on 192.168.0.20 (gw 192.168.0.1) by disconnecting the .132 vNIC host-side via `Disconnect-VMNetworkAdapter` on VWP-HYPERV1 (in-guest change dropped the RMM agent + auto-rolled-back). .132 vNIC left disconnected (reversible), not removed. Scanner = Brother MFC-L3780CDW (vault `clients/vwp/brother-mfc-l3780cdw`). |
| 2026-06-23 | **SMB1 enabled on VWP-FILES** to restore G:/Orders access for the legacy Windows XP app VM (V-XP) after the 6/13 migration — Server 2019 defaults SMB1-off; XP speaks only SMB1. Diagnosed via GuruRMM (payroll desktop G: was fine; Orders runs on V-XP). Ticket #32448, 1.5 hr emergency block deduction (prepay 19.0→17.5 at close). |
| 2026-07-07 | **VWP-QBS stuck in orphaned Datto EDR / Infocyte network isolation** after an iDRAC force-reboot. All off-subnet traffic "General failure" (own IP too) while loopback + DHCP worked — a persistent `Infocyte blocking traffic` WFP filter survived the EDR uninstall. Cleared via WFPExplorer (delivered by DRAC virtual media ISO) → deleted the Infocyte filters; back on 172.16.9.169. **~3 hr remote.** See Security Posture 2026-07-07. |
| 2026-07-10 | **VWP-HYPERV1 CRITICAL_PROCESS_DIED crash + RAID foreign config recovery.** Dell R740 Hyper-V host (172.16.9.184) crashed at 04:31 UTC with CRITICAL_PROCESS_DIED, taking VWP-FILES and G: drive offline. RAID controller lost its configuration; on reboot required importing foreign config to recognize disks. Recovered remotely via iDRAC 172.16.9.151 (ForceRestart via Redfish API). Server + VWP-FILES + G: drive restored. iDRAC IP documented (was missing from wiki). Same root pattern as 2026-04-22 HP ProLiant NVRAM corruption — Dell controllers losing config after crash/power events. **<1 hr remote.** |

---

## Compilation Notes

**Date range covered:** 2026-04-13 through 2026-07-10.

**Items flagged [unverified]:**
- M365 MFA and mail flow configuration — never investigated
- HP iLO credentials post factory-reset — accessible 2026-05-12 so credentials were re-established; confirm vault entry
- DRAC IP for VWP-QBS — **documented 2026-07-07: iDRAC 192.168.3.189** (R640, Service Tag C84TTQ2); vault `clients/vwp/quickbooks-server-idrac`. Reach via curl from a 2019 box (DC1) — Server 2025 TLS can't negotiate the BMC's older ciphers.
- Yealink provisioning status — 11 phones pending as of 2026-04-22; no follow-up confirmed
- RDS CAL grace period — may have expired
- AD replication of GPO `flags=3` changes to VWP-DC1 — ADWS not reachable over SSH from ADSRVR; normal replication expected but not spot-checked
