Homelab – 2012 to 2019 AD upgrade

Posted on July 28, 2020 by pkremer

I foolishly thought that I would quickly swap out my 2012 domain controllers with 2019 domain controllers, thus beginning a weeks-long saga. I have 2 DCs in my homelab, DC1 and DC2.

Built a new DC, joined to the domain, promoted to a DC (it ran AD prep for me, nice!), transferred FSMO roles (all were on DC1), all looked great! Demoted DC1, all logins failed with ‘Domain Unavailable’.

Uh-oh.

Thankfully I had my Synology backing up my FSMO role holder DC. So I restored it from scratch. I figured I might have missed something obvious so I did it again. Same result.

Ran through all sorts of crazy debugging, ntdsutil commands looking for old metadata to clean up, found some old artifacts that I thought might have been causing the issue, and repeated the process. Same result.

Several weeks later I realized what happened – I had a failing UPS take down my Synology multiple times until I replaced it a few days ago. Guess which VM I never restarted? The Enterprise CA. The CA caused all of this. Or at least most of it. Even after I powered up the CA, I was unable to cleanly transfer all FSMO roles. Everything but the Schema Master transferred cleanly, even though they all transferred cleanly while the CA was down. I had to seize the schema master role and manually delete DC1 from ADUC – thankfully, current versions of AD do the metadata cleanup for you when you delete a DC from ADUC.

In hilarious irony, I specifically built the CA on a member server and not a domain controller to avoid upgrade problems.

In summary:

When you don’t administer AD every day, you forget lots of things
No AD upgrade is easy
Make sure you have a domain controller backup before you start
Turn on your CA
Run repadmin /showrepl and dcdiag BEFORE you start messing with the domain
Run repadmin /showrepl and dcdiag AFTER you add a domain controller and BEFORE you remove old domain controllers
ntdsutil is like COBOL – old and verbose

My MCSA 2012 upgrade exam experience – MS 70-417

Posted on February 20, 2013 by pkremer

I passed the Microsoft 70-417 exam today; it wasn’t my first attempt. I don’t pursue many Microsoft certifications because I find them to be of questionable value. The use of braindumps is rampant in IT certification, particularly true in the case of Microsoft exams. I feel this is in part due to the ridculous nature of most of the questions. There are always going to be people who simply don’t want to learn, the so-called “paper MCSEs”. But unlike exams from other vendors such as VMware and Cisco, experience with Microsoft’s products has nothing to do with passing their exams. Microsoft’s inability to write decent exam questions is truly baffling to me.

I had many questions that forced me to try and remember where in the GUI certain options were. As an example, think about the advanced NTFS permission list. Is “Create files / write data” before or after “Create folders / append data” in the permission list? You probably don’t know and you surely don’t care. If you do happen to know, it doesn’t make you a better administrator. It doesn’t demonstrate much of anything other than a photographic memory. The 417 exam is loaded with these kinds of worthless questions. Even worse is trying to remember a particular switch for a PowerShell command – that’s why cmdlets are self-documenting.

The 70-417 exam is divided into 3 parts, the 70-410 (Install and Configure), the 70-411 (Administering) and the 70-412 (Advanced). My exam had 61 questions and you have to take each section invidually. Once you complete a section, there is no going back. I would never have passed this exam without J.C. Mackin’s Exam Ref 70-417: Upgrading Your Skills to MCSA Windows Server® 2012 and Timothy Warner’s 70-417 videos on CBTnuggets.

I’m normally proud and excited when I pass an exam, but not this time. I mostly feel anger toward the Microsoft Certification team for wasting my time. The exam hasn’t measured my actual skill with Server 2012, all it’s done is measure how well I can remember trivia. I’m happy to have this one behind me. I doubt I’ll look at any more Microsoft exams until this MCSA expires.

Windows 2012 DHCP – Migration and Fault Tolerance

Posted on January 27, 2013 by pkremer

A long overdue feature in Windows Server 2012 is the ability to have a truly distributed DHCP infrastructure. You used to have to use the 80/20 split scope configuration which was at best administratively burdensome, and at worst unmanageable for a large enterprise. Alternatively, you’d have to run a Windows cluster for DHCP – who actually wants to do that? Windows Server 2012 now offers distributed DHCP failover.

I’ll start by talking about migrating your DHCP configuration from Windows 2008 to Windows 2012. First, you obviously have to install Windows 2012 and add the DHCP role. Microsoft has made it ridiculously easy to export and import the configuration with PowerShell – you can complete the process with 2 commands.

Open a PowerShell window on your 2012 server and run
Export-DhcpServer -ComputerName your2008DHCPserver.foo.com -Leases -File C:\path\to\exportfilename.xml -verbose

Exporting Windows 2008 DHCP configuration

A bit of advice from my lab environment – if you have a clock mismatch between domain controllers, you won’t be able to run these remote Powershell commands. If you’re getting strange errors in your lab, check the clocks on your DCs. My 2012 DC was many hours behind my 2008 DC and I couldn’t run any commands. I fixed the clock and the problem disappeared.

When your export is complete, run the import.
Import-Dhcpserver -Leases -File C:\path\to\exportfilename.xml -BackupPath C:\windows\temp\ -verbose

Importing DHCP configuration from a Windows 2008 export

Import of 2008 DHCP configuration completed.

The 2008 imported scopes on the 2012 DHCP server.

Moving on to configuring the failover –

Configuring failover on a DHCP scope

Not much to see here, but if you don’t have any scopes visible you aren’t going to be able to go much farther. One possible solution to the problem is in this post.

First screen of the failover wizard

Specify another Windows 2012 server with the DHCP role already installed.

Specifying a failover partner in the failover wizard

The failover relationship must be named. Maximum client lead time refers to amount of time the surviving DHCP host will wait before assuming complete control over the scopes. For mode, you can pick either load balanced or hot standby – basically an active-active or active-passive relationship.

Defining the failover relationship

Finish will kick off the process.

Last screen of the failover wizard

Failover progresses to completion

The scope and leases are now visible from the secondary DHCP server.

The failover scope as seen on the secondary DHCP server

I will now shut down the primary DHCP host and leave the secondary host online. You can see my Linux guest with the DHCP address of 192.168.237.201. After shutting down primary DHCP, I reboot this Linux guest.

Client IP prior to reboot

The guest comes back with the same .201 IP address, this time served by the secondary DHCP host.

Client IP after reboot – DHCP served by failover host.

Now I boot a second Linux guest and it draws a .220 IP address from the secondary DHCP host.

A second client VM booted with primary DHCP server disabled

Here are the leases as seen from the secondary DHCP host. Both of the Linux hostnames are the same because I didn’t bother customizing them in the guest. However, the MAC addresses are different and each VM is drawing the correct IP.

DHCP leases on failover host

I now bring the primary DHCP host back up. Immediately after boot, you can see that the lease for the .220 IP is not listed.

DHCP leases on DC2 after powerup

We could wait for the hosts to do this themselves, but we’re impatient and force a replication.

Forcing scope replication to pull leases from failover host

Now the .220 lease is visible from the primary host.

DHCP leases on primary host

Now we take down the secondary DHCP host, leaving only the primary online. Reboot both of the Linux guests and they both correctly draw the .201 and .220 IP address.

DHCP IP on client 1 after reboot

DHCP IP on client 2 after reboot

Once you have this set up you can configure your network infrastructure with multiple DHCP addresses. Vendors have various names, but Cisco refers to this as the ip helper address. DHCP requests will always be sent to both DHCP hosts, but each scope is active on one host at a time. One DHCP request will be acknowledged and the other will be ignored.

Windows 2012 DHCP Failover – Cannot enable

Posted on November 23, 2012 by pkremer

I tried setting up the new Windows 2012 DHCP failover and got it working, but I couldn’t get some of my scopes that I’d imported from 2008 to 2012 working. If I built the same scope (or what I THOUGHT was the same scope) from scratch in 2012, I could configure failover.

I posted in the Microsoft forums but didn’t find resolution. However, one month later somebody posted the solution on my thread. My 2008 scopes happened to have both DHCP and BOOTP enabled, and you can’t enable failover on a scope set to both DHCP and BOOTP.

Patrick Kremer

Technical perspectives from a VMware Cloud Solution Architect

Tag Archives: 2012

Homelab – 2012 to 2019 AD upgrade

My MCSA 2012 upgrade exam experience – MS 70-417

Windows 2012 DHCP – Migration and Fault Tolerance

Windows 2012 DHCP Failover – Cannot enable