Ron van Elteren

Hi Maurice,

Yes, I only did a data export/import and nothing else.

I have tested it and it works well.

But good that you point this out for users who will want to do the same.

We extended our Enterprise license again with 1 year this week, so for now we are good to go ;-)

Unfortunately this company that acquired us, doesn't use RDM but it now gives me 1 year to convince them to start using it ;-) hahahaha

Kind regards,

Ron

Hi Hubert,

My colleagues dropped the request at Securelink on the 18th of March.

But from what I understood, SecureLink doesn't have a SDK or API currently to connec to.

So only when they decide to open up connections from a third party, they still have to create/write a SDK or API.

I'm not sure how quick they are, but it could take a while...

Hi Hubert,

I have asked our IT team, who has the contacts in SecureLink, to contact them and let them know that Devolutions is willing to co-operate in a RDM integration.

I don't know if they already contacted Devolutions though...

Hi Jeff,

I understand the decision of deprecation and I don't hold any grudges or anything.

Our company has been acquired by an American firm and they are using SecureLink to connect to customers.

From what I can gather, SecureLink is practically a copy of ConnectWise Control.

We use CW currently for customers who normally use a VPN to their servers.

But as VPN tunnels always run on virtual PC's on our network, RDP into the virtual PC + start the VPN + RDP into customer server just takes too long.

CW is much faster and secure enough (encrypted connection). Our Customer Service benefits greatly from the faster connection, also for our consultants (over 100).

Do you then perhaps know any good alternative for CW ? Secure connection + RDM integration ?

I'm open to idea's.

Hi guys,

I have a big issue with ConnectWise and I have contacted them, but they are eighter unwilling to help or just fed up with me.

Background: I have been using CW for more than 1 year now and never really had an issue.....up untill now.

I use LDAP (configured in their web portal) for our users to get authenticated. Again, this works really well.

In RDM I have several sessions, which are customer specific and so point to the correct session.

Currently I am on version 20.12.1734.7640.

If I try any newer version, the sessions stop working and I get the error "authentication failed".

All of them.

First I thought it could have something to do with the configured LDAP, but on their web portal there's the option to do a lookup and that works.

So LDAP seem to work.

Each time when they release a new version, they change servers with new IP addresses (AWS). So I thought it could be something blocking the connection.

But when I try it from home, where I don't have IP whitelisting or blocks to their portal, I get the same error.

Funny thing is, I only get this error when I use RDM with the CW integration.

When I use the portal and start a session over there, everything works fine.

When I revert back to version 20.12.1734.7640, I am able to use RDM with the CW integration again.

Could it have something to do with the CW integration ?

Could they have done something on their end that makes the CW integration in RDM stop working ?

I really hope you guys can help, we have over 50 customers configured in CW and I don't want to move them all to another solution.

P.S. I'm running 2 different versions of RDM, both have the same problem. Versions 2020.1.20 and 2020.3.23.

Than the only way is to contact their support, I'm afraid.

@andre07

As I said, I have the same issue not able to connect to my ConnectWise sessions with RDM version 2020.3.23 or even 2020.1.20 (we are using 2 different RDM versions, 1 for production other for testing).

The problem is not related to RDM or the ConnectWise integration add-in.

It is related on side of ConnectWise itself.

Just log into your ConnectWise instance https://cloud.screenconnect.com/#/account

Click on the 3 dots next to your instance name and select "Revert to Snapshot"

Select a snapshot of version .7640 or earlier.

(version .7657 and upwards gave the issues, so I reverted back to .7640).

This solved the issue for me at least.

Thank you Ron for the details. Let us know if they answer. For now, we don't plan to remove the integration or the code. It's just that it's not easy for us to support our users when we don't have the support from the third party. We mark it deprecated because we know that it's possible that we could not find a solution if the problem is not on our side.

By the way, this does not mean that in the future we will not change our mind.

Regards

Hi David,

Working for a software company myself, I really understand that it is not easy to support a third party product.

I am only worried if you have to switch our current customers, for which we use ConnectWise Control add-in of RDM, to another solution to remotely connect to.

We made a decision over 1 year ago to use ConnectWise, solely based on the fact that RDM has an integration.

Seeing that RDM is our main application for remote connections to our customers, an integration is crucial for us.

Because our company has been acquired by an American/Canadian firm (Aptean) and they don't use RDM for remote connections, we might need to switch to another solution anyways.

But I'll try to hold on to RDM as long as I can, simply because I just love it !

May I ask if an integration with SecureLink is in the pipeline ? I know Aptean uses SecureLink to remotely connect to its customers, so an integration with RDM would be awesome !

Hello,

Sadly we still feel its better to just drop the integration. We have few integrations that require plugins, and we are moving away from that as best we can.

Best regards,

Hi Maurice,

Will the ConnectWise Control add-in stop working in general, even if we don't update RDM ?

For us this is very crucial information, as we have a lot of customers we connect to using ConnectWise Control and we need to switch to another way of remote connecting.

Well, that is very unfortunate to hear that the ConnectWise Control integration will be depreciated.

We use it a lot, are depended on it even. So that makes me really wonder if I want to upgrade RDM.

@andre07 : I have the same issue with ConnectWise as you have. The problem is not related to RDM/Devolutions, but on ConnectWise side.

You need to revert back to a snapshot of version .7640 for it to work again. I already raised a ticket at ConnectWise, but haven't heared back from them yet.

For more than 2 years I have been a very satisfied RDM user, in which I have several types of remote sessions configured

(Teamviewer, ConnectWise Control, direct RDP, jumps to VM's to start VPN tunnels, etc).

However our company has been acquired by an American/Canedian company and this company is using SecureLink to connect to its customers.

Of course it is just a matter of time that they force us to use SecureLink also to connect to our customers.

I see that RDM doesn't support SecureLink sessions now, but I absolutely love working with RDM.

I don't want to stop using RDM, so therefor my request to integrate SecureLInk with RDM.

Would that be possible ?

Website : https://www.securelink.com/

Kind regards,

Ron

Thanks Michaël,

That looks very promising !

Will this new feature make sure that the add-ons are available for ALL users of RDM, without for them to manually install the add-ons ?

I am also not really happy with the new add-on management.

Situation :

Currently we are using corporate wide RDM version 14.0.5.

When someone needs to create a VPN connection to one of our customers, RDM is configured to jump to one of 16 virtual machines where the VPN

connection is created.

RDM on the virtual machines is configured to look for an add-on folder which resides on a network share.

That way RDM knows exactly which add-ons are available.

This is also not USER installed, but SYSTEM installed. Everyone who logs on to the virtual machines sees all installed add-ons.

Situation with new add-on manager :

When a user logs onto one of the virtual machines, there is no add-on installed when checking Add-On Manager.

Strangely enough, the session still works and starts the correct VPN connection (for example Forticlient).

When checking the session properties, the correct VPN add-on is also not visible and even the VPN settings (like username/password) are not visible.

Only when adding the correct add-on in Add-On Manager will bring back the add-on with its settings.

HOWEVER.....this only applies to the current user and not for system. The next person who logs onto the same virtual machine where I added the VPN add-on, will have to do the same as I did.

Please let me the best solution for :

- Every user who logs onto a virtual machine sees all available VPN add-on WITHOUT them needing to install it themselves.

- All configured add-on are updated automatically

- Add-on settings are visible instantly.

Hi,

Currently we are on RDM Enterprise 14.0.5 with a SQL database (on prem server) as datasource.

I want to test the new release 2019.1.21.0, but without converting the database.

Therefor I have made a copy of the RDM database and will use this new database to connect a new installation to.

Ofcourse that will work, but I need to be able to use my current installation (14.0.5) as well for normal daily work.

Naturally I can use a seperate (virtual) machine to test a new installation, but it would be very cool to be able to use

2 different version on my machine, both connected to another data source (e.g. different SQL databases).

Is that possible ?

if not, can it be implemented ?

Maybe it is a good idea to create an installation wizard, where extra parameters have to be entered (like data source) to create a custom installation.

When different version of RDM will be installated into seperate installation folders, maybe that will make multiple installation of RDM possible.

(like RDM 14.x.x installation will be installed in C:\Program Files (x86)\Devolutions\Remote Desktop Manager\14 and new installation of RDM 2019.x.x will be installed into C:\Program Files (x86)\Devolutions\Remote Desktop Manager\2019 )

Hi Hubert,

Sure, I can give that a go.

I will install RDM latest beta on 1 of our VM's and then test it for you.

Will come back when I have the info.

EDIT : it turns out I have RDM 2019.1.12.0 already installed on 1 of our VM's and just tested, Screenconnect works perfectly.

Hi Hubert,

By accident I stumbled yesterday upon a blog post from ConnectWise that there should be a new version of ConnectWise Control

https://www.connectwise.com/blog/remote-support/control-q1-2019-product-recap

Indeed, it now gave me the option to upgrade to new stable release 19.0.23234.7027, which I did yesterday evening.

After the upgrade I was able to connect again to our customers, using RDM 14.0.5 (using the RDM extension 2.5 on CW).

So the problem is solved for us, hope you can do something with this info.

Any update on this issue ?

I've found something in the Application log which could be helpfull.

Error :

System.NullReferenceException: De objectverwijzing is niet op een exemplaar van een object ingesteld.

bij Devolutions.RemoteDesktopManager.Business.Importers.ContactOutlookImporter.ca505697887085e420858b28e97a741bd(NameSpace c8f6c252014042057d9e2afbbab0119aa, ContactItem c794ffc578afe6dc22be072f97c413273)

Message translation from Dutch to English : the object reference is not set to an instance of an object.

No idea why importing contacts in Outlook would break the connection to ConnectWise cloud instance, but after this event occured we seem to have that problem.

Hi Hubert,

I have LDAP configured on the ScreenConnect server and so I use Windows credentials to log into the server and start RDM sessions.

Up until last week, this worked perfectly.

I've tried setting it to default or another value, still can't connect.

I'll try talking to a tech support guy from ConnectWise to see if I can upgrade to version 19.x without additional costs

BTW : see screenshot, these are the upgrade options. As said earlier, version 6.9.x is the stable version while 19.x are the experimental ones.

Have you resolved the issue?

Not resolved yet, are you experiencing the same problem ?

Hi,

I have 2 errors in the application log :

First one :

System.Net.WebException: De externe server heeft een fout geretourneerd: (500) Interne serverfout.

bij System.Net.HttpWebRequest.GetResponse()

bij Devolutions.RemoteDesktopManager.Business.Helpers.ScreenConnect.ScreenConnectHelper.c806ca9c37977f2694ab50d9983cf9406(Uri c5037b87218d33968ed5997f1e6129673, String ce3fdffbfdaf778b0b6e1bed746c5e5f0, String c5f4fb67d45af188491bb0f4d5eff06d8)

Second one :

GetServerResponse uri=<my servername> url=App_Extensions/1b088c99-69bd-43e6-8176-14a3a9af0552/Service.ashx/GetInstallerUrl requestBody=["msi","" , []]

(in the second one I masked my server name)

Hi Hubert,

We are using ScreenConnect service instance version 6.9.21870.6964

(see screenshot).

As far as I know, version 6.9.x.x is a stable version and version 19.x.x.x are experimental versions.

But please correct me if I'm wrong.

Otherwise I have to look if I'm able to upgrade from version 6.9.x to 19.x.x.

EDIT : Installed latest RDM (2019..1.12) on a test virtual machine and tried to connect --> same error.

So it is not the RDM version that is causing the issue.

Can it be the extension itself ? we didn't have issues before upgrading the extension from 2.4 to 2.5

Hello,

Extension 2.5 is now available. You'll also need version 2019.1.9.0 or higher of RDM so the new extension works properly.

Regards,

Can it be that extension 2.5 doesn't work anymore with older version of RDM ?

We are using RDM 14.0.5 and receive error "Successfully connected to server, but not able to fetch server information" (translated from Dutch to English).

(see screenshot).

Thanks Erica,

I did do a search before I posted, but couldn't find anything.

Seems I didn't search good enough :-)

Best regards,

Ron

Hi,

I've noticed that on regular bases the log entry doesn't show that a session is closed.

See attachment as example.

Is there a way to script or automate that all "active" sessions are marked as closed at 00:00 for example ?

(I'm pretty sure no one is working anymore at that time).