onsdag den 5. oktober 2011

First encounter with SuperOffice 7 PocketCRM

Apparently some people inside the company I work for, have told some one else that I have had a bit of experience with SuperOffice. One of our SuperOffice consultants was troubleshooting a failed SuperOffice 7 PocketCRM installation, and needed some help getting it up and running. I have never seen that product but I never back down from a good challenge.

The first thing I noticed when logging on to the server, was that SuperOffice web was installed, and didn’t work. If you browsed the local website, no matter what you wrote you would just get an HTTP 404 file not found. The weird thing was the error came from a Tomcat server and not IIS. I did a net stat –ano to see if Tomcat had “stolen” port 80, but that was not the case. After looking around a bit inside IIS, I noticed there was added an ISAPI filter pointing to a DLL inside the tomcat directory. After removing that entry, IIS worked again, and we could login to SuperOffice web.

But now Pocket CRM wasn’t working. Knowing that the ISAPI DLL was “eating” all web request, I  decided to created a new website and added the ISAPI filter to that website, and I also added a virtual directory pointing to Jakarta as it had been doing on the original website. browsing to the new website’s /dl I would now be presented with the option to download the pocket CRM client. We tested if we could login from a client, but had no luck. After several different test’s we managed to get an error from the client saying it couldn’t connect to http://fqdn/NetServer/soPrincipal . I ran the installer for SoWeb and created a new NetServer installation on the main website (the one with SoWeb) with a virtual directory called /NetServer. Ran config and we tested the CRM Pocket client again.

Now we would just get login failed, no matter what. I enabled logging on the NetServer installation, but it wouldn’t generate any log.

<SuperOffice>
<Diagnostics>
<add key="LogError" value="True" />
<add key="LogWarning" value="True" />
<add key="LogFailureAudit" value="True" />
<add key="LogSuccessAudit" value="True" />
<add key="LogInformation" value="False" />
<add key="LogToFile" value="True" />
<add key="LogFolder" value="c:\temp" />
</Diagnostics>
</SuperOffice>

Weird. I opened visual studio on my own machine, added a reference to the above server and created a small test application
    Sub Main()
Dim WS As New ServiceReference1.SoPrincipalClient
Dim Password As String = "secret", UserName As String = "user"
Dim Succeeded As Boolean, TimeZone As ServiceReference1.SoTimeZone, Response As ServiceReference1.SoPrincipalCarrier
Dim AuthenticationSucceeded
Dim Credentials As ServiceReference1.SoCredentials
Dim WsClient As test.ServiceReference1.SoExceptionInfo = WS.AuthenticateUsernamePassword(Password, UserName, _
Succeeded, TimeZone, Response, AuthenticationSucceeded, Credentials)
Console.WriteLine(
"Succeeded: " & Succeeded)
Console.WriteLine(
"AuthenticationSucceeded: " & AuthenticationSucceeded)
If Credentials Is Nothing Then
Console.Write(
"Credentials is nothing")
Else
Console.Write(
"Credentials Ticket: " & Credentials.Ticket)
End If
Dim s As String = ""
Console.WriteLine(
"done.")
Console.ReadLine()
End Sub


I cant re-generate the error message, to show here on the blog, but it said something about about not being able to bind the web service to port “http”. I have seen that error before so I opened web.config and added


<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>

After that I could now successfully authenticate to the NetServer, so we went back to the SuperOffice client. Same stuff, Client would say “authentication failed” and NetServer was net generating any log.

I went back to my application and wrote a wrong username and password. a log file was created. I delete the logs, chanced username/password to some valid credentials and ran the application again. no log file got generated … So seems SuperOffice has a bug and isn't logging successful logins when told too. We did the same test from the PocketCRM client, and saw the same thing happen. It would log when typing wrong username and password, and no log when we typed valid credentials. But the client kept saying “authentication failed”


After enabling debug logging inside tomcat I noticed PocketCRM wasn’t talking with NetServer though Tomcat, so I had the weird idea that maybe the PocketCRM application inside Tomcat didn’t talk with the correct NetServer


After looking though different files, I found \SuperOffice\SuperOffice 7 Server\Modules\PocketCRM\Tomcat 6.0\webapps\#pocketcrm\WEB-INF\classes and saw the NetServer URL was wrong. I changed it, and restarted PocketCRM, and voila. Everything worked.

5 kommentarer:

  1. Nice walk-through comments.
    What server-os are you working with on the CRM-server?

    We have a Win2008r2 srv with the updated SOCRM7, with SO-consultants not beeing able to make-it-work-properly.

    Any hints on how to make the http://so.[mywebserver].no/scripts/customer.exe/getAttachment/70-8E6qYPolsK3g4hxCQk32PBKDKuTpoOX0LkusZJ0Syxz0jW346tcw8OKWlPKNEXSg-0/1.5326852%2521img5326832.jpg

    to work?
    It's displaying red-X and not the apropriate image...

    Best // Sven Ivar

    SvarSlet
  2. If it is showing an red X, it means its not getting an image back but the mimetype is to be one. Its proberly sending back an HTTP 500 error message, but you cant see it, since the browser is expecting an image.

    Look in the eventlog on the SO web server, hopefully it contains an uncatch exception. If not, and i was troubleshooting, next step (if there is nothing in the SO log files) would be to install ISS exception monitor, or WinDBG to try and catch the error.

    Before doing that, running Process Monitor is always a good idear, just in case its something simple, like permissions.

    SvarSlet
  3. ah, just remembered. An easy way to see the error message would be to install fiddler2 on a client machine and watch the trafic. You could also the that by installing WireShack or Microsoft Network Monitor.

    SvarSlet
  4. Thanks, I'll invetigate a bit further and get back to you.

    We're "out in the dark" here, because a norwegian team of SO-internal consultants is working on this and there is abs no progress...

    Regz,
    Sven Ivar

    SvarSlet
  5. Hi, if you need a fresh set of eyes on it, I'll gladly go though it with you. You can contact me on alz_proinfo_dk

    SvarSlet