How I Solved a Tricky Active Directory Problem on a Virtualized Windows 11 Server

Recently, I was tasked with setting up an on-premises Active Directory (AD) environment for my company. Everything went smoothly — at first. I was able to onboard all the devices onto the domain without issues. But then came an interesting challenge: I needed to add the server itself (running Windows 11) to the very AD environment it was hosting. Here’s the setup to make things clear: We had a physical server with Windows 11 installed as the primary operating system. On this Windows 11 host, I created a virtual machine (VM) to run the Active Directory Domain Services (AD DS) role — just like how you might run Kali Linux or any OS inside a virtual machine. Everything was fine until I realized: To join a machine to an AD domain, the domain must be available — but the machine joining (in this case, the Windows 11 host) would need to reboot during the process. The problem: The Windows 11 server was also hosting the virtualized domain controller (DC). If it shut down or rebooted, the domain would be unavailable, and the domain join would fail. I had a problem: how could I reboot the Windows 11 machine and still keep the AD services available for authentication? Here’s How I Solved It: Identified the Existing Setup: The primary account logged into the Windows 11 host was a Cloud AD account (Azure AD joined). However, to join an on-premises AD, the system must be disconnected from any other domain first (you can't be joined to two ADs at once). Enabled the Local Administrator Account: I enabled the local built-in Administrator account on Windows 11 and logged into it. This gave me full local control without being tied to the cloud AD session. Reconfigured VM Management: I moved the responsibility of starting and managing the Active Directory VM from the cloud AD user session to the local Administrator session. This way, even if the server rebooted and logged into the local Admin account, I could manually or automatically power up the domain controller VM immediately after boot. Created a New On-Prem AD User Account: While logged in as the local Admin, I created a new user account in the newly set up on-premises Active Directory specifically for managing the server. Disconnected from Cloud AD: Still under the local Administrator session, I disconnected the Windows 11 host from Azure AD, preparing it to join the on-premises AD instead. Rebooted the Server: As expected, disconnecting from the cloud AD forced a mandatory reboot. Joined Windows 11 to the New On-Prem AD: After the reboot, I logged back in as the local Administrator, powered on the Active Directory virtual machine, and then pressed Ctrl+Alt+Del to switch users. I proceeded to log in as the newly created on-prem AD user. Important to note: By first logging in as the local Administrator and then switching users (instead of logging out), the local Administrator session remained active in the background. This was crucial because it kept the Active Directory services running, allowing the new AD user login to succeed and enabling the Windows 11 server to be successfully registered as a device in the on-premises AD. Final Touch: I successfully joined the Windows 11 host to the on-premises Active Directory! Afterward, I could log in using the new on-prem AD account, cleanly managed without any dependency on the old cloud AD account. Reflections What looked like a dead-end initially turned out to be an opportunity to sharpen my problem-solving skills. The key lessons I learned were: Always ensure local administrative access is available when transitioning between domains. Architect domain controller availability carefully, especially when systems are both hosting and depending on domain services. Reboots aren't just technical steps — they are architectural events that can make or break a smooth deployment if not planned properly. It’s moments like this that make me say: I think I'm in love with Active Directory.

Apr 27, 2025 - 22:02

How I Solved a Tricky Active Directory Problem on a Virtualized Windows 11 Server

Recently, I was tasked with setting up an on-premises Active Directory (AD) environment for my company. Everything went smoothly — at first. I was able to onboard all the devices onto the domain without issues.

But then came an interesting challenge:

I needed to add the server itself (running Windows 11) to the very AD environment it was hosting.

Here’s the setup to make things clear:

We had a physical server with Windows 11 installed as the primary operating system.
On this Windows 11 host, I created a virtual machine (VM) to run the Active Directory Domain Services (AD DS) role — just like how you might run Kali Linux or any OS inside a virtual machine.

Everything was fine until I realized:

To join a machine to an AD domain, the domain must be available — but the machine joining (in this case, the Windows 11 host) would need to reboot during the process.

The problem:

The Windows 11 server was also hosting the virtualized domain controller (DC). If it shut down or rebooted, the domain would be unavailable, and the domain join would fail.

I had a problem: how could I reboot the Windows 11 machine and still keep the AD services available for authentication?

Here’s How I Solved It:

Identified the Existing Setup:
The primary account logged into the Windows 11 host was a Cloud AD account (Azure AD joined). However, to join an on-premises AD, the system must be disconnected from any other domain first (you can't be joined to two ADs at once).
Enabled the Local Administrator Account:
I enabled the local built-in Administrator account on Windows 11 and logged into it.
This gave me full local control without being tied to the cloud AD session.
Reconfigured VM Management:
I moved the responsibility of starting and managing the Active Directory VM from the cloud AD user session to the local Administrator session.
This way, even if the server rebooted and logged into the local Admin account, I could manually or automatically power up the domain controller VM immediately after boot.
Created a New On-Prem AD User Account:
While logged in as the local Admin, I created a new user account in the newly set up on-premises Active Directory specifically for managing the server.
Disconnected from Cloud AD:
Still under the local Administrator session, I disconnected the Windows 11 host from Azure AD, preparing it to join the on-premises AD instead.
Rebooted the Server:
As expected, disconnecting from the cloud AD forced a mandatory reboot.
Joined Windows 11 to the New On-Prem AD:
After the reboot, I logged back in as the local Administrator, powered on the Active Directory virtual machine, and then pressed Ctrl+Alt+Del to switch users. I proceeded to log in as the newly created on-prem AD user.
Important to note:
By first logging in as the local Administrator and then switching users (instead of logging out), the local Administrator session remained active in the background.
This was crucial because it kept the Active Directory services running, allowing the new AD user login to succeed and enabling the Windows 11 server to be successfully registered as a device in the on-premises AD.
Final Touch:
I successfully joined the Windows 11 host to the on-premises Active Directory!
Afterward, I could log in using the new on-prem AD account, cleanly managed without any dependency on the old cloud AD account.

Reflections

What looked like a dead-end initially turned out to be an opportunity to sharpen my problem-solving skills.

The key lessons I learned were:

Always ensure local administrative access is available when transitioning between domains.
Architect domain controller availability carefully, especially when systems are both hosting and depending on domain services.
Reboots aren't just technical steps — they are architectural events that can make or break a smooth deployment if not planned properly.

It’s moments like this that make me say:

I think I'm in love with Active Directory.