For this pattern, the most relevant supported checks are on the wireless, driver, firewall, policy, and event-log path rather than Intune vs. SCCM management itself.
- Confirm the receiver side is actually available for Miracast.
- On Surface Hub, Miracast requires Wi-Fi to be turned on, even if the device is not connected to a wireless network.
- If the receiver is a Surface Hub and it does not appear in Windows + K, check Settings > View as Admin > Network & Internet and verify Wi‑Fi is On.
- If a previous session was closed incorrectly, sign in on the Surface Hub and end the previous session, then try again.
- Restart both ends to clear stale discovery state.
- Restart the external device.
- If the issue has worked before, restart both the external device and the receiver to reset the connection.
- Reinstall the Wi‑Fi adapter on an affected client.
- Open Device Manager.
- Expand Network adapters.
- Right-click the Wi‑Fi adapter and select Uninstall.
- Restart the device.
- Then try reconnecting through Settings > Bluetooth & devices > Add device > Wireless display or dock.
- This is specifically documented as a recovery step for wireless display connection failures.
- Verify both Wi‑Fi and graphics drivers are current on affected devices.
- In Device Manager, check both Network adapters and the video/display adapter for updated drivers.
- The documented Miracast troubleshooting guidance calls out both Wi‑Fi and video adapter drivers, plus firmware for the wireless display or adapter.
- Test whether Windows Firewall is blocking Miracast traffic.
- The documented test is to temporarily disable the firewall and test projection.
- If projection works only with the firewall disabled, add an exception for:
-
C:\Windows\System32\WUDFHost.exe - Allow inbound and outbound TCP and UDP connections, all ports
-
- This changes security posture, so validate it through normal change control before leaving it in place.
- Check domain policy on affected corporate devices.
- On a domain-joined device, run
rsop.msc. - Review Computer Configuration > Windows Settings > Security Settings > Wireless Network (IEEE 802.11) Policies.
- Open the wireless policy and check Network Permissions.
- The documented setting to verify is Allow everyone to create all user profiles.
- This is relevant because policy can block Miracast even when drivers and hardware report support.
- On a domain-joined device, run
- Collect WLAN diagnostics from affected and unaffected devices and compare them.
Run these commands from an elevated Command Prompt:
Then compare:netsh wlan show drivers netsh wlan show interfaces netsh wlan show networks mode=bssid netsh wlan show profiles netsh wlan show wlanreport- adapter model, driver version, and driver date
- visible networks / BSSID / band / channel
- recent wireless session failures in the WLAN report
- Event Viewer > Applications and Services Logs > Microsoft > Windows > WLAN-AutoConfig > Operational
- Check Miracast-related event logs on both sides.
- Miracast events are logged to Wlanautoconfig on both the receiver and the external device.
- The event log is the documented place to identify where the connection is failing.
- If the environment uses Miracast over Infrastructure, verify the network prerequisites.
- TCP 7250 must be open.
- Source and receiver must be connected to the same enterprise network via Ethernet or secure Wi‑Fi.
- The receiver hostname must be resolvable in DNS.
- If the receiver is on open Wi‑Fi, Miracast over Infrastructure disables itself.
Given the symptom that newer devices discover only one receiver while older devices discover multiple receivers, the strongest documented areas to compare are:
- WLAN driver state and version
- firewall behavior
- wireless policy / Group Policy results
- WLAN-AutoConfig and Miracast event logs
- network prerequisites for Miracast over Infrastructure, if used in meeting rooms
The provided documentation does not identify Intune migration, build 26200.9106, or AX211 specifically as the root cause.
References: