The 32-hour Upgrade to Windows Server 2012

Doctor Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, describes the long weekend he took to upgrade his servers to Windows Server 2012 including lessons learned. Microsoft Scripting Guy, Ed Wilson, is here. Well, I was told this past weekend was really nice down here in Charlotte, North Carolina, in the United States. With no aftermath of hurricane Sandy, we were lucky. I decided to go ahead and take the plunge to upgrade my six servers to Windows Server 2012. I figured it would be a relatively simple matter—previous operating system upgrades had gone flawlessly. My only concern was for one of my older servers that was running Windows Server 2008 R2 Hyper-V because I know the new Hyper-V in Windows Server 2012 relies on a new memory model. The one older server I was not certain would upgrade to Hyper-V … AND I needed that server.

Devising the plan

I have one old 32-bit server that still earns its living running Windows Server 2008, and, so obviously, I cannot upgrade it. I can upgrade it to Windows PowerShell 3.0, and I will do that later. I have three Hyper-V machines—all of which are loaded down with virtual machines. Some of the virtual machines are already running Windows Server 2012, and others are running Windows Server 2008 R2 (as well as various client operating systems). These form a major part of my network, and they will need special attention. I have one server that runs Windows Server 2008 R2 and Windows Deployment Services, as well as System Center Virtual Machine Manager. I plan to remove these roles and upgrade them to new versions of those features. Once the roles are removed, I will upgrade it. Oh, yeah, it also hands out DHCP for a couple of different networks, but I am not worried about that upgrade. I have one server running Windows Server 2008 R2, SQL Server 2008 R2, and SharePoint 2010. I need to add in service packs for SQL Server and SharePoint 2010 as well as apply the SharePoint 2010 all in one rollup from August 2012. I am very concerned about this upgrade because I do not spend a lot of time doing SharePoint admin work. All of the servers are headless. All of the servers have Windows PowerShell 2.0 installed and WINRM enabled. They are all full versions of the operating system (no Windows Core Edition running right now), and, therefore, RDP is also configured. I used RDP to launch Setup on the servers. To be safe, I rounded up a crash cart with a monitor, keyboard, and mouse. I was tempted to write a Windows PowerShell script and launch Setup on all of the servers by using an Unattend file, but I did not want to end up with a totally non-functioning network, so I decided to monitor things more closely. The one big disadvantage I have at home is that every single server on the network is a different make, model, and mixture of hardware components. It is not like the days when I worked for a Microsoft Solutions Provider Partner and purchased industry standard servers for the house at great discounts.

Plan of action

After considering the role and the importance of the specific servers on my network, I decided to perform the upgrade in the following manner:

  1. Upgrade the Windows Deployment Services server.
  2. Upgrade the three Hyper-V servers.
  3. Upgrade the SharePoint 2010 server.

The first upgrade was easy

The Windows Deployment Services server was the easy one. I removed the WDS role and the associated virtualization manager software, ran Windows Update to ensure I had the latest Windows Server 2008 R2 bits, and then I put in the CD-ROM to upgrade to Windows Server 2012. During the installation, it asked to go online to update Setup bits, I said OK. The upgrade itself took nearly an hour, and once it came out of the final reboot, I logged back on to the domain, and ran Windows Update for Windows Server 2012. After an additional 15 minutes to download and to install the 160 MB patch, everything worked.

The second upgrade introduces the first problem

It is time to upgrade my first server running Hyper-V. Because of the importance of this server, I took a portable USB drive, attached it to the server running Hyper-V, and exported all of the virtual machines to the device. This way, I thought, the virtual machines would be safe in the event of disaster. It was painfully slow to export the virtual machines … on the order of hours.

Note   If your virtual machines have snapshots, the snapshots are lost when you upgrade to Windows Server 2012. This is due to an incompatibility of formats. After I exported all of the virtual machines, I ran Setup to begin the upgrade. After an hour, I still could not ping the server. I decided it was time to bring the crash cart into play. I hooked up the monitor, keyboard, and mouse and, sure enough, the upgraded halted. The message said that it could not continue and suggested a reboot. I did, and selected continue upgrade from the boot menu. That did not work. Nor did it work the subsequent three times I chose the continue upgrade action. Finally, I selected rollback to Windows Server 2008 R2. That took some time, but it worked perfectly. So, my first server running Hyper-V did not make the cut.

The third upgrade introduces a new problem

So, now, I come to the third upgrade—my second server running Hyper-V. Once again, I exported all of the virtual machines to my portable USB drive and started the upgrade. About an hour later, I could not contact the server. I decided to move the crash cart to the machine and saw that Windows Server 2012 was running with no problems. Well, there was one problem, the network adapter did not detect properly, and, therefore, I had no network connectivity. I thought I remembered the hardware in the server, and went online to get the latest drivers. They did not work. I shut down the server, popped the hood, and got out a flashlight to read the numbers from the motherboard. I went back on line, and, while I was at it, downloaded a new bios update as well as the specified network driver from the web site. I flashed the BIOS, and following the reboot, attempted to install the network card driver—no go. I rebooted again, rolled back the driver, and entered the BIOS to double check settings … everything said it was fine.I went back to the web site, and downloaded other network card drivers, but they did not work either. Following a cup of tea, I decided to try one last thing—I went into the computer manager tool, and selected a network card driver that was very close to the same model number as my errant network card. Luckily, it worked. I now have one server running Hyper-V. I imported the virtual machines, started them up, and moved to the next server.

The fourth upgrade worked with no problems at all

So, my last server running Hyper-V—the one I had been afraid of—worked with no problems. I exported the virtual machines to the portable USB drive, upgraded to Windows Server 2012, imported the virtual machines back, and started the virtual machines.

The last upgrade was also no problem

Upgrading my server running SharePoint 2010 to Windows Server 2012 also proved to be no problem. While I was at it, I applied a SQL Server Pack and the updates to SharePoint 2010. I did this prior to upgrading to Windows Server 2012 because I know that sometimes we introduce capabilities in Service Packs to permit running on newer operating systems. This upgrade was straight forward.

Lessons learned

After spending two days shuttling DVDs and stuff, I wish I had done the following:

  1. Install Windows PowerShell 3.0 on the servers prior to attempting the upgrade. This would permit me to use Windows PowerShell Workflow, which would be ideal for this type of upgrade situation. I can easily script the installation of Windows PowerShell 3.0 because I have Windows PowerShell 2.0 installed on my servers, and I have Windows PowerShell remoting enabled as well.
  2. Virtual machines are WAY easier to manage than physical servers. I will talk about upgrading my virtual machines later, but one of the nice things about them is they all have standard hardware. Especially with Hyper-V running on Windows Server 2012, and the very sophisticated Hyper-V cmdlets, this is a piece of cake.
  3. I could have scripted the export and import of the virtual machines on my servers running Windows Server 2008 R2 with Hyper-V by using the Hyper-V module from CodePlex. This free module has an Export-VM cmdlet as well as a Remove-VMSnapshot cmdlet. With three servers running Hyper-V to deal with, this tool could have saved me a lot of time. I could have run these commands as jobs against the remote servers and saved a lot of waiting.
  4. Once the servers running Hyper-V are upgraded to Windows Server 2012, I need to add the Hyper-V role because it is not installed by default. This is as simple as typing the following command.

Get-WindowsFeature hyper-v-powershell | Add-WindowsFeature

Because I am installing the feature on two servers, I use the following three commands:

$session = New-PSSession -cn hyperv2,hyperv3 -cred iammredadministrator

Invoke-Command -Session $session {Get-WindowsFeature hyper-v-powershell | Add-WindowsFeature}

Invoke-Command -Session $session {Get-WindowsFeature hyper-v-powershell} | select pscomputername, name, installed Now that I have the Hyper-V role installed on my two servers, I can do additional cleanup work. I will talk about that tomorrow. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy

0 comments

Discussion is closed.

Feedback usabilla icon