it tries to connect to autodiscover.domain.com:443 which is correctly setup with a cname for autodiscover.outlook.com but fails, tries to connect on port 80 which providers a redirect to autodiscover-s.outlook.com but doesn't seem to follow that and EWS fails, no contacts are added, and the ones I add manually show up as offline.
But, if I set the autodiscover.domain.com cname to autodiscover-s.outlook.com, contacts that I add manually show the correct status, but contacts are not automatically added.
I created the debug log, but did not want to attach it since I couldn't find the base64 field that we are supposed to remove when following the directions in the FAQ. Here is a portion of it though.
Sorry, but I fail to see any error on SIPE's or libpurple's part in your log. It shows:
(10:08:47) dnsquery: Performing DNS lookup for autodiscover.domain.com
(10:08:47) dnsquery: IP resolved for autodiscover.domain.com
(10:08:47) proxy: Attempting connection to 18.104.22.168
which reverse resolves to autodiscover.outlook.com. Those servers don't answer on ports 443, that's why the first attempt fails with:
(10:08:46) proxy: Connecting to autodiscover.domain.com:443.
(10:08:46) proxy: Error connecting to autodiscover.domain.com:443 (Connection refused.).
(10:08:46) proxy: Connection attempt failed: Connection refused.
The second attempt to port 80 remains unanswered for 60 seconds:
(10:08:47) proxy: Connecting to autodiscover.domain.com:80.
(10:08:47) proxy: Connected to autodiscover.domain.com:80.
(10:08:47) sipe: sipe_http_transport_connected: autodiscover.domain.com:80
(10:09:47) sipe: sipe_http_transport_drop: dropping connection 'autodiscover.domain.com:80': timeout
(10:09:47) sipe: sipe_http_transport_free: destroying connection 'autodiscover.domain.com:80'
When I compare it to debug log from another Office 365 account, that request on that connection should be answered with a HTTP/1.1 302 Moved Temporarily response, redirecting the request to the real autodiscover server for your domain.
HTTP/1.1 302 Moved Temporarily
Please make sure that your Office 365 setup is correctly configured and that you have no network elements in the path to 22.214.171.124:80 that prevent a correct connection, e.g. a blocker for unauthorized HTTP connections from your intranet to the internet.
Another user reported the same problem in this thread [fc28ad9f].
Using the data from the provided log I can confirm that the reason is not a HTTP connection blocker, because I get the same behaviour from my computer for your domain.
After reading another M$ document I tried one of the things listed as "alternatives" for autodiscover and voilá:
$ wget -S http://autodiscover.<SOMEDOMAIN>/Autodiscover/Autodiscover.xml
--2014-03-30 21:44:24-- http://autodiscover.<SOMEDOMAIN>/Autodiscover/Autodiscover.xml
Resolving autodiscover.<SOMEDOMAIN> (autodiscover.<SOMEDOMAIN>)... 126.96.36.199, 188.8.131.52, 184.108.40.206, ...
Connecting to autodiscover.<SOMEDOMAIN> (autodiscover.<SOMEDOMAIN>)|220.127.116.11|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 302 Moved Temporarily
Location: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml [following]
Tim: as your log is obfuscated, I can't verify if the same is true for your account. It would be nice if you could confirm this.
I'll look into options how to implement this. I think I'll add the GET approach as an alternative if the POST method times out.
I've added the new EWS autodiscover type in commit 04e87de.
Tim & Sparhawk: I've provided a new Windows libsipe.dll in the development area. Please download and retry if this now works for you.
Hi, thanks for update.. I tryed it.. even reinstalled pidgin and sipe plugin etc.. but no change :( here is the log from new version of libsipe.dll.
The log shows that EWS autodiscover works and the buddy list is retrieved correctly. But your server rejects our request for buddy presence information with ms-diagnostics: 4001;reason="XML parse failure";source=.... The XML sent to the server is valid, I verified it with xmllint.
ms-diagnostics: 4001;reason="XML parse failure";source=...
Nothing I can do there.
BTW: Please change your password. You didn't obfuscate the log file as described in the FAQ.
now it is solved.. all I needed to do was added new contact.. now I can see statuses as well.. great work... btw I cant see my pwd in that log.. I deleted it, so it will be ok :)
Yeah, that was one thing I was going to suggest: delete all your contacts and start the buddy list from fresh. AFAIR another user had problems with an incorrectly-to-UCS-migrated contact list too.
Thanks for the feedback, one step closer to next release.
Thanks for checking into this!
I replaced the dll with the file downloaded from the link you provided and restarted Pidgin. I have not had the time to watch logs, but so far it does seem to have fixed part of the problem.
I can now see user status, and it even updated my contact photos.
I'm still having to manually add users though. It isn't automatically updating the contact list or groups.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.