Module: Monitor and Maintain AVD

Section: Monitoring AVD Services

Lesson: Log Collection and Analysis

Introduction: Why Log Collection Matters in AVD

Azure Virtual Desktop (AVD) is a complex, multi-layered service that relies on the interaction between the Azure control plane, the virtual machine (VM) host pool, user profiles, and network connectivity. When a user reports that their desktop is "slow" or "not connecting," the root cause could be anywhere along this chain. Log collection and analysis act as the diagnostic backbone of your AVD environment. Without a structured approach to capturing and interpreting these logs, you are effectively flying blind, relying on guesswork rather than data-driven troubleshooting.

Effective log management is not just about fixing problems when they occur; it is about visibility. By centralizing logs from your session hosts, FSLogix profile containers, and AVD management services into a single workspace, you gain the ability to correlate events. For instance, you can see if a specific network latency spike coincides with a user’s attempt to mount a profile container. In the modern cloud-native landscape, proactive monitoring means identifying trends—such as a gradual increase in login times—before they become helpdesk tickets. This lesson will guide you through the technical implementation of log collection and the analytical strategies required to maintain a healthy AVD deployment.

The AVD Diagnostic Architecture

To understand how to collect logs, you must first understand where the data originates. AVD generates logs across several distinct layers. If you do not capture data from all these layers, you will inevitably encounter "blind spots" during your root cause analysis.

1. The Azure Control Plane Logs

These logs are generated by the AVD service itself. They track management operations, such as creating host pools, assigning users to application groups, or updating VM images. These are captured via Azure Activity Logs and can be sent to a Log Analytics Workspace.

2. The Session Host Logs

This is the most critical layer. It includes the Windows Event Logs from the virtual machines themselves. You need to capture specific channels, such as the Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational log for connection events and the Microsoft-Windows-FSLogix-Apps/Operational log for profile-related issues.

3. The FSLogix Profile Logs

FSLogix is the standard for managing user profiles in AVD. Because profile issues are the single most common cause of "slow login" complaints, capturing these logs is non-negotiable. These reside locally on the VM but must be forwarded to a centralized location to be useful for global analysis.

Callout: Diagnostic Data vs. Operational Logs It is important to distinguish between "Diagnostic Data" and "Operational Logs." Diagnostic data in AVD refers to the specific telemetry sent by the AVD agent to Microsoft to track connection success and failure rates. Operational logs, by contrast, are the raw event logs generated by the OS and applications. You need both to perform a full health assessment of your environment.

Setting Up Log Collection: Step-by-Step

To centralize your logs, you will use the Azure Monitor Agent (AMA) and a Log Analytics Workspace. This setup allows you to query data across your entire fleet of session hosts using Kusto Query Language (KQL).

Step 1: Create and Configure the Log Analytics Workspace

Before you can collect logs, you need a destination. Ensure your workspace is in the same region as your AVD resources to minimize data egress costs and latency.

1. Navigate to the Azure Portal and search for "Log Analytics workspaces."
2. Click "Create" and provide a name, subscription, and resource group.
3. Select a tier (usually Pay-As-You-Go) and complete the deployment.

Step 2: Deploying the Azure Monitor Agent (AMA)

The legacy Log Analytics Agent (MMA) is being phased out. You must use the Azure Monitor Agent. To deploy this to your AVD session hosts:

1. In the Azure Portal, go to "Monitor" and select "Data Collection Rules" (DCRs).
2. Create a new DCR.
3. Select your session host VMs as the target resources.
4. In the "Collect" tab, select "Windows Event Logs."
5. Add the following XPath queries to ensure you capture the necessary AVD and FSLogix events:
   • Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational!*
   • Microsoft-Windows-TerminalServices-LocalSessionManager/Operational!*
   • Microsoft-Windows-FSLogix-Apps/Operational!*

Note: Always verify your XPath syntax before saving the DCR. A typo in the XPath query will result in zero logs being collected, and you won't receive an error message indicating that the filter is invalid—it will simply remain silent.

Step 3: Enabling AVD-Specific Diagnostic Settings

To capture control plane activity, you must enable diagnostic settings on the AVD host pool resource itself:

1. Navigate to your AVD Host Pool in the portal.
2. Select "Diagnostic settings" under the Monitoring section.
3. Click "Add diagnostic setting."
4. Select the categories: Checkpoint, Error, Management, and Connection.
5. Send these to the Log Analytics Workspace you created in Step 1.

Analyzing AVD Logs with KQL

Once your data is flowing into Log Analytics, you need to write queries to make sense of it. KQL is the language used for these logs. It is similar to SQL but is optimized for time-series data.

Example 1: Identifying Failed Connections

This query searches the WVDConnections table (which is populated by the AVD control plane) to identify users who failed to connect to their desktops.

WVDConnections
| where State == "Failed"
| project TimeGenerated, UserName, CorrelationId, ErrorCode, ErrorMessage
| sort by TimeGenerated desc

Explanation:

• WVDConnections: This is the primary table for AVD connection telemetry.
• where State == "Failed": Filters the dataset to show only unsuccessful attempts.
• project: Selects only the relevant columns to keep the output clean.
• sort by: Orders the results so the most recent failures appear at the top.

Example 2: Detecting FSLogix Profile Load Issues

FSLogix issues often manifest as "Profile not available" or "Slow login." We can query the Event table to find errors originating from the FSLogix source.

Event
| where Source == "FSLogix"
| where LevelName == "Error"
| project TimeGenerated, Computer, RenderedDescription
| summarize count() by Computer, RenderedDescription

Explanation:

• Source == "FSLogix": Filters logs specifically generated by the FSLogix service.
• summarize count(): This is a powerful command that groups identical errors by computer, allowing you to see if a specific host is having more issues than others. This is a common indicator of a localized storage or network problem.

Tip: If you see a high frequency of "Profile load failed" errors on a specific host, check the network connectivity between that host and your Azure Files storage account. It is rarely an FSLogix software bug and almost always a DNS or SMB port-blocking issue.

Best Practices for Log Maintenance

Log collection is not a "set it and forget it" task. As your environment grows, the volume of logs can become overwhelming and expensive.

1. Implement Retention Policies

Azure Log Analytics charges based on data ingestion and retention. If you retain logs for 365 days, you will pay for that storage. For most AVD environments, 30 to 90 days of retention is sufficient for incident investigation. Review your retention settings under "Usage and estimated costs" in the workspace.

2. Filter Noise at the Source

Do not collect "Information" level logs for every service. They will flood your workspace with useless data, making it harder to find the "Error" and "Warning" logs that actually matter. Use your Data Collection Rules to target specific event IDs or warning levels.

3. Use Workbooks for Visualization

Instead of writing raw KQL queries every time you need to check the health of your AVD environment, use Azure Monitor Workbooks. You can create a dashboard that displays:

• Average connection time.
• Number of active sessions.
• Top 10 users with the most connection failures.
• Host pool CPU and memory utilization trends.

4. Correlation is Key

If a user complains about a slow experience, look at the WVDConnections table for their CorrelationId. Then, take that ID and search the Event logs for that specific time window on the host the user was assigned to. This "detective work" is how you bridge the gap between user experience and technical reality.

Common Pitfalls and How to Avoid Them

Even experienced administrators often make mistakes that render their logs useless. Here are the most frequent traps.

Pitfall 1: Time Synchronization Issues

If the time on your session hosts is out of sync with the Azure control plane, your logs will be impossible to correlate. A 5-minute drift can make it look like a connection failure happened before the user even initiated the request.

• Solution: Ensure all AVD session hosts are joined to a domain or use an NTP server to keep their clocks synchronized.

Pitfall 2: Ignoring DNS Resolution Failures

Many connection failures in AVD are caused by the session host failing to resolve the address of the Azure Files storage account where the profile container resides. If you are only looking at AVD connection logs, you will see "Failed to load profile," but you won't see the underlying DNS error.

• Solution: Include system-level DNS client logs in your collection rules if you suspect network or resolution issues.

Pitfall 3: Failing to Monitor Disk Space

When session hosts run out of disk space, the local event logs often stop writing. You lose the ability to see why the host crashed because the logs were never saved.

• Solution: Set up Azure Monitor Alerts to notify you when disk space on your session host pool reaches 15% or less.

Comparison Table: Monitoring Tools

Callout: AVD Insights vs. Custom Log Analytics AVD Insights is a pre-built solution that provides excellent, out-of-the-box visibility into connection success and latency. However, it does not replace the need for custom Log Analytics queries. Use AVD Insights for your daily "health check" and use custom KQL queries when you need to perform deep-dive forensics on a specific user or technical incident.

Advanced Troubleshooting Scenarios

Scenario 1: The "Ghost" Session

A user claims they are logged in, but the host pool says the session is disconnected. You need to identify the process that is holding the session open.

1. Use KQL to query the WVDCheckpoints table to see the last recorded state of the session.
2. If the logs show the user disconnected but the session remains, check the System event log on the host for "TermService" errors.
3. Often, a hung application (like an Outlook process with an open dialog box) prevents the session from terminating correctly.

Scenario 2: High Latency Reports

Users in a specific branch office complain about "lag."

1. Query the WVDConnections table and filter for the ClientIP column.
2. If all users from a specific IP range report high RTT (Round Trip Time), you have identified a network path issue between that office and the Azure region.
3. This is a common indicator that the users are not using the closest Azure entry point or are being routed through a restrictive corporate firewall.

Step-by-Step: Creating a Custom Alert

You should not have to manually check logs to find errors. You should be notified when they happen.

1. In your Log Analytics Workspace, navigate to "Logs."
2. Run your query for errors (e.g., the FSLogix error query provided earlier).
3. Once the results are displayed, click the "New alert rule" button in the toolbar.
4. Set the "Condition" to trigger when the number of results is greater than 0.
5. Define the "Action Group" to send an email or a push notification to your mobile device.
6. Give the alert a clear name, such as "Critical FSLogix Error on Session Host."

Warning: Be careful with alert thresholds. If you set an alert for "any error," you will be bombarded with emails for minor, non-critical events. Always filter your alerts to only notify you for high-severity issues or patterns that repeat more than X times in 5 minutes.

Summary and Key Takeaways

Mastering log collection and analysis is the difference between being a reactive administrator and a proactive one. By centralizing your telemetry and learning to query it effectively, you reduce the time required to resolve user issues from hours to minutes.

Key Takeaways for Your AVD Environment:

• Centralize Everything: Never rely on local VM logs. Use the Azure Monitor Agent to send all relevant logs to a single Log Analytics Workspace.
• Use the Right Logs: Prioritize WVDConnections for control plane issues and FSLogix-Apps for user profile issues.
• Master KQL: Kusto Query Language is your most powerful tool. Learn how to summarize, project, and join tables to correlate events across your infrastructure.
• Automate Alerts: Do not wait for a user to call. Set up alerts for critical errors so you know about problems before the user experience is impacted.
• Keep It Clean: Manage your log retention policies to avoid unnecessary costs and ensure that your queries remain performant.
• Think Like a Detective: Always use a CorrelationId to track a single user's session from the moment they click the icon to the moment they disconnect.
• Visuals Matter: Use Workbooks to create a "single pane of glass" view of your AVD environment, allowing you to spot trends before they become outages.

By following these practices, you ensure that your AVD environment remains stable, secure, and easy to manage. Log collection is not just a technical requirement—it is the foundation of a reliable cloud workspace.