Intermediate
Prepare and test your skills
Intermediate
Prepare and test your skills
Azure File Sync Tiering and Recall Diagnostics
Free sample question, answered and explained below. The AZ-800 Administering Windows Server Hybrid Core Infrastructure Exam practice bank has 168 more like it. Try 10 free: instant score, no account.
A company has Azure File Sync deployed with cloud tiering enabled on several Windows Servers. Users report that some files that should be tiered are still consuming local disk space, and some tiered files are failing to recall. The administrator needs to investigate these issues efficiently.
Which monitoring tools and event logs should the administrator primarily use on the Windows Server to diagnose why files are failing to tier and recall, and to check the overall health of the server endpoint?
Explanations
Use Azure Monitor for historical trends and aggregated status, and the Telemetry, TieringResults, and RecallResults event logs on the Windows Server for detailed diagnostics.
Use Azure Monitor for historical trends and aggregated status, and the Telemetry, TieringResults, and RecallResults event logs on the Windows Server for detailed diagnostics.
What this solution is
This solution combines the strengths of Azure Monitor for comprehensive, long-term monitoring and Windows Server event logs for granular, server-side diagnostics. Azure Monitor is a service that collects, analyzes, and acts on telemetry data from your Azure and on-premises environments. It provides capabilities for visualizing metrics, creating alerts, and querying logs over extended periods, offering a holistic view of the Azure File Sync service and its components. On the Windows Server, the Telemetry event log (located under Applications and Services\Microsoft\FileSync\Agent) captures general sync, registered server, and cloud tiering health events. The TieringResults and RecallResults event logs (also under Microsoft-FileSync-Agent) provide specific, per-file error details for tiering and recall operations, including HRESULT codes and remediation guidance.
How it meets the requirements
- Diagnose files failing to tier: The TieringResults event log is specifically designed to log events for each file that fails to tier, providing error codes and context necessary for troubleshooting. The Telemetry log also contains Event ID 9003 for error distribution and 9016/9029 for ghosting (tiering) results.
- Diagnose files failing to recall: Similarly, the RecallResults event log logs events for each file that fails to recall, including
DataTransferHresultfor successful or failed recalls. The Telemetry log includes Event IDs 9005, 9006, 9009, and 9059 for recall activity and error distribution. - Check overall health of the server endpoint: The Telemetry event log is crucial for this. Event ID 9301 indicates if the server can communicate with the Azure File Sync service, and Event IDs 9102, 9121, and 9302 provide detailed sync health information, including per-item error counts and sync progress. Azure Monitor complements this by providing aggregated health status and historical trends over longer periods than the 24-hour view in the Storage Sync Service portal.
- Efficient investigation: By combining Azure Monitor for high-level trends and alerts with the detailed, specific event logs on the server, an administrator can quickly pinpoint the scope of an issue and then drill down to the root cause using the granular error information.
Key advantages/capabilities
- Granular error details: Event logs provide specific HRESULT codes and contextual information for individual file failures.
- Comprehensive health monitoring: Covers sync, tiering, recall, and server connectivity status.
- Historical analysis: Azure Monitor allows for querying and visualizing data over custom time ranges, beyond the default 24 hours in the portal.
- Alerting capabilities: Azure Monitor can be configured to send alerts for specific error events or thresholds, enabling proactive issue resolution.
- Centralized logging: Azure Monitor can consolidate logs from multiple servers, simplifying management in large environments.
- Official diagnostic tools: These are the primary and recommended tools by Microsoft for in-depth Azure File Sync troubleshooting.
Why this is optimal
This approach is optimal because it leverages the strengths of both cloud-based and server-side monitoring. Azure Monitor provides the aggregated view, historical context, and alerting capabilities necessary for managing a hybrid environment at scale. Simultaneously, the dedicated event logs on the Windows Server offer the precise, per-item error details that are indispensable for diagnosing specific file-related issues with cloud tiering and recall. Without the detailed server-side logs, diagnosing individual file failures would be extremely difficult, and without Azure Monitor, tracking long-term trends and setting up proactive alerts would be cumbersome or impossible. This combination ensures both efficient high-level oversight and effective deep-dive troubleshooting.
Utilize the Security event log for tiering and recall errors, and the System event log for server endpoint health.
Utilize the Security event log for tiering and recall errors, and the System event log for server endpoint health.
What the Security and System event logs are
The Security event log in Windows records security-related events, such as successful and failed login attempts, resource access, and privilege use. It is primarily used for auditing and security monitoring within an operating system. The System event log records events logged by Windows system components, such as driver failures, hardware issues, and operating system errors. These logs are fundamental for general system health and security auditing but are not specific to application-level diagnostics.
Why it doesn't meet the requirement
While the Security and System event logs are crucial for overall server health and security, they do not contain the specific, detailed diagnostic information for Azure File Sync operations, such as cloud tiering or file recall failures. Azure File Sync logs its operational details and errors in dedicated event logs, making these general Windows logs ineffective for the specific issues described.
Key characteristics/limitations
- General purpose: These logs are designed for broad system and security monitoring, not for specific application troubleshooting.
- Lack of detail: They do not capture the granular HRESULT codes, file paths, or specific reasons for Azure File Sync tiering or recall failures.
- Irrelevant events: Searching these logs for Azure File Sync issues would yield little to no relevant information, leading to inefficient troubleshooting.
- Application-specific logging: Modern applications, including Azure File Sync, use their own dedicated event channels for detailed operational logging.
This answer would be correct if
This answer would be correct if the problem involved general server security breaches, unexpected system reboots, or hardware failures, and not specific application-level issues related to Azure File Sync cloud tiering and file recall. For instance, if the server was experiencing unauthorized access attempts or critical system service crashes, these logs would be highly relevant.
Rely solely on the Storage Sync Service portal metrics for all diagnostics, as they provide real-time updates.
Rely solely on the Storage Sync Service portal metrics for all diagnostics, as they provide real-time updates.
What Storage Sync Service portal metrics are
The Storage Sync Service portal metrics provide a high-level overview of Azure File Sync operations within the Azure portal. These metrics include aggregated data such as bytes synced, files not syncing, cloud tiering cache hit rate, and server online status. They offer a quick way to gauge the overall health and performance of your Azure File Sync deployment, often with a time range of 24 hours for charts directly in the portal.
Why it doesn't meet the requirement
While portal metrics are useful for a quick overview and identifying trends, they are not sufficient for detailed diagnostics of specific file tiering and recall failures. The portal provides aggregated data and may have a delay (e.g., 15 minutes for sync status). It does not offer the granular, per-item error details or the specific HRESULT codes found in the server's local event logs, which are essential for efficient troubleshooting of individual file issues. The question asks for primary tools to 'diagnose why files are failing to tier and recall,' which requires more detail than portal metrics typically provide.
Key characteristics/limitations
- Aggregated view: Provides summary data, not individual file-level details.
- Limited time range: Charts in the portal typically show a 24-hour range, which might not be enough for historical analysis or long-term trends without using Azure Monitor.
- Delayed updates: Some metrics might have a delay, meaning real-time troubleshooting of rapidly changing issues could be challenging.
- No specific error codes: While it shows 'files not syncing,' it doesn't provide the detailed error codes (HRESULTs) or reasons for individual file failures that are crucial for remediation.
- Complementary, not sole source: Portal metrics are best used in conjunction with more detailed server-side logs and Azure Monitor for comprehensive diagnostics.
This answer would be correct if
This answer would be correct if the administrator only needed a high-level overview of the sync service's performance and general health, or if the question specifically asked for a quick way to check aggregated status without needing to delve into specific file-level errors. For example, if the requirement was to 'quickly assess if sync is generally active and healthy,' then portal metrics would be a primary tool.
Check the Application event log for sync errors and use fltmc to verify filter driver status for tiering issues.
Check the Application event log for sync errors and use fltmc to verify filter driver status for tiering issues.
What the Application event log and fltmc are/do
The Application event log in Windows records events logged by applications or programs. While some applications log their errors here, Azure File Sync uses its own dedicated event channels for detailed operational logging. Therefore, the Application log is generally not the primary source for specific Azure File Sync diagnostics. The fltmc (Filter Load Monitor Control) command-line utility is used to manage and display information about file system filter drivers. Running fltmc can verify if the Azure File Sync filter drivers (StorageSync.sys and StorageSyncGuard.sys) are loaded and running, which is a crucial step in troubleshooting tiering and recall issues, as these drivers are essential for cloud tiering functionality.
Why it doesn't meet the requirement
While checking the filter driver status with fltmc is a valid and important step for troubleshooting cloud tiering, it is only one specific diagnostic check and does not provide a comprehensive solution for diagnosing why files are failing to tier or recall, nor does it cover the overall health of the server endpoint. The Application event log is not the correct place to find detailed Azure File Sync errors; those are logged in the dedicated Microsoft-FileSync-Agent event logs. Therefore, this option is incomplete and misdirects the administrator regarding the primary source of detailed error information.
Key characteristics/limitations
- Application event log limitation: It does not contain the specific, granular error codes and contextual information for Azure File Sync operations. Relying on it would lead to missed diagnostic data.
fltmcspecificity:fltmconly confirms if the filter drivers are loaded. It does not explain why tiering or recall failed (e.g., network issues, access denied, file in use, storage account issues), nor does it provide sync session health or server connectivity status.- Incomplete diagnostic picture: This combination provides only a partial view of the problem, missing critical details available in the dedicated Azure File Sync event logs.
- Reactive, not proactive: Neither tool provides historical trends or proactive alerting capabilities.
This answer would be correct if
This answer would be correct if the administrator had already narrowed down the problem to a suspected issue with the Azure File Sync filter drivers not loading, and needed to confirm their status. For example, if the server endpoint showed 'No Activity' and there was a suspicion of a core component failure, checking fltmc would be a relevant part of the troubleshooting process, but not the primary or comprehensive solution for diagnosing the full range of issues described.
Try 10 interactive questions like this one, free
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
- 168 practice questions across all 5 exam domains
- Every answer explained: why it is right, and why the others are not
- Scout, an AI tutor that answers your follow-up questions
- Readiness tracking by domain, so you know when to book the exam
Related questions
Keep the momentum going with these hand-picked practice scenarios
Last updated