I wrote this article to better understand all the pieces called “AD” or “Active Directory” in Microsoft Azure fit together. The pieces are as follows:

• Active Directory (AD): The is the classic on-premise Active Directory with LDAP, Kerberos, group policies and all that. Traditionally Windows machines in larger environments have been domain-joined to on-premise AD.

• Active Directory Federation services (AD FS): adds support for modern web-SSO protocols (SAML, OAuth 2.0 and OIDC) to on-premise Active Directory.

Vagrant has built-in support for connecting to Windows VMs using the vagrant rdp command. It does basically does the same as vagrant ssh for Linux VMs. There are a few shortcomings, though: vagrant rdp fails to automatically accept the host key of the VM it is connecting to, at least when using it from Linux with xfreerdp. So, you first need to connect to the VM directly once with raw xfreerdp, then vagrant rdp will start working. Then, when you wipe out the VM, you need to repeat the process again. If you have a high resolution screen you will also notice that vagrant rdp will give you a tiny Windows desktop where you need a magnifying glass to read the text.

I’ve been doing lots of Windows automation recently. My goal has been to be able to reproducibly create a Windows Server 2019-based Buildbot workers, first in a Vagrant environment, then later in AWS EC2 using pre-built images created with Packer. This task requires installing Visual Studio 2019 build tools automatically and fetching the project’s dependencies with vcpkg automatically. It is possible to install Visual Studio 2019 with Chocolatey quite easily, but what if you need to install additional components to Visual Studio without using the Visual Studio installer GUI? Looking around did not quickly reveal any de facto instructions on how to do it, so this article aims to fill that gap.

This posting comes strictly from the land of esoteria. We have a Vagrant + Virtualbox environment that sets up Foreman used for PXE booting baremetal servers. The environment work fine on Linux and MacOS. But we needed to make this environment work also on Windows. Easy, right? Vagrant and Virtualbox are supposed to abstract all those pesky operating system settings away, correct? After resolving a non-Windows related challenge provisioning of Foreman on Windows almost worked. Except that it failed when foreman-installer attempted to start[*]. The error message was this:

The vagrant-hostmanager plugin is a really nice plugin which helps Vagrant VMs communicate with each other using names instead of IP addresses. Essentially it manages hosts entries for the VMs, acting like a poor-man’s DNS. Now, on *NIX operating systems you typically use sudo, which caches your authorization. So, when hostmanager starts, you type your password once and then it is able to add all the host entries it needs to /etc/hosts. This is not so on Windows: you will get one UAC prompt per modification to c:\windows\system32\drivers\etc\hosts. This will eventually drive you crazy. To fix this you need to permit your Windows user account to modify the hosts-file without privilege elevation. To pull this off, you will need to modify that file’s access control lists. The process is quite convoluted imho, but here it goes: