[GH-ISSUE #125] Option to cleanup Terminal Server Client registry tree, so user can re-setup connection's parameters #103

Closed
opened 2026-02-26 11:56:45 +03:00 by kerem · 14 comments
Owner

Originally created by @Kyogre on GitHub (May 20, 2021).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/125

Originally assigned to: @VShawn on GitHub.

I suggest to add an option to cleanup registry tree "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client", so user can re-setup connection's parameters.

For example, I have setup my RDP-connection in PRemoteM, but when I connected for the first time I mistakenly turned ON the parameter "share drives with remote computer". Later I wanted to turn it OFF, but there was no interface in PRemoteM to do so. Thus I need to cleanup mentioned registry tree manually to force parameters window to reappear, so I can uncheck unwanted parameter.

P.S. in PRemoteM option Advantage -> Resources -> unchecking "Disk Drives" have no effect, and connection establishes with connected drives if you haven't unchecked same option in Windows native RPD-parameters window.

Originally created by @Kyogre on GitHub (May 20, 2021). Original GitHub issue: https://github.com/1Remote/1Remote/issues/125 Originally assigned to: @VShawn on GitHub. I suggest to add an option to cleanup registry tree "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client", so user can re-setup connection's parameters. For example, I have setup my RDP-connection in PRemoteM, but when I connected for the first time I mistakenly turned ON the parameter "share drives with remote computer". Later I wanted to turn it OFF, but there was no interface in PRemoteM to do so. Thus I need to cleanup mentioned registry tree manually to force parameters window to reappear, so I can uncheck unwanted parameter. P.S. in PRemoteM option Advantage -> Resources -> unchecking "Disk Drives" have no effect, and connection establishes with connected drives if you haven't unchecked same option in Windows native RPD-parameters window.
kerem 2026-02-26 11:56:45 +03:00
Author
Owner

@VShawn commented on GitHub (May 20, 2021):

sorry but i dont remember we have the option share drives with remote computer, can you give me a screenshot?

if the option you mentioned is this option, then I‘m sure it can work, I test it just now.

image


BTW, I think operating the registry of Terminal Server Client is out-of-bounds for PRemoteM.

<!-- gh-comment-id:844980114 --> @VShawn commented on GitHub (May 20, 2021): sorry but i dont remember we have the option `share drives with remote computer`, can you give me a screenshot? if the option you mentioned is this option, then I‘m sure it can work, I test it just now. ![image](https://user-images.githubusercontent.com/10143738/118966364-3cbd2e80-b99c-11eb-9031-428e6a1e9bed.png) --- BTW, I think operating the registry of `Terminal Server Client` is out-of-bounds for PRemoteM.
Author
Owner

@Kyogre commented on GitHub (May 20, 2021):

First problem is that native RDP-client overwrites PRemoteM-client when multiple monitors enabled in Windows settings: https://youtu.be/qLGHBM35zuA
Thus spawns second problem that described in the issue.

Second and third problem: https://youtu.be/mxkaUijttPk
The third problem: if you uncheck "Drives" parameter in native RDP-client window, the settings wont save, so when you are connecting again you will got message "the publisher of this remote connection can't be identified" again despite you checked "don't ask me again" mark.

If the first problem will be fixed another two problems will be gone.

<!-- gh-comment-id:845138201 --> @Kyogre commented on GitHub (May 20, 2021): First problem is that native RDP-client overwrites PRemoteM-client when multiple monitors enabled in Windows settings: https://youtu.be/qLGHBM35zuA Thus spawns second problem that described in the issue. Second and third problem: https://youtu.be/mxkaUijttPk The third problem: if you uncheck "Drives" parameter in native RDP-client window, the settings wont save, so when you are connecting again you will got message "the publisher of this remote connection can't be identified" again despite you checked "don't ask me again" mark. If the first problem will be fixed another two problems will be gone.
Author
Owner

@VShawn commented on GitHub (May 21, 2021):

Ahh I see, thank you for your youtu. This problem occurs when there are multiple monitors with different zoom ratios. PRemoteM will call the system mstsc.exe to make a full-screen connection. Since I bought two 4k monitors, I have never used this mode again and I almost forgot about it.

Perhaps using a random connection name each time can bypass the registry problem —— If you operate the registry, you may accidentally delete the existing configuration with the same name. Wait for me to test it.

@majkinetor any thoughts on this?

<!-- gh-comment-id:845682821 --> @VShawn commented on GitHub (May 21, 2021): Ahh I see, thank you for your youtu. This problem occurs when there are multiple monitors with different zoom ratios. PRemoteM will call the system mstsc.exe to make a full-screen connection. Since I bought two 4k monitors, I have never used this mode again and I almost forgot about it. Perhaps using a random connection name each time can bypass the registry problem —— If you operate the registry, you may accidentally delete the existing configuration with the same name. Wait for me to test it. @majkinetor any thoughts on this?
Author
Owner

@majkinetor commented on GitHub (May 21, 2021):

Perhaps using a random connection name each time can bypass the registry problem

I think this is OK. I don't see why PRM should mingle with mstsc and that will allow users to use whatever on any side.

<!-- gh-comment-id:845918600 --> @majkinetor commented on GitHub (May 21, 2021): > Perhaps using a random connection name each time can bypass the registry problem I think this is OK. I don't see why PRM should mingle with mstsc and that will allow users to use whatever on any side.
Author
Owner

@VShawn commented on GitHub (May 21, 2021):

I don't see why PRM should mingle with mstsc

reason: when the user using 2 monitors with different zoom ratios and wants goes to full-all-screens, I didn't find a solution to handle this 2 different zoom ratios, and found that only mstsc can do this.

see also https://github.com/VShawn/PRemoteM/blob/dev/PRemoteM/Model/RemoteWindowPool.cs#L207-L215

<!-- gh-comment-id:846030526 --> @VShawn commented on GitHub (May 21, 2021): > I don't see why PRM should mingle with mstsc reason: when the user using 2 monitors with different zoom ratios and wants goes to full-all-screens, I didn't find a solution to handle this 2 different zoom ratios, and found that only mstsc can do this. see also https://github.com/VShawn/PRemoteM/blob/dev/PRemoteM/Model/RemoteWindowPool.cs#L207-L215
Author
Owner

@majkinetor commented on GitHub (May 21, 2021):

Cant you deduce that from registry settings that mstsc puts and setup registry yourself for mstsc instead using it via API ?

Why not do exactly what OP requested: in connection editor add button [ Clear MSTS settings ] ?

<!-- gh-comment-id:846039084 --> @majkinetor commented on GitHub (May 21, 2021): Cant you deduce that from registry settings that mstsc puts and setup registry yourself for mstsc instead using it via API ? Why not do exactly what OP requested: in connection editor add button [ Clear MSTS settings ] ?
Author
Owner

@VShawn commented on GitHub (Jun 28, 2021):

I can't reproduce the issue.

I save a session in the mstsc.exe

image

But nothing shown in the registry tree HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client

image

and the software will automatically use the login credentials saved by windows for authentication #126 @dongyi945

And no, password and username in PRM just works. I set a wrong username in PRM, correct username saved by windows, then of course login failure

image

<!-- gh-comment-id:869508538 --> @VShawn commented on GitHub (Jun 28, 2021): I can't reproduce the issue. I save a session in the mstsc.exe ![image](https://user-images.githubusercontent.com/10143738/123609054-e90ef200-d831-11eb-9a72-a8d61c77ab96.png) But nothing shown in the registry tree ```HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client``` ![image](https://user-images.githubusercontent.com/10143738/123609175-05129380-d832-11eb-976b-c4fcb7d0f2ba.png) > and the software will automatically use the login credentials saved by windows for authentication #126 @dongyi945 And no, password and username in PRM just works. I set a wrong username in PRM, correct username saved by windows, then of course login failure ![image](https://user-images.githubusercontent.com/10143738/123609894-aa2d6c00-d832-11eb-906b-8575be1eab42.png)
Author
Owner

@VShawn commented on GitHub (Nov 10, 2021):

@Kyogre do you have any idea how to cleanup registry tree? I didn't know what should be deleted when I open a new rdp session form PRemoteM

<!-- gh-comment-id:964845965 --> @VShawn commented on GitHub (Nov 10, 2021): @Kyogre do you have any idea how to cleanup registry tree? I didn't know what should be deleted when I open a new rdp session form PRemoteM
Author
Owner

@Kyogre commented on GitHub (Nov 20, 2021):

there will be created tree "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\LocalDevices" after you connect in multimonitor scenario. We need to delete string "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\LocalDevices\ address of the remote machine belonged to current connection".
But this will not resolve the third problem described by me in this thread. Maybe this is Microsoft's bug...

Do you still can't reproduce it? I easily reproduce it in clean virtual machine.

I save a session in the mstsc.exe

you need to perform connection steps at least to step "enter credentials". Only after that the registry tree will be created.

<!-- gh-comment-id:974677850 --> @Kyogre commented on GitHub (Nov 20, 2021): there will be created tree "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\LocalDevices" after you connect in multimonitor scenario. We need to delete string "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\LocalDevices\ `address of the remote machine belonged to current connection`". But this will not resolve the third problem described by me in this thread. Maybe this is Microsoft's bug... Do you still can't reproduce it? I easily reproduce it in clean virtual machine. > I save a session in the mstsc.exe you need to perform connection steps at least to step "enter credentials". Only after that the registry tree will be created.
Author
Owner

@VShawn commented on GitHub (Nov 21, 2021):

Do you still can't reproduce it?

Yes I tried reproduce it a week ago, here is what I have in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server

image

Then I changed username & password in the PRemoteM, PRemoteM will return login failed when I open the session.

Besides, I wonder if we deleting the registry directly will affect the user's mstsc.exe.

<!-- gh-comment-id:974738721 --> @VShawn commented on GitHub (Nov 21, 2021): > Do you still can't reproduce it? Yes I tried reproduce it a week ago, here is what I have in `HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server` ![image](https://user-images.githubusercontent.com/10143738/142745808-f2c912f0-62ba-43cd-8b1e-9948fdb92371.png) Then I changed username & password in the PRemoteM, PRemoteM will return login failed when I open the session. Besides, I wonder if we deleting the registry directly will affect the user's `mstsc.exe`.
Author
Owner

@Kyogre commented on GitHub (Nov 21, 2021):

here is what I have in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server

thus you reproduced it)

Then I changed username & password in the PRemoteM, PRemoteM will return login failed when I open the session.

As I understood correctly, you are talking not about my problem, but about dongyi945's https://github.com/VShawn/PRemoteM/issues/126. Can't help you there.

Besides, I wonder if we deleting the registry directly will affect the user's mstsc.exe

are there another choice? I am not an expert, but I think we could delete it only via deletion of the registry tree.

<!-- gh-comment-id:974784640 --> @Kyogre commented on GitHub (Nov 21, 2021): > here is what I have in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server thus you reproduced it) > Then I changed username & password in the PRemoteM, PRemoteM will return login failed when I open the session. As I understood correctly, you are talking not about my problem, but about dongyi945's https://github.com/VShawn/PRemoteM/issues/126. Can't help you there. > Besides, I wonder if we deleting the registry **directly** will affect the user's mstsc.exe are there another choice? I am not an expert, but I think we could delete it only via deletion of the registry tree.
Author
Owner

@Kyogre commented on GitHub (Nov 21, 2021):

I think I found the root of the third and second problem: PRM creates in %temp% rdp-file, that contains in it's config string drivestoredirect:s:* - that string is the cause. If you copy that temp rdp-file, open it in notepad, change drivestoredirect:s:* to drivestoredirect:s: you will get rid of the problems. RDP connection will opens without annoying "the publisher of this remote connection can't be identified" dialog and "Disks" mark will be saved correctly.

<!-- gh-comment-id:974792401 --> @Kyogre commented on GitHub (Nov 21, 2021): I think I found the root of the third and second problem: PRM creates in %temp% rdp-file, that contains in it's config string `drivestoredirect:s:*` - that string is the cause. If you copy that temp rdp-file, open it in notepad, change `drivestoredirect:s:*` to `drivestoredirect:s:` you will get rid of the problems. RDP connection will opens without annoying "the publisher of this remote connection can't be identified" dialog and "Disks" mark will be saved correctly.
Author
Owner

@VShawn commented on GitHub (Nov 23, 2021):

ahh.. sorry I mixed up these 2 tickets : (

are there another choice

I am not an expert on RDP protocol eigher, I just a developer using Microsoft's doc & lib.

PRM creates in %temp% rdp-file

So you are using the rdp file mode of PRemoteM? Okey...I have always thought that you use the rdp window mode. So I have been mistaken the direction of the investigation. I alway test on window mode, That's why I cant reproduced unchecking "Disk Drives" have no effect

I should have checked these code:

https://github.com/VShawn/PRemoteM/blob/dev/PRemoteM/Model/RemoteWindowPool.cs#L204-L214

drivestoredirect:s:*

I will check this.

<!-- gh-comment-id:976046447 --> @VShawn commented on GitHub (Nov 23, 2021): ahh.. sorry I mixed up these 2 tickets : ( > are there another choice I am not an expert on RDP protocol eigher, I just a developer using Microsoft's doc & lib. > PRM creates in %temp% rdp-file So you are using the rdp file mode of PRemoteM? Okey...I have always thought that you use the rdp window mode. So I have been mistaken the direction of the investigation. ⛔ I alway test on window mode, That's why I cant reproduced `unchecking "Disk Drives" have no effect` I should have checked these code: https://github.com/VShawn/PRemoteM/blob/dev/PRemoteM/Model/RemoteWindowPool.cs#L204-L214 > drivestoredirect:s:* I will check this.
Author
Owner

@VShawn commented on GitHub (Nov 23, 2021):

It works, THX for your help @luki1412 , this ticket is finally fixed 👍

You will see it in the pre-release version of 0.6.0 (maybe next month)

image

image

<!-- gh-comment-id:976105000 --> @VShawn commented on GitHub (Nov 23, 2021): It works, THX for your help @luki1412 , this ticket is finally fixed 👍 You will see it in the pre-release version of 0.6.0 (maybe next month) ![image](https://user-images.githubusercontent.com/10143738/142962155-568647cd-8791-414b-9939-c83b5e2ac491.png) ![image](https://user-images.githubusercontent.com/10143738/142962040-4f1b10a8-8d91-41cd-88ab-c25ccde6fedc.png)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/1Remote#103
No description provided.