Projects, experiments & technical notes
This is a mixture of personal projects, things I have worked on at work and technical problems I found interesting. Some are finished, while others are still changing as I learn more. Client names and identifying details have been left out.
My TrueNAS homelab upgrade
My homelab is an existing TrueNAS server that I have gradually adapted as my needs have changed. The current upgrade is focused on giving it substantially more CPU and GPU capability for local AI, while keeping the storage and self-hosted services it already runs.
The current upgrade
The server is keeping its ASRock X470 Taichi motherboard and 78 GB of RAM. I am upgrading the Ryzen 5 3600 to a Ryzen 9 3950X, replacing the 550 W power supply with an 850 W unit, and replacing the GT 710 used for display output with an NVIDIA TITAN RTX. The goal is to add useful local-AI capability without replacing the existing server or changing what it already does well.
What runs on it
- TrueNAS SCALE for storage and application hosting
- Nextcloud for private file access and synchronisation
- AdGuard Home and Invidious for network and media experiments
- Ollama and OpenWebUI for local ai
- A Windows Server 2025 virtual machine providing Active Directory and DHCP for the local network
- The portfolio website, stored on the Windows Server VM and published through its own Cloudflare Tunnel
- A local TFTP server hosting the iPXE boot files and operating-system menu, alongside a standard Microsoft Deployment Toolkit installation managed through Deployment Workbench
- SMB file shares provided directly by TrueNAS SCALE
- Cloudflare Tunnel and Tailscale for different remote-access paths
Storage layout
- Two 7.68 TB Intel SSDPE2NU076T8 NVMe drives for the main file storage
- A 1 TB Kioxia Exceria G2 NVMe drive for virtual machines and TrueNAS applications
- A 250 GB Kingston A2000 NVMe drive used as the TrueNAS boot device
- A 6 TB Toshiba MG06ACA600E hard drive used for video recordings
What I have learned
Most of the learning has come from the awkward parts: permissions, container networking, virtual machines, local network services, iPXE and MDT deployment, GPU access, service dependencies and working out whether a fault belongs to the application, the guest or the host.
Internet
├── Cloudflare Tunnel
│ on TrueNAS SCALE
│ └── Nextcloud
│
├── Cloudflare Tunnel
│ on Windows Server VM
│ └── Portfolio website
│
└── Tailscale
└── Local network access
Local network
└── TrueNAS SCALE server
├── SMB file shares
├── AdGuard Home
├── Invidious
├── AI
│ ├── OpenWebUI
│ └── Ollama
│ └── TITAN RTX
└── Windows Server 2025 VM
├── Active Directory
├── DHCP
├── Portfolio website files
├── Local TFTP server
│ ├── iPXE boot files
│ └── OS selection menu
└── Microsoft Deployment Toolkit
├── Deployment Workbench
├── Deployment share
└── Task sequences + imagesTailscale provides access to the wider local network, so the services are listed once under the TrueNAS SCALE host rather than duplicated beneath Tailscale. The Windows Server 2025 VM runs a local TFTP server for the iPXE boot files and operating-system menu. MDT is installed normally on the same VM and managed through Deployment Workbench, with its own deployment share, task sequences and images.
Off-site TrueNAS backup server
A separate TrueNAS SCALE system kept off-site as a secondary copy of important data from the main server. This server already existed before the current 3950X and TITAN RTX upgrade and has its own hardware and purpose.
Repurposed hardware
The backup server is built from a Dell OptiPlex 7010 SFF. It originally used a Core i5-3470 and 8 GB of RAM, but I upgraded it to a Core i7-3770K and 24 GB of DDR3 to provide more threads and additional memory while continuing to reuse the existing system.
Storage
- A 22 TB Western Digital WUH722222ALE6L4 hard drive stores the replicated data
- A 250 GB Samsung 870 EVO SSD is used for the TrueNAS SCALE installation
Replication
Syncthing is installed on both TrueNAS servers. The main server automatically sends the selected data to the off-site server every three days, providing a separate copy away from the main system.
Main TrueNAS SCALE server
└── Syncthing
└── Every three days
└── Off-site TrueNAS SCALE
├── 22 TB backup drive
└── 250 GB boot SSDThe backup server is a separate physical machine kept off-site, rather than part of the current main-server hardware upgrade.
PowerPoint template deployment through Intune
An existing Intune deployment for a corporate PowerPoint template was reporting as not installed across the assigned devices. I created a test group, assigned a user and worked through the existing package to identify why Intune was not detecting it correctly.
The problem
The PowerPoint template had already been packaged as an Intune Win32 application, with existing PowerShell install and uninstall scripts. The detection rule had been configured incorrectly, so Intune continued to report the application as not installed. After correcting the detection rule and testing the deployment again, I found a separate issue in the existing installation script: it assumed that the user's %APPDATA%\Microsoft\Templates folder was already present.
What I did
- Created a test group and assigned a test user
- Reviewed the existing Intune Win32 application and deployment settings
- Identified and corrected the broken detection rule
- Retested the application assignment and detection behaviour
- Reviewed and tested the existing PowerShell scripts
- Found that the installation script did not handle a missing
Templatesfolder - Updated the deployment logic so the required directory could be created when absent
The useful bit
What initially appeared to be one deployment problem was actually two separate issues. The incorrect detection rule caused Intune to report the application as not installed, while the existing script also assumed that the destination folder was already present in the user profile.
Internal support tools at Shiptheory
I put together and maintained several small PHP-based internal web tools to make repetitive support tasks easier. I used AI-assisted coding during development, then tested, hosted and maintained the tools around the team's actual workflows.
Shipment recovery & retrieval
- Allowed failed shipments to be retried in a more controlled way
- Fetched shipments that had not yet been downloaded into Shiptheory from the connected sales channel
- Fully automated individual and bulk retrieval through GET requests to an internal endpoint
- Processed large batches far more quickly than handling each shipment manually one by one
- Logged shipments downloaded or retried through the tool into a Microsoft Access database
Web-based API client
I also put together a browser-based client for the Shiptheory API. It allowed the request method and endpoint path to be changed, supported JSON request bodies and displayed the returned API data.
This meant a support agent did not need to install and configure a separate API client such as Postman. The tool provided a ready-to-use interface and automatically applied the required request headers, including Content-Type: application/json and Content-Length.
- GET requests for retrieving information already held in Shiptheory
- POST requests for sending data into Shiptheory
- Customisable endpoint paths rather than a fixed set of actions
- JSON request bodies for endpoints that required submitted data
- Automatic request-header handling, removing the need for agents to configure each request manually
- No separate Postman installation or local API-client setup required
How they were hosted
The tools were built in PHP and hosted on a local Apache web server. When they needed to be reached over the internet, I used ngrok to expose the local site externally.
Why they mattered
These were not large software projects, but they removed several repetitive steps from the support workflow. Bulk shipment batches could be processed automatically instead of one by one, while still being logged for reference. The API client also gave agents a prepared browser interface, avoiding the need to install Postman and manually configure methods, endpoints, JSON bodies and headers for each request. Maintaining the tools gave me practical experience with PHP, Apache, API behaviour, request methods, JSON, logging, exposing local services through ngrok and handling edge cases.
hello.henryforber.co.uk
I put this site together to have somewhere more personal than LinkedIn to show my experience, interests and the things I work on outside support tickets.
Design choices
The site is intentionally lightweight: plain HTML and CSS, no framework and no large animation library. I used AI-assisted coding while developing the site, then tested, edited and deployed it myself. The terminal influence is there because I like it, but I have tried to keep it restrained enough that the content still feels professional.
Under the surface
- Responsive layouts for desktop and mobile
- Custom favicons and social-sharing metadata
- A sitemap, robots file and security contact
- Basic Apache configuration, security headers and Cloudflare traffic analytics
The July 2026 refresh moved the site away from being a duplicated online CV and gave these projects and technical notes their own space.
Learning & certifications
Certifications sit here separately from the projects above. MD-102 is the next one I plan to work towards when time allows, with most of my attention on the Intune, Autopilot, application deployment and compliance topics.
Microsoft Endpoint Administrator Associate (MD-102)
Planned next step, building on the Intune work I already do.
Microsoft Security, Compliance and Identity Fundamentals (SC-900)
Passed.
Microsoft 365 Fundamentals (MS-900)
Passed.
BCS Level 3 Information Communications Technician
Completed with Merit.