Now that the DC1 is online, I’ll add the other Domain Controller, DC2, to the cluster on the “inside” of the TMG (see Network Design, TTG LAN)
Keep in mind that it’s not a Microsoft recommendation to put a virtual DC on a Cluster Shared Volume. File corruption and replication errors can happen!
First create the site, using AD Sites & Services, where the DC2 will reside, as I am using two different IP ranges. I have named the sites DMZ-SITE and TTG LAN-SITE and added the associated IP ranges to these sites.
Now you can add the DC2. Because DC1 is online and you’ve created the two sites, installing the DC2 is a breeze. The wizard will find all the necessary information as you can see in the following screenshots.
Assign a separate password for the Domain Services Restore Mode. I’ll keep the default file locations.
After selecting the domain, the wizard finds the site (bases on the IP address of the VM) to which the DC2 belongs. The DNS notification is weird though, I’ve checked and it’s all in working order. After the wizard completed I see no DNS errors in the logs.
Verify the information and proceed
That’s it, now I have two DC’s. Based on the site TTG-LAN, all VM’s will primarily authenticate to DC2 now.
Routing
The DC1 is in a different subnet and has its default gateway set to the DMZ gateway of 172.16.111.33. So it needs to know where to send all those nice replication packets to as the DC2 is on the other side of the TMG in a different network.
On the DC1, open an administrator CMDline, and do the following:
- netsh <enter>
- interface <enter>
- ipv4 <enter>
- show interfaces <enter> (make note of the correct interface name)
- add route 172.16.11.0/26 “TTG DMZ” 172.16.111.11
To review the route that you’ve just created, enter the following command:
netsh interface ipv4 show route
The route can be deleted by entering:
netsh interface ipv4 delete route 172.16.11.0/26 “TTG DMZ” 172.16.111.11
Now the DC1 knows where to send traffic intended for DC2. Of course the default gateway for DC2 is already correct.
Funny story
Late at night, or if you prefer early in the morning, I decided to fix the “RAID set not clean” message on the QNAP. When you press the Check Now button on the RAID set it will verify the integrity … what it also does, and I completely forgot about, is that it drops all connections to this particular RAID set. You know, the one that hosts all the LUNs for the cluster.
The cluster itself and the clusternodes came up fine after that. The DC2 had some issues with files and replication .. as expected and warned about by Microsoft and the top of this page :).
I had to separately reboot the DC2 twice, from an administrator CMDLINE use:
- repadmin /options +DISABLE_OUTBOUND_REPL
- repadmin /options +ENABLE_OUTBOUND_REPL
- repadmin /options +DISABLE_INBOUND_REPL
- repadmin /options +ENABLE_INBOUND_REPL
and then force sync and replication before all was well. So yes, it can be fixed if you yank out the storage underneath the cluster but it takes a bit of time 🙂