PDA

View Full Version : Can CommitCRM be run via VPN?


MichaelG
December 7th, 2007, 10:14 AM
Hello All,

Can CommitCRM run via VPN? I would like to access it remotely, but don't particularly care for the web access version. Thanks!

Support Team
December 7th, 2007, 10:33 AM
Hello Michael,

The best way to use RangerMSP over VPN is to remote desktop your office PC after establishing a VPN connection.

Dina

CliffordG
December 11th, 2007, 01:39 PM
Interesting, you say to "remote desktop" but by what method do you recommend remoting? If you attempt to run CommitCRM via Terminal Services (RDP in Windows XP) and do not have the SQL solution deployed CommitCRM will not run.

I never did get around to testing PcAnywhere or GoToMyPc so those may work.

To the question my experience has been that a straight vpn connection is too slow and CommitCRM will time out before it manages to fully launch.

We purchased the SQL version and use CommitCRM remotely through a Citrix / Terminal server.

Support Team
December 11th, 2007, 02:13 PM
You can run the RangerMSP client remotely using various remote control technologies which take control over a remote PC (desktop), whether it's GotoMyPC, PC-Anywhere or built-in tools including the XP ones. However, these are all used to take full control over a client PC and while you remote control it no one else can use it (and it's power should be ON all the time).

On the other hand, server based remote control sessions (such as Terminal Services and Citrix) have several advantages over remote controlling a client PC: client PC's can be turned OFF (as your session runs on the server), you do not interrupt anyone while being connected, you work on the server itself which is usually faster etc. Note that you should obtain a license for SQL Database in order to use RangerMSP client with server based sessions.

BTW, though optional, SQL Database has various advantages for larger networks. You can read more about it here.

Doron

jpicard
December 19th, 2007, 03:25 PM
It runs on a VPN, but poorly. You need to have much bandwidth to do so. We use it that way because the web client is a poor substitute for really working withCommitCRM. The only acceptable alternative is to run with a Terminal Server or equivalent setup.

FunctionOne
August 19th, 2008, 06:10 PM
We have tested with a VPN as well and find it to be too slow as well.

Does anyone know if this latency is solely a bandwidth issue or if there may be some needed tweaking in the HOSTS file or if the above mention of the SQL version of CommitCRM would improve this situation?

We also find the web client to be too limiting remote and would love to see a .NET version that could keep a local cache of the DB found on the server so we can have the full GUI interface on our laptops while in the field and not be limited by the web interface.

Support Team
August 20th, 2008, 08:29 AM
Hi FunctionOne - as mentioned, working with RangerMSP remotely requires remote technology solutions in order to achieve the best performance results. When using server-based remote technologies, such as Terminal Services and Citrix (as opposed to remote technology which takes over one of your office PCs when connected), this requires the server-based SQL Database component, as mentioned above.

Thanks for the feedback regarding a standalone client. At the moment, you may consider both working with the web interface and working with the client application remotely. Regarding the web interface, as you may know, we have recently released version 4.4 which includes many enhancements to the web interface, making it much more flexible and easy to use. It also includes many new options (such as creating new charges out of appointments, etc.). In our coming release (version 4.5), we've added some additional capabilities, and I believe the web interface is definitely a great working tool when out of the office.

Sherry

novacomputersolutions
August 24th, 2008, 03:45 AM
Any plans to adapt the web interface to a version that works on mobile devices (pda phones)

Support Team
August 25th, 2008, 06:20 AM
Yes, We are currently working on optimizing the Web Interface and making it even more suitable to PDAs in one of our next releases.

At the moment you can usually use the Web interface from PDA's with Internet access which have the Opera web browser installed (available for download on Opera's web site, make sure you test it with your PDA). You may also be able to work with other browsers which are native to your PDA - you should simply try it out and see how it works for you. Working via your PDA allows you to remotely connect to the database and perform all the actions which are supported by the Web Interface - add and update Tickets and charges, view and update Account information, Appointments, Tasks, add and update Charges and Assets records and more.

Neta

asmbit
September 1st, 2008, 10:22 AM
how much does it cost to setup SQL Database for CommitCRM? i don't like the idea of using remote desktop, then from there open commit, it's annoying especially when i want to update just a ticket or something. VPN is useless. Web interface, well it's like technology which is years older than the windows version.

Support Team
September 2nd, 2008, 06:10 AM
Hi asmbit - the SQL is indeed the best solution in case you wish to work remotely using terminal services. The pricing varies between users depending on your needs - please contact us directly and we will be able to provide more accurate information.

BTW, I believe you haven't used the web interface for employees recently (you probably remember it from the past). Though not as feature rich as the installed client, the web interface currently provides a very good solution for working remotely using a web browser (so you don't face any VPN issues and such).
Using the Web interface it is very easy to add/update service tickets, charges, appointments, tasks, assets, accounts, opportunities, items etc... And, it is getting more robust with each release. I encourage you to install a trial for the employees web interface and see how it works for you. You can contact us directly for more details on how to enable it.

Ethan

danoli
September 2nd, 2008, 05:39 PM
Are there any plans to modify the web interface calandar to be a proper calandar rather than a list based view which is impossible to glance at a day/week/month to see availability.

Support Team
September 3rd, 2008, 07:03 AM
Hi,

I checked and this feature request is indeed in our development queue. I apologize in advance but beyond that I do not have any information regarding this feature.

Sherry

cjezell
January 16th, 2009, 04:51 PM
we setup a couple of virtual pc's on one of our servers and have our field employees remote into those vpc's via log me in. Works like a champ.

tcsrvcs
January 18th, 2009, 11:38 AM
I also have used Log Me In successfully

Support Team
January 19th, 2009, 07:56 AM
Hi All,

Thanks for your input.

Here's some more relevant information -

Using server-based virtual PCs or server based remote-sessions (such as Terminal Services and LogMeIn to your server) requires using the server-based SQL version of RangerMSP (click here for more info). Working without SQL Database with such remote server-based sessions is not supported and might cause unexpected issues, including database corruption :-(

In order to use the system correctly with such sessions you should be using SQL Database. Besides server-based remote sessions, SQL Database also offers many other advantages, it increases performance and makes your entire system more robust. We also recommend on using it when your business grows and the volume of database transactions increases.

Sherry

cforger
January 19th, 2009, 01:55 PM
I have the SQL version of CommitCRM - I may give VPN with it a shot and report back. I'm assuming it's not too chatty being SQL, but there are never any guarantees. I find CommitCRM to be fairly well written and small, so I'm fairly sure it would work better than the standard database.

Support Team
January 19th, 2009, 03:18 PM
Just some more details regarding this -

RangerMSP client is actually not installed on each PC. This is one of the nicest things about RangerMSP - it is simple. Nothing is actually being installed on each client PC and all you have on the local PC is a shortcut to <server>\RangerMSP\Client\RangerMSP.exe.
This makes the system easy to maintain and very easy to install without any conflicts what so ever on each local PC, as nothing is being modified/changed/installed on the local PC.

This has some significance however when you want to use RangerMSP client over VPN (directly, without a remote control session). The main point is that it takes much longer to load. Once you double click the RangerMSP icon on your desktop the entire executable file and all related dll's needs to be loaded to the local PC. This takes almost no time on your LAN, however, over a VPN this may take longer. This is one of the reasons why we state that it is not optimized to be used over VPN without remote sessions.

Once loaded, the system will work much better with SQL Database than without it, as much less network communication is required - most database processing is done at the server-side and only results are sent back to the client (unlike the non-SQL edition which performs all database transactions over the network).

I hope this sheds some light on this. We do have some items on our to-do list which should make it 100% optimized when used over VPN with SQL. The RangerMSP system is really optimized and uses resources very carefully (see how small the entire setup program is...), however, there is some more work that needs to be done until we will officially announce that it completely optimized for VPN use.

Sherry

FunctionOne
January 19th, 2009, 03:53 PM
Hey Sherry -

You guys wouldn't be working on a .NET version of your client that can sync over the WAN would you? :) That's our biggest item on our internal CommitCRM wishlist. :)

Support Team
January 20th, 2009, 08:16 AM
RangerMSP client runs on any Windows based PC without any special requirements, (including no requirements for specific version of .Net). We would like to keep it this way. It makes everything much easier to setup and maintain.

That said, there are different ways to implement using the client in WAN configuration, and this is on our radar. Thanks for the feedback.

Sherry

JoshuaB
April 15th, 2009, 08:57 AM
cjezell,

What do you use for virtual PC software? I planned to use LogMeIn, but that would limit to one session. I'd love to know what is working for you. Thanks!

natrat
April 18th, 2009, 03:31 PM
I've run it successfully over a VPN (the non SQL version) but as you say it takes a long time to load and it is also very slow when updating record data. Mind you I was on a slow ADSL connection when doing it. It's got me out of trouble though, as I can't yet afford the SQL version (and the upgrade to version 5).

JoshuaB
April 18th, 2009, 03:51 PM
Easy Remote Access:
I setup virtualization and it works great (thanks cjezel)! I setup VMware's free server on the same box as the Windows CommitCRM server with a few virtual servers. Install CommitCRM and LogMeIn on each and your remote techs are ready to go! Use LogMeIn's Desktop Shortcut to access the box in a snap (1-click with free, LastPass browser plugin). Hope this works for others.

natrat
April 18th, 2009, 04:58 PM
That is a great solution actually. I wouldnt use LogMeIn personally, I'd use RDP with the router redirecting ports for the RDP session to the relevant virtual XP machine. Nice one, i'm going to give this a shot.

racassel
May 16th, 2012, 07:32 PM
19-Jan-2009 "hope this sheds some light on this. We do have some items on our to-do list which should make it 100% optimized when used over VPN with SQL" -Commit

-- Any progress on this? Any tricks, like copy the exe's dll's and hlp files to a folder on the local machine to speed up access?

danoli
May 17th, 2012, 12:17 AM
you are joking right? It's only been just over 3 years since this promise. It normally takes them double this assuming everyone continues pestering them for the fix :) report back in a few more years.

Support Team
May 17th, 2012, 05:54 AM
Well, despite @danoli's sarcasm it is already possible for quite a long time now. It can be implemented when using SQL.
Please contact us by email for further information.

danoli
May 17th, 2012, 06:16 AM
Touched a nerve...

All joking aside, it still requires the expensive SQL upgrade and still runs the executables via the server.

Updates for common customer requests do take a while so while I 'was' a little sarcastic, I am not too far from the truth.

Support Team
May 17th, 2012, 07:23 AM
Using SQL is optional. It does add and offer many technology related benefits. We also believe that it is offered for an affordable price. But, I guess that price discussions are always subjective.
More details on SQL can be found here and about its pricing here

danoli
May 17th, 2012, 07:38 AM
"Well, despite @danoli's sarcasm it is already possible for quite a long time now. It can be implemented when using SQL. "

then next post....... "Using SQL is optional."

Which is it? Do we need SQL or not? Can you post here how it is done for all to see?

nattivillin
May 17th, 2012, 07:43 AM
I can report the recent update (5.7 or 5.6) does run better over a vpn. The real variable is the connection speed. We tested it over a 30/30mbps channel and it works flawlessly.

We cant afford that so we are using a vmware setup with 6 xp vmmachines that we use rdc to connect to.

Not the best, solution but that run just fine.

Using vpn over our regular 10/2 is ok, but slooooow. But still faster than before the upgrade to 5.6. Im sure it is the upload that makes it slow.

Using wirespeed, i think we determined it would run just fine over a 6/6 (4xT1) but we cant afford that either.

vmware was much cheaper than 4t'1s so we went with that.

Support Team
May 17th, 2012, 07:52 AM
To danoli's request here's a clarification:

SQL is always optional.

To enjoy some of the technology related benefits it offers, like using the client over VPN as asked above, you will need to have it.

Having said that, we still recommend using remote sessions over VPN and not to simply run RangerMSP client locally over VPN. Both options require SQL.

For more information please contact us directly.

Support Team
May 17th, 2012, 07:54 AM
Thank you @nattivillin for sharing this info.

danoli
May 17th, 2012, 09:06 AM
So you are saying to operate CommitCRM across WAN links or slower LAN links we need to use SQL via a VPN link or to use VMWare sessions?

Support Team
May 17th, 2012, 09:33 AM
We're saying that to use RangerMSP Windows client remotely (e.g. not in your LAN) SQL is required. This is the case whether you use it over remote sessions to your remote server (Terminal Services, etc.) or run the Windows client locally on your remote PC while being connected to your office network over VPN.

While there are benefits of using SQL on your LAN (even if you never connect remotely), it is still optional. For what it worth, SQL can always be added and all your data, settings and customizations are reserved.

nattivillin
May 17th, 2012, 09:50 AM
Just to clarify;

Not sure required is the right term when using with RDC. I think we are not being specific enough.

If you have CommitCRM installed on your server and you try to use it while being connected via RDC it will not run. It tells you you must upgrade to sql, yada-yada.

If you have CommitCRM installed on a local workstation, then connect to that workstation with RDC, and then run commit, i am pretty sure it does work. This method just takes up an entire workstation with all the energy and space that that requires. But since it does work, it led us to the following;

If you virtualize that workstation and run it in vmware or vbox, that also works without using the SQL upgrade.

nattivillin
May 17th, 2012, 09:53 AM
I think i should add this is setup may not be support by CommitCRM. From the server it sees all vmware workstations as being reqular workstation on the lan. As do all out other software like QB which we also run rdc.

I haven't been fully convinced of the benefit of the SQL upgrade. As others have said, it is very costly.

Maybe someone who is using the SQL upgrade can shed some light on this.

danoli
May 17th, 2012, 09:58 AM
cheers @nattvillin, exactly what I thought, so the answer is that CommitCRM does not work without either SQL or VMWare (or some other virtulization)

Running CommitCRM across a 'slow link' still requires the CommitCRM clients to execute the main executable and pull DLL's across the wire.

To CommitSupport... When will (if ever) CommitCRM support a true local client that runs on the Client machine not from the server to allow or minimise the data traffic to pure data only?

Support Team
May 17th, 2012, 10:01 AM
@danoli - with SQL this can already be achieved.

Currently we do not have any plans to support this configuration with the non-SQL edition.

danoli
May 17th, 2012, 10:33 AM
Does it run the executables/dll's across the wire or on the local machine?

nattivillin
May 17th, 2012, 10:43 AM
Is that the main benefit of using the SQL? Each machine now runs CommitCRM locally and only send the changes over the wire? That would make the VPN work well with much less bandwidth. That would also make CommitCRM much faster even on the lan.

How much bandwidth is required per user using the SQL upgrade?

I would love to stop using the vmware solution, its adds another thing to maintain and upgrade. I could presuppose those XP licenses for other uses. as well.

danoli
May 17th, 2012, 11:07 AM
@nattivillin
I suspect not, although I would be happy if this is the case.

I suspect the answer is, SQL uses less bandwidth for data queries, queries are handled server side, but EXE and DLL's are still 'dragged' slooowly from the server...

I so hope I am wrong though :)

Support Team
May 17th, 2012, 11:37 AM
The good news are that @danoli is wrong :-)
With SQL you can have a local copy (e.g. on your local PC) of all executable/dll files.

nattivillin
May 17th, 2012, 11:42 AM
That is an eye opener.

The cost is still steep. The CommitCRM modules require one sql account so with 5 actual users, we need a 10 pack right?

Is there an SQL trial?
Is it easy to switch to and from sybase SQL if we are not impressed with it?

danoli
May 17th, 2012, 11:56 AM
Wow, well why didn't you announce it clearly? This thread has been open over 3 years!

danoli
May 17th, 2012, 11:58 AM
Yes, I would like a trial...

danoli
May 17th, 2012, 12:07 PM
"The good news are that @danoli is wrong :-)"

Yeesh, Seems this is where the good news ends!
Just noticed this is per connection and not per license.... we are gonna need to cough up $729...! (this is the 'offer' price) lol

nattivillin
May 17th, 2012, 12:34 PM
I agree, that is where the good news ends, the price is steep.

@CommitCRM Users, How many people are using the SQL link?

@CommitCRM Support, do you think you would get more sales with a lower price?

Does sybase charge that much per connection, or it is just a nice markup?

Support Team
May 17th, 2012, 12:37 PM
Correct. if you use about 15 RangerMSP client sessions at the very same time then the 15 concurrent connections license is required. It is indeed indeed $729 (which is about $49/connection) for a lifetime license.

nattivillin
May 17th, 2012, 12:52 PM
What exactly counts as a connection?

Support Team
May 17th, 2012, 01:29 PM
An application that runs and connects to the database, like RangerMSP client.

Note: during the same user session and the same PC if you run RangerMSP and another program that you developed (based on the RangerMSP API) then it will only count as one.
Do not confuse this with multiple remote sessions where each session counts as one.

nattivillin
May 17th, 2012, 02:03 PM
Seems like it really is only per user except for the modules then?

Unless we are running an api that doesn't run on top of the CommitCRM client?

What happens if we run out of sql connection licenses? Will it warn us, default back to the non sql connection, or refuse to connect for that user until another user logs off?

What about some of my previous questions;

Do you think you would get more sales with a lower price?
Does sybase charge that much per connection, or it is just a nice markup?
Is there an SQL trial?
Is it easy to switch to and from sybase SQL if we are not impressed with it?
How much bandwidth is required per user using the SQL upgrade?

Support Team
May 17th, 2012, 02:21 PM
It is per database connection. Any program of any type that access the database consume a connection, with the note I mentioned about (same PC / session).

If all connections are used a message will pop when using the client saying that it cannot connect to the database. It does not default back to the non SQL version.

The "previous" questions -
Lower prices means more sales - probably.
Yes, it's a per connection originally by the vendor, we did not invent anything here and this is not where we make our profits from.
Trial - In some cases as a third party is also involved. You can contact us by email for more information.
Easy - yes.
Bandwidth - I don't have exact numbers, I can say that that it consumes much less bandwidth. Please keep in mind that we still recommend (performance wise) using RangerMSP client over Terminal Services for remote sessions.

lpopejoy
May 18th, 2012, 01:49 PM
We've been using the SQL version ever since we started using Labtech. I can't really relate to the comments on price. IMO, the pricing of CommitCRM overall is great. Find another CRM package for our industry that does what this one does at this cost (seriously, let me know if exists!). The value that the SQL version brought, to me, makes the price question a non-issue. Benefits:

Reports run MUCH faster
Performance of the client is increased
VPN access
RDP access
ODBC works better/faster
Backups can be performed without stopped DB services (and can be automated).

Did I miss anything? At most of our hourly rates, the cost of the SQL upgrade is covered by billing a couple extra hours. IMO, the value that the SQL version brings to the table has allowed me to spend less time doing CommitCRM stuff and more delivering value for our clients. It is helpful to look at stuff like this as an investment rather than an expense.

RE the VPN access... TBH, I don't use this much due to the face that my upload here is only 5Mbps. However, I used RDP all the time. I can confirm that CommitCRM caches the exe's locally when using the VPN though, but it IS still slow - but definitely usable.

That's my .02.

wtbservices
May 18th, 2012, 02:52 PM
Getting back to the original posts from 2008 I think the ideal long term solution is to get the web interface up to full functionality. Running through a VPN without a SQL server will always entail the client side having to drag large amounts of data across the WAN. There is only so much the devs can to speed that up.

Has anyone tried to run CommitCRM as a remote application through either Citrix or TS Web Access?

racassel
May 21st, 2012, 01:19 PM
You can't really call it SQL can you? I mean, it is more of a psuedo-SQL as it is still the same flat file database files, only accesed using client/server technology and sql commands. I mean, its not like MySql, or Microsoft SQL or any other SQL for that matter. It's more like Pervasive "Sql", another flat file SQL overlay. For the price, the "SQL" is worth it and has requied zero maintenance... What would 15 user MSSql cost you if you didn't have the Action Pack? It is nutso that the "server" takes up one license. That means it's not really SQL, its an SQL overlay. CommitCRM should absorb the cost of that one license "overhead". Thats expensive.

That said, How do I get it to run over the VPN with local files on my desktop? I tried running the shortcut across the VPN and it timed out, saying can't connect to Advantage database.... Do you have a step by step for VPN access?

Support Team
May 21st, 2012, 02:13 PM
We totally disagree with you. MySQL, just one example, is implemented in the the very same way. In any case, please contact us directly for more information about configuring it.

racassel
May 22nd, 2012, 08:25 AM
I am used to seeing all the related tables and fields in an SQL datbase in a container, not flat files in a directory. It is interesting that CommitCRM can use the same files with or without the Advantage Database Engine. I did some research and stand corrected. Because it sits between the commands and the data, and uses SQL queries, its SQL. Sybase has lost marketshare over the years, but for the price its a value and is working well for us withCommitCRM. It is optimized for Delphi, and I see now why you are so proud of it. My only objection is the cost of one CommitCRM licence and one Sybase license for the "server" but would be the subject for another thread.....

danoli
May 24th, 2012, 02:41 AM
So, how do I arrange a trial of the SQL?

For the relative costs, I need to evaluate this in a real live environment before committing to the purchase.

Support Team
May 24th, 2012, 06:02 AM
You are welcome to contact us directly by email and we will arrange a special trial for this for you.

hayden
May 24th, 2012, 07:56 PM
Would love to see this come to MS SQL at some point. Pretty sure you guys use Interbase...

Most of us techies already have copies of MS SQL, imo it's a better database too.

I know there are no plans for this.... :P Just saying.

nattivillin
May 24th, 2012, 09:14 PM
After using it for a few days it is indeed much faster on the lan. Not like it was slow before but the entire office noticed the difference. Reports, opening, closing, switching screens, all faster.

Over the vpn.... it is much faster than it was without sql. It is still somewhat-slow imo, just faster than before. We went from 15mph to 25mph. It is nearly twice as fast, but still slow.

That being said you can actually use it over the lan with the sql upgrade. Before you really couldn't.

We are now evaluating if the vpn speed is worth the cost. We were thinking we needed 5 sql licenses for our 7 user licenses, but according to the sybase server, we are using almost 15 connections.

humbug,