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.
<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" />
Weird. I opened visual studio on my own machine, added a reference to the above server and created a small test application
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 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")
Console.Write("Credentials Ticket: " & Credentials.Ticket)
Dim s As String = ""
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
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
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.