We've got 6 Surface Pro 2 Tablets within our enterprise that we've been using for the executive team. We are implementing a new office display system and want to be able to mirror the Surface screens to TVs. We purchased a NetGear PTV3000 to utilize the built in Miracast. We originally couldn't get it to work at all. When pulling the charm bar and clicking Devices-->Project, it didn't give me an option to connect to a wireless display. Just the options for PC Screen Only, Duplicate, Extend, Second Screen Only. I had to disconnect it from the domain, so I logged in as local admin, joined a test workgroup, then rebooted. When it came back up on the WORKGROUP, I had a "Add a Wireless Display" option, and it worked! It beamed to my Miracast Receiver just fine. So, I rejoined it to the Domain, and lo and behold, the Add A Wireless Display option disappeared, and it wouldn't even find the device. We checked Group Policy and we can't find anything that would prevent it from working (our GPO runs on Server 2008 FWIW). And yes all drivers are up to date, all Windows updates have been applied, it's been rebooted plenty of times. Any ideas on why it doesn't work after being domain joined?

Thanks!

• Edited by WDT Ops Tuesday, January 21, 2014 9:35 PM

On Tue, 21 Jan 2014 21:23:55 +0000, WDT Ops wrote:   >I rejoined it to the Domain, and lo and behold, the Add A Wireless Display option disappeared, and it wouldn't even find the device. We checked Group Policy and we can't find anything that would prevent it from working      this is the second post I've seen on this issue. I've sent it in to some folks at Microsoft. No promises that there will be an answer/solution.  

Hi WDT,

I am not sure since I have no environment for testing.

But maybe this is a way to discover the differences:

Try the Regshot or Regsnap tool to capture the Registry keys before and after joining the domain on the Surface.

Let's see the compared results.

We actually were able to get it to work. We took a completely blank group policy and applied it to the Surface and it worked. That was with the firewall OFF. Then we slowly are working on turning the firewall on but with certain features. As soon as we can get the Firewall settings set to A: Something that's safe, and B: Something that allows this to work. But yea it's working great now with Firewall on and domained account. So for other folks having issues this seems to be a key point is the GPO and Firewall.

• Marked as answer by WDT Ops Wednesday, January 22, 2014 6:57 PM

I think I found the ACTUAL fix, or at least an alternative fix.

I had two Surfaces with the EXACT issue, as well as several other WIDI enabled machines that are joined to the domain.  I created an new OU just for the devices i wanted to connect to the miracast, blocked inheritance then added ALL policy objects that were applied to the WORKSTATIONS OU as well as a duplicated Default Domain Policy. One by one I removed every policy object and ran a gpupdate each time until I could connect to the wireless display.  Policy that seemed to do it:

Computer Configuration > Policies > Windows Settings >Security Settings > Wireless Network (IEEE 802.11) Policies

The policy we were using to configure our wireless for our production network was an "XP" policy.  I recreated the connection policy as a "Policy for Windows Vista and Later Releases". 

The setting to pay attention to is on the "Network Permissions" tab: "Don't allow Wi-Fi Direct groups".  selecting that option prevents the machine from connecting to Wi-Fi Direct devices such as the Miracast.  I suspect the XP policy disables that or does not have a mechanism for setting it.

Note: All my DC's are Server 2008 and 2008r2, but I set the policy on my Windows 8.1 machine in order to get access to all the current policy objects.

• Proposed as answer by CraigWorkPAc Wednesday, June 04, 2014 11:34 PM

Thank you Kevin!

This absolutely fixed the issue. We had a blank policy called XP Test in the Wireless Network Policy. Don't ask how that got there (or better yet, who put that there) but after I removed it and did a gpupdate the option was there again!

Problem solved!

Hi, My surface pro 3 is not connected to a domain but it is a part of a workgroup...can you tell me how I can fix this issue on the SP3?

Thanks

I found the issue to be a VPN client issue.  Disable the client on the adapter fixed the issue.  See here.

Looks like I'm going to end up piling on here as well.  I too have a SP3 with this issue.  It does not have and has never had any VPN installed.  Our domain is at 2003 functional level, so the particular 802.11 policy setting referenced doesn't even seem to exist in my config.  I moved the tablet to its own OU with inheritance blocked and a copy of the domain policy applied.  Blocking the "user" portion of the GPO has no effect, but if I disable the "computer" portion of the policy and do a gpupdate, the wireless display will start to work again.  If I enable the "computer" portion and do a gpupdate, connection attempts will display "connecting" on the table AND on the TV (so it is talking to the wireless display adapter), but the connect will fail.  Obviously the problem is a setting in the "computer" portion of the GPO.  Even though I don't have the 802.11 settings referenced in the post, I tried completely deleting the default 802.11 policy in the GPO and that didn't resolve the issue.

Anyone have any other suggestions?  Is there any way to turn on debugging or anything useful?  I find it interesting, and frankly not at all surprising, that this app doesn't seem to write anything to the event logs...

After playing around with this for most of a day, I found the answer in our particular environment...

We had Firewall policies that turned the firewall on for Public and Private profiles.  In the Public profile it was set to block all incoming connections - relaxing this to "block (default)" resolved the issue.  The software apparently creates a Wi-Fi connection to the adapter, and that connection becomes Public.  The computer sends a connect request to the adapter and you can see on the screen "connecting to computername", but apparently the adapter starts an entirely new connection back to the computer instead of just replying to the initial request.

Setting the Group Policy for the Public profile to not defined will not resolve the issue - apparently even with the entire profile section of the GPO set to undefined, if an individual setting below that is specified, it will get applied.  That little bit of business is why it took me so long to find our solution!

I think KevinJjohnson should get the answer for this one. His solution was my issue exactly. Miracast was simply not available as soon as I connected to my domain and did a gpupdate. Checked my group policy and I had not created a new wireless configuration policy for new OS's. Once done it allowed for miracast displays to connect.

Thanks for finding and posting this. Below I'm including a few screenshots of the different policies (XP and the 'migrated/upgraded' Vista & Beyond policy). We got the upgraded policy by right-clicking the XP policy in the GPO editor and choosing the option to upgrade the policy.

Also, here is some more info on the relationship between Wi-Fi Direct and Miracast:

How is Miracast related to Wi-Fi Direct?

Wi-Fi Direct allows devices to connect directly to each other, without the need for a Wi-Fi AP, and requiring just the push of a button, the entry of a PIN, or tapping two NFC-capable devices together. Wi-Fi Direct allows source and display devices to discover one another and provides the underlying device-to-device connectivity for Miracast. Miracast builds upon Wi-Fi Direct with mechanisms to negotiate video capabilities, setup content protection (if needed), stream content, and maintain the video session. - See more at: http://www.wi-fi.org/discover-wi-fi/wi-fi-certified-miracast#sthash.vHtDZgXW.dpuf

• Edited by Roybotic Thursday, January 08, 2015 12:12 AM

I think I found the ACTUAL fix, or at least an alternative fix.

I had two Surfaces with the EXACT issue, as well as several other WIDI enabled machines that are joined to the domain.  I created an new OU just for the devices i wanted to connect to the miracast, blocked inheritance then added ALL policy objects that were applied to the WORKSTATIONS OU as well as a duplicated Default Domain Policy. One by one I removed every policy object and ran a gpupdate each time until I could connect to the wireless display.  Policy that seemed to do it:

Computer Configuration > Policies > Windows Settings >Security Settings > Wireless Network (IEEE 802.11) Policies

The policy we were using to configure our wireless for our production network was an "XP" policy.  I recreated the connection policy as a "Policy for Windows Vista and Later Releases". 

The setting to pay attention to is on the "Network Permissions" tab: "Don't allow Wi-Fi Direct groups".  selecting that option prevents the machine from connecting to Wi-Fi Direct devices such as the Miracast.  I suspect the XP policy disables that or does not have a mechanism for setting it.

Note: All my DC's are Server 2008 and 2008r2, but I set the policy on my Windows 8.1 machine in order to get access to all the current policy objects.

It worked, our domain had a empty file in place , I remove it and then magic after a gpupdate /update + reboot on the client computer it work!