none
Miracast Broke after connecting to Domain

    Question

  • 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
    Tuesday, January 21, 2014 9:23 PM

Answers

  • 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
    Wednesday, January 22, 2014 6:57 PM

All replies

  • 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.
     

    -- Barb Bowman
    Wednesday, January 22, 2014 10:22 AM
  • 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.

    Wednesday, January 22, 2014 1:26 PM
  • 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
    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.

    Friday, April 18, 2014 1:59 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!

    Wednesday, June 04, 2014 11:36 PM
  • 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

    Wednesday, November 26, 2014 6:17 PM
  • I found the issue to be a VPN client issue.  Disable the client on the adapter fixed the issue.  See here.
    Wednesday, December 03, 2014 10:13 PM
  • 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...

    Wednesday, December 10, 2014 3:54 PM
  • 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!

    Thursday, December 11, 2014 4:46 PM
  • 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.
    • Proposed as answer by CrazyTegger_v2 Friday, November 20, 2015 2:09 AM
    Friday, December 19, 2014 6:30 PM
  • 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
    Thursday, January 08, 2015 12:11 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!
    • Proposed as answer by GertjanBanga Monday, December 14, 2015 1:51 PM
    Friday, March 13, 2015 10:26 AM
  • Was not able to see this. Was able to do the following

    If that doesn't work or doesn't show up. I was able to get it to work by doing the following:
    * open regedit
    * Go to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Wireless
    * Deleted Windows XP Folder
    * reboot machine

    not sure if this will stay permanent after a gpupdate but worth a shot

    Wednesday, July 22, 2015 12:02 PM
  • Worked for me.

    Monday, December 14, 2015 1:53 PM
  • Worked for me, thank you
    Tuesday, January 05, 2016 1:52 AM
  • Can anyone help\assist by instructing me how to  'Enable Allow WiFi Direct Groups'  as above via a registry fix.

    thanks


    Hifz Shaikh

    Wednesday, January 06, 2016 3:24 PM
  • I need the corresponding regkey value for the highlighted 'WiFi Direct Groups' setting.

    Hifz Shaikh

    Wednesday, January 13, 2016 4:20 PM
  • worked for me if i do not activate the "prevent connections to infrastructure networks" button. If i activate the button, it s not possible to connect to the miracast adapter. Is it possible to add a permission for the WIDI/ Miracast Connection via GPO?

    Thanks and best regards

    Tuesday, February 09, 2016 10:39 AM
  • sorry but still cantt find this window , i have windows 10
    Wednesday, October 05, 2016 4:01 PM
  • I have windows firewall turned on by GPO under windows 10, using the microsoft connect to wireless display app from the apps store. The "don't allow wi-fi direct groups" was unchecked.
    I was still having problems when the windows firewall was on.

    Did a netstat -b and found:
      TCP    192.168.137.1:7236     192.168.137.247:37134  ESTABLISHED
     [WUDFHost.exe]
      TCP    192.168.137.1:50604    192.168.137.247:1189   ESTABLISHED
     [WUDFHost.exe]

    Added windows firewall Exception for:
    C:\WINDOWS\system32\WUDFHost.exe

    Started working!
    Tuesday, November 01, 2016 12:14 AM
  • Just an FYI post.  I found a fix for our particular environment and figure I would share in case it could help someone else.  After adding the devices "Compatible ID" via the GPO, it allowed the device to connect.  I had to connect the device after removing it from the GP first so I could locate the ID via Device Manager and then add those to the "Allow installation of devices that match any of these device ID's" located at Computer Configuration\System\Device Installation\Device Installation Restrictions.

    Cheers,

    Andy

    Thursday, January 26, 2017 6:07 PM