On Friday, I ran into a little bump when performing in-place upgrades of three (3) Windows 2008 R2 domain controllers (DC) to Windows 2012 R2 and thought you would like to know of my experience. Two were hosted on VMware 5.x servers, and one was a physical server. If the following is a known issue, I was not aware.
On two virtualized domain controllers running Windows Server 2008 R2 Datacenter, I successfully performed an in-place upgrade to Windows Server 2012 R2 Datacenter. With some spotty mouse and video response via the VMware console after the upgrade, the customer attempted to update the VMware tools but they would not update. Eventually, the customer performed a repair of the VMware tools. Everything was smooth sailing until I attempted to complete the in-place upgrade of the only physical Windows 2008 R2 DC; which failed and had to perform a rollback. All servers at that point showed as being “disconnected” in the vSphere client, even all of the ESX servers. Nothing was available to the customer (i.e. email, shares, printing, etc.). While I was attempted to see what was going on with DNS, I noticed that it appeared the DCs I was working with were not locatable in DNS.
During our troubleshooting and investigation session, the customer found on the two virtualized DCs that they had an IP address on them that was not previously assigned (he was accessing via iLO). Further looking into showed that the NICs were set to receive IP settings via DHCP. Additionally, the name of the NICs weren’t the same.
My initial thoughts were that the in-place upgrade caused these changes; however, that wasn’t the case in my Hyper-V lab environment when I tested the process. While researching, I found a reference that alluded to a server losing its NIC settings in a VMware environment after performing an in-place upgrade.
The customer then realized that the repair of the VMware tools may have removed the NIC and created a brand new one with default settings based on receiving IP settings via DHCP. Oh boy!
After the customer realized what probably happened, they reset the NICs statically to their previous IP settings and things immediately began to function as normal.
I really don’t think this issue has anything to do with Windows 2012 R2 specifically. But if you have any insight or can confirm what we presume, it would be greatly appreciated if you will share that information.