PDA

View Full Version : Updating Version woes


stephajn
August 9th, 2012, 05:34 PM
We are running CommitCRM CRM 6.0 on Windows Server 2008 R2. It is in a domain environment, and we are using the SQL version.

We seem to be having a problem where on most startups, the client will say it is updating the version and to please wait, only it gets caught in a loop and never really doing anything. When we just double click on the shortcut to start CommitCRM again, then it works and eventually the instance that was trying to update complains that CommitCRM is already running.

We had this same problem with CommitCRM 5.7 after we moved from our Windows Server 2003 environment which wasn't on a domain to our new Windows Server 2008 R2 environment which is on a domain.

The client machines are all Windows 7 Professional 32 bit clients. They are all members of the domain. We even tried to set up the ads.ini file that helps to prevent the discovery process of the database, but this hasn't totally cured the issue.

Has anyone else had problems running Windows Server 2008 R2 forCommitCRM? If so, what problems did you have and how did you overcome them? Did anyone else have the same problem with ANY version of CommitCRM like the one I described above?

Support Team
August 10th, 2012, 06:28 AM
Please try the following:
Log into your server using an Administrator account
Locate the \RangerMSP\Client folder
Right click the RangerMSP.exe file and select 'Run as Administrator'.

Test.

In addition, please verify that all users all all privileges and all access rights to all file under the entire 'RangerMSP' folder tree. It's possible that the new files that arrived with the upgrade have received different default permissions than the ones originally assigned to the old-version files.

stephajn
August 13th, 2012, 12:55 PM
Hello,

Tried suggestions recommended. CommitCRM starts just fine on the server, and it always has. But on the client machines, this is where the problem is.

Also checked permissions on the server. Domain Users group has Full Control on the folder at both the share level and the NTFS file system level. So permissions are not a problem here.

We are getting mixed results all over the board and nothing is consistent. Sometimes it works, and sometimes it doesn't. On one workstation, he hasn't been able to log in for a few days now as every time he starts up CommitCRM on his workstation, he is told that a version update is in progress and to wait a few minutes. And yet, there IS NO version update that is in progress.

Is there some kind of flag in some file somewhere that controls whether this message is reported? Or even one that controls whether a client installation should be updating itself?

for that matter, is there some document somewhere that step by step explains what is needed in order to make this product run reliably on Windows Server 2008 R2?

Support Team
August 13th, 2012, 01:34 PM
Thank you for the updates. RangerMSP should run reliably and consistent with Windows Server 2008 R2.

Please note that RangerMSP client is NOT really installed on each PC. All you have is a network shortcut to an executable file on the server. If it works once it should always work, unless something interrupts it...

Now that you've verified permissions I would check local firewalls. As I believe you're using SQL RangerMSP client sends UDP packets to locate the SQL server automatically. If a local firewall blocks UDP packets, or at least partially, then it might not work (though with somewhat different errors than the one you listed originally). I recommend that you try to disable it on each client PC as well as the server and see if that helps.
Also - you can skip this auto SQL discovery process altogether by configuring an ADS.ini file that teaches the client where the SQL is. Click here to learn all about it.

HTH