Best practices for Windows Server VMs

Windows

You can apply several best practices to optimize Compute Engine instances that run Microsoft Windows Server. This document describes how you can utilize other products available on Google Cloud and to ensure your Windows instances are performing optimally in terms of performance, security, redundancy and availability. For further information on configuration and setup of Windows instances, see Windows Workloads. For Microsoft SQL instances, refer to Best Practices for SQL Server.

General Compute Engine best practices

• Understand which versions of Windows Server are supported, best suited for your use case, and which versions might be coming up to the end of Windows Server support on Google Cloud. Further information can be found at Lifecycle FAQ from Microsoft.
• Understand how to correctly Add a persistent disk to your Windows VM.
• Enable or disable Windows Server operating system features not required for the services run by your organization, unused features will consume resources you might not be using.
• Launch new instances with the latest image version provided by Google Cloud public images, if you are using Pay-as-you-go (PAYG) licence.

Security

• If you are running Windows, you should be running antivirus software. Malware and software viruses present a significant risk to any system connected to a network, and antivirus software is a simple mitigation step you can use to protect your data. Microsoft provides advice about on antivirus software.
• Understand how to create new local users and grant/revoke Administrator privileges on local accounts to limit critical applications and system files.
• If you are using Active Directory, make use of Configuring User Access Control and Permissions to implement the principle of least privilege for user permissions within the Windows operating system. For further information see summary of best practices for Active Directory.

Best practices for securing Windows VMs with BitLocker

Bitlocker provides enhanced protection for your Windows operating system (OS) and data drives, but the increased security comes with the added risk of inadvertently losing access to your own data. You are responsible for ensuring the backup of your recovery key. Don't rely solely on the vTPM for seamless boots in a disaster recovery scenario. You should always externally store the BitLocker recovery key.

Warning: If you lose access to your BitLocker recovery keys, then you won't be able to decrypt the disks and the data is unrecoverable. Google can't recover your data if you lose your BitLocker recovery keys.

To prevent losing access to your data, follow these best practices to safely store your BitLocker recovery keys.

• Ensure that you don't start BitLocker encryption unless the recovery key is stored in Managed Service for Microsoft Active Directory. For more information, see Require BitLocker escrow with a Group Policy Object (GPO).
• Deploy your Active Directory instance across multiple regions to ensure you can access your recovery keys even during a regional outage.
• Periodically export your recovery keys to a secure, versioned location such as a Cloud Storage bucket in a different project or a Secret Manager instance.
• Certain operations or modifications On Shielded VM instances, such as changing the vTPM or recreating an instance from a disk, trigger recovery mode. Once the instance is in recovery mode, you can't access the instance until you enter the recovery key. Therefore, you must always maintain an external copy of the recovery key.

Require BitLocker escrow with a Group Policy Object (GPO)

To prevent losing access to your BitLocker-encrypted disks, configure your instances to ensure that encryption never starts unless the recovery key is safely stored in Managed Service for Microsoft Active Directory.

1. Open the Group Policy Management Console: on your Domain Controller or management VM, open gpmc.msc.
2. Create a GPO: create a new GPO linked to the OU containing your Compute Engine Windows instances.
3. Open the BitLocker Policies: Click Computer Configuration > Policies
4. Click Administrative Templates.
5. Click Windows Components
6. Click BitLocker Drive Encryption.
7. Click Operating System Drives.
8. Configure backup requirements:
   1. Open Choose how BitLocker-protected operating system drives can be recovered.
   2. Select Enabled.
   3. Select Do not enable BitLocker until recovery information is stored in Active Directory DS for operating system drives.
   4. Make sure Store BitLocker recovery information in AD DS is selected and set to store both recovery passwords and key packages.
   5. To protect secondary disks, repeat these steps for the Fixed Data Drives folder.

For detailed information about configuring BitLocker, see Configure BitLocker.

To recover a Windows VM that requires a BitLocker recovery key, see Recover a Windows VM that requires a BitLocker recovery key.

Backup & Recovery

• Routinely review and verify your backup and recovery strategy.
• Enable regular disk snapshots for a quick recovery from a previous backup if there is a VM failure.
  • Only enable VSS snapshots on data volumes and where the application is VSS compatible. Avoid creating VSS snapshots on the operating system disk because the VSS service marks this disk as read-only.

Patch Management

• Confirm your Windows operating system is updated to the latest version and all system and quality updates (also referred to as "cumulative updates" or "cumulative quality updates") are installed.
• Make use of automatic Windows Update on your instance. Microsoft releases patches every second Tuesday of each month at minimum. You should have a strategy for applying these updates to help safeguard the system from known bugs and vulnerabilities. If automatic restarts are not an option, consider creating patch jobs by using VM Manager, which can schedule updates and restart your instances at an appropriate time.

Logging and Monitoring

• Enable virtual displays to better understand the current state of the operating system, and to allow you to view the console in case your instance is inaccessible.
• If your VM instance is stopped, logs from the serial console will no longer be available, to retain these logs you can stream serial port output to Cloud Logging and use the output stored to assist with troubleshooting and auditing.
• Consider configuring the Ops Agent to centralize the logs you see in Event Viewer by streaming logs to Cloud Logging, this allows for easier retrieval of the logs and more consistent retention. This step is completely optional, but recommended.
• Consider installing the Ops Agent to monitor and retain the monitoring data of your instance performance.
• Consider streaming logs from third-party Applications.

Google related drivers, agents & features

• When you use Microsoft software, you are responsible for understanding and complying with any licensing agreements that you might have with Microsoft. To understand the requirements and options for licensing, refer to the Microsoft Licenses documentation.
• Keep the guest environment updated in line with your Windows Update strategy. Regularly updating the guest environment of your Windows instance will ensure you are running the latest and most stable version of all necessary Google Cloud agents and drivers.