Log Analytics Agent-based Azure Management Services: Shut down starting 28 February 2025
Overview The legacy Log Analytics (LA) agent, which has played a critical role in transferring data logs for software and applications to Azure, was deprecated on August 31, 2024. Subsequently, all Azure services and solutions relying on the Log Analytics agent for data collection are also being phased out. This transition ensures a seamless shift to more robust replacement products, enhancing continuity, security, and performance for customers' IT estates. Two of the Azure Automation solutions provided management of machines using the LA agent namely, Azure Automation Update Management for streamline software update deployment & Azure Change Tracking & Inventory for tracking changes and inventory for in-guest environments. These agent-based services were also deprecated on 31 st August 2024. Over the last 6 months, these solutions were maintained, giving customers time to move their management processes to the replacement products. In order to ensure a security posture of the customer environments, these LA agent-based solutions will be completely shut down starting 28 th February 2025. You may encounter your existing patching jobs fail and staleness in the changes data in the log analytics workspace after this date. Following captures further details on the impact to operations for the machines that continue to be on these solutions and provides additional guidance. What will change after 28 th February 2025? a) You will not be able to access both Azure Automation Update Management & Azure Change Tracking & Inventory enabled with the LA agent from the Azure Portal. b) For Azure Automation Update Management, no new periodic assessments or patching data corresponding to configured machines will be populated. c) For Change Tracking & Inventory with LA agent, no new changes or inventory logs will be captured. Note: Historical data for the last 30 days will continue to be available in LA workspace and can be directly queried from the LA tables LA workspace table Purpose ConfigurationData To obtain inventory logs for auditing and compliance needs ConfigurationChange To obtain logs corresponding to the changes made in customer environment Update To query periodic assessments and patched updates data for pending updates view What next? If you have any machines configured with legacy version of above-mentioned services, please use one of the following available methods to migrate to replacements products – Product Service Product Migration Guidance Azure Change Tracking & Inventory with LA agent a) Migrate to Azure Monitoring Agent (AMA) version of Change Tracking & Inventory – Using Azure Portal Using PowerShell b) If you have enabled File Integrity monitoring (FIM) with LA agent & managing it via Change Tracking & Inventory experience, here are the available options to migrate to - Move to Change Tracking & Inventory with AMAfor enhanced insights for data types including Files, Registry Keys, Software, Windows Services, Linux Daemons, File content changes. Move to FIM with MDE (part of Defender for Servers Plan 2) Azure Automation Update Management Migrate to Azure Update Manager (Does not rely on AMA) Using Azure Portal Using Runbook scripts Additionally, you can refer to these instructions to disable LA agent from your environment. Please feel free to reach out to us on aumpm@microsoft.com for any queries or feedback.Azure Landing Zones - Policy Refresh Q2 FY25
As before, we release updates to Azure Landing Zones policies (and the portal accelerator) on a quarterly basis to reduce the burden of managing change frequently. The policy updates part of this release process are consumed by all the reference implementations (Portal, Terraform, Bicep) but the portal changes are only applicable to the portal accelerator. An important note, is that the ALZ portal accelerator and all Azure Policy provided by Azure Landing Zones are maintained in the same GitHub repository, which is why policy and portal accelerator changes are grouped together. This release has been slightly delayed due to the festive season and new security patches deployed by resource providers that have had impacted Azure Landing Zones deployments. These are the highlights of this release: Policy With the announcement and preview release of policy versioning back in May 2024, we've been tracking the potential impact on Azure Landing Zones. To this end as part of this releases we've implemented support for policy versioning in all ALZ initiatives and initiative/policy assignments referring to a built-in policy/initiative. This means that all the ALZ initiatives and assignments are now pinned to the current validated major version of the built-in policy (defined as `1.*.*`, or whatever the current major version is). A policy's major version is incremented whenever there is a breaking change to the definition/function of the policy. Pinning to the current major version of the policy gives us control in determining the version that we've validated, tested and confirmed to work with ALZ. As new major versions are published we'll review the changes we need to make, test and validate the new version and then publish as part of our regular policy release cadence (quarterly). This change also required us to update the Policy(Set) API version to the latest version which supports policy versioning. We've also included a number of fixes and updates requested by the community. A community request for better tag auditing based on an array of required tags, has resulted in two new custom policies: Audit-Tags-Mandatory-Rg Audit-Tags-Mandatory Policy updates are available today in the portal accelerator, and will be included in the Terraform and Bicep accelerators in the coming weeks. Portal Accelerator With this release we've added support for deploying Azure Virtual Network Manager (AVNM) for Hub & Spoke and NVA network topologies. You will now have the option to deploy it as part of the network configuration: Today, we only support the Security Admin rules feature of AVNM, which we deploy to manage the Intermediate Root management group scope, include Network Groups for all scopes under the Intermediate Root management group and deploy policies to automatically add virtual networks under those scopes to the relevant Network Group. To illustrate the Network Groups, this is an example of a multi-region (Sweden Central and UK South) deployments Network Groups: As part of the deployment, we've included a Security Admin rule collection that blocks high-risk ports from the internet (Protect High-Risk Ports) that we apply to the "all virtual networks" network group. We've had feedback that for the Workload Specific Compliance section some of the controls are very restrictive out of the box and the ask was to include an "Audit Only" option for each of the guard rails. We've updated the portal accelerator and enabled this by changing the iniative enforcement mode to "DoNotEnforce" if the "Audit Only" option is selected. Once audit compliance has been remediated, you can then choose to update the assignment to enable enforcement to activate the guardrails. Under the hood we've also made significant quality of life changes: We now register all required resource providers with all included subscriptions in the ALZ deployment, which helps avoid issues for new tenants (greenfield environments). We've also changed how we wait for management groups to be registered which has significantly improved the reliability and consistency of ALZ deployments using the portal accelerator. Important Links Quick link to the portal accelerator: And as always, to get all the details, please review: ALZ What's NewNow Open Source: nxtools, managing Linux IaC just got simpler using Automanage machine configuration
We are "nxcited" to announce the release of nxtools, an opensource collection of class-based DSC resources for commonly used Linux / Unix modules and built-in Machine Configuration packages for customers. Azure Automanage Machine Configuration (previously known as Azure Policy Guest Configuration) enables configuration as code allowing you to audit and configure OS, app, and workload level settings at scale, both for machines running in Azure and hybrid Azure Arc-enabled servers.Exciting News: AMBA Portal Accelerator is now Generally Available!
We are thrilled to announce that the Azure Monitor Baseline Alerts-Azure Landing Zones (AMBA-ALZ) Portal Accelerator has officially reached General Availability (GA). This achievement is a big step forward in our goal to make onboarding and simplify monitoring your Azure environment regardless of whether or not you are fully aligned to Azure Landing Zones. Screenshot of Azure Landing Zone portal Accelerator What is the AMBA Portal Accelerator? As we introduced AMBA into the ALZ portal experience (not to be confused with this accelerator!) and with the increased flexibility AMBA-ALZ provided for the preferred action notification types, this introduced a need to provide a post ALZ-AMBA Portal to accommodate those notification types that required an existing resource (Azure Function, Event Hub, and Logic App) and in the case of deploying ALZ possibly for the first time these resources may not be present. The AMBA-ALZ Portal Accelerator is designed to simplify the process of setting up baseline alerts, helping you boost your observability maturity in your Azure environment with minimal effort or expertise. You can set up alerts faster and with more confidence. You'll get timely notifications about critical metrics and log anomalies that might signal potential issues with your Azure workloads. What Scenarios Does The Accelerator Help Address? There are a few scenarios as to where the Accelerator can help meet you where you are in your journey: You are an existing Azure customer and looking to mature your observability posture (and at the same time with low effort move one step closer to being aligned to Azure Landing Zones You have an existing Azure Landing Zones implementation prior to AMBA being released and are looking to update your environment to include AMBA-ALZ You may be new to Azure and deploying Azure Landing Zones (the recommended way to onboard to Azure) and wanting to use Azure Function, Event Hub, and Logic App Notification Types Getting Started To begin using the AMBA-ALZ Portal Accelerator, navigate to https://aka.ms/amba/alz/portal or click the "Deploy to Azure" button on the documentation page. Detailed deployment instructions and further guidance are available to help you get started quickly and efficiently. If you have any further feedback please use the following links: 💬 - Feedback GitHub Issues: https://aka.ms/amba/issues 💬 - Feedback survey: https://aka.ms/ambaSurveyAzure Change Tracking & Inventory: Simplified onboarding to manage in-guest changes on Azure Arc VMs
Explore new Azure native few clicks onboarding experience for Change Tracking & Inventory on Azure Arc servers, streamlining in-guest change management operations, while strengthening your adaptive cloud strategy.
Ensure failover capacity at optimal cost with Azure Site Recovery
Business Continuity and Disaster Recovery (BCDR) is becoming increasingly crucial as the data estates of customers are growing. Azure Site Recovery (ASR) is the Virtual Machine (VM) Disaster Recovery (DR) service provided by Azure and is a key component of several customers' BCDR strategies. ASR enables the replication of workloads from a primary location to a secondary location. In the event of an outage at the primary site, workloads can be accessed from the secondary location by failing over. Once the primary location is operational again, it is possible to fail back to it. In this article, we address a common question: How can you improve the chances of capacity availability for completing failovers at optimal costs? When planning the Disaster Recovery strategy, it’s essential to understand that the cloud ecosystem operates on a shared responsibility model between customers and cloud providers. If compute capacity is unavailable in the DR region due to some reasons, failovers may fail with allocation issues. Therefore, it is recommended to identify the workloads that require high SLA for capacity availability in the DR location, based on business criticality or compliance requirements. For these critical workloads, you are recommended to opt-in for On-Demand Capacity Reservations when using Azure Site Recovery. When you configure capacity reservation group with ASR, Capacity Reservation SLA gets added for failovers in DR location. Please keep in mind that capacity reservation has cost implications. How can cost be optimized for capacity reservations? Capacity Reservations are priced at the same rate as the underlying VM size. To optimize cost when using Capacity Reservation along with ASR, you can also use Azure VM Reserved Instances or Azure Savings plan for compute. This is because capacity reservations are eligible for Savings Plan and Reserved Instances term commitments discounts. Azure Reserved Instances or Azure Savings Plan do not provide any capacity SLA but provide discounted rates for commitments whereas Capacity Reservation provides the capacity SLA. Keep in mind that reserved instances or savings plan only cover the compute cost of VMs; additional costs (like OS license cost, software licenses, etc.) will still apply. Azure Reserved Instances allows you to commit to one-year or three-year term of compute capacity by paying up-front or monthly at a discounted rate compared to pay-as-you-go rates, enabling customers to save up to 72% for the VM cost. Azure Savings Plan allows you to reduce compute usage costs by up to 65% compared to pay-as-you-go rates by making an hourly spend commitment across all in-scope instances. Depending on your workloads pattern and needs, you can decide between a savings plan and a reservation. If you have workloads that run continuously and are stable, Azure Reserved Instance may be the preferable option. If you have workloads that are dynamic and evolving, Azure Savings Plan may be a preferable option. If you are using Azure Reserved Instances for the ASR protected workload configured for regional protection, note that the targeted region would not be covered by the Reserved Instance pricing that was being applied in the source region. The target region would require its own Azure Reserved Instance commitment to cover the additional VMs in the failed over region. Since failed over workloads are typically short term and tend to be failed back to the original source, you will need to determine if additional Reserved Instance commitments make sense for your situation. If you are using Azure Savings plan, ensure ASR failed over VMs are within scope of the savings plan. With Azure savings plan, hourly usage charges incurred from savings plan-eligible resources, which are within the benefit scope of the savings plan, are discounted and applied to your hourly commitment until the hourly commitment is reached. Illustration Let us take an example of an Azure Reserved Instance: Source location of VMs: East US2 Target location: West US2 2 VMs: each of D4s_v5 (4 vCPU, 16 GiB RAM), one running Windows utilizing Azure Hybrid Benefit and the other Linux. Both these VMs have ASR configured with the source VM size configured for ASR target as well. Target resource group named: asr-westus2-rg You have also associated a Capacity Reservation Group while configuring ASR on each of above VMs. This associated capacity reservation group has two (2) VM instances of size D4s_v5. By default, capacity reservation will utilize the pay-as-you-go pricing of the D4s_v5 VM. The cost for this capacity reservation will be for two D4s_v5 VMs in West US2 per month (2*140.16 = USD 280.32). So irrespective of whether you have failed over to West US2 or not, you will keep paying USD 280.32 per month for capacity reservation. Now, you purchase reserved instance for 2 VMs of size D4s_v5 in West US2 for a commitment term of 3 years with the scope as single resource group (asr-westus2-rg) which is same resource group used as target resource group for ASR. The price for reserved instance for 3-year term is (2*51.8592 = 103.7184) USD 103.7184 per month, thus having ~63% of cost savings. This reserved instance applies to your capacity reservation, and you are paying USD ~104 per month effectively. Please note that prices in the illustration are from Pricing - Windows Virtual Machines | Microsoft Azure as on 08-Nov-2024. For Windows, Azure Hybrid Benefits (AHB) were also applied while making the above calculations. Prices are estimates only and are not intended as actual price quotes. Actual prices may vary. nshot of price from Azure Pricing Page for Windows OS with AHB applied Conclusion Using Capacity Reservation along with Reserved Instances or Savings plan together can provide high SLAs for capacity availability at discounted rates. One thing to note before we conclude this article is that you can use Azure Site Recovery to perform global disaster recovery to replicate VM between any two regions if Azure Site Recovery supports them. These 2 regions can be non-paired regions as well. Please note: Scope of this article is disaster recovery for Azure VMs.Everything New in Azure Governance @ Ignite 2024
You've come to the right place if you're looking for everything happening with Azure Governance at Microsoft Ignite, November 19-22, 2024. Azure Governance is an ecosystem of neatly integrated services that provide the ability to ensure speed and control across your cloud environment. From enforcing rules in your cloud environment to querying the state of your resources at-scale, Azure Governance services keep your resources secure and compliant with corporate standards. The Azure Governance team is excited to share all the following new features across our product portfolio. For each of the features, you will find an accompanying announcement with scenario details, documentation and blog posts to follow along! Azure Change Analysis Change Actor – Generally Available We are excited to announce the General Availability of Change Actor in Azure, a feature that enhances Change Analysis by identifying who made changes to your resources and how. With this update, you can audit changes across all tenants and subscriptions, seeing who initiated changes and with which identity. Changes are available in under five minutes and are queryable for fourteen days, allowing for timely auditing and troubleshooting. Additionally, you can craft charts and pin results to Azure dashboards based on specific change queries through Azure Resource Graph, providing a comprehensive view of changes across your environment. Change Actor experience in Azure Portal Overview of change analysis: https://learn.microsoft.com/azure/governance/resource-graph/changes/get-resource-changes?tabs=azure-cli Change analysis portal experience: https://learn.microsoft.com/azure/governance/resource-graph/changes/view-resource-changes Change actor blog announcement: https://techcommunity.microsoft.com/blog/azuregovernanceandmanagementblog/announcing-the-general-availability-of-change-actor/4171801 Azure Policy Policy Versioning support Built-in Definitions – Public Preview With Versioning, you can now gradually ingest built-in definition changes with zero-gap in enforcement! All Azure Policy built-in definitions will now follow a standardized version pattern: at assignment time, simply specify the version number of the built-in definition to enforce on your environment. Have a previous definition version already assigned? Leverage assignment-level selectors and overrides property to gradually update the assignment to the latest version of the built-in definition. Additionally, versioning awareness is displayed in compliance logs on a per-resource basis, enhancing your ability to govern and evolve your cloud governance policies with greater agility. Tech Community Blog: https://techcommunity.microsoft.com/blog/azuregovernanceandmanagementblog/public-preview-announcement-azure-policy-built-in-versioning/4186105 MS Learn Documentation: https://learn.microsoft.com/azure/governance/policy/concepts/definition-structure-basics#version-preview Query Component-level policy compliance in Azure Resource Graph Effortlessly query policy compliance down to the component-level across your AKS, Key Vault, and Managed HSM resources in Azure Resource Graph! With component-level granularity of AKS Policy compliance, you verify if your pods are using approved base images, audit the labelling of your namespaces or ensure your Managed HSM instances to configure the required security settings—all through ARG. Through a unified experience with Azure Policy and Azure Resource Graph, you can gain deeper insights into the compliance state of each AKS component with precision, ensuring your resources are always in line with your organization’s standards. AKS Policy component-level compliance in ARG CEL-based support for AKS Policy (preview) Introducing CEL and VAP support in AKS Policy! Common Expression Language (CEL) is a Kubernetes-native expression language that can be used to declare validation rules of a policy. Validating Admission Policy (VAP) feature provides in-tree policy evaluation, reduces admission request latency, and improves reliability and availability. The supported validation actions include Deny, Warn, and Audit. Custom policy authoring for CEL/VAP is allowed, and existing users won't need to convert their Rego to CEL as they will both be supported and be used to enforce policies. You'll be able to view violation messages at request time and audit results in the portal just like with Rego. MS Learn documentation: https://learn.microsoft.com/azure/governance/policy/concepts/policy-for-kubernetes#171 Support for Expansion in AKS Policy Introducing expansion, a shift left feature that lets you know up front whether your workload resources (Deployments, ReplicaSets, Jobs, etc.) will produce admissible pods. Expansion shouldn't change the behavior of your policies; rather, it just shifts Gatekeeper's evaluation of pod-scoped policies to occur at workload admission time rather than pod admission time. To enable expansion for a given policy definition, set.policyRule.then.details.source to All, and if needed, use a mutation with source Generated to mutate the what-if pods for evaluation purposes. MS Learn documentation: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/policy-for-kubernetes#170 Expanded list of Policy for AKS Built-In Definitions – Generally Available Azure Policy has expanded the list of mutation built-in definitions for Azure Kubernetes Service (AKS). These new definitions allow you to automatically remediate the configuration of your AKS pods and containers at scale across your cluster. With this update, you can manage and enforce configuration changes more efficiently, ensuring consistency and compliance within your AKS environment. With Mutation policies, you can: Enforcing Resource Limits: Automatically set resource limits on pods and containers to prevent any single workload from consuming too many resources. Injecting Sidecars: Mutate pod specifications to include sidecar containers for logging, monitoring, or security purposes, without requiring changes to the original pod definitions. Setting Environment Variables: Specify the environment variables set in containers, which can be used for configuration or to pass secrets securely. MS Learn documentation: https://learn.microsoft.com/azure/aks/policy-reference Azure Machine Configuration Support for User Assigned Identity Based Access for Configuration Packages – Generally Available User Assigned Identity support for configuration package access in Azure Machine Configuration is now Generally Available, reinforcing our commitment to security and simplicity in at-scale server management for all Azure customers. This feature enhances your server configuration management lifecycle by providing a secure and straightforward alternative to the use of Shared Access Signature (SAS) Tokens for anonymous access. With User Assigned Identities, you can now privately access configuration packages stored in Azure Storage Blobs, ensuring that your server management operations are both secure and efficient. Tech Community Blog: Securely store your Machine Configuration packages in Azure Storage using User Assigned Identities MS Learn Documentation: https://learn.microsoft.com/azure/governance/machine-configuration/how-to/create-policy-definition SSH Posture control through Machine Configuration – Generally Available Additional built-in capabilities to enhance your Linux management scenarios are now generally available through Azure policy and Machine Configuration! Through new built-in policies, you can manage your SSH configuration settings declaratively at-scale. SSH Posture Control also provides detailed Reasons describing how compliance or non-compliance was determined. These Reasons help you to document compliance for auditors with confidence and evidence. They also enable you to take action when non-compliance is observed. MS Learn documentation: https://learn.microsoft.com/azure/osconfig/overview-ssh-posture-control-mc Azure Resource Graph ARG PowerBI – Generally Available We are pleased to announce General Availability of the Azure Resource Graph Power BI connector! Now, you can run queries against your Azure resources and visualize the results directly in Power BI. With seamless integration, you can connect Azure Resource Graph with Power BI Desktop or Power BI service to analyze your Azure resources, and the connector has an optional setting to return all records if your query results exceed 1,000 records. This feature provides deeper insights and more control over your Azure resources, enhancing your ability to manage and govern your cloud infrastructure. Learn documentation: https://learn.microsoft.com/azure/governance/resource-graph/power-bi-connector-quickstart?tabs=power-bi-desktop Azure Resource Graph Copilot – Public Preview With the release of the Azure Resource Graph (ARG) skill within Copilot, customers can access the ARG query skill through Azure Portal or Github Copilot. Questions about resource governance like “how many Linux VMs do I own” will be sent to the ARG Skill. With this release, customers can easily turn natural language questions into ARG queries. ARG Copilot helps users create queries to quickly surface insights about resources and simplify operational investigations. ARG Copilot in Azure Portal ARG Copilot in Github Copilot MS Learn documentation: https://learn.microsoft.com/azure/copilot/get-information-resource-graph ARG GET/LIST API - Private preview Now available for private preview is the Azure Resource Graph GET/LIST API, a highly scalable, fast, and performant alternative to existing control plane GET and List API calls within the Azure ecosystem. This API allows you to mitigate issues related to throttling, such as performance degradation and failed requests offering a 10X higher Read throttling quota to callers, ensuring faster and more efficient read operations for your critical cloud native workload. Contact argpms@microsoft.com to join the private preview program! Azure Resource Manager All New Azure Resource Manager Throttling Experience We are thrilled to announce the modernization of Azure Resource Manager throttling. This upgrade introduces a revamped throttling experience for Azure subscriptions, bringing increased limits and a token bucket algorithm for managing API requests! Throttling limits have increased by roughly 30 times for writes, 2.4 times for deletes, and 7.5 times for reads. Tech Community Blog: https://azure.microsoft.com/updates?id=azure-resource-manager-throttling Learn documentation: https://learn.microsoft.com/azure/azure-resource-manager/management/request-limits-and-throttling Azure Resource Notification ContainerserviceEventresources System Topic for AKS - Public Preview We are excited to announce public preview of the Azure Resource Notification ContainerServiceEventResources system topic that empowers customers with proactive notifications for critical AKS cluster maintenance events, covering statuses such as scheduled, started, and completed. By enhancing planning capabilities, this feature reduces operational disruptions and minimizes costs, allowing you to manage maintenance with greater confidence and efficiency. MS Learn documentation: https://learn.microsoft.com/azure/event-grid/event-schema-containerservice-resources Stay Updated Keep in touch with Azure Governance products, announcements, and key scenarios. Bookmark the Azure Governance Tech Community Blog, then follow us @AzureGovernance on X (previously known as Twitter) Share Product feedback/ideas with us here- Azure Governance · Community For questions, you can reach us at: Azure Policy: policypm@microsoft.com Azure Resource Graph: argpms@microsoft.com
