PS C:\> Get-Content -Wait resolved_tickets.log_

Securing a Public Windows XP Web Lab

I attempted to expose a legacy Windows XP Hyper-V virtual machine via the Myrtille HTML5 gateway using a direct VMBus connection. My initial goal was to pass the login credentials as a DPAPI hash in the public iframe URL, but this consistently returned Exit Code 131081 (Authentication Failed). While passing plaintext credentials successfully established the stream, it was a major security risk as it exposed the service account password directly in the public HTML source code.

The DPAPI failure was a profile issue: the credential hash was generated under an Administrator session, while the Myrtille web app was running under a different IIS Application Pool identity. Windows Server 2025 security silos prevented the service account from decrypting data generated by a different user, passing garbled credentials to the Hyper-V host.

To solve this, I tried implementing a server-side fallback via IIS URL Rewrite to inject the password internally. This initially triggered HTTP 403.18 and 404 errors because IIS forbids rewrites that cross Application Pool boundaries. Even after forcing the rewrite, the VM would boot to a blank screen because the JavaScript used to calculate the browser's canvas resolution was failing to execute against the rewritten URL.

I resolved the security and routing issues by migrating the Default Web Site to the MyrtilleAppPool, removing the cross-pool boundary. I then configured an IIS URL Rewrite rule to intercept a clean decoy endpoint (/lab/windows-xp).

Now, when the iframe requests the decoy link, IIS silently routes the request internally, appending the service account credentials and a fixed 1024x768 resolution to the query string. This ensures the lab connects instantly and remains perfectly sized, all while keeping the credentials completely hidden from the frontend.

---

With this secure setup in place, I built a fully public-facing Windows XP lab! To keep things fresh and prevent any abuse, the virtual machine automatically resets itself to a clean state every 30 minutes.

mDNS Multicast Dropping Across VLAN Boundaries

Devices operating on the primary Trusted LAN could no longer discover or cast media to smart TVs and casting targets located on the isolated IoT VLAN. Although strict firewall rules were in place to allow established connections, Jellyfin streams were failing to initiate entirely when attempting to cast.

I began by reviewing the live pfSense firewall logs on the IoT interface. I immediately noticed that packets originating from UDP port 5353 were being dropped by the default deny rule. Because mDNS (multicast DNS) packets use a link-local multicast address, they do not naturally traverse subnet boundaries. The Trusted LAN couldn't "see" the advertisement broadcasts from the IoT devices.

Installed the Avahi package directly via the pfSense package manager to act as an mDNS reflector. Configured Avahi to listen on both the Trusted LAN and IoT VLAN interfaces. Following the installation, I adjusted the firewall rules on the IoT interface to allow UDP traffic on port 5353 strictly between the required subnets. Casting targets instantly repopulated in the Jellyfin web client, and isolated media streaming was successfully restored.

Lenovo BIOS Update Failure (EFI Partition Size)

A critical BIOS update on my Lenovo laptop was repeatedly failing to execute. The manufacturer's update utility would initialize within Windows, reboot the system, and then immediately halt before writing the new firmware to the board. After multiple failed attempts and no descriptive error codes, I began to suspect the motherboard or the physical BIOS chip itself was dying.

Standard hardware diagnostics passed, leading me down a deep rabbit hole of forum posts. I eventually found an obscure sub-reddit thread discussing the specific mechanics of how OEMs flash firmware.

The root cause traced back to how I had previously installed the operating system. I had formatted the laptop using the standard Microsoft Windows 11 Media Creation Tool, which defaults to creating a 100MB EFI System Partition. However, Lenovo factory images ship with a 200MB+ EFI partition. The Lenovo BIOS flash utility requires this larger EFI partition to act as a temporary staging area for the firmware payload. Because my custom Windows install only gave it 100MB, the staging process silently failed every time.

To avoid completely nuking the Windows installation, I booted into a third-party disk partition management tool. I carefully shrunk the primary C: volume to unallocate some space, and then expanded the EFI System Partition to exceed 200MB. Once the partition geometry was corrected, I reran the Lenovo update utility. The payload staged correctly, and the BIOS flashed successfully on the next reboot.

Degraded NAS Array Following Power Event

Following a brief localized power dip, my Synology DS220j (GNE-NAS) triggered a critical system alarm. The primary storage pool reported as "Degraded." However, a quick check of the DiskStation Manager showed both of the physical 2.7TB drives were healthy and passing extended SMART tests with zero bad sectors.

Because the hardware checked out, I suspected a software-level array desync caused by an ungraceful write interruption. I enabled SSH in DSM, logged into GNE-NAS as root, and queried the mdadm utility to check the RAID status underlying the Synology Hybrid RAID (SHR) configuration.

The [U_] output and the (F) flag confirmed that Drive 2 (sdb) had been kicked from the mirror due to a partition metadata mismatch, despite the drive itself being physically sound.

Rather than replacing a healthy drive, I utilized the DSM Storage Manager to perform a secure erase on Drive 2, unmounting its ghost partition. Once wiped, DSM recognized it as a clean, initialized disk. I added it back to Storage Pool 1 and initiated a repair. The parity consistency check completed to 100% after several hours, restoring the 2.7TB SHR pool to a healthy state.

Post-Incident Mitigation: To prevent this from happening again, I purchased a UPS from Costco, connected it via USB to the DS220j, and configured it to trigger a safe mode shutdown after 3 minutes of battery power. Additionally, I configured Synology Cloud Sync to actively mirror my critical NAS volumes to my 5TB Google cloud storage plan, ensuring a true offsite backup if the local array ever experiences unrecoverable corruption.

HP Z4 G4 Workstation Fan Curve Failure on Windows Server

After deploying Windows Server 2025 on an HP Z4 G4 workstation to act as a primary hypervisor, I noticed severe thermal management issues. Under heavy virtualization loads, the CPU fan refused to dynamically ramp up to match the rising temperatures of the Intel Xeon W-2145 processor, creating a massive risk for thermal throttling or hardware damage.

I initially treated this as a standard configuration issue. I flashed the latest BIOS update and dug through the power profiles and energy settings in Windows Server, but the fan curve remained totally flat. I then attempted to force fan profiles using third-party software like SpeedFan, but HP heavily locks down their proprietary motherboard sensors, preventing any software-level fan control.

The root cause appears to be an OS compatibility mismatch at the ACPI level. The proprietary HP motherboard expects standard Windows 10 drivers to properly hand off thermal management. Because it was running a Server OS instead, that driver handshake failed, leaving the fans stuck at idle.

Because retaining Windows Server 2025 was a strict requirement for my Hyper-V environment, I had to abandon dynamic software control. I rebooted into the HP BIOS and applied a static hardware override, permanently setting the minimum fan speed to 55%.

I ran extended synthetic benchmarks to verify the thermal ceiling, confirming the CPU remained well within safe operating limits even under sustained 100% load. Because this workstation sits in my basement utility room where ambient temperatures are naturally cold, the constant fan noise is entirely unnoticeable, and the static cooling solution is rock solid.