Troubleshooting

From RangerMSP Wiki - PSA software for MSPs and IT services providers
Revision as of 11:07, 29 July 2009 by Yarden (talk | contribs)
Jump to navigation Jump to search

Troubleshooting Menu:


CommitCRM Installation Troubleshooting

When running CommitCRM getting error message: "Error while running client: Cannot modify a read-only dataset"

Solution: This error may occur when trying to run the CommitCRM client application (usually for the first time), and it may indicate a Windows' privileges or permissions issue in accessing the CommitCRM installation folder.
Should a user receive this error message, make sure the user has full access rights to the CommitCRM installation folder on the server (or locally, if the system is installed in a stand-alone configuration). Without full access rights, the user will not be able to log in to the system or update information in the database.
A simple way to verify that a user has all the required permissions to the CommitCRM installation path (read/write/ delete) is to create a simple text file (e.g. "test.txt") under <Shared-Server-Folder>\Commit\DBSys\ folder, using the same PC on which you are running the CommitCRM client application. The client should then attempt to edit the file's content with some text, save it, and then delete it. Once a client is able to perform this test successfully, they should be able to run CommitCRM without a problem.

When running CommitCRM getting error message: "Error while running client: Cannot load CommitCRM client due to Windows permissions error."

Solution: This error indicates a privileges or permissions issue. See section above for solution.

Web Interface Installation Troubleshooting

Changing CommitWebInterface.ini parameters does not take effect

Solution: After modifying <Installation_DIR>\Commit\WebInterface\CommitWebInterface.ini, restart CommitWebInterface service for the changes to take effect.


Cannot login using newly defined web users

Solution: If you cannot login using web users you've just created/enabled, please note that it may take up to five minutes until your new settings take effect, and that the password is case sensitive.


No response from the server (seeing a blank page or an access error message)

Solution:

  1. If a connection cannot be established through the Internet/LAN, and the CommitWebInterface service is running, make sure no other applications or services on the server are using the same port as that set for Commit Web Interface, and that you have set up the correct IP/URL address.
  2. If a connection cannot be established through the internet, but can be established on your LAN, make sure you have opened up the port used by Commit Web Interface in your firewall/proxy.
  3. A common problem which can result with no response from the server, relates to DEP (Data Execution Prevention). You should open Window's DEP settings and allow CommitWebInterface service to accept connections.
    DEP can be found under System Properties -> Advanced -> Performance - Settings -> tab DATA EXECUTION PREVENTION.
    Make sure you allow the CommitWebInterface service (its executable is found in <server>\Commit\WebInterface\CommitWebInterface.exe)
    Usually this requires reboot of the server for the changes to take effect.


Session timeout is too short

Solution: If a user doesn't perform any action within a specified period of time his session expires and he needs to reenter the system. The default timeout value is 60 minutes. You can modify the default by editing the TimeOutAmount value in file <Installation_DIR>\Commit\WebInterface\CommitWebInterface.ini


Can't download documents from the web interface

Solution: Using the Web Interface, employees can download Commit documents which are located on your server, directly from the browser.
In order to allow file downloads, you should first map the folder locations for the download, so that the Web Interface Service will be able to access them for download. You can also define folders which will deny download, in case you need to protect sensitive information from being accessed via the web interface. To setup the documents download settings, go to Tools > Options > Web Interface. Read more about this under Document Download Settings.

Alerts Server Installation Troubleshooting


I set my user to receive Alerts but I do not get any email alerts

Solution: You should check the following options:

  1. It can take up to 10 minutes for new Alerts preferences to take effect. You can wait, or restart the Commit Server service in order for the settings to take effect immediately.
  2. Make sure your system administrator has activated the system alerts (set the system to ON using the ServerConfig utility) and that the CommitServer Windows service is running).
  3. When testing the alerts, note that you will not receive Alerts for changes you have made. You should perform the changes with a different Commit user.


I checked all of the settings, the alerts system is activated, and and I still don't get email alerts

Solution: In some cases, old settings already created wrong email alerts which are "stuck" in the outgoing queue and prevent the system from going on to the new alerts. In this case, you should first cleanup the outgoing queue:

  1. Stop CommitServer service
  2. Run <server>\Commit\Server\ServerConfig and make sure all settings are correct. Check that the "From Email Address" is correct. Save any changes you make.
  3. To delete old pending alerts, delete all the files in the following folder: <server>\Commit\Server\QSysEDOutbox\
  4. Restart CommitServer service and verify email alerts are being sent

For more Outgoing Emails troubleshooting, please refer to the Email Connector Troubleshooting section below (both the Email Connector and the Alerts Server use the same Outgoing mechanism).


I made changes in Commit (i.e. added a new Ticket, etc.) and I am not getting any Alerts

Solution: You only receive Alerts for changes made by other people. When you make a change in the system on entities related to you (e.g. you assign yourself a new Ticket), you will not receive an Alert.

Email Connector Installation Troubleshooting

Emails aren't being pulled from the Incoming Email mailbox (Incoming Emails Troubleshooting)

Solution:

  1. Make sure the email address you defined as the incoming mailbox is not being used anywhere else in the settings. For example, it should not be used for the backup or error mailboxes, or the "response reply-to" address.
  2. Make sure you have allowed the Email Connector Service in your Windows' Server DEP settings. DEP can be found under Windows: System Properties -> Advanced -> Performance - Settings -> tab DATA EXECUTION PREVENTION.
    In case you needed to add/update you DEP settings, make sure you restart CommitServer service after modifying your DEP settings.
  3. While working on the same server where CommitServer is installed, try sending an email using a standard email client (like Outlook® Express) – use the same Hostname (or IP), Port, User Name and Password as you've set for the Commit Server and make sure the email gets sent. (This test is completely disconnected from Commit, but enables you to check whether the email address is working at all.)


Responses and forwarding of unrecognized emails doesn't work (Outgoing Emails Troubleshooting)

Solution: Problems with the Outgoing emails can be a result of various issues: Pending Outgoing emails with wrong settings: In order to send the automatic email response, the system uses the Outgoing Emails engine. In some cases, while testing the Outgoing settings, old settings already created wrong emails which are "stuck" in the outgoing queue and prevent the system from going on to the new emails. In this case, you should first cleanup the outgoing queue.

  • Stop CommitServer service
  • Run <server>\Commit\Server\ServerConfig and make sure all settings are correct. Check that the "From Email Address" is correct. Save any changes you make.
  • To delete old pending emails, delete all the files in the following folder: <server>\Commit\Server\QSysEDOutbox\
  • Restart CommitServer service and verify email alerts are being sent

Possible causes:

  1. Authentication:
    Make sure you are using an authenticated method to access the mail server - you should define the username and password in order to access your Exchange server. Use the ConfigServer utility to set it up and try the test again. Make sure to restart the service after changing the parameters. This will make sure you are using a authenticated user.
  2. Mail server does not support relay:
    Make sure to allow relay on your mail server. For example, when an email which is not being processed by the Email Connector is detected, it only tries to forward it to the internal email address as-is. When the security settings prevent relay on the server, this may fail for this reason.
  3. Wrong SMTP settings:
    Email delivery should be set up to use port "smtp". However, sometimes when the default port on the outbound server is configured as SMTP this does not work. Try changing it to 25 on the server configuration, restart the service and see if this helps.
  4. Mailbox Account Rights in the server:
    Make sure the account you use for sending has "Send As" rights for the email address you specify in the "From address".
  5. Using domain in the user name:
    When defining the user name in the Outgoing email settings, some servers require using the domain in the user name (e.g. "domain\user") and some don't. Try removing or adding the domain name from the user name and restart the service between tests. Note that although the manual test via the ServerConfig may work in both ways, the service itself works in a different way, and may require different username settings.
  6. Hosting Customer Web Sites:
    When you host customer Web Sites on your premises, but they host their own email elsewhere, the DNS settings may confuse the mail server when it is set to receive email locally for theses domains. Make sure to set up the mail server to send emails to these domains externally.


Customer replies aren't being filed under the ticket (Email threading troubleshooting)

Solution: Only emails which contain the ticket number in the email subject will be filed under the ticket and forwarded to the internal email support address. Make sure the customer replies to the automatic email response sent when the new ticket was created, which already contains the ticket number in the subject.


I BCC/CC the Email Connector, but email is not filed in the ticket, just forwarded to the internal support email address

Soltuion: Make sure the following terms apply:

  1. The email contains the ticket number in the email subject.
  2. The sender's email address is defined as one of employee's emails (Email1 or Email2)
  3. The employee is marked as an Active employee in CommitCRM.

Note that when a technician BCCs the Email Connector and is identified properly, the email will be filed in the ticket, and will not be forwarded for manual processing. See more details on matching the email to an account in Matching by Email or Domain Name

The changes I am making to my settings using the setup program aren't taking effect

Solution: Once you have made your changes, you must restart the CommitServer service for the changes to take effect.


New Tickets are being created when clients reply to the Email Connector Response

Solution: The reply-to address which is used in the response emails sent by the Email Connector is taken from the Internal Support Email address. Make sure the Internal Support Email is different from the Email Connector's Incoming Email address.


Attached emails only open in Outlook Express

Solution: Commit stores the incoming emails used for creating new Tickets in the folder that was selected during the setup phase (set by running the ServerConfig.exe utility). The email is stored in the exact form it was received from the mail server, without any modifications to it. Apparently, Outlook Express is able to work with native formatted email message files (.eml) and knows how to parse and display them (there may be additional email applications that can handle this). However, MS-Outlook (the email client included with MS-Office) uses a proprietary file format (.msg) which is also related to the format used by Microsoft Exchange. Therefore, other email clients cannot view these emails.
Note that the first time you open an .eml file you may be prompted to set up Outlook Express. Click Cancel, and the files will be opened anyways.


I can't see email attachments on emails that are opened in Outlook Express

Solution: If you are not able to view attachments in messages opened in Outlook Express, you should check the settings to see if they are configured to hide attachments for security reasons. To allow viewing attachments, open Outlook Express and go to Tools > Options > Security tab. Deselect the "Do not allow attachments to be saved or opened that could potentially be a virus" checkbox. Now you should be able to open and view attachments.

See Also


Retrieved from "https://www.rangermsp.com/w/index.php?title=Troubleshooting&oldid=542"