Easy domain joins with Vagrant and Uplift project
Building infrastructure for Windows, SQL Server or SharePoint is not an easy task. It involves dozens of files to be downloaded, several dozens of configurations, several virtual machines, and hours of work.
Wouldn’t it be great just to run a few commands, and end-to-end setup happens automatically? With the recent patches, updates and minimal configurations? And the ability to execute your scripts on top? And also run this on Windows/MacOS, and under CI/CD pipelines?
Get into this blog post and learn several useful skills:
- Really easy domain joins with Vagrant and Uplift project
- Creating and managing Vagrant multi-machine environments
There is no manual steps, wizards or screenshots. We value your time offering a scalable and highly repeatable solution for your team or the whole company.
Introducing The Uplift project
This post shows how you can easily deal with Windows domain join without manual interventions while building Vagrant managed virtual machine.
There is no manual steps, wizards or screenshots. We value your time and offer a scalable solution for your team or the whole company — this is a fully automated and hence scalable Packer/Vagrant workflow which can be run on Windows/MacOS laptops, on Windows 2008, 2012, 2016, in the cloud, share with the team or integrate into CI/CD pipelines.
This post also continues a mini-series on The Uplift project — a Packer/Vagrant toolkit for SharePoint professionals more details on which you can find below.
- The Uplift Project — Packer/Vagrant toolkit for SharePoint professionals
- Open-sourcing The Uplift project, high-level overview and how it works
- Building a disposable Windows 2016 domain controller in 20 minutes with Vagrant
Make sure you caught up on this mini-series, and let’s start building!
Fast forward to Packer/Vagrant
If you are already familiar with Packer/Vagrant, feel free to skip this section.
With the increasing complexity of the infrastructure builds and software engineering, the right tooling and automation is a crucial contributor to the overall project success. Automation and tooling can save hours of work, lower down internal cost, help to deliver more features, and maybe most important — improve the team’s moral and happiness.
When it comes to baking virtual machine images and managing Virtual machines, there might be no better tool than HashiCorp’s Packer and Vagrant by HashiCorp.
In a nutshell, Packer provides an easy way to create any type of machine images, including Sysprep-ed Windows images for Hyper-V, VirtualBox, Azure, Amazon and many others.
More details on why to use Packer and its benefit can be found on the official Packer web site:
Vagrant is another tool by HashiCorp which comes handy while building development, test or lab virtual machine environment.
More details on why to use Vagrant and its benefit can be found on the official Vagrant web site:
Altogether, Packer/Vagrant reduce the complexity of dealing with low-level details of virtual machine image builds, creating and configuring virtual machines and other useless tasks. In return, we have more time to work on features rather than fighting boring and never-ending issues.
In more details, we described how’s and why’s we use Packer/Vagrant in the Uplift project in the previous post. Feel free to park it for later read.
Fast forward to domain joins with Vagrant and Uplift
Assuming you’ve got a disposable Windows 2016 domain controller in 20 minutes with Vagrant (if not, check this post), we can now think of adding another virtual machine into our topology and then joining it to the domain controller.
More or less, a routine provisioning workflow looks like this:
- Create a new virtual machine
- Set the same or similar setting as domain controller has (time, zone, etc.)
- Setup network
- Join into a domain controller
- Reboot
This can easily take an hour, can go wrong and seriously boring while requires manual steps. Let’s see how this can be done with Vagrant and the Uplift project under fully automated workflow.
Crating Vagrant multi-machine environments
Vagrant is able to define and control multi-machine environments. It is known as “multi-machine” Vagrantfile. It comes handy while building client-server scenarios, app-database and many other multi-machine topologies.
Your current Vagrantfile with a domain controller should define one virtual machine named “dc”:
Let’s add a second virtual machine named “client” with the following Vagrant configuration. We also use a vagrant-uplift plugin to simplify common routines of setting up and provisioning client VM similar to a domain controller.
In this case, a few methods related to network and domain join are different:
Let’s check how Vagrant sees our configuration:
vagrant status
Now you can see two VMs out there: “dc” and “client”. Every time we run a vagrant command, we should also include VM name. If no VM name is provides, Vagrant performs a command against all VMs back to back.
vagrant up dc
vagrant up clientvagrant halt dc
vagrant halt clientvagrant destroy dc -f
vagrant destroy client -f
Getting client VM up and running should be straightforward. Make sure the domain controller is up, and then simply run vagrant up against client VM:
# bring both VMs up
vagrant up # bring only dc
vagrant up dc
vagrant up dc --provision# bring only client VM up
vagrant up client
vagrant up client--provision
Similar to domain controller provision, you can see information messages coming from the uplift plugin — from configuring the Vagrant machine, to applying various PowerShell scripts, joining and rebooting the machine.
Provisioning process is split into several phases:
- Configure machine RAM/CPU
- Setup hostname and network
- Apply base SOE settings (locale, timezone, basic features, etc.)
- Join to domain controller and reboot
- Provision base shortcuts on the default desktop
SOE means “standard operating environment”. A set of things which are common for all virtual machines; PS modules, locale, timezone, features, so on.
Well done! You now have a domain controller and a client VM up joined to the domain and ready to rock! Check out VirtualBox and use default vagrant user with a vagrant password to get into and explore what’s in there.
A few notes on the network and configurations
Underneath, the vagrant-uplift plugin makes two things:
- configures network consistency so that VMs are in the same network
- executes pre-defined PowerShell and PowerShell DSC scripts
With the network, domain controller always gets 192.168.4.5, and all other machines get an incremented IP address such as:
- 192.168.4.6
- 192.168.4.7
- 192.168.4.8
- …etc..
Automatic IP allocation and network setup is a feature of the Uplift project and vagrant-uplift plugin!
By default, 192.168.4.* is used, and it can be changed with the following configuration prior to the machine configs. That said, most of the time you don’t have to change this unless you bring several domain controllers in the different networks at the same time, wow!
# uplift helper for vagrant configurations
uplift = VagrantPlugins::Uplift::Config()# network range where dc and other vms will be created
# by default 192.168.4.*, use as following or skip it
# be aware that two dc won't get along within the same network
# use different networks for different stacks or one stack at a time
uplift.set_network_range("192.168.16")
What’s next?
Congratulations!
We hope you enjoyed mastering Vagrant and by this time see more value in our work. We think that automation can be easy and enjoyable, and we did our best to reduce the complexity of the infrastructure setup while building and open-sourcing the Uplift Project.
What’s next for us? — posts on SQL, SharePoint 2016, CRM and Exchange.
What else can you do? Review this post example on GitHub:
Probably you already have an idea or two, but here are a few more scenarios to explore:
- Open-sourcing The Uplift project, high-level overview and how it works
- Building a disposable Windows 2016 domain controller in 20 minutes with Vagrant
- SubPoint Solutions boxes for the Uplift Project
- Vagrant Documentation
- Kitchen CI — infrastructure testing is done right
- Pester — test and mock framework for PowerShell
- Matt Wrock blog; Packer/Vagrant and many other things
- Gusztáv Varga blog; Packer/Vagrant and Windows automation
If you find this useful, drop us a line or give feedback on the GitHub, feel free to share feedback and improvements in the comments, follow us here or on Twitter and feel free to share this post too.
