This is part two of demonstrating the process of rolling out a 2-node, hyperconvered Hyper-v cluster. This post assumes you’ve completed the prior post and have successfully rolled out the lab environment from part one. Additionally, it assumes you’ve got a functional Active Directory Domain, which I’ve written up as a lab environment in this post. In this post we’re going to get our nodes joined up to the domain, configure storage, and get a VM running on the cluster.

This post is intended to demonstrate the process of rolling out a 2-node, hyperconvered Hyper-v cluster. I’m going to go over some planning considerations, as well as point out some important differences and requirements for production deployments rather than the humble lab we’ll build. Lab Overview Hardware I’ll be deploying two nodes: hyperv1 and hyperv2. These devices should be as identical as possible, both in hardware and in BIOS and firmware versions.

This post outlines how I’ve implemented a secure, fast, and reliable VPN solution for my mobile devices. I spend a good deal of time working outside of an office or my home, often on public or otherwise potentially nefarious networks. By setting up an on demand VPN connection, I can keep my traffic and DNS requests encrypted and out of the hands of potential malicious actors. Parts needed I’m electing to use DigitalOcean for this project.

This post will focus on a recent project of mine to containerize my personal Nextcloud instance. I’ve been running Nextcloud for years as my personal cloud file storage. I find the ability to automatically sync my phone’s pictures and videos back home particularly handy! My previous Nextcloud instance was running on a FreeBSD VM for quite some time, so why the change? Goals and Planning A lot of projects began moving to containers as a way to standardize development environments and practices, as well as a bunch of other reasons.

If you followed along with the previous post, you should have a fully working Nextcloud setup, all running in a pod called ‘nextcloud’. In this article, we’re going to use podman to generate systemd service units and set them to run at boot in a user’s context. In order to accomplish this, we have to first tell logind to let our user’s account to be ‘logged in’ even when it’s logged out.

Ok, now we’ve got a big empty domain. What to do next? Structure Let’s add some logical structure so we can target objects better. By default every user object in AD ends up in CN=Users,DC=win,DC=hrkrdr,DC=com. There are already built in objects that live there, such as Administrator and some security groups. In order to start granular targeting or messing with delegation we want some Organizational Units. Build OUs Before we build a ton of new objects into AD, let’s enable the Active Directory Recycle Bin.

By request, here’s the first part in the series of how to set up a home computer lab for testing and learning. Let’s put together a quick checklist of what we want to build before we get started: Two Windows Server 2019 Standard core virtual machines. I’m assuming you’ve got a working hypervisor and access to developer or evaluation licenses for Windows Server. I highly recommend using Core for domain controllers to keep them as low profile as possible.