Performing an in-place upgrade of Windows Server 2008 R2

If you have virtual machine (VM) instances running on Windows Server 2008 R2, you can upgrade them to Windows Server 2012 R2.

For VM instances running Windows Server 2008 R2, the only available upgrade path is to upgrade to Windows Server 2012 R2. For more information, see Upgrading from Windows Server 2008 R2 or Windows Server 2008.

If you plan to upgrade Windows Server 2008 R2 to a version later than Windows Server 2012 R2, you must:

  1. Perform an initial upgrade to Windows Server 2012 R2.
  2. Perform a second upgrade to Windows Server 2016 or Windows Server 2019.

Objectives

This guide describes how to perform an in-place upgrade from Windows Server 2008 Datacenter edition or Windows Server 2008 R2 Datacenter edition to Windows Server 2012 R2 Datacenter edition by:

  1. Planning the in-place upgrade
  2. Performing the in-place upgrade
  3. Troubleshooting the in-place upgrade
  4. Cleaning up after the in-place upgrade

Costs

There is no charge for performing an in-place upgrade of Windows Server. You are only charged for the resources consumed during the upgrade, including:

Use the pricing calculator to generate a cost estimate based on your projected usage.

Before you begin

The guide assumes that you have basic knowledge of:

Planning the in-place upgrade

Performing an in-place upgrade of a virtual machine (VM) instance that is running on Windows Server 2008 R2 can be a pragmatic way to modernize your infrastructure and to mitigate the risks of approaching the end of the support lifecycle of Windows Server 2008.

Alternatives to consider

Before you decide to use an in-place upgrade to migrate to a newer version of Windows Server, be aware of the following limitations:

  • Downtime: Depending on the configuration and software installed, the upgrade might take an hour or longer. During the upgrade, access to the VM instance is limited because:

    • Workloads running on the VM instance are unavailable to users
    • Remote Desktop Protocol (RDP) is not available
    • There are limited ways to check the upgrade progress and the time remaining in the upgrade

  • Risk: Depending on the configurations of your existing instances and the installed software:

    • The upgrade can fail
    • Some configuration options can be overridden
    • Incompatibilities can cause your workload to malfunction on the upgraded instance

Depending on the workload running on your Windows Server 2008 R2 instance, you can reduce downtime and risk by pursuing different approaches.

Workload Approach
Your VM instance is running a workload that supports replication, such as:
  • Active Directory Domain Services
  • DNS
  • SQL Server
 Consider setting up a new VM instance that is running a more recent version of Windows Server, and then use replication to shift the workload from your existing VM instance to the new VM instance.
You have a VM instance that is running a multitude of workloads Consider migrating these workloads to separate VM instances so that each VM instance runs only a single workload. Even if you can't migrate all workloads, reducing the number of workloads running on a single VM instance can help reduce risks during an in-place upgrade.

Server editions and license conversion

Google provides Windows Server 2008 R2 Datacenter edition as a public operating system image. You can upgrade VM instances based on this image to Windows Server 2012 R2 Datacenter edition without incurring additional charges.

If your VM instance uses an existing license (BYOL), check the Microsoft documentation to determine which edition you can upgrade to and whether you are eligible for license conversion.

Product keys

A Windows Server product key is valid for only a specific version; when you perform an upgrade to a later version of Windows Server, you must supply a new product key. There are two primary scenarios:

  • You are upgrading a VM instance based on the Windows Server 2008 R2 image provided by Google: In this scenario, you must use the predefined KMS client setup keys for Windows Server 2012 R2 Datacenter because Google's volume licensing handles activation of images based on these VM instances.

  • You are upgrading a VM instance for which you brought an existing license: In BYOL, you need to acquire a custom product key from your license vendor to perform the upgrade.

Installation media

Google provides a volume license media for Windows Server 2012 R2 that you can use to upgrade VM instances that have been created with the Windows Server 2008 R2 image. You can access the Windows Server 2012 R2 volume license media by creating a persistent disk based on the windows-install-media image family. Then, before you start the upgrade, attach this disk to one or more of your VM instances, and then perform the upgrade. For more information, see Attaching the install media.

To upgrade a VM instance that is based on an imported disk or image, you have to use a custom install media that matches the type and the language of the media that you used to install Windows Server 2008 R2 on the imported disk or image.

Other prerequisites

Before you begin your upgrade, review the Microsoft documentation about prerequisites and potential limitations:

Performing the in-place upgrade

The following sections guide you through the process of upgrading your VM instance to Windows Server 2012 R2.

Creating a snapshot

Before you start the upgrade, we recommend that you create a snapshot of your VM instance, so that you can revert to a safe state in case anything goes wrong:

Blocking ingress traffic during the upgrade

Since the GA release of Windows Server 2012 R2, Microsoft has released a number of security updates. When you upgrade to Windows Server 2012 R2, these security updates might not be installed automatically. After the upgrade completes, you must download and install missing security updates by using Windows Update.

Downloading and installing security updates can take a substantial amount of time, and during this time, the Windows Server instance might be vulnerable to security exploits. To reduce risk, consider blocking all nonessential ingress traffic to the VM instance. To do this:

  1. Temporarily disable any firewall rules that grant access to external services such as Internet Information Services (IIS) or Remote Desktop Protocol (RDP).

  2. Use hybrid connectivity or Cloud IAP TCP tunneling to access RDP, so that you don't need to externally expose port 3389.

  3. Create firewall rules to temporarily block access to nonessential ports from within your Virtual Private Cloud (VPC).

Preparing your Windows Server configuration

Verify the configuration of your Windows Server 2008 R2 VM instance:

  1. Connect to your VM instance with an RDP client.

  2. Verify that Windows Server is up to date by using Windows Update.

  3. Disable or uninstall antivirus, antispyware, and other agents that can interfere with the upgrade or are incompatible with Windows Server 2012 R2.

Attaching the install media

Before you can perform the upgrade, attach the Windows Server 2012 R2 installation media to the VM instance. Google Cloud doesn't support mounting a CD or ISO file directly, so you can use an image that Google provides:

  1. In the Google Cloud Console, open Cloud Shell by clicking the Activate Cloud Shell Activate Cloud Shell. button.

    Go to the Google Cloud Console

  2. Set the default project ID. Replace [PROJECT_ID] with the name of your Compute Engine project:

    gcloud config set project [PROJECT_ID]

  3. Create a disk based on the installation media. Replace [ZONE] with the name of the zone where the VM instance is located:

    gcloud compute disks create win-installers --image-family=windows-install-media --image-project=compute-image-tools --zone=[ZONE]

    This command adds a disk named win-installers to your project. This disk is not attached to any VM instance.

  4. Attach the disk to your VM instance, by using read-only (ro) mode so that you can attach the disk to multiple VM instances if necessary. Replace [INSTANCE_NAME] with the name of the VM instance to upgrade, and replace [ZONE] with the name of the zone where the VM instance is located:

    gcloud compute instances attach-disk [INSTANCE_NAME] --disk=win-installers --mode=ro --zone=[ZONE]

Preparing an answer file

By default, Windows Setup prompts you for input at various points during an upgrade. Because you can't connect to the VM instance by using RDP during the upgrade, you can't provide the requested input, which can stall the upgrade. To suppress these prompts, provide an answer file to perform the upgrade in unattended mode.

The answer file instructs Windows Setup to:

  • Suppress all user input prompts
  • Select the correct edition of Windows Server 2012 R2
  • Provide a product key that is suitable for Windows Server 2012 R2

Prepare the answer file as follows:

  1. Connect to your VM instance with an RDP client. For more information, see Connecting to instances.

  2. Open Windows Explorer.

  3. In the root directory of the C: drive, create a Windows.setup folder.

  4. Configure Windows Explorer to show file extensions.

  5. In the C:\Windows.setup folder, use Notepad or another text editor to create a file named unattend.xml with the following contents:

    <?xml version="1.0" encoding="utf-8"?>
  <unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="windowsPE">
      <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
        <UpgradeData>
          <Upgrade>true</Upgrade>
            <WillShowUI>Never</WillShowUI>
        </UpgradeData>
        <ImageInstall>
          <OSImage>
            <WillShowUI>OnError</WillShowUI>
            <InstallTo>
              <DiskID>0</DiskID>
              <PartitionID>1</PartitionID>
            </InstallTo>
            <InstallFrom>
              <Path>install.wim</Path>
              <MetaData>
                <Key>/IMAGE/NAME</Key>
                <Value>Windows Server 2012 R2 SERVERDATACENTER</Value>
              </MetaData>
            </InstallFrom>
          </OSImage>
      </ImageInstall>
      <ComplianceCheck>
        <DisplayReport>OnError</DisplayReport>
      </ComplianceCheck>
      <UserData>
        <AcceptEula>true</AcceptEula>
        <ProductKey>
          <!-- See https://docs.microsoft.com/en-us/windows-server/get-started/kmsclientkeys -->
          <Key>W3GGN-FT8W3-Y4M27-J84CP-Q3VJ9</Key>
        </ProductKey>
      </UserData>
    </component>
  </settings>
</unattend>

  6. In the C:\Windows.setup folder, use Notepad or another text editor to create a file named setup-prep.ps1 with the following contents:

    $ErrorActionPreference = "Stop"
Write-Host "== Enabling EMS access ===================================" `
     -ForegroundColor Black -BackgroundColor Yellow

$SvchostPath = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost'
$SvchostServices = (Get-ItemProperty -Path $SvchostPath).netsvcs
$SvchostServices += 'sacsvr'
Set-ItemProperty -Path $SvchostPath -name netsvcs `
    -value $SvchostServices -type MultiString

& bcdedit /emssettings EMSPORT:2 EMSBAUDRATE:115200 | Out-Default
& bcdedit /ems on  | Out-Default

Write-Host "== Updating Google drivers and packages ==================" `
     -ForegroundColor Black -BackgroundColor Yellow

& googet -noconfirm install google-compute-engine-auto-updater  | Out-Default
& googet -noconfirm install google-compute-engine-driver-gga    | Out-Default
& googet -noconfirm install google-compute-engine-driver-gvnic  | Out-Default
& googet -noconfirm install google-compute-engine-driver-netkvm | Out-Default
& googet -noconfirm install google-compute-engine-driver-pvpanic| Out-Default
& googet -noconfirm install google-compute-engine-driver-vioscsi| Out-Default
& googet -noconfirm install google-compute-engine-sysprep       | Out-Default
& googet -noconfirm install google-compute-engine-vss           | Out-Default

Write-Host "== Synchronizing time ====================================" `
     -ForegroundColor Black -BackgroundColor Yellow

Start-Service W32time
& w32tm /resync | Out-Default

Write-Host "== Restoring TCP timeout and route to metadata server ====" `
     -ForegroundColor Black -BackgroundColor Yellow

$TcpParams = 'HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters'
New-ItemProperty -Force -Path $TcpParams -Name 'KeepAliveTime' `
   -Value 300000 -PropertyType DWord

& route add 169.254.169.254 mask 255.255.255.255 0.0.0.0 -p | Out-Default

Write-Host "== Refreshing Windows license ============================" `
     -ForegroundColor Black -BackgroundColor Yellow
& 'C:\Program Files\Google\Compute Engine\sysprep\activate_instance.ps1' | Out-Default

Write-Host "== Completed =============================================" `
     -ForegroundColor Black -BackgroundColor Yellow

Starting the upgrade

To start the upgrade:

  1. Open an elevated command prompt:

    • On the Start menu, right-click Command Prompt and select Run as administrator.

  2. Run the setup-prep.ps1 script that you created earlier. The script installs the latest Google driver packages, which are critical for the Windows Server upgrade to succeed. Additionally, the script applies specific Compute Engine settings and enables access to the Emergency Management Services (EMS) console.

    powershell -ExecutionPolicy Bypass -file c:\Windows.setup\setup-prep.ps1

    The upgrade process might issue the following warning. If so, you can ignore it:

    [package name] or a newer version is already installed on the system

  3. Change the working directory to the installation media:

    cd /d d:\*2012*\sources

  4. Start Windows Setup, passing it the unattend.xml file created earlier:

    setup.exe /unattend:c:\Windows.setup\unattend.xml /EMSPort:COM2 /emsbaudrate:115200

    Because you are running the upgrade in unattended mode, the setup wizard immediately begins to copy files.

    After about 5 minutes, the machine reboots, and RDP disconnects.

Observing the upgrade process

Depending on the machine type of your VM instance and your Windows Server configuration, the upgrade might take between 10 and 60 minutes to complete. During that time, you can observe the status through the serial port output:

  1. In Cloud Shell, observe the boot process by running the following command:

    gcloud compute instances tail-serial-port-output [INSTANCE] --zone=[ZONE]

    Replace [INSTANCE] with the ID of your VM instance and [ZONE] with the name of the zone where the VM instance is located.

  2. Wait until the machine has rebooted four times. Depending on the configuration of your VM instance, it might take 30 minutes or more for these reboots to occur. You can recognize a reboot by output that looks similar to this:

    SeaBIOS (version 1.8.2-20190620_103534-google)
Total RAM Size = 0x00000001e0000000 = 7680 MiB
CPUs found: 2     Max CPUs supported: 2

  3. After the fourth reboot, wait until the following line appears:

    GCEMetadataScripts: Finished running startup scripts.

Performing post-upgrade steps

You can now connect to the VM instance to verify that the upgrade has been successfully completed.

  1. Connect to the VM instance by using an RDP client. For more information, see Connecting to instances.

  2. Log in using a user account with local administrator privileges.

  3. Verify that the machine is now running Windows Server 2012 R2:

    1. Right-click the Start button.
    2. Select Run.
    3. Enter winver and click OK.

  4. Verify that the About Windows dialog box indicates that the VM instance is running Windows Server 2012 R2.

  5. Open an elevated command prompt:

    1. Right-click the Start button.

    2. Select Command Prompt (Admin).

  6. Run the setup-prep.ps1 script to re-apply specific Compute Engine settings that might have been lost during the upgrade:

    powershell -ExecutionPolicy Bypass -file c:\Windows.setup\setup-prep.ps1

    The upgrade might issue the following warning, which you can ignore:

    [package name] or a newer version is already installed on the system

  7. You no longer need the unattend.xml file or the setup-prep.ps1 script, so you can optionally delete the C:\Windows.setup folder.

  8. Restart the VM instance to enable all changes to take effect. It might take 1 to 2 minutes for the reboot to complete before you can connect to the VM instance again.

Detaching the installation disk

You can now detach the installation disk from the VM instance:

  • In Cloud Shell, detach the installation disk from your VM instance:

    gcloud compute instances detach-disk [INSTANCE_NAME] --disk=win-installers

    Replace [INSTANCE_NAME] with the name of your VM instance.

Installing updates and restoring access

After the upgrade is complete, run Windows Update to download and install any security updates. To install these updates:

  1. Connect to the machine by using an RDP client. For more information, see Connecting to instances.

  2. Use Windows Update to install the latest Windows updates. You might have to restart the VM instance multiple times during this process.

  3. Re-enable any agents, antivirus, or antimalware software that you disabled before the upgrade.

  4. If you previously blocked ingress traffic to the VM instance, you can now restore the original firewall rules.

Troubleshooting the in-place upgrade

While running Windows Setup, you can't connect to the VM instance with RDP. If you suspect that the upgrade failed or is not progressing, use the following approaches, in order, to diagnose the situation:

Check the serial port output

Windows Setup doesn't emit any logs to the serial port, but you can use the serial port output to observe the restarts and the boot status of the VM instance.

During the upgrade, you should observe four reboots. If you don't observe any progress for more than 30 minutes after the first reboot, it is likely that the upgrade failed.

Check CPU and I/O metrics

Running a Windows Server upgrade is a CPU and disk I/O intensive operation. By checking the CPU and I/O metrics, you can get an indication for whether the setup is progressing.

View the CPU and I/O metrics in the Google Cloud Console:

  1. In the Cloud Console, click the instance that you're upgrading.

    Go to the Cloud Console

  2. Click the Monitoring tab.

Connect to the Emergency Management Services console

Both during and after running Windows Setup, you can connect to the Emergency Management Services (EMS) console. Using the EMS console, check the Windows Setup log files and the event log for indications that the upgrade is still progressing or for information about any errors that might have occurred.

Connect remotely by using WinRM

If connecting by using RDP or EMS fails, you can try using WinRM to establish a remote PowerShell session:

  1. Connect to a different Windows Server instance in the same VPC.

  2. Open PowerShell.

  3. Establish a remote PowerShell session:

    Enter-PSSession -ComputerName [INSTANCE-NAME] -UseSSL -SessionOption (New-PsSessionOption -SkipCACheck) -Credential (Get-Credential)

    Replace [INSTANCE-NAME] with the name of the instance you are trying to upgrade.

  4. When prompted for credentials, enter the username and password of an administrative user account.

  5. Use the remote PowerShell session to check the Windows Setup log files and the event log.

Analyze log files offline

If you can't connect to the instance by using Windows Remote Management (WinRM), you can cancel the upgrade and analyze the log files from a different VM instance. To do this:

  1. Stop the VM instance.

    This can take several minutes if Windows Server is unresponsive.

  2. Detach the boot disk from the instance.

  3. Create a new, temporary Windows Server instance, and attach the boot disk of the original instance as an additional disk.

  4. Use the temporary Windows Server instance to analyze the setup log and event log files of the instance that you were trying to upgrade.

  5. After you have completed the analysis, detach the disk from the temporary instance and reattach it as a boot disk to the original VM instance.

Troubleshoot RDP

For information about troubleshooting RDP, see Troubleshooting RDP.

Troubleshoot your Windows Server instances

For information about troubleshooting your Windows Server instances, see Tips and troubleshooting for Windows instances.

Cleaning up

To avoid incurring further costs after you have completed this process, delete the installation disk.

Deleting the installation disk

You can create an installation disk based on the Google-provided image at any time. If you don't plan to upgrade more VM instances in the same zone, delete the installation disk:

  • In Cloud Shell, delete the win-installers disk that you created earlier:

    gcloud compute disks delete win-installers

What's next