If you have virtual machine (VM) instances running Windows Server 2008 R2, you can use the gcloud CLI to automatically upgrade them to Windows Server 2012 R2.
Using the gcloud CLI to perform an in-place upgrade is an alternative to performing a manual upgrade. By automating the upgrade process, the gcloud CLI lets you reduce the effort required for each VM that you need to upgrade.
During an in-place upgrade of a VM, the gcloud CLI performs the following steps:
- Stops the VM.
- Creates a standard Persistent Disk snapshot as a backup.
- Creates a copy of the boot disk, keeping the original boot disk as a backup.
- Attaches an installation disk containing the Windows 2012 R2 install media.
- Launches Windows Setup (
setup.exe
) from the installation disk to perform an upgrade in unattended mode. - Applies post-upgrade configuration.
- Detaches the installation disk.
- Stops the VM.
Limitations
You can use the gcloud CLI to perform upgrades from Windows Server 2008 R2 to Windows Server 2012 R2. This approach only supports VM instances that are based on a public operating system image provided by Google. To upgrade other configurations of Windows Server, or to upgrade VM instances for which you bring your own license, see Performing an in-place upgrade of Windows Server.
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
- Make sure you understand the limitations and potential alternatives to performing in-place upgrades of Windows Server.
- 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 the Windows Server version that you're upgrading to.
- Review the Microsoft documentation about prerequisites and potential limitations of Windows Server 2012 R2:
- 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.
- Make sure you are granted one of the following Cloud IAM roles before proceeding:
- This guide uses Cloud Shell to run the gcloud CLI. If you want to run the gcloud CLI on your local computer instead, make sure to download and install the latest gcloud CLI first.
Starting the upgrade
The following sections guide you through the process of upgrading your VM instance.
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
Run the following command to start the upgrade:
gcloud beta compute os-config os-upgrade VM_NAME \ --zone=
ZONE
\ --source-os=windows-2008r2 \ --target-os=windows-2012r2 \ --async \ --auto-rollbackReplace the following:
VM_NAME
: the name of the VM instance to upgradeZONE
: the zone the VM instance is running in
The
--async
flag tells the gcloud CLI to run the upgrade in the background by using Cloud Build. Running the upgrade in the background lets you upgrade multiple VM instances in parallel and also ensures that the process continues even if you close your Cloud Shell session. You can find a link to the Cloud Build job in the command output:Created [https://cloudbuild.googleapis.com/v1/projects/...]. ... logUrl: https://console.cloud.google.com/build/builds/... ... status: QUEUED ...
Observing the upgrade process
Depending on the configuration of your VM instance, the upgrade might take between 40 and 90 minutes to complete. You can check the status of the upgrade process by opening the Cloud Build log:
- Click the URL shown next to
logUrl
in the command output of the gcloud CLI. - Under Build log, you can see the current status of the upgrade process.
When the upgrade finishes successfully, the build is marked as Successful and you can see the following output in the build log:
Successfully upgraded instance 'projects/...!'
If the gcloud CLI encounters a problem during the upgrade, it marks
the build as Failed. If the --auto-rollback
option is specified,
the gcloud CLI also initiates an automatic rollback. You can find
further details about the problem encountered in the build log.
If the upgrade is still running after 90 minutes and you suspect that the upgrade is not progressing, use one of the approaches described in Troubleshooting the in-place upgrade to find out whether the upgrade process failed or is stalled.
Completing the upgrade
After the upgrade is complete, start the VM instance and run Windows Update to download and install the latest security updates:
Start the VM instance:
gcloud compute instances start
VM_NAME
--zone=ZONE
Replace the following:
VM_NAME
: the name of the VM instanceZONE
: the zone the VM instance is running in
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.
Verify that all your applications work as expected.
Rolling back an upgrade
If the upgrade fails, the gcloud CLI automatically initiates a roll-back. If the upgrade succeeds, you might still find that one of your applications does not work as expected. In that case, roll back the upgrade by changing the VM instance to use the original boot disk again:
Stop the VM instance:
gcloud compute instances stop
VM_NAME
--zone=ZONE
Replace the following:
VM_NAME
: the name of the VM instanceZONE
: the zone the VM instance is running in
In the build log, find the lines indicating the name of the original boot disk and the name of the attachment:
4. Original boot disk: ORIGINAL_DISK_NAME - Device name of the attachment: DEVICE_NAME
Detach the disk containing the malfunctioning operating system from your instance:
gcloud compute instances detach-disk VM_NAME \ --device-name=DEVICE_NAME \ --zone=ZONE
Replace the following:
VM_NAME
: the name of the VM instanceDEVICE_NAME
: the device name as indicated by the build logZONE
: the zone the VM instance is running in
Reattach the original boot disk:
gcloud compute instances attach-disk
VM_NAME
\ --disk=ORIGINAL_DISK_NAME \ --device-name=DEVICE_NAME \ --zone=ZONEReplace the following:
- VM_NAME: the name of the VM instance
ORIGINAL_DISK_NAME
: the name of the original boot disk as indicated by the build logDEVICE_NAME
: the device name as indicated by the build logZONE
: the zone the VM instance is running in
Start the VM instance:
gcloud compute instances start VM_NAME --zone=ZONE
Replace the following:
VM_NAME
: the name of the VM instanceZONE
: the zone the VM instance is running in
Clean up
To avoid incurring additional charges, remove the backups that the gcloud CLI automatically created before the upgrade:
In the build log, find the line indicating the name of the disk snapshot and the original boot disk:
3. Snapshot for original boot disk:
SNAPSHOT_NAME
4. Original boot disk:DISK_NAME
- Device name of the attachment: ... - AutoDelete setting of the attachment: true 5. Name of the new boot disk: ...Return to Cloud Shell and delete the disk snapshot:
gcloud compute snapshots delete SNAPSHOT_NAME
Delete the original boot disk, replacing
ZONE
with the zone the VM is deployed in:gcloud compute disks delete DISK_NAME --zone=ZONE
What's next
- Read about manually performing in-place upgrades of Windows Server.
- Find out how you can troubleshoot an in-place upgrade.
- Learn more about persistent disk snapshots.