This may not be specific to Win10, to be honest I've never tried it before. We have an old phone system, the administration of it is through a dumb terminal with RS232C connection. I have replaced the terminal with a computer. I'm using PuTTY connected to COM1 to administer the phone system. Everything works well when I'm connected locally. The reason I did this is so I can administer from somewhere else. My desk in a different part of the same building, or from home over VPN. In either case I will connect to the computer with RDP. Problem is, when I'm connected remotely, I cannot get the COM port to do anything. If I walk back in there and login locally, I get a popup from putty about a serial port error. Then I can restart the session and it will connect. Once I'm connected, I can then go back to my office and connect to the machine over RDP and it works. But if the connection ever drops, I have to login locally again. I am not talking about serial port redirection. The RDP host machine is the one with the serial port. It just doesn't work from a client connection. Did I miss some configuration step somewhere?
Most users nowadays don't have these jurassic period ports on their machines to be able to try to reproduce this issue Just to confirm, emulating something via a software-emulated COM/LPT in a VM or on a Bluetooth connection then sending that session to RDP, reproduces this?
No. The com port is physical, on the host machine. If I launch putty while logged in locally, I can access what's connected to the port. If I'm connected to that machine via RDP and launch putty, it doesn't work. If I do it locally, then connect to that session from RDP, the connection is still alive. If the serial connection drops, it can't be re-established until I log on locally again. In all cases putty is running on the host machine, I am not trying to virtualize the com port to the local machine. [[ah, wait a minute. maybe I am doing exactly that without realizing it, if the action of connecting with RDP is redirecting so that com1 is the port on my local machine instead of the host, that would explain the whole thing. Now I'll have to check on Monday and see if I have that option enabled or not.]] As far as emulating the whole thing in a VM and seeing what happens if I connect to that with RDP, haven't tried that. I'm not sure I even know how... The com port is the only way I have of accessing this ancient pbx and I much prefer to do it from my office or even from home, than in the freezing cold noisy server room.
Myrrh, I've read your first post, no need to repeat. I asked if emulating a host serial/parallel port also causes this issue. Explanations for the suggestions of trying an emulated port on host then trying to connect to the host over RDP: Pair a Bluetooth device that require serial ports (depending on the drivers for your Bluetooth stack there is a settings tab in advanced BT settings for creating incoming/outgoing pseudo-COM ports), or Create a VM with a serial port, map that port in the VM to be e.g. COM6, and either map to a host text file for testing simple input and then checking if whatever you typed got echo'd to the text file, or; attach a host named pipe and a kernel debugger to it for testing response; connect over RDP to your VM, try to putty in the VM to COM6, should be connected to the mapped file or the debugger (but don't break execution lol), unless RDP moves ports numeration to place client's redirected port if exists, to COM1. If that's what happening, then COM1 is the RDP-redirected host port, and the actual port (the VM doesn't know its not a real port) would be COM7
The more I think about it, I probably need to just disable com port redirection at the host. When I connect with rdp and the com1 port isn't already in use, it gets replaced with the rdp client's com1 port, of course nothing is connected to that. It took me describing the problem twice before it hit me.