01-15-2014 01:37 AM
We have a clean 8.1 install but the Desktop Integration is failing with a 401 Unauthorsied error (similar error to the other thread on hear, but we've checked Authentication and all fine), if you actually fire the sdata/slx/gcrm/-/$service/registerClient url into a browser, authenticate as the user, the error message we get is;
Solved! Go to Solution.
01-15-2014 04:58 AM
A little more meat (removing sdata portal had no effect), server side error is;
2014-01-15 12:54:15,457 [42] WARN Sage.SalesLogix.Web.SLXWebBasicAuthenticationModule - Unable to authenticate user 'admin'
{
"date": "2014-01-15T12:54:15",
"utc": "2014-01-15T12:54:15",
"stackTrace": " at Sage.Platform.Diagnostics.ErrorHelper.LogEvent(ILog log, EventLogEntryType entryType, String message, UInt16 eventId, Exception exception, Boolean debug)\r\n at Sage.SalesLogix.Web.SLXWebBasicAuthenticationModule.AcceptCredentials(HttpApplication application, UserInformation information, IDictionary`2 authValues)\r\n at Sage.Integration.Web.BaseAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs e)\r\n at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()\r\n at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)\r\n at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)\r\n at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)\r\n at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)\r\n at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)\r\n at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)\r\n at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)\r\n at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)\r\n at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)\r\n",
"hashCode": "C06BDD2C-F9CF4FC3-433E1775",
"pid": 4504,
"identity": {
"name": "",
"isAuthenticated": false,
"authenticationType": ""
},
"version": "8.1.0.1146",
"logger": {
"level": "WARN",
"location": "?",
"name": "Sage.SalesLogix.Web.SLXWebBasicAuthenticationModule",
"message": "Unable to authenticate user 'admin'"
},
"request": {
"looksLikeAjax": false,
"isLocal": false,
"method": "POST",
"url": "http://INSERTHOSTNAMEHERE!:3333/sdata/slx/gcrm/-/$service/registerClient",
"referrer": "",
"ipAddress": "192.168.0.144",
"userAgent": "Sage",
"userLanguages": ""
},
"browser": {
"type": "Unknown",
"name": "Unknown",
"version": "0.0",
"majorVersion": 0,
"minorVersion": 0.0,
"platform": "Unknown"
},
"server": {
"host": {
"siteName": "Saleslogix",
"applicationId": "/LM/W3SVC/3/ROOT/sdata",
"applicationPhysicalPath": "C:\\inetpub\\saleslogix\\sdata\\",
"applicationVirtualPath": "/sdata"
}
}
}
01-15-2014 10:46 AM
Sorry to keep replying to my own post but hoping to prod someone into a genius moment!
Looking at the IIS logs (Note that port 3333 and 443 are bound to the same site so the same sdata portal below), what's confusing me is when the Outlook Connector (which works) connects I see something like;
014-01-15 07:18:39 192.168.0.36 POST /sdata/slx/gcrm/-/$service/registerClient - 443 - 192.168.0.144 Saleslogix+Outlook+Connector+WinHTTP+Agent/1.0 - 401 0 0 3 2014-01-15 07:18:39 192.168.0.36 POST /sdata/slx/gcrm/-/$service/registerClient - 443 andy 192.168.0.144 Saleslogix+Outlook+Connector+WinHTTP+Agent/1.0 - 201 0 0 573
So a 401 at first, then an immediate retry with my username which authenticates, and I assume a 'session' as such is created. tey for the Desktop Manager I see;
2014-01-15 08:46:03 192.168.0.36 POST /sdata/slx/gcrm/-/$service/registerClient - 3333 - 192.168.0.48 Sage - 401 0 0 1 2014-01-15 08:46:03 192.168.0.36 POST /sdata/slx/gcrm/-/$service/registerClient - 3333 - 192.168.0.48 Sage - 401 0 0 661
As if the Client is not sending the username / password combo on the second attempt - or is that just because I'm clicking 'test' in the Desktop Manager settgings as opposed to a real session and it interacts differantly?
Conversley, on the Eval Deployment, same client, I get;
2014-01-15 07:41:40 192.168.0.36 POST /sdata/slx/gcrm/-/$service/registerClient - 3334 - 192.168.0.144 Sage - 401 0 0 1757 2014-01-15 07:41:49 192.168.0.36 POST /sdata/slx/gcrm/-/$service/registerClient - 3334 admin 192.168.0.144 Sage - 201 0 0 9257
So the Test button has sent the user in the second request - am beyond confused!
01-16-2014 07:49 AM
Andy,
Just to make sure I am clear on a few things:
1. You have the site deployed for your database
2. From Desktop manager you are failing to test connect (401 error)
3. From within Outlook you are able to test the connection and it works correctly?
4. If you restore an eval database and build/deploy to another site (or portal) this one works correctly.
The error would indicate an authentication issue. Possibly with how Windows authentication is configured.
Are you using Windows Authentication?
Do you have the admin user mapped to a network user? Is the user andy also mapped?
You stated you deleted the portal and redeployed. Did you delete the portal in IIS and also from the drive, then redeploy? You might try comparing the site/portal settings between the one that is working and not working.
I will investigate further on my end as well with the errors you have provided.
Thank you
01-16-2014 09:24 AM
Hi, Thanks for replying, and yes your 4 points were correct. No we're not using Windows Authentication, and yes the WebDLL user is mapped to the Admind user (also set as the Application Pool Identity etc, etc). And Yes I delete the portal entirely in IIS and redeployed.
When I compared the two sdata folders the file count was the same, but a slight difference in file size. I agree that authentication behind the scenes seems the obvious answer, but for all intents and purposes that sdata portal works for all other functions, it's an odd one :-/
01-31-2014 06:19 AM
Did you make any headway on this issue? I am experiencing the exact same issue.
Thanks ~ Chad
01-31-2014 07:18 AM
No, none as yet. I have an open ticket with support and they've suggested a few things, but heard no more in the last week :-/
02-06-2014 02:46 PM
02-06-2014 03:03 PM
02-07-2014 04:55 AM
I love simple solutions, but that's ridiculous - fixed, in working terms, basically the Test button doesn't work anywhere near as expected. Type in the correct details, click OK, and *actually* test and it works a treat, ridiculous!