Look at this cluster.... What a mess. Running 19.6 and will be updating to 20.3 soon. 

Just fills and fills the event logs. 

The bridge would probably work great for Control only users. Our staff uses Automate via the control plugin and because we have all our access permissions built in Automate the bridge won't work for us without a huge overhaul of the Control / Automate integration. 

• If they integrated RDP like backstage then it could be permission based with a drop down under logon session.

• Because the control agent is installed locally it would be able to access the registry and auto obtain the RDP port from the registry. 
• It could be tunneled via the loopback address. (we do this at my company today with other technology)
• The control agent could auto acquire your screen resolution and feed that into the RDP session. 

Then when users are in Automate they could select RDP that would tunnel over the control session. Making more users happy with one change. Then as control matures, they could implement some driver to adjust screen resolution.

At the moment this request was over 4 years ago and they don't seem very interested in building a driver to adjust the screen resolution. Maybe this would be a happy middle ground until it gets built. 

Just my 2¢. 

A simple workaround until they can build a driver is for them build a function so we can RDP over the control connection. 

Give us a rightclick and RDP button. This would allow users to set the resolution to what ever they want and would fix many other issues that same time. 

Yes, painful looking through the mess control makes in the event viewer. I get complaints all the time saying something is wrong because it creates soo many entries. 

Control Bridge. Maybe this is it?

Any update on this?

Good point, I forgot that the control portion is using the relay address and is AES encrypted.  

I could be wrong, but connecting via IP sounds dangerous unless your SSL certificate has your IP address inside of it. Otherwise the control agent would have to accept invalid SSL certificates which could be bad if someone is preforming a MITM attack. 

• Started
• Under Review
• Started
• Under Review
• Started

Please make the port adjustable for the second host. i.e primary  relay://domain.com:443 secondary relay://domain.com:80  This would allow us to attempt a connection on port 443 by default and then failover to port 80 for sites that do packet inspection on 443 and block the relay from connecting.