I have a Thinkpad T430s running a fresh install of Windows 10 Pro (Build 10.0.14393), and it has an issue with inbound remote desktop sessions that causes the wifi connection to be dropped as soon as the remote desktop logs in, resulting in the termination of the remote session.


  • Sometimes I can see the lock screen rendered on the remote desktop for a split second before it freezes, presumably due to wifi connection loss.
  • If I'm logged in locally at the laptop, and then try to login with the same user remotely, the local login will be booted out to the lock screen. This behaviour is as I would expect.
  • When the remote desktop session freezes after login, I can see on the lock screen locally that there is no wifi connection (as shown by the wifi icon). Reconnection does not occur automatically here on the lock screen.
  • Wifi connection is automatically re-established after I log in locally.
  • If I remove the wifi hotspot from config (either through "netsh wlan delete profile name=" or through "Forget" in the UI), add the hotspot back and connect, log in remotely without first logging out locally, then the remote session will connect successfully.
  • If I reboot the laptop after doing the step described above, then the problem returns.

What I've tried:

  • Updated to latest WLAN driver.
  • Installed all Windows updates.
  • Disabled the option to "Allow the computer to turn off this device to save power" for the WLAN device.

The user I'm trying to log in as is a local, non-domain user. Wifi hotspot is secured with WPA2-Enterprise and EAP-MSCHAPv2.

  • @MagicallyDelicous - I can reproduce the same behaviour starting a RDP session from another computer. There is an INFO level event in the log that says "The browser has forced an election on network \Device\NetBT_Tcpip because a master browser was stopped.", but I believe that's due to the connection drop, not the cause of it.
    – Shimakaze
    Mar 10, 2017 at 0:44
  • @MagicallyDelicous - The two machines do not have the same mapped printers; however, I tried unchecking the share printer option anyway, and that did not solve the issue. This seems to be specific to this particular wifi network, as I have discovered after trying RDP successfully in other wifi networks. Possibly due to EAP-MSCHAPv2? That is the only difference I can see, but I don't know enough about wireless authentication to know if that could affect anything.
    – Shimakaze
    Mar 10, 2017 at 17:55
  • Are the machines you're connecting to and from with RDP on separate subnets or making hops across routers other than the wifi connection component to talk with each other? Wonder if allowing 3389 and/or 389 TCP rules for "allowed" in any of the devices would make any difference? I assume the traffic isn't going thru any FW filters but setting up rules to bypass or proxy is another thing to at least check on potentially. Mar 10, 2017 at 19:03

4 Answers 4


OK, this is an old thread, but it might be useful for some with this issue.

If you want your wifi connection to be configured for "all users" you can export it from your profile, and then reimport it for all users.

Open an elevated command prompt. (hit windows key, type cmd, then press Ctrl+Shift+Enter) to see what profiles are on remembered on the system, use the command

> netsh wlan show profiles

then, copy the name of the profile you want to make for all users, (drag the mouse over the text and hit enter to put it in the clipboard)

Now, export the WiFi profile with:

> netsh wlan export profile name="your copied Wifi Network name" folder="C:\path\" key=clear

After that, add it to all users:

> netsh wlan add profile filename="full path of .xml file" user=all

That should do it. :)

  • 1
    Worked like a charm. Didn't know netsh was a thing until now. Thank you!
    – motto
    Oct 23, 2019 at 22:53
  • Worked for me, but I have to create the C:\path prior to entering the command, otherwise it would fail. - Using Windows 10 + PowerShell
    – astroflyer
    Nov 22, 2022 at 10:55
  • Before adding it, I had to remove it first with command: netsh wlan delete profile name=
    – Tomasito
    Dec 19, 2022 at 9:18

I had the same problem and not solved it, but found a workaround. I sincerely hope this problem will be solved.

Workaround, similar to yours:

  1. When logged in, disconnect wifi.
  2. Lock the machine
  3. On the lock screen, click the wifi icon in the lower right corner.
  4. Provide credentials.
  5. If the connection is established, the remote desktop works as expected.

That tells me that the problem is not the drivers, rdp/port mapping or the authentication. It's to do with how the credentials are shared in the windows "multi-user" environment. If my memory serves me correctly, in previous versions of windows there was an option to automatically connect wifi on lock screen. However with "newer-is-always-better" update of the interface, I can't seem to find this option and I doubt it will have found it's place in the reworked UI. So possible a register hack will solve this, however windows-fu reghacking skills elude me.


I tried @Motto's answer on windows 11 and it didn't work for me. However saving the 802.1x credentials did work. This setting was a bit difficult to find...

  1. Open network & internet settings, click "Advanced network settings" (at the bottom)

    network & internet settings

  2. Click "More network adapter options" on the next screen

    more network adapter options

  3. Right click your network and select "Status"


  4. Click "Wireless properties" -- note that this only shows up if you're already connected to the network

    Wireless Properties

  5. Go to the "Security" tab and click "Advanced settings"

    Advanced settings

  6. Under "Specify authentication mode" click "Save credentials" (in my screenshot I already saved them, so it says "Replace credentials"

    Save credentials

  7. Enter your network credentials...


Another working workaround is to intall RDPWRAP from GitHub. It prevents to disconnect from wifi after successfully login into remote desktop.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.