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:
- Perform an initial upgrade to Windows Server 2012 R2.
- 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 Datecenter edition or Windows Server 2008 R2 Datacenter edition to Windows Server 2012 R2 Datacenter edition by:
- Planning the in-place upgrade
- Performing the in-place upgrade
- Troubleshooting the in-place upgrade
- 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:
|
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
To upgrade a VM instance that was created with the Windows Server 2008 R2 image provided by Google, you must use Windows Server 2012 volume license media. You can access the Windows Server 2012 volume license media by creating a persistent disk based on a public image in thewindows-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.
If you are bringing an existing license and your VM instance uses an imported disk or image, use the install media that matches the type of 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:
Verify that your VM instance meets the system requirements for Windows Server 2012 and has sufficient free disk space.
Review recommendations for upgrading server roles, known issues, and the upgrade process for Windows Server 2012 R2.
Review the recommendations for planning an in-place upgrade.
Verify that you aren't affected by features removed or deprecated in Windows Server 2012 R2.
Verify that any of your custom or third-party software is compatible with Windows Server 2012 R2.
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:
Create a regular snapshot for the boot disk of your VM instance.
If the VM instance has additional data disks attached, create snapshots for the data disks by using the Volume Shadow Copy Service (VSS).
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:
Temporarily disable any firewall rules that grant access to external services such as Internet Information Services (IIS) or Remote Desktop Protocol (RDP).
Use hybrid connectivity or Cloud IAP TCP tunneling to access RDP, so that you don't need to externally expose port 3389.
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:
Connect to your VM instance with an RDP client.
Verify that Windows Server is up to date by using Windows Update.
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:
In the Google Cloud Console, open Cloud Shell by clicking the Activate Cloud Shell
button.
Set the default project ID. Replace
[PROJECT_ID]
with the name of your Compute Engine project:gcloud config set project [PROJECT_ID]
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.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:
Connect to your VM instance with an RDP client. For more information, see Connecting to instances.
Open Windows Explorer.
In the root directory of the
C:
drive, create aWindows.setup
folder.Configure Windows Explorer to show file extensions.
In the
C:\Windows.setup
folder, use Notepad or another text editor to create a file namedunattend.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>
In the
C:\Windows.setup
folder, use Notepad or another text editor to create a file namedsetup-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:
Open an elevated command prompt:
- On the Start menu, right-click Command Prompt and select Run as administrator.
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
Change the working directory to the installation media:
cd /d d:\*2012*\sources
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:
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.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
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.
Connect to the VM instance by using an RDP client. For more information, see Connecting to instances.
Log in using a user account with local administrator privileges.
Verify that the machine is now running Windows Server 2012 R2:
- Right-click the Start button.
- Select Run.
- Enter
winver
and click OK.
Verify that the About Windows dialog box indicates that the VM instance is running Windows Server 2012 R2.
Open an elevated command prompt:
Right-click the Start button.
Select Command Prompt (Admin).
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
You no longer need the
unattend.xml
file or thesetup-prep.ps1
script, so you can optionally delete theC:\Windows.setup
folder.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:
Connect to the machine by using an RDP client. For more information, see Connecting to instances.
Use Windows Update to install the latest Windows updates. You might have to restart the VM instance multiple times during this process.
Re-enable any agents, antivirus, or antimalware software that you disabled before the upgrade.
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:
In the Cloud Console, click the instance that you're upgrading.
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:
Connect to a different Windows Server instance in the same VPC.
Open PowerShell.
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.When prompted for credentials, enter the username and password of an administrative user account.
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:
-
This can take several minutes if Windows Server is unresponsive.
Detach the boot disk from the instance.
Create a new, temporary Windows Server instance, and attach the boot disk of the original instance as an additional disk.
Use the temporary Windows Server instance to analyze the setup log and event log files of the instance that you were trying to upgrade.
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
Learn how to bring existing licenses to Compute Engine.
Learn how to connect to Windows instances.
Learn about sole-tenant nodes on Compute Engine.
Work through more Windows tutorials.