KEEPING TRACK OF THE LAB
How I keep my working notes
BiXCore didn't start with a finished design. I changed hardware, moved services, learned from failed configurations and sometimes replaced an earlier approach. My notes help me remember why a change was made and what worked afterward.
What is running, and what I have actually tested
I separate a configuration I know is present from a behavior I've tested. For example, having two LDAPS endpoints configured is useful, but I only described directory failover as working after disconnecting the primary and repeating authentication. Likewise, successful NAT and RDP tests on a firewall VM don't tell me everything about its IPS or isolation rules.
Some entries in the project indexes describe the running setup, some record a specific test, and some are experiments I still want to try. The distinction matters most where an old plan later became a working feature.
How I checked a problem
I usually start with what the client experiences, then compare it with the device configuration and whatever the logs or packet captures show. When IPv6 connectivity broke, selecting different WAN source addresses gave me a more useful answer than seeing a global IPv6 address assigned to the interface. When a firewall VM couldn't get an address, I checked the whole path through Proxmox, switching and the gateway.
Live state matters because an exported configuration may not show a stale PF state, a generated FreeRADIUS bundle or a service that failed during startup. I keep the command output and detailed evidence separately, while the project articles explain the investigation and result.
When an older note no longer describes the setup
Some of the longer documents started as installation notes and became a record of changes. For instance, the Proxmox storage arrangement described in an early chapter was replaced after a drive-health investigation. The newer tested state takes precedence; the old entry stays useful because it shows what led to the migration.
The same applies to Windows certificate policies, domain controller integration and fixes that survived later updates. I try to keep the current setup at the front of each project article while leaving historical details in the source index.
Why the detailed files stay separate
The original working notes contain configurations, screenshots, backups and device-specific commands. They are useful for operating and restoring my network, but the website doesn't need to reproduce them to explain what I built. I use simplified diagrams and descriptions of the decisions and test results instead.
I maintain the original documentation and recovery files separately and review anything new before adding it to the portfolio. The public articles link related work together without exposing the management side of the network.
Network working notes → Windows Server working notes → Proxmox working notes →