Azure Configuration: Essential Steps to Document Your Current Setup (Step 2)
Documenting your current Azure environment configuration is a crucial step in maintaining control, ensuring compliance, and planning for future changes. As cloud services evolve, so do the underlying components responsible for monitoring, management, and security. A significant area of change in many Azure configurations involves the transition from the legacy Microsoft Monitoring Agent (MMA) to the newer Azure Monitor Agent (AMA). Understanding and meticulously documenting the agent deployments and configurations across your virtual machines (VMs) is fundamental to Step 2 of outlining your current setup. This phase requires a deep dive into how various Azure services interact with monitoring agents and the implications of migrating to AMA.
Understanding Agent Transition in Azure Environments¶
Historically, many Azure services relied on the Microsoft Monitoring Agent (MMA), also known as the Log Analytics agent, for collecting data from virtual machines and other resources. This agent was versatile, serving capabilities like monitoring, security, automation, and update management. However, with the evolution of Azure Monitor, a more unified and flexible agent, the Azure Monitor Agent (AMA), has been introduced. AMA offers several advantages, including enhanced security through managed identities, simplified management via Data Collection Rules (DCRs), cost efficiency, and improved performance.
Microsoft Monitoring Agent (MMA) Legacy¶
The Microsoft Monitoring Agent has been the workhorse for collecting logs and performance counters from Windows and Linux machines, forwarding them to Azure Monitor Logs (formerly Log Analytics workspace) and Azure Security Center. It supported various solutions, including Change Tracking and Inventory, Update Management, and part of the Hybrid Runbook Worker functionality. While robust, its configuration often involved per-workspace settings, and it could be resource-intensive. Many existing deployments still rely on MMA, making its current state a critical part of your documentation. Note which VMs have MMA installed and which services are configured to use it.
Introducing Azure Monitor Agent (AMA)¶
Azure Monitor Agent represents the future of monitoring data collection in Azure. It uses Data Collection Rules (DCRs) to explicitly define what data to collect from which machines and where to send it (e.g., Log Analytics workspace, Azure Event Hubs). This rule-based approach provides granular control and improves efficiency. AMA is designed to be the single agent for Azure Monitor, simplifying agent management and reducing the footprint on monitored systems over time. Documenting which VMs have AMA installed and the associated Data Collection Rules is paramount.
Documenting Agent Deployments Across Azure Services¶
The transition from MMA to AMA is not always a simple in-place upgrade. For many Azure services, it involves adopting updated versions of the solutions that are built to leverage AMA. Documenting your current state means identifying which services are still using MMA and which are transitioning to or already using AMA, along with the steps taken or needed for migration or coexistence.
System Center Operations Manager (SCOM) Integration¶
If your organization uses System Center Operations Manager (SCOM) to monitor your Windows or Linux virtual machines, the Microsoft Monitoring Agent often plays a dual role. MMA is used as the Operations Manager agent for communication with the SCOM management server. This functionality typically continues even when you begin adopting Azure services that use AMA. Therefore, in environments integrating SCOM with Azure monitoring, you will likely encounter scenarios where both agents are present on the same VM.
Coexistence Requirements and Scenarios¶
When using SCOM and needing to send data to Azure Monitor (e.g., for Log Analytics queries, Workbooks, or Azure Sentinel), you must install Azure Monitor Agent separately alongside the MMA used for SCOM. The key documentation point here is to note the presence of both agents. Ensure your documentation specifies that MMA is serving SCOM needs, while AMA is serving Azure Monitor needs. A critical technical detail to document is that these agents must be configured to use different ports for communication to avoid conflicts. Standard SCOM agent communication uses specific ports, and AMA also requires ports for outbound communication. Verify and document the port configurations in your firewall rules and agent settings. This coexistence is a valid and supported configuration during transitional phases or for organizations committed to both SCOM and Azure-native monitoring.
Azure Automation Change Tracking and Inventory Migration¶
The legacy versions of Azure Automation Change Tracking and Inventory relied on the Microsoft Monitoring Agent to collect data about software installed and configuration changes on your VMs. To utilize the current, improved versions of these solutions, you must migrate to the AMA-based implementation. This shift involves disabling the legacy MMA-based feature and enabling the new AMA-based version.
Step-by-Step Migration Process¶
The process requires careful documentation of each step. First, document the removal of the legacy solution’s configuration from your Log Analytics workspace and potentially the uninstall of MMA from VMs if it serves no other purpose (like SCOM or Hybrid Runbook Worker). This ensures the old data collection method is stopped. Next, document the process of installing Azure Monitor Agent on your VMs. This can be done manually, via Azure Policy for large-scale deployments, or through Azure Arc for servers outside of Azure. Finally, document the addition of the current version of the Change Tracking and Inventory solution to your workspace, which now uses AMA via Data Collection Rules. Documenting the specific DCRs created for these solutions is essential for understanding what data is being collected.
Considerations for Data and Reporting¶
During this migration, document how you plan to handle historical data. The new solution starts collecting data fresh. Document the transition period and how reporting or auditing will be managed using data from both the old and new systems if necessary. Ensure you document the verification steps to confirm that the new AMA-based solution is correctly collecting inventory and change data after the migration.
Azure Automation Update Management Migration¶
Similar to Change Tracking and Inventory, the original Azure Automation Update Management solution also depended on the Microsoft Monitoring Agent to assess and manage updates on your VMs. The current iteration of Update Management requires migration to the AMA-based platform. This migration streamlines update assessment and deployment leveraging the unified Azure Monitor Agent infrastructure.
Step-by-Step Migration Process¶
The migration path mirrors that of Change Tracking and Inventory. Document the process of removing the legacy Update Management configuration from your Automation account and associated Log Analytics workspace. This step stops the MMA-based assessment and deployment schedules. Next, document the installation of Azure Monitor Agent on all relevant VMs that need update management. Finally, document the configuration of the current Update Management solution, which connects through AMA and utilizes Data Collection Rules for assessment data. Document the setup of update schedules and deployments within the new platform.
Ensuring Continuous Patch Management¶
A critical documentation point during Update Management migration is how continuity of patching is maintained. Document the overlap strategy, if any, and the process for verifying that VMs are correctly reporting compliance and receiving updates via the new AMA-based solution. Detail any specific configurations related to maintenance windows, reboot behavior, and pre/post-scripts within the new Update Management setup.
Azure Security Center (Defender for Cloud) Agent Transition¶
Azure Security Center, now part of Microsoft Defender for Cloud, leverages data collected from VMs to provide security posture management, threat detection, and vulnerability assessment. Traditionally, it relied heavily on the Microsoft Monitoring Agent (sometimes referred to as the “Log Analytics agent for Security Center”). The current version of Defender for Cloud is transitioning to use Azure Monitor Agent for its data collection needs from VMs.
Enabling AMA Data Collection in Security Center¶
The migration process for Security Center is slightly different as it involves configuring the data collection source within the Defender for Cloud settings itself. Document the process of enabling the Azure Monitor Agent data collection option within the relevant Defender for Cloud settings or policies. This action signals Defender for Cloud to expect security-related data via AMA. Concurrently, or immediately after, document the installation of Azure Monitor Agent on the VMs you wish to protect.
Managing the Transition Period¶
It is possible to have both MMA and AMA sending data to Defender for Cloud during a transition period. Document this overlap phase. Once you have confirmed that AMA is successfully collecting the necessary security data and Defender for Cloud is receiving it, document the process of disabling the Microsoft Monitoring Agent data collection option in Defender for Cloud. This ensures you are not collecting duplicate data and fully transition the security data stream to AMA. Documenting the relevant security policies or initiatives in Azure Policy that enforce AMA deployment and configuration for Defender for Cloud is also crucial.
Azure Automation Hybrid Runbook Worker Coexistence¶
Azure Automation Hybrid Runbook Worker allows you to run Automation runbooks directly on machines outside of Azure or within Azure virtual networks where direct access from Azure Automation isn’t feasible. This feature, unlike Change Tracking and Inventory or Update Management, continues to use the Microsoft Monitoring Agent (MMA) for its core functionality – specifically, for the Hybrid Runbook Worker role to register and communicate with Azure Automation.
Maintaining Hybrid Runbook Functionality¶
If you use Hybrid Runbook Workers, document that the Microsoft Monitoring Agent must remain installed and configured on these machines to allow them to function as workers. MMA’s role here is distinct from monitoring or data collection for Log Analytics or Security Center. Document which VMs are configured as Hybrid Runbook Workers and their dependency on MMA.
Adding Monitoring Capabilities with AMA¶
While MMA facilitates the runbook execution for HRW, if you also need to monitor these Hybrid Runbook Worker machines within Azure Monitor (e.g., collect performance counters, application logs, or forward security events), you must install Azure Monitor Agent separately. As with the SCOM scenario, document the installation of AMA alongside MMA on these HRW machines. Crucially, document that AMA is used only for sending monitoring data to Azure Monitor and does not replace MMA’s role in executing runbooks. Again, verify and document that both agents are configured to use different ports to avoid communication conflicts.
Visualizing the Agent Landscape¶
To effectively document the agent setup, a visual representation can be incredibly helpful. Consider creating a diagram or a table that outlines the different Azure services, the agent required (MMA, AMA, or both), and the specific configuration steps or dependencies. This provides a clear overview of the agent ecosystem in your environment.
A conceptual diagram could illustrate the data flow: showing VMs with either MMA, AMA, or both, and arrows pointing to the services they send data to (Log Analytics, Azure Security Center, Azure Automation, SCOM). It could highlight that MMA often sends data to a workspace directly for multiple services, while AMA uses Data Collection Rules pointing to specific destinations. Another visual could be a table detailing each service, the required agent(s), the migration path (if applicable), and key configuration notes (like port requirements or DCR names).
The Importance of Documenting the Migration Process¶
Thorough documentation of the agent migration process is critical for several reasons. It provides a clear record of changes made, which is essential for troubleshooting if issues arise post-migration. It helps new team members understand the current architecture and the rationale behind using specific agents for particular services. Documentation ensures compliance requirements are met by detailing how monitoring and security data are collected. Finally, it serves as a blueprint for migrating additional machines or rolling back changes if necessary. Documenting successes, challenges, and lessons learned during the migration enriches your operational knowledge base.
Planning and Executing the Agent Migration¶
Beyond documenting the state, detailing the plan for migration where needed is part of documenting your current trajectory.
Prerequisites and Assessment¶
Document the prerequisites for installing AMA, such as supported operating systems, network requirements, and necessary permissions. Detail any assessment performed to identify which VMs need migration and the dependencies of those VMs on the legacy solutions. This includes identifying custom configurations or third-party integrations that rely on MMA data.
Phased Rollout and Testing¶
Document the strategy for a phased rollout. Migrating agents across a large environment should ideally be done in waves (e.g., test group, pilot group, production groups). Document the criteria for selecting machines for each phase and the testing procedures performed to validate successful migration and data collection for each relevant service (monitoring, security, automation).
Verification and Rollback Planning¶
Crucially, document the verification steps performed after migration. How did you confirm that AMA was installed correctly? How did you verify that data was flowing correctly to Log Analytics, Defender for Cloud, etc., via the new DCRs? Documenting the rollback plan – the steps to revert to the MMA-based setup if the AMA migration fails or causes critical issues – provides a safety net and is a vital part of operational readiness.
Conclusion and Next Steps in Configuration Documentation¶
Step 2 of documenting your current Azure configuration heavily involves understanding the agent landscape on your virtual machines and how it supports various Azure services. Meticulously detailing the presence of Microsoft Monitoring Agent and Azure Monitor Agent, their roles for specific services (SCOM, Change Tracking, Inventory, Update Management, Security Center, Hybrid Runbook Worker), and any migration steps taken or planned provides a solid foundation for managing your environment. This documentation is not static; it should be a living record updated as you progress through agent migrations and configure new monitoring or security solutions.
We encourage you to share your experiences with migrating from MMA to AMA. What challenges did you face, and how did you overcome them? Let us know in the comments below!
Post a Comment