First Party Services Adoption for Migrated Virtual Machines via Azure Policy

Posted by

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.


Server migrations to Azure Virtual Machines either through Azure Migrate or via a redeploy approach can benefit from Azure policies to accelerate adoption of Azure first party services across BCDR, Security, Monitoring and Management. 


Our Cloud Adoption Framework’s guidance for Azure Landing Zones already provides a good baseline of recommended Azure policies. However, a variation to this baseline is described in this article with a focus on newly migrated Azure Virtual Machine resources.  



To enable Azure Backup and Azure Site Recovery for Virtual Machines, a recovery services vault is needed.  


For Azure Backup, the recovery services vault is to be deployed in the same region as the virtual machine. Commonly, the recovery services vault will be used for multiple virtual machines in the same region. A pre-created recovery services vault is needed, and the following built-in policy can be used to enable backups for the migrated servers to use this existing recovery services vault: 


For Azure Site Recovery, the recovery services vault should be deployed in the target region where virtual machines will failover. Similarly, a recovery services vault should be pre-created and used for multiple virtual machines which will failover to the same target region. The following built-in policy can be used to enable Azure Site Recovery replication for the migrated servers and use an existing recovery services vault: 




Defender for Cloud, previously known as Azure Security Center, can be enabled for the migrated servers using a collection of built-in policies and initiatives either through the Defender for Cloud interface or directly through Azure policies. Depending on whether you are planning on consuming the free or paid offerings for Defender for Servers and Defender for SQL Server, you can enable the following built-in initiatives and policies as needed. We recommend these be enabled at the subscription or management group scope as Defender for Cloud does not yet support features enablement to resource groups scopes: 


The Defender Free Tier, which includes the Microsoft Cloud Security Posture and OS Hardening Recommendations features: 


In addition to the above Free Tier built-in initiatives, Defender for Servers offers paid plans which require the following built-in initiatives for Defender for Servers Plan 1, Endpoint Protection feature: 



Further, Defender for Servers Plan 2 offers additional features related to OS-level events data collection via the Azure Monitor Agent which are stored in log analytics workspaces, as well as File Integrity features. A log analytics workspace should be pre-created for the virtual machines to leverage as a shared data store resource in the same region. Second, in advance, File Integrity should be enabled within Defender for Cloud to create a Data Collection Rule which will be specified in the Initiative. To configure these features the following are the necessary built-in initiatives: 


Finally, Defender for Cloud offers a workload specific offering for SQL databases via the Defender for SQL Server plan, which is in addition to Defender for Servers. The following built-in initiative configures Defender for SQL Servers on Virtual Machines: 




Azure Monitor is the central place to enable, view and alert based on metrics and diagnostics data collection for the migrated virtual machines into a log analytics workspace via the Azure Monitor Agent and Data Collection Rules. A log analytics workspace should be pre-created for the virtual machines to leverage as a shared data store resource in the same region. In addition, Data Collection Rules should be pre-created to collect basic performance and events data, specifically a DCR for Windows and a DCR for Linux Virtual Machines. One these resources are created; you can leverage the following built-in initiatives to enable the AMA agent installation and Data Collection Rule linking at scale for Windows and Linux Virtual Machines: 



Further, alerting on the monitoring data collected is necessary to make it actionable. The following custom initiatives and policies for migrated virtual machines are recommended to create a baseline set of alerts based on Service Health, VM Metrics and VM Logs data: 




Tagging virtual machines (and any Azure resource) is a recommended practice to more easily differentiate the purpose of these resources when reviewing cost invoices or when querying and inventorying based on metadata. The below Azure built-in policy is a simple way to add a tag to a migrated virtual machine: 



Finally, patching virtual machines using Azure’s Update Manager can be accomplished by configuring the below built-in policy. In advanced, a Maintenance Configuration resource needs to be created: 



All the above policies and initiatives deploy configurations to Azure subscriptions. If you wish to view in advance the scope of the migrated resources missing these configurations, an Azure Monitor Workbook can be used. The following Azure Monitor Workbook identifies a subset of the above post-migration activities commonly recommended for your migrated virtual machines: 





In summary, the above initiatives and policies can better accelerate the adoption of Azure’s first party services for migrated virtual machines. While there are additional policies and initiatives to consider for other resource types, such as the virtual machine’s underlying networking, this article focuses on a subset of policies and initiatives for an environment focused on Infrastructure as a Service - Virtual Machines. 


Happy migration and adoption of our first party services for your virtual machines! Let us know what you think. 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.