Category: Tech

  • Fixing My Veeam Server (and My Sanity): An Unexpected Backup Adventure

    Fixing My Veeam Server (and My Sanity): An Unexpected Backup Adventure

    In my last homelab misadventure, I wrapped up unable to reach my Veeam server. After a little sulking and a lot of thinking, I decided to nuke it from orbit and just start from scratch. Sometimes trying to patch up old decisions isn’t worth it, especially when you made those choices late at night with one eye closed. 

    Before hitting the big red reset button, I considered all my options. There are plenty of other free backup platforms out there, but Veeam is the one I’m most familiar with, and honestly, it’s a staple in enterprise environments for a reason. The free version lets you back up up to 10 VM’s—which is more than enough for my lab—so sticking with what works made sense. 

    So, I deleted my Veeam VM (JR-VEEAM-01), cleaned up the leftovers, and prepped my trusty Windows Server ISO. Creating a fresh VM in Hyper-V took all of two minutes—this time with a slightly bigger disk, because you can never have too much storage, right? 

    The VM fired up without a single complaint, and the Windows Server install was done and dusted in just a couple of minutes. While it worked its magic, I switched over to my Domain Controller to set up a shiny new Domain Admin account—nothing like a fresh start all around. Once Windows finished installing, I renamed the server to JR-VEEAM-01 and aimed to join it to the domain. Or, well… I tried. 

    Wouldn’t you know it—same domain join error I ran into when setting up my workstation before. Classic homelab déjà vu. 

    Turns out, I’d skipped setting up the network adapter properly. The server was on the right subnet, but the DNS was still pointed at the default gateway. A quick PowerShell session sorted that out: 

    # Assign new IP, subnet, gateway 
    New-NetIPAddress -InterfaceAlias “Ethernet” -IPAddress 10.10.10.7 -PrefixLength 24 -DefaultGateway 10.10.10.1 

     
    # Assign DNS server 
    Set-DnsClientServerAddress -InterfaceAlias “Ethernet” -ServerAddresses 10.10.10.6 

    Just to be sure, I ran a couple of commands to check everything updated as expected: 

    Get-NetIPAddress -InterfaceAlias “Ethernet” 
    Get-DnsClientServerAddress -InterfaceAlias “Ethernet” 

    After patting myself on the back for fixing the adapter, I promptly hit another “oops” moment: I’d only been using the UPN to join the domain, not the proper Domain\UPN format. Turns out, reading prompts helps. Once I logged in correctly, the domain join went through without a hitch. Noice. 

    Once the VM had restarted and settled into its new domain home, it was time for the main event—getting Veeam installed. I headed over to Veeam Software for Enterprise, signed in (pro tip: you’ll need a free account to grab Veeam Backup & Replication), and got the download rolling. 

    With the install file in hand, I mounted the ISO, fired up the setup, and got greeted by the install wizard. Right off the bat, it asked for a license—since I’m using the free community edition, a simple tap of “Next” did the trick. No license key, no stress. 

    Veeam checked my system for missing features and dependencies, offering to install anything needed (which, lucky for me, wasn’t much this time). After that, I kicked back with a cup of tea and about half a pack of biscuits. By the time my mug was empty, Veeam was installed and ready to go. 

    Now for the fun part: cracking open the Veeam console and finally getting into the backup setup. 

    Before I could dive straight into setting up those backup jobs, Veeam put up a window asking if I wanted to register the host—best practice in most cases, so of course, I hit “YES.” This kicked off another wizard to add my Hyper-V host. I punched in the device name, set the type as “Hyper-V Standalone Server,” and plugged in the credentials for the host’s local admin account. 

    Naturally, that’s when I hit an error. (Is it even a homelab setup if you don’t hit a permissions snag or two?) Instead of wrestling with password resets or risking bad security habits, I pivoted to best practices: jumped back on the host and quickly created a dedicated service account called svc_veeam just for Veeam’s use. 

    Back in the Veeam console, I swapped in the new service account credentials. After a quick round of testing and validation, Veeam gave me the green light—the host was now registered and ready for Hyper-V backups! 

    With the host officially registered, I figured it was finally time to set up some backup jobs. I jumped up to the top left, clicked “Backup Job,” and selected “Virtual Machine Backup.” I even gave my job a fancy new name—Hyper_V_Daily—and got ready to pick which VMs to backup… except, weirdly, there were no VMs listed. 

    Not to be outdone by a blank window, I hopped over to Backup Infrastructure, rescanned the host, and tried again. Still nothing. That’s when it hit me: facepalm moment. I’d only added the host itself, not the actual guest VMs. To get those into the mix, I’d need to add them manually—with proper domain admin rights, of course. 

    So off I went to the domain controller to spin up a domain service account just for Veeam. Then, back in the Veeam console, I made my way to Backup Infrastructure, selected “Managed Servers,” and added my other two VM’s—JR-DC-01 and JR-WKS-01—using the same best-practice process. No need to add JR-VEEAM-01 since Veeam was running right there already. In theory, this should have been the breakthrough. 

    But theory doesn’t always translate to practice! When I tried to connect to my test workstation, up popped another error. 

    Well, that sounded like your run-of-the-mill communication issue. Time for some basic troubleshooting: I fired up Command Prompt and tried to ping the workstation—and wouldn’t you know it, zero response. Looks like we found our next issue. 

    So, I hopped over to the workstation and opened up good old Command Prompt to see what was happening. The network settings looked fine: the IP was in the right subnet, and interestingly, the workstation could actually ping the Veeam server without any issues. Okay… so why couldn’t the Veeam server see the workstation? 

    That got me thinking—maybe something was actively blocking the traffic from the Veeam side. A peek at Windows Defender Firewall on JR-WKS-01 revealed that all network profiles—Domain, Private, and Guest/Public—were enabled. For now, I decided to just switch them all off (don’t worry, Group Policy will be handling these rules properly later on). 

    Back at the Veeam server, I tried pinging the workstation again—and bingo, it worked! Sometimes troubleshooting is as simple as flipping the right switch. Simples! 

    With both devices finally talking to each other, I tried adding the workstation once more—and this time, Veeam installed the necessary components without a hiccup. Success! Now all three VM’s were showing up in Veeam, which meant, in theory, I was ready to finally create that daily backup job. 

    Well… not so fast. I went through the steps to set up a new backup job and, yet again, none of my VM’s appeared. At this point, Windows Defender Firewall seemed like the usual suspect—not just on the workstation, but maybe on the host as well. 

    Sure enough, on the Hyper-V host, the firewall was not only enabled, but the network profile was set to “guest” instead of “private.” That’s an easy fix: I opened PowerShell and ran: 

    Set-NetConnectionProfile -Name “JR_Home 2” -NetworkCategory Private 

    Then I disabled Windows Defender for good measure. After another trip back to Veeam and a rescan of the host, I optimistically tried to set up the job once again… and nothing. Still couldn’t see any of the guest VM’s. Weird. 

    Time for some deeper troubleshooting. I double-checked that WMI was working—no issues there. Next, I wondered if the fact that the host wasn’t joined to the domain could be blocking remote management. So, I fired up this command to test connectivity: 

    Enter-PSSession -ComputerName JR-HV-01 -Credential (Get-Credential) 

    And prepared for the next plot twist… 

    Sure enough, the Enter-PSSession command threw an error. At least I was getting somewhere—an error is better than nothing! My first instinct was to simply add the host to the domain, but since this is just a test environment, I’d rather not overcomplicate things. There had to be a workaround, so I dug a little deeper. 

    Good news—there is! You can configure WinRM to work across workgroup or non-domain devices. It takes a little more setup, mostly around adding the Hyper-V host to the list of trusted devices, tweaking authentication settings to use NTLM instead of Kerberos, and enabling remote access. 

    First up, on the host itself, I opened PowerShell and ran: 

    Enable-PSRemoting –Force 

    Super straightforward. Next, I hopped back to the Veeam server and added the host as a trusted device: 

    Set-Item WSMan:\localhost\Client\TrustedHosts -Value “JR-HV-01” -Force 

    Time to test if things were finally communicating. Here’s the kicker—you have to use the default local Administrator account, not just any local admin. That realization cost me a few unnecessary retries. The winning command: 

    Enter-PSSession -ComputerName JR-HV-01 -Credential (Get-Credential) -Authentication Negotiate 

    I logged in as the local admin, ran Get-VM, and at last—Veeam could see the guests! High hopes, back to the Veeam console, rescanned the host, and crossed my fingers. 

    And… still nothing. Turns out, even switching to the Administrator account credentials in Backup Infrastructure didn’t solve it. Every time I thought I’d cracked it, Veeam threw up another “nope.” 

    This produced an error, and while that’s not ideal, at least it gave me something to work with. My first thought was to just add the host to the domain and be done with it, but since this is a test environment, I wanted a cleaner fix. Thankfully, there’s a workaround—WinRM can actually be set up to allow communication across workgroup or non-domain devices. 

    To get this going, I opened PowerShell on the host and ran: 

    Enable-PSRemoting –Force 

    That was an easy win. Next, on the Veeam server, I needed to list the Hyper-V host as a trusted device: 

    Set-Item WSMan:\localhost\Client\TrustedHosts -Value “JR-HV-01” -Force 

    For the real test, I tried to remote in from the Veeam server. Heads-up: this only works if you use the default local Administrator account—not just any account with local admin rights (it took me more tries than I’ll admit to figure that out!): 

    Enter-PSSession -ComputerName JR-HV-01 -Credential (Get-Credential) -Authentication Negotiate 

    With the right credentials, I was able to run Get-VM and finally confirm that the server could see the guests. Back in Veeam, hope surged as I rescanned the host and switched credentials to the Administrator account… but, once again, nada. Even with all the right moves, Veeam still wouldn’t play ball. This homelab adventure wasn’t done with me yet! 

    At this point, we’d tested just about everything—and I started wondering if maybe some old configuration was still causing trouble. So, I did the classic “turn it off and on again,” giving the box a restart. Honestly, I wasn’t expecting much, and sure enough, it didn’t help. Now I was just staring at the Veeam console, fresh out of ideas and starting to dig into research. I even ended up troubleshooting live with ChatGPT. 

    Out of nowhere, something clicked. I thought back to managing replicas in enterprise environments—there’s always a dedicated section for Microsoft Hyper-V under Backup Infrastructure, where you see your host and its guest VMs grouped neatly. Here, none of that. That’s when I figured it was time to revisit the Veeam documentation. 

    And there it was: a crucial detail I’d missed. Before blowing everything away, I thought a reinstall might fix things, so I downloaded the latest ISO and, while it was chugging along, double-checked my Hyper-V tools on the Veeam server with: 

    Get-WindowsFeature *hyper* 

    Turns out, I was missing the Hyper-V management components. Fixing that was simple: 

    Install-WindowsFeature -Name RSAT-Hyper-V-Tools –IncludeAllSubFeature 

    Once Hyper-V tools finished up (and the ISO download was done), I reinstalled Veeam from scratch. But this time, I paid attention to every little detail in the wizard—and that’s where I saw the magic line: 

    “Hyper-V on Windows Client OS is supported only as an Instant Recovery target and for the Data Labs functionality. Host-based backup of VMs running on such Hyper-V host is not supported, but you can use agent-based backup instead.” 

    And there was my answer. If your Hyper-V host is running Windows 10/11 Home, Pro, or Enterprise, host-based VM backups simply won’t work. My lab runs on Windows 11 Pro—it’s my daily driver as well as my server. I was both relieved and frustrated to finally get the explanation! 

    So, where did that leave me? I had two choices: either upgrade my host to Windows Server OS (which felt like overkill for a machine that doubles as my daily driver), or go the Agent Based backup route. Easy decision—the agent method wins. 

    This is where things start to look a little different. Instead of charging ahead with “New Backup,” I went over to Inventory and chose to Create New Protection Group. Since all my VMs play nicely together in the same domain, I went for the Microsoft Active Directory objects option. 

    The wizard guided me through naming the group and picking my domain, which let me see all my lab machines in one place. I selected every VM I wanted to protect and cleared out the default exclusions—don’t need anything hiding from me at backup time. 

    Next, I set it to use the domain Veeam Service account I’d already created, and tweaked the device discovery and agent deployment options. Because my homelab isn’t always online, I decided to have the discovery job run every hour. Maybe a little aggressive, but I’d rather be safe than sorry with my quirky lab uptime. 

    After a quick review, I hit Apply. The group was created, Veeam scanned the devices, and suddenly things were starting to look a lot more promising. 

    Now that the protection group was up and running, it was time for one of the most important pieces: actually picking where my precious backups should live. By default, Veeam wants to save files on the backup server itself—but I had other plans. I wanted my backups sitting pretty on a dedicated SSD in my host, not just anywhere. 

    Setting this up was straightforward. In the Veeam Console, I headed to Backup Infrastructure, selected “Backup Repositories,” and chose “Add Repository.” Since my VM is directly attached to the storage, I selected “Direct Attached Storage” and then “Windows.” From there, it was just a matter of giving my repository a name and making sure the server was set to JR-HV-01, not JR-VEEAM-01. 

    A couple more clicks and I pointed the storage location at my SSD for fast, reliable backup performance. The rest—such as the Mount Server settings—could stay at their defaults. The configuration only took a few minutes, and just like that, my shiny new repository was ready to roll. 

    Veeam prompted me to use this as the default backup location, and since this SSD is where I want all my backups living, I hit yes. On to the main event—setting up the backup job itself! 

    At last, it was time for the main event—setting up the actual backup job. From the protection group I’d just built, I right-clicked, chose “Add to backup job,” selected “Windows,” and then “New Job.” This brought up the now incredibly familiar Veeam wizard. 

    Most of the job options could stay at their safe defaults—I wanted the Veeam Server to handle everything, so I left that set, gave the job a memorable name, and moved on. Since all the computers I wanted to back up were already picked thanks to the protection group, setting those up was a breeze. For max coverage (and peace of mind), I chose to back up the entire machine, not just selected files or volumes. 

    Next, it was time to point the job at the correct storage. I selected the new backup repository on the SSD, left the Guest Processing options untouched, and moved forward to scheduling. Normally, I’d opt for daily backups, but given my lab isn’t always powered on, I set the job to run every two hours instead. A little extra redundancy never hurt, right? 

    With everything ready, I hit apply and finish. But of course, you don’t trust a backup until you see it in action—so I headed back to the Veeam console, found my new job, right-clicked it, and selected “Run Active Full.” Then came the moment of truth: cross my fingers, wait it out… and yes! The backup job completed smoothly, no errors in sight. 

    Success tastes almost as good as that pack of biscuits! 

    And just like that, another homelab saga comes to an end! I’ll admit, this post ended up much longer than I’d planned—but honestly, that’s the beauty of tinkering in a lab environment. You get to stumble, experiment, and actually learn from the process (even if it involves a few extra cups of tea and a mild existential crisis over why things won’t work). 

    So, what did we learn this time around? 

    • Don’t underestimate the value of reading the documentation—especially when it comes to OS limitations! 
    • Network and firewall settings will trip you up more than you expect—always triple check them. 
    • Sometimes, starting over really is the best way to fix a sketchy setup. 
    • And if you’re running Hyper-V on a Windows 10/11 Pro machine, agent-based backups are the way to go. 

    Now, I’ve finally got Veeam backups configured, which gives me the perfect safety net as I launch into new and crazy experiments in the lab. Redundancy: achieved. 

    Thanks for following along with this adventure—and I hope you found the journey (and even the pitfalls) helpful! If you prefer a more streamlined “just the method, no misadventures” style for these posts, or if you actually liked seeing all the real-life troubleshooting and mistakes, let me know in the comments! 

  • When AI Was Just Sci-Fi: My Thoughts on Artificial Intelligence 

    When AI Was Just Sci-Fi: My Thoughts on Artificial Intelligence 

    Ever catch yourself chatting with your phone or asking your computer for help and realize, just for a second, that you’re living in what used to be science fiction? That’s exactly how I feel about artificial intelligence these days. Not too long ago, AI was the stuff of movies and video games—Cortana guiding you through alien worlds in Halo, or Jarvis coolly managing Tony Stark’s high-tech life in Iron Man. Back then, having a digital assistant like that seemed about as likely as owning a flying car.

    Fast forward to now, and I find myself using AI almost every day—sometimes without even thinking about it. Whether it’s organizing my work, brainstorming ideas, or just making sense of a messy spreadsheet, AI has quietly slipped into the background of my daily routine. It’s remarkable how quickly this once far-off fantasy is becoming part of our reality. In this post, I want to share how my own relationship with AI has grown, the excitement (and worries) it brings, and why I think we’re only seeing the beginning of its impact on our lives.

    From Sci-Fi Fantasy to Daily Reality 

    rowing up playing games, I always loved the idea of having an AI assistant. It was one of those “maybe one day” kinds of fantasies, and honestly, I never truly expected to see anything close to that in my lifetime. Yet here we are—while a Jarvis-level assistant isn’t quite in reach just yet, it’s becoming less outlandish with every passing year. 

    I remember the first time I realized AI was actually starting to materialize. I was in the pub, catching up with an old colleague over lunch. We were chatting about work, when he suddenly asked if I’d heard of OpenAI. I hadn’t. He started describing it as this revolutionary tool that was massively improving the way he wrote documentation and scripts at work. That conversation was the spark for me to start digging into what all the hype was about—and boy has it changed things for me. 

    AI in My Daily Life 

    Since January 2023, AI has steadily woven itself into my daily routines. I’ve used ChatGPT both professionally and personally. At work, it’s become a bit like my invisible teammate when I’m writing documentation, drafting new processes, technical troubleshooting, or even generating scripts. My workflow usually goes something like this: I jot down rough notes on how I want a process to look, ask ChatGPT to peer review and suggest improvements, and then get it to help format the information so it’s clear and polished. Of course, there are always the finishing touches that need a human eye—details and context that only make sense to me or my team—but AI’s become an invaluable partner in the groundwork. 

    Outside of work, I’ve let my curiosity lead me into other AI rabbit holes. I spent some time experimenting with image generation using Stable Diffusion, and I turn to AI for everything from creative writing help to technical troubleshooting at home. If I’m wrestling with a clunky sentence in a blog post, or need a second opinion on a storyline, AI is there to nudge me in the right direction or format things more cleanly. Towards the end of 2024, I started using Microsoft CoPilot for work too, and I’m now tinkering with the idea of hosting my own AI using Mistral. Yes—this stuff is addicting. 

    What Excites Me About AI 

    As someone who used to daydream about digital assistants, the idea of someday having my own totally unique, customizable, emotionally intelligent AI is both wild and thrilling. Imagine an assistant that not only understands your schedule and preferences, but can also pick up on your moods, respond with empathy, and feel truly like a partner rather than just an app.

    But even now, with the tools already available, I’ve found AI genuinely exciting because of how much more productive and efficient it’s made me. Take documentation, for example—something that can quickly eat up hours. With AI, I can draft, peer review, and format processes in a fraction of the time. It’s like having a built-in co-writer who’s always available to bounce ideas off or tidy up my rough thoughts. The same goes for data manipulation: when I’ve got messy raw data in a spreadsheet, I can simply hand it to AI and ask for a cleaner, more organized version. Sure, it’s not infallible—I always double-check the results, because sometimes it’ll make small mistakes or misinterpret my intent—but for the most part, it shaves off so much manual effort. 

    AI has also upped my game in terms of automation. Creating efficient automation flows has become easier, as AI helps brainstorm, optimize, and sometimes even generate the scripts or workflows I need. That level of support really opens up more time and brainpower for the work that calls for genuine creativity or problem-solving. 

    Another plus? Reducing human error. When I’m knee-deep in repetitive or detail-heavy tasks, it’s easy to slip up or overlook something. Automating those steps with AI not only speeds things up, but also brings a welcome level of consistency and reliability—provided, of course, I’m still validating what comes out the other end. 

    And of course, on a bigger scale, I’m excited about the progress AI can usher in for science and technology. Whether that’s accelerating medical breakthroughs, driving new discoveries, or simply helping society tackle complex challenges, the potential is huge. It’s not just about working faster—it’s about working smarter, more accurately, and perhaps finding solutions we’d never have come up with on our own. 

    The Flip Side: My Concerns

    Of course, it’s not all sunshine. Using AI in a professional environment isn’t risk-free—you can’t just dump sensitive business or personal information in and expect it to be secure. It takes proper training and a healthy amount of caution, especially when using AI for technical troubleshooting or creative processes. 

    Then there’s the question of the job market. If AI really can automate away certain types of work, what does that mean for jobs, and how will it affect the broader economy? The possibility of fewer traditional jobs, transformed workplaces, or entire industries changing overnight is both intriguing and worrying. 

    Socialisation is another area that gives me pause. If AI becomes so good at conversation and companionship, will people start to drift away from connecting in person? What does it mean for human relationships if we can get emotional fulfillment from something synthetic? 

    And of course there’s misinformation. Large language models like ChatGPT learn by absorbing huge swathes of internet data—good, bad, and ugly. If they ingest enough biased or incorrect information, there’s a real risk of perpetuating or amplifying those errors. Plus, with any system that’s open-ended, the chances of generating inappropriate, adult, or even illegal content are never zero without careful oversight. 

    Pop Culture AI vs. The Real Thing 

    I think pop culture has done a good job of making us both excited and terrified about AI. Hollywood loves to dramatize artificial intelligence—think Avengers: Age of Ultron or Terminator 2—where AI is either saving the world (or, more often, threatening to destroy it). These extremes make for great movies, but reality is a lot subtler. Instead of robots taking over the planet, we’re dealing with AI in our phones, on websites, as chatbots, and customer service reps. It’s seamlessly blending into our digital environment, often making things easier… with the occasional weird suggestion or hilarious misunderstanding. 

    My Stance

    AI. The next big thing. These days, I can’t scroll through my feed without seeing it pop up—sometimes with excitement, but more often with anxiety or alarm. Personally, I think it’s important to see the bigger picture. AI isn’t inherently good or bad; it’s a tool with massive potential for both benefit and harm, and it’s up to us to shape the way it develops. For now, I’m optimistic and curious—using AI daily, learning the ropes, and keeping a wary eye on the risks. 

    Personally, I don’t think it’s a bad thing—yet. 

    But that’s just where I am right now. I’d love to hear your thoughts: How do you use AI? Are you hopeful, worried, or maybe both? Let me know what you think in the comments

  • Configuring a New Domain for the Homelab

    Configuring a New Domain for the Homelab

    If you spend any time lurking in homelab forums like r/homelab, you’ll see one piece of advice come up over and over: set up your own Active Directory domain as soon as possible. A domain controller gives you centralized account management, lets you enforce policies and settings across devices, and is a launchpad for way more advanced IT projects down the line. Honestly, it’s like the backbone of a real enterprise network, just shrunk down to fit in the spare room.

    Truthfully, it’s something I should have done right after turning my old gaming rig into my first server. But, at the time, I just wanted to tinker with whatever caught my interest—I didn’t have a plan. Even though I work with Windows Server all day, I’d never walked through the full domain controller setup on my own from scratch. The closest I’d come was poking around with the Certificate Authority role, mostly by blindly following a how-to!

    So, today was finally the day. I put on my “ITIL brain” (yes, it haunts me even at home), spent a few hours researching and documenting each step so Future Me can fix whatever I break, and sat down to spin up a shiny new virtual environment. My plan was simple: deploy a Windows Server 2022 domain controller, create an external virtual switch so it could actually talk to other devices, set up a Windows 11 Pro workstation to test future GPOs (and break things safely), and prep my trusty Veeam server to join the new domain. This post is more of a behind-the-scenes walkthrough than a step-by-step guide—but don’t worry, I’ll link to my documentation at the end for anyone who wants to try it out.

    Getting Set Up: ISOs and Virtual Switches

    First up: downloading the tools. Microsoft makes it easy—just hop onto their Evaluation Center, grab the Windows Server 2022 ISO, and you’re good for 180 days (or up to 1080 days if you get creative with re-arms). Luckily, I already had a Windows 11 ISO on hand, but for anyone who doesn’t, here’s the official link.

    Windows Server 2022 Evaluation ISO – Can be downloaded from here

    While the server ISO downloaded, I headed into Hyper-V Manager to set up a new external virtual switch—essential for letting the VMs talk to other devices across my network. With the switch prepped, the ISO finished up just in time for the next phase: creating the actual domain controller VM. I gave it a minimal but adequate spec (4GB RAM, 60GB disk), knowing I can always bump things up if I need to down the road.

    While the server ISO downloaded, I headed into Hyper-V Manager to set up a new external virtual switch—essential for letting the VMs talk to other devices across my network. With the switch prepped, the ISO finished up just in time for the next phase: creating the actual domain controller VM. I gave it a minimal but adequate spec (4GB RAM, 60GB disk), knowing I can always bump things up if I need to down the road.

    Installing Windows Server and Basic Setup 

    Watching JR-DC-01 pop up in Hyper-V was weirdly satisfying. I fired it up and started the server install, making sure to select the “Desktop Experience” option—no command-line only installs for me this time! After a quick custom install on my fresh disk, Windows Server was running in just a few minutes.

    From here it was all about the admin basics: creating a strong password, running updates (which took forever—thanks, Microsoft!), and then popping into my firewall to check which IPs were free outside my DHCP pool. Once the server was up to date, I set a static IP so everything on my network stays predictable. 

    Adding the AD DS Role and Promoting to Domain Controller

    With my new admin account set up and Windows fully updated (why do server updates always take so long?), I got ready to configure the server’s static IP. A quick check of my firewall showed which addresses were free outside the DHCP pool, so I set up a neat static IP for the new domain controller—no surprises with DHCP changes down the road.

    With networking sorted, I dove into Server Manager to tackle Active Directory. Installing the AD DS (Active Directory Domain Services) role turned out to be refreshingly simple: just click on “Manage,” choose “Add Roles and Features,” and select Active Directory Domain Services from the list. During the prerequisite screen, I deliberately left the DNS Server role unchecked—my UniFi firewall already handles DNS and I figured, why make things more complicated? (Spoiler alert: More on that later!) The installation zipped by in less than a minute.

    Next up was promoting the server to a domain controller, the real heart of this whole exercise. The wizard was straightforward: I selected “add a new forest,” plugged in jr-network.local as my root domain name. After a few prerequisite checks, I hit “Install” and let Windows do its thing. After a quick reboot, I saw that familiar domain sign-in screen pop up. That first log-in with your shiny domain admin credentials feels pretty great—domain admin power, officially unlocked.

    Setting Up the Testing Workstation 

    With the domain controller sorted, it was time to spin up a guinea pig: a Windows 11 Pro VM (4GB RAM, 64GB disk), with TPM enabled to make Windows 11 happy. The install was mostly straightforward, but here’s where I hit my first snag: Microsoft really, really wants you to use a Microsoft Account, opt in to every privacy setting (ironic), and subscribe to Game Pass and Office 365 along the way. I pressed “skip” so many times I started to think Skynet was judging me. 

    A small slip-up had me accidentally set up the device as “home,” but after sorting that, I logged into Windows and set about joining the workstation to my shiny new domain—until, of course, I ran smack into an error. Despite double-checking the spelling, network, and connectivity (all fine), it just wouldn’t join. 

    Oops, You Really Do Need DNS… 

    Classic learning moment: turns out, AD domain joins rely on DNS, and I’d skipped installing the DNS Role on the DC. Time for a quick detour—back to Server Manager, enable the DNS Server role, fast-forward through setup, and voilà: DNS was operational. After a DC reboot, domain join worked first time. Gotta love it when a fix is that clean. 

    The Not-So-Simple Part: The Veeam Server Saga 

    With my domain and test workstation finally communicating happily, I turned my attention to reconfiguring JR-VEEAM-01 to join the domain… only to find it was powered off and refusing to start. Because of course it was. I opened up the console and, instead of a login screen, got hit with a fresh error. Homelabbing, am I right? If you ever think everything’s going to go smoothly, the universe sends you a quick reminder. 

    Instead of squeezing that fix into this (already long) post, I’ve decided to save the Veeam adventure for next time. That’ll include troubleshooting whatever is going on, getting it attached to the domain, and setting up proper backup jobs for both the new domain controller and workstation. 

    Lessons Learned & The Road Ahead

    Today, I managed to get a domain controller up and running, deploy Active Directory Domain Services and DNS, and prove out the basics of account and policy management on a test workstation. Even with a few detours, it’s been a solid step forward—and proof that you don’t need a complicated lab to learn real enterprise skills.

    If you’ve read this far, thanks for sharing in my victories (and commiserating in my “facepalm” moments). I hope this gives you the confidence to try setting up your own domain, or at least assures you that bumps along the way are all part of the process. If you want a copy of my detailed documentation or want to see a deep-dive on any step, let me know in the comments!

  • My Current Homelab Setup—and Where I’m Headed Next 

    My Current Homelab Setup—and Where I’m Headed Next 

    Over the past couple of months, I decided it was time to give my old gaming PC a new purpose. These days, I rarely find time to game, so I’ve been looking for ways to get hands-on with something fresh—enter the world of self-hosting. With so much tech shifting to the cloud, I’m eager to see how much I can do on my own, just for the sheer challenge and the chance to learn something new. Of course, the added perk of keeping more control over my own data doesn’t hurt (and no, I’m not a tinfoil hat conspiracy theorist!). For me, it’s about getting curious, gaining new skills, and taking a bit more ownership in an increasingly invasive digital world. 

    The Setup So Far

    Right now, my homelab setup is simple but solid—a great foundation to build on. One of my first moves was ditching the default ISP router for a UniFi networking stack, mainly so I could finally create multiple VLANs and take advantage of built-in IDS/IPS security features. My network now consists of a UniFi Gateway Max, an 8-port Ultra 60W PoE switch, and two U6+ access points, which gives me robust wireless coverage and dedicated networks for personal devices, IoT gadgets, and guests. Everything feels so much more organized—and a lot more secure—since making the switch. 

    At the heart of my platform is a repurposed gaming PC, now doing duty as a Hyper-V server. It’s powered by an 8-core Ryzen 7 2700X, 32GB of RAM, a GTX 1080ti, and about 1.75TB of storage cobbled together from a 500GB NVMe SSD, a 1TB and a 500GB SATA SSD, plus a 1TB HDD. At the moment, it’s mainly running a single VM for Veeam backups, leaving me with plenty of room (and plans) for launching new projects. Alongside that, I’ve got a Home Assistant Green running my smart devices, and a Raspberry Pi 2 Model B that’s been collecting dust—just waiting for me to get more hands-on with Linux in the near future. 

    Where I’m Headed Next: Big Plans and New Experiments

    So, where does all this leave me? In short, I want to see just how much I can self-host—and how far I can push my Home Assistant setup. There’s something rewarding about having full control and actually building out the digital tools I use every day. 

    Here’s what’s on my list: 

    • Build and configure a NAS: I’m aiming to create a reliable, expandable storage solution for all my files, backups, and media.
    • Self-host my own cloud storage: Tools like NextCloud and Seafile are at the top of my list for keeping my documents, photos, and calendar in sync—without relying on the big clouds.  
    • Migrate my password manager: I’d like to move everything over to a self-hosted Bitwarden instance. 
    • Set up Plex or Jellyfin: Centralized media storage: each has its pros and cons and I’m not set on what one I’ll go with, but its high up on the list of priorties 
    • Create a VPN: Secure remote access (and the ability to safely share content with friends and family) is a must-have. 
    • Host my own website & try running an AI model: I want to try hosting my own site—and maybe experiment with my own locally hosted AI model 
    • Run my own email server 

    Home Automation

    My basic Home Assistant Dashboard – Out of the box with the Tuya integration configured for managing lights and aircon

    My interest in home automation has really taken off since discovering Home Assistant. Right now, I’ve got a growing pile of smart devices scattered around my house, each with its own app and login. One of the best things about Home Assistant is finally being able to control everything from a single dashboard—no more toggling between a dozen apps just to turn off the lights and lock the door. The platform’s flexibility is wild; I can even pull data from my car, and the potential for custom dashboards and automations is almost endless. 

    I’ve only just dipped a toe into this world, and so far I’ve got the integrations setup for my smart bulbs and air con unit. I’ve repurposed an old Galaxy Tab A that I’m using as a dedicated dashboard to manage these for the time being as a bit of a proof of concept. Once I’ve got a stable platform with more integrations setup, and had made some progress on a custom dashboard then I’ll look to upgrade this to something a bit more sleek. I’d like to get one for each floor too and have them wall mounted with either magnetic wireless chargers, or wired in if I can’t get that to work.

    The Ultimate Smart Dashboard

    One of my big goals is to design and build a dashboard that puts everything I care about front and center—true “mission control” for my home. Here’s what I want it to show and do:

    • Live electric, gas, and water usage, with clear graphs 
    • Family calendar and running to-do list 
    • Weather forecasts and advance commute times (based on our phones’ locations) 
    • Controls for lighting, music, and smart speakers everywhere in the house 
    • Real-time feeds from my CCTV cameras 

    Building the Perfect Setup

    My future plans include building a tidy rack to house all my networking gear, the NAS, and my Home Assistant Green—with room for a small display screen to monitor performance metrics in real time. On top of that, I’m planning a big “smart migration” for my house: upgrading to a smart meter, switching over to smart heating, and replacing all the lighting with gear that seamlessly integrates with Home Assistant. And, for a bit of fun, I’m also interested in building a magic mirror—something that would display the weather, calendar, and news while I brush my teeth. 

    As I work through these upgrades and projects, I’ll be documenting each step, sharing what I learn, and inviting you along for the ride. There’s plenty to build, break, and (hopefully) improve—so if you’re into homelabs, tech, or just enjoy a good experiment, stay tuned!