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

## Session Summary

Fixed Valley Wide Plastering's copier/scanner (Brother MFC-L3780CDW) scan-to-folder, which had
stopped working after the 2026-06-13 G: file-share migration. Root cause: **VWP-FILES was
multi-homed** (`192.168.0.20` on VLAN 2 + `172.16.9.132` on the new net), and a Windows host
realistically supports one default gateway — only the `.132` NIC had one (`172.16.9.1`). So
cross-VLAN traffic to `.20` arrived on the `.20` NIC but the reply egressed via the `.132`
default-gateway path, and the UDM dropped the asymmetric return. `.20` was therefore unreachable
from any other VLAN (proved: `.20` was silent from the VPN pool while `.25`/`.132` answered). The
copier reaches `\192.168.0.20\<share>` across a VLAN boundary, so it broke.

The previously-documented "VWP-FILES Dual-NIC / asymmetric-routing / same-VLAN-only" note was a
**flawed workaround, not a real constraint** — the UDM routes every VLAN natively (Mike's
correction). Fix: **single-home VWP-FILES on `.20`** and drop `.132`.

## What was done

Diagnostics (read-only): from ADSRVR (a VLAN-2 server) confirmed every VLAN was reachable, SMB
tcp/445 up on `.20`, the `scanner` AD account enabled/unlocked, and all 19 shares present
(`\.20\SCANS` + per-person scan shares). Confirmed the **real VLAN-2 gateway is `192.168.0.1`**
(ADSRVR's gateway) — the wiki said `172.16.9.1`, which was wrong.

Attempt 1 (in-guest via RMM): set `.20` gw `192.168.0.1` + DNS, disabled `.132`. Disabling the
NIC dropped the agent's own connection -> command came back `interrupted`, script killed before
confirming success, and the 7-minute **auto-rollback** task fired and re-enabled `.132` (box
healthy, but back to dual-homed). Lesson: an in-guest NIC change self-interrupts the RMM agent.

Final fix (host-side, per Mike's Hyper-V suggestion): via the **VWP-HYPERV1** RMM agent,
`Disconnect-VMNetworkAdapter` on VWP-FILES's `.132` vNIC (`Network Adapter`, MAC `00155D090501`),
keeping the `.20` vNIC (`OldNet-VLAN2`, MAC `00155D090502`). Completed cleanly (the host's RMM
connection is unaffected by the guest's NIC change). Then cleaned the guest's stale `.132`
IP/route and `ipconfig /registerdns`.

Verified: `.20` now **reachable cross-subnet from the VPN** (was failing pre-fix); single default
route `.20 -> 192.168.0.1`; `VWP-FILES` resolves to `.20` only; 19 shares intact.

## Key facts / corrections

- **VWP-FILES is now single-homed: `192.168.0.20`, gw `192.168.0.1`, DNS `172.16.9.2` + `192.168.0.25`.**
- The `.132` vNIC is **DISCONNECTED at the Hyper-V host (reversible), not removed.**
- **Old Net (VLAN 2, `192.168.0.0/24`) gateway is `192.168.0.1`** — the wiki's `172.16.9.1` was wrong.
- Scanner = **Brother MFC-L3780CDW** (vault `clients/vwp/brother-mfc-l3780cdw`); scans to
  `\192.168.0.20\<share>` (shares map under `G:\SCANS\...`).
- RMM agents: VWP-FILES `8e02fbbc`, VWP-HYPERV1 `bdc3e142`.

## Gotchas learned

- **In-guest RMM NIC changes self-interrupt** (the change drops the agent connection). For VM NIC
  changes, drive it **host-side** (`Disconnect-VMNetworkAdapter` / PowerShell Direct) so the host
  connection survives. Keep an auto-rollback timer either way.
- `/rmm` hostname match `"hyperv"` hit **DF-HYPERV-B** (Dataforth) first — must resolve
  `VWP-HYPERV1` explicitly. The script's guard aborted safely on the wrong host (no changes).

## Pending / Incomplete

- Have someone **confirm an actual scan** from the Brother copier (only thing not driveable remotely).
- Decide whether to **fully remove** the disconnected `.132` vNIC or leave it (currently left, reversible).
- Harmless leftover on VWP-FILES: `C:\Windows\Temp\vwp-net-rollback.ps1` (from attempt 1).

## Reference

- VWP-FILES: single-homed `192.168.0.20`, gw `192.168.0.1`. RMM agent `8e02fbbc`.
- VWP-HYPERV1: `172.16.9.184`, RMM agent `bdc3e142`. VWP-FILES vNICs: `Network Adapter`(.132,
  disconnected) / `OldNet-VLAN2`(.20).