Windows-itpro-docs: MiraCast and Windows 10 Autopilot Intune MDM managed devices

[RaimondMoerman]

Hello,

We are currently in the midst of a migration project to migrate on-premise domain joined Windows 7 devices to Azure AD joined Windows 10 devices via Intune MDM Autopilot. These devices run Windows 10 build 1809 (or higher) and are hardened with the MS Security Baseline v1903. When we try to connect to a Surface Hub device from a Lenovo ThinkPad T470 test device using the MiraCast WiFi Direct connection we are able to scan and find the Surface Hub, pair with the device using the provided PIN and start the Projection Session. However we receive an error that "Something went wrong with the projection".

During our research we found that the Surface Hub creates a temporary virtual network adapter with a name like "DIRECT-%SurfaceHubName%xxxx".This virtual network adapter is wrongly considered to be a Public network, resulting in the MiraCast session to end prematurely.

Then we manually changed the network category for the temporary virtual network adapter on the Windows 10 Enterprise Autopilot enrolled Intune MDM managed device using the PowerShell cmdline: "Set-NetConnectionProfile -Name DIRECT-%SurfaceHubName%xxxx -NetworkCategory Private"
After changing the network category we were able to project to the Surface Hub.
The culprit here is that the change in network category can only be executed while the temporary virtual network adapter is visible. As soon as the error that "Something went wrong with the projection" is shown, the temporary virtual network adapter is deleted/hidden and we can't change the network category anymore.

This whole situation is unwanted and, quite frankly, unlogical behaviour from Windows 10 as the connection between the Windows 10 device and the Surface Hub is a WiFi direct connection and as such should automatically be considered a Private network.

We compared this behavior to what we see on a brand new out of the box Lenovo ThinkPad T470 device that runs the OEM Windows 10 Pro version and has received no GPO settings, Security Baseline or Device Configuration Profiles. We found that on that device the temporary virtual network adapter for the WiFi direct connection is considered to be Private by default, so projection works.

Then we took an on-premise domain joined Windows 10 Enterprise device that receives GPO settings and firewall policies and tested on that. Same result, Surface Hub is considered to be Private network and projection works.

So there is a significant difference in the behavior on the Windows 10 Enterprise Autopilot enrolled Intune MDM managed device and we can't pinpoint what is causing this nor how to automatically fix this.
Can anyone help us solve this issue? Thank you in advance!

Kind regards,

Raimond Moerman

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 3aeb8eec-e501-825b-0533-0b64cbf7f46b
• Version Independent ID: 86686680-e646-45de-f096-49ddb28542d6
• Content: Troubleshoot Miracast on Surface Hub
• Content Source: devices/surface-hub/miracast-troubleshooting.md
• Product: surface-hub
• Technology: windows
• GitHub Login: @Dansimp
• Microsoft Alias: dansimp

[jonarmstrong]

This article got me pointed in the right direction. A little background, I originally deployed the October Preview template and recently updated to the May 2019 template. One of the documented differences is that the new template enables a new Windows Defender FIrewall - Connection security rules from group policy not merged policy. This triggers the issue noted in the above article. In short, the policy prevents the local Windows Firewall rules (which would work otherwise to let the wudfhost.exe through the firewall) from being applied to the automatically created virtual network adapters which are flagged as a _public network_. I was able to work around the policy and successfully initiate a miracast connection by creating a local GPO inbound firewall rule in Computer Configuration > Windows Settings > Security Settings > Windows Defender Firewall with Advance Security with the suggested rule in the above article. I haven't gotten around to it, but next I'm going to try using a WDF Intune Rule to push the same rule and see if that yields the same bypass of the rule.

I did try disabling the rule in the template, but because it had been set to "yes" (enforce), when I changed it back to "not configured" it just left it as effectively enforced on my box, because it didn't unconfigure the previous configuration. Hence; the need to manually push a GPO inbound firewall rule.

Also the Windows Defender ATP security baseline configures the same policy.

[RaimondMoerman]

@jonarmstrong 🥇 You are my hero! Thank you for pointing me in to the right direction.
I created a WDF Intune rule and applied it to my test devices. Unfortunately this was not sufficient to fix the issue. We had to to change our baseline profile (based on the May 2019 template) to re-allow the merge of GPO and local firewall rules for the public network profile. This allows the built-in local MiraCast firewall rule to be applied. Now everything is working as expected.