I have an 8-node cluster. 3 of the nodes setup using MSFT RD setup work fine. The other 5 nodes I get 131085. I created an RDP connection using RDP 8.0 and that worked fine. I imported that RDP into RDM and it works. What causes this issue? As now I need to re-create the RDM entries for the 5 that don't work. And I'm just getting started as I have another 20 node cluster to check for this same issue.
Help....
The other interesting thing is if I re-create new RDM entries that doesn't work. I need to create in RDP 8.0 and export/import into RDM to get them to work.
Hello,
Are you using RDM Mac or RDM Windows?
Best regards,
Jeff Dagenais
MacBook Pro
Hello,
I have moved your topic into RDM Mac - Support.
Is it possible that you encounter the same issue reported here?
https://forum.devolutions.net/topic29290-unable-to-connect-after-march--patches.aspx
Best regards,
Jeff Dagenais
i tried switching to RDP Engine 5 and no go.
Hi,
Could you try with this version: https://www.dropbox.com/s/d3fsphhjo1w61pf/Devolutions.RemoteDesktopManager.Mac.5.1.0.1521122932.dmg?dl=0
Best regards,
Xavier Fortin
Will this upgrade or do I need to remove/install new.
You should only have to run the .dmg file and than move the app to your Applications folder. This should override the previous version.
Best regards,
Xavier Fortin
I was also getting 131085 messages when connecting to some (not all) servers.
Always the same servers that did not work.
When trying this version, I can connect to some servers that previously didn't work.
But now on most others, I cannot connect and I do not get any error message (just "not connected").
Open external always works fine.
Edit: I now also sometimes get the popup: Unable to connect to host
Hi Naftali,
Could your try generating your RDP log on one of the session that fails to connect and post back with it? Here are the instructions: https://helpmac.remotedesktopmanager.com/howto_rdplogs.htm
Best regards,
Xavier Fortin
I've attached the log file.
These are two connection attempts to the same machine.
The first one terminated without any message.
The second I tried connecting to the IP address of the machine directly instead of its DNS name, and it returned the popup message "unable to connect"
5.1 build you gave me does not work for embedded. It does work with External use case.
I don't get 131085 with the new build just a "not connected" like Naftali mentioned.
Hi Naftali,
Does the log contains the attempt with the IP address to?
Hi Barkz,
Could you also get me the RDP log of your session?
Best regards
Xavier Fortin
Yes, the log contains both attempts
Hi Naftali,
Except for the fix for the Windows March 13 update, I don't see what could cause your issue. We changed how we handle Security Negotiation settings, maybe this is it. We see to attempt being made in your log one with NLA and TLS On and one with NLA and TLS Off:
[21:08:28:589] [5697:0b8e3000] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[21:08:28:589] [5697:0b8e3000] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[...]
[21:09:26:556] [5719:0e3b8000] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: FALSE
[21:09:26:556] [5719:0e3b8000] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: FALSE
Maybe trying the other combinations could help (NLA: On + TLS: Off and NLA: Off + TLS: On).
You can change those in your RDP session properties: Microsoft Remote Desktop (RDP) -> Connection -> Authentication -> "Active network level authentication NLA" and "Enable Transport Layer Security (TLS)".
Best regards,
Xavier Fortin
I'll try changing the NLA and TLS settings and let you know.
However, note that I did not change NLA or TLS settings between those two tries, just the host/IP of the.server.
This issue is also not as consistent as the 131085 error I had before, as now I am able to connect sometimes just by retrying.
[14:08:38:527] [31375:095dc000] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[14:08:38:527] [31375:095dc000] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[14:08:38:529] [31375:095dc000] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[14:08:38:529] [31375:095dc000] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[14:08:38:529] [31375:095dc000] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[14:08:38:529] [31375:095dc000] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[14:08:38:529] [31375:095dc000] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[14:08:38:529] [31375:095dc000] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[14:08:38:529] [31375:095dc000] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[14:08:38:529] [31375:095dc000] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[14:08:38:529] [31375:095dc000] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_DNS_NAME_NOT_FOUND [0x00020005]
[14:08:38:529] [31375:095dc000] [ERROR][com.freerdp.core] - unable to set TCP_NODELAY
[14:08:38:529] [31375:095dc000] [WARN][com.freerdp.core] - setsockopt() SOL_SOCKET, SO_KEEPALIVE
[14:08:38:529] [31375:095dc000] [WARN][com.freerdp.core] - setsockopt() IPPROTO_TCP, TCP_KEEPIDLE
[14:08:38:529] [31375:095dc000] [WARN][com.freerdp.core] - setsockopt() SOL_TCP, TCP_KEEPCNT
[14:08:38:529] [31375:095dc000] [WARN][com.freerdp.core] - setsockopt() SOL_TCP, TCP_KEEPINTVL
[14:08:38:529] [31375:095dc000] [WARN][com.freerdp.core] - setsockopt() SOL_SOCKET, SO_NOSIGPIPE
[14:08:38:529] [31375:095dc000] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3
[14:08:38:529] [31375:095dc000] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[14:08:38:529] [31375:095dc000] [ERROR][com.freerdp.core.nego] - Protocol Security Negotiation Failure
[14:08:38:529] [31375:095dc000] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure
I have some of them working now in the 5.1 build you posted. Here is what I did:
- Edited entries, changed RDP type to a different option (Azure)
- Then changed RDP Type back to Normal
- Then changed RDP Engine to Default then back to Modern
- Connect
This has worked with some. The problem is I can't touch 100+ entries individually and the above steps just seem odd to get things to work.
Thoughts?
I try this same above method on our entries and it does not work. This is very frustrating.
I'll try changing the NLA and TLS settings and let you know.
However, note that I did not change NLA or TLS settings between those two tries, just the host/IP of the.server.
This is normal, if the connection first fails, we're trying with different security negotiation settings since these are frequently overlooked settings.
This issue is also not as consistent as the 131085 error I had before, as now I am able to connect sometimes just by retrying.
I try this same above method on our entries and it does not work. This is very frustrating.
I think you are both hitting a known issue with the RDP session Modern Engine (previously V5). The issue being that some connections can sometime fails multiple times before succeeding. There is two thing I'd like both of you try.
Could you try disabling Sandboxing and see if this helps in any way?
If this does not fix the issue, could you than try switching to the Legacy (previously V4) engine? I'd guess that you were both using the Legacy engine before this version (since this was the default value) and if nothing else works, this should.
Best regards,
Xavier Fortin
Hi Naftali --
Legacy mode is working. The strange thing is some of my RDPs are set to Legacy and others to Modern. They all work now but it's like a mix mode.
Thanks,
Barkz
I'm fairly new to RDM so based on the Legacy changes I need to make how do I mass update all Entries?