Black Screens At 8 A.M.

Why it is empty. Insights is a workbook over Log Analytics tables. Those tables are populated only by diagnostic settings on the AVD objects and by the Azure Monitor Agent plus a data collection rule on the hosts. With no diagnostic settings configured, there is no connection, checkpoint, error, or registration data to query, so the workbook renders blank. That is expected behaviour, not a fault.

Enable:

• Host pool, workspace, and application group diagnostic settings sending Connection, Checkpoint, Error, HostRegistration, Management, and AgentHealthStatus to the workspace. Checkpoints are what make a five-minute wait explicable; without them you only know a session was slow.
• Azure Monitor Agent on the session hosts with a data collection rule for a small, named set of performance counters at 60-second intervals: Processor(_Total) % Processor Time, System Processor Queue Length, Available MBytes, and LogicalDisk average disk seconds per transfer.

Staying under 5 GB/day:

• Performance counters dominate volume. Roughly 10 counters x 38 hosts x 1,440 minutes is over half a million records a day; four counters at 60 seconds is comfortably under a gigabyte. Do not enable every counter.
• Avoid shipping the Windows event logs wholesale. Filter with an XPath query in the DCR, for example System log Error and Critical only, plus specific FSLogix operational channels at Warning and above.
• Use table plans and retention deliberately: interactive retention short, total retention with archive long. Set the daily cap and alert at 80 percent of it so the cap never silently drops the data you need on the morning it matters.
• AgentHealthStatus is cheap and non-negotiable; it is the only signal that catches a host that is running but not serving sessions.

Convert the wait into phases, then attribute each phase. Take the correlation ID for the session and read the timeline:

1. Entra sign-in to broker. If this is slow, it is identity, Conditional Access, or MFA prompting, not AVD.
2. Broker to host assignment. If a connection record is created but no session host name is attached for minutes, the broker could not place the user. Causes: max session limit reached, hosts in drain mode, hosts unregistered or agent unhealthy, or genuinely no capacity. This is an infrastructure fix, and restarting session hosts is exactly the wrong response because it destroys capacity.
3. Host assigned to RDP established. Delay here is transport or name resolution, not the profile. Compare with the same user from a different network.
4. RDP established to shell ready. Now it is inside the host: FSLogix attach, sign-in processing, policy application, or resource starvation during a logon storm.
5. Shell ready but black screen. Explorer or a startup app failing, or the graphics stack struggling; check the application and system logs on that host at that timestamp.

Apply it to this pattern. The failures cluster in a 45-minute window while CPU is under 20 percent. That points away from raw CPU and toward either host placement (capacity or agent health at ramp-up) or storage latency during simultaneous profile mounts. Restarting a host 'fixes' it because it re-registers the agent and forces a fresh attach, which is why it has become folklore.

Also quantify the arrival rate: 700 users over 45 minutes against 38 hosts with a session cap is a burst that the share sees as concurrent profile mounts. Check whether affected users are spread across both pools; if they concentrate on one, the problem is that pool, not the platform.

1. Storage account platform metrics (free, no ingestion cost). SuccessE2ELatency against SuccessServerLatency. If end-to-end is much higher than server-side, the delay is client-side or network. If both climb together while transaction count spikes and throttling or server-busy responses appear, you are at the share's IOPS or throughput ceiling. This is the fastest way to falsify the storage hypothesis during the 08:00 window.

2. Host performance counters via the data collection rule. Processor queue length is the discriminator: a long processor queue with low average disk seconds per transfer means CPU contention; high disk latency with an idle processor means I/O. Note that low average CPU utilisation can still hide a queue, which is why the queue length counter matters more than the utilisation percentage that the service desk is quoting.

3. FSLogix operational logs, sampled. Attach duration per stage on a handful of hosts, filtered at Warning and above to stay inside the 5 GB cap. If the attach phase dominates the five minutes and correlates with the storage latency chart, the answer is the share. If attach is fast and the shell start is slow, it is the host.

Tie it together with checkpoints. The checkpoint timeline tells you which phase is slow; these three tell you why that phase is slow. Neither alone is sufficient, and a dashboard that only shows CPU utilisation below 20 percent is actively misleading here. Add an Azure Monitor alert on Azure Files end-to-end latency and on host registration failures so the next occurrence pages someone instead of waiting for a ticket.