Contacts not showing up with the latest Office365 that is currently being rolled out. log file -> http://pastebin.com/g3b6LfrX
Ticket moved from /p/sipe/bugs/199/
Can't be converted:
Your Lync contact list on the server is empty:
<contactList deltaNum="1" ucsMode="migrated" >
My guess the reason can be seen from this error message in the log:
MESSAGE START <<<<<<<<<< SIP - 2013-06-17T14:22:58.043381Z
SIP/2.0 403 Forbidden
CSeq: 1 SERVICE
ms-diagnostics: 2164;reason="Contact list is read only as the contact list is being migrated or has migrated to Exchange.";source="BL20B04FES03.infra.lync.com"
Supporting Lync contact list stored on Exchange would be a new feature (moved from bugs to feature requests). I have no idea if it is documented by M$, so the schedule for a possible implementation is unknown.
BTW: your Useragent string has a copy & paste error and is still pointing to a Lync 2010 client:
User-Agent: CCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
FYI: according to this you could ask your IT that UCS to be disabled for your user account.
MSDN documentation link: Unified Contact Store in EWS in Exchange 2013
Oops sorry. Didnt notice the response. I will talk with the admin and see if we can get that enabled.
Alright after a vacation I worked on this a little more. We kept trying to get the command to work and continued to get an odd error message. After looking that up, we found the info stating that it only works on the on-prem Lync. We are using office 365. :/ thoughts?
In my Office 365 test account UCS is disabled. I couldn't find any option in the Web Admin UI to enable it. WhSo my guess that the feature is enabled automatically for Office 365 installations with a certain amount of users. Probably only M$ can disable it for your installations.
Which brings us to the interesting question: would your organization be willing to provide a test account in your installation, so that the SIPE project can implement this feature?
Hmmmm I am assuming that this would be a generic user account with no special access correct?
Yes, no special access required, except Office 365 and Exchange/EWS (where UCS data is stored). Of course I would need to be able to add/remove some buddies from your organization, e.g. you provide me a fixed list, so that I don't accidentally bother some stranger :-)
This same issue just struck me this week. It might be due to some rolling deployment to O365 customers, but it strikes me as a pretty big coincidence that it happened pretty much immediately after my Office 2013 Preview expired and I had to uninstall it and install the RTM version... Could launching RTM of Outlook 2013 and/or Lync 2013 (of which the Preview wasn't ever working and would always stall when I launched it, but the RTM works) have flipped some bit on the server I wonder?
While the test account still hasn't UCS enabled, I have been scratching my head why EWS autodiscover didn't work for it. It turned out that it (probably) never worked for Office 365 accounts, because a different autodiscover URL is used.
git commit 43b1ae4 has all the changes required to make this work, i.e. calendar information is now published also for Office 365 accounts.
The calendar part now works great. Watched it turn to busy, and watched the debug output. Well done. Now are we jut waiting for your account to turn UCS on correct?
Yes. But EWS is required for UCS, so we have this already out of the way.
BTW: it might be good idea not to use the reply button in the mailer to answer ticket update mails :-)
SOB! Thanks. I cant believe I did that.
Can you log into OWA with your test account and see if you have the upgrade yet. That is a clear indicator if your account has been upgraded.
It is confirmed now: sign-in with Lync 2013 triggers the migration (my guess: undocumented feature). Once this has been completed Lync 2013 client asks user to sign out and sign back in, because of "sysadmin changes affecting your Contact List". At the same time I could see my buddy list contents appearing on the Office 365 web interface.
Well account is migrated and I have something to test against.
With git commit 0f5cb72 the existing buddies show up correctly again. You won't be able to modify the list yet.
I found out from the log that in the UCS migrated case the server does send an empty list first and then immediately sends a NOTIFY with the real list. By skipping the first list and instead processing the second one the basic functionality started to work again.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.