Test Lab Notebook

A Rant.. Microsoft’s Own software and SQL Server Permissions: A Security Concern That is a real nuisance for DBAs Introduction: How many times have you heard the phrase “Microsoft best practice”? For many DBAs, it often rings hollow. We’re used to developers requesting sysadmin permissions to sidestep issues, sometimes out of laziness or convenience, but the real challenge often comes not just from our own developers or COTS packages, but from Microsoft’s own products. Microsoft’s installers frequently request sysadmin rights during setup — even if only temporarily. While this might seem necessary for some installations, it raises serious security concerns. Once granted, these permissions can lead to changes that DBAs may not fully understand or be able to track. This post explores why Microsoft’s approach conflicts with the security principles it advocates and why it’s a major challenge for database administrators. The Challenge: Sysadmin Permissions During Installation Many Microsoft...

Exporting the RADV Router VM as OVA and Vagrant Box for Fast Deployment# Continuing the Lab Build Process With the RADV Router now up and running, we’re continuing the lab build process by exporting the virtual machine as both an OVA and a Vagrant box. In our previous post, we stopped the OVA creation process, but now it’s time to complete it and ensure a repeatable deployment for the rest of the lab environment. This VM serves as the foundation for the entire lab, so getting it into a reusable format is crucial. Why Export the VM as an OVA? One of the main reasons I wanted to export the RADV Router VM as an OVA (Open Virtual Appliance) was to show how versatile and portable it can be. By converting the VM to an OVA, I make it much easier to move the machine across different platforms. It can be used not just in VirtualBox, but also in other hypervisors like VMware, Hyper-V, or even cloud environments. The OVA format is a great way to package a virtual machine because it includes ...

Happy New Year! As we start 2025 , it’s time for a nod to all of us in IT and Ops who keep the digital wheels turning, day in and day out. Whether you’re a lone ranger troubleshooting mysteries in the middle of the night or part of a bustling team that tackles issues with efficiency and the occasional eye roll, there are a few eternal truths we carry forward. These aren’t just rules – they’re survival tactics, learned the hard way and honed over countless hours in the trenches of troubleshooting. To mark the new year, here are my 10 Rules of IT , distilled from experience and ready to face another year of tech challenges. 1. ALWAYS cover your own arse... When things hit the fan, you’d rather be safely tucked away in a blanket of plausible deniability or armed with the right documentation. Make it bulletproof. 2. ALWAYS ensure you can get back to where you started... Leaving a trail of digital breadcrumbs is essential, especially when navigating a maze of new changes. After all...

More to life than IT on the eve of Trump arriving at the white house the situation in Ukraine is scary For those whose understanding of history comes from war films, it’s important to recognize that Europe has been a continent of continuous conflict, shifting borders, and shattered empires for over 110 years. The collapse of empires after World War I left a volatile vacuum, creating the conditions for instability and aggression that would continue for decades. Do we really want to return to a world of imperialism, authoritarianism, and the subjugation of smaller nations at the hands of the powerful? The story of the 20th century begins with the devastating effects of World War I. The collapse of the Austro-Hungarian, Russian, and Ottoman empires created new borders and reshaped nations, but left behind unresolved conflicts and growing nationalist tensions. The aftermath of the war was supposed to bring peace, but instead, it set the stage for the next catastrophe. In 1938, the Munich P...

Happy Christmas/Yule: Reflecting on Why I’m Doing This Project and What I’ve Achieved So Far Happy Yule! As we embrace this festive season, it’s a wonderful time to reflect on my learning journey since September with this project. It’s been both challenging and rewarding, providing a great way to keep my mind active. Over the years, I’ve built a few test labs, but this one has been the slowest and most complicated. Blogging about my progress is helping me solidify what I’ve learned while also supporting others in their own learning journeys. In addition to this project, I’ve worked on a couple of electronics projects, organised meetups for my photography group, and balanced my day job as a DBA with being a father. Here are some key highlights from the test lab project so far: Building a Foundation and Project Goals : This laid the groundwork for everything that followed. Getting Things Ready with Vagrant and Packer : Streamlining the setup made the process much smoother. Sett...

Setting Up a RADV and NAT64 Router with Packer and VirtualBox In this post, I'll go through setting up the core functionalities to make the bare bones VM fully operational as an IPv6 router, including configuring RADV and NAT64. After that, I'll secure the VM, power it down, and run some final checks to ensure everything is working as expected. Once validated the build phase will be complete and will be setting up for the final step, packaging it for deployment. Prevent Premature OVF Export To ensure that the VM remains available for further customisation before being wrapped into an OVF, I adjusted the Packer HCL file. This change allows me to apply additional configurations directly within the guest environment. By keeping the VM in this state, I have more flexibility to refine the build process before creating the final image. Here's the adjustment I made to the HCL file: skip_export = true keep_registered = true The skip_export setting prevents ...

Troubleshooting and Refining the AlmaLinux VM Build With Packer Learning How to Deploy a AlmaLinux VM With Packer (Part 2) Recap of Part 1 In Part 1, I started building an AlmaLinux VM using Packer but encountered several challenges during the installation process, including insufficient disk size and memory allocation, as well as issues retrieving the Kickstart file due to network configuration. In Part 1, I outlined the troubleshooting steps taken to address these issues, such as increasing the disk size to 256GB, upgrading the memory to 8GB, and switching from a NAT to a bridged network for improved access to the Kickstart file. While these adjustments allowed the Kickstart to begin executing, the installation was not yet complete, highlighting the ongoing challenges and lessons learned in this iterative process. Introduction to Part 2 Continuing from the progress made in Part 1, this section dives deeper into the troubleshooting phase of my AlmaLinux VM build using Packer. Afte...