none
No better way to have chat history? RRS feed

  • Question

  • Lync/Skype for Business is a pretty nice collaboratoin tool, even though it's quite complicated in handling in some situations. But there is one feature which I am realy disappointed of, it's about chat history. Despite audio, vidoe or screen sharing features, I would say that chat is still the most used communicatin channel. In my opinion it's not feasable how SfB deals which chat history. I will list issues I encounter with this, maybe some is because of wrong configuration, or I do not know how to deal with it:
    - Ok, I can save all my chats in Outlook recorded conversations folder. I have to say, this is more then nothing, but far not a good approach. What if I now and than run the client on a mobile device, or on a computer which has no Outlook, at least not one configured with my profile, like business notebook vs. private notebook? I assume I will loose some of the conversations.
    - From what I could figure out, if I do some conversation with someone, close that window for a while, but the conversation continues after some time again, not just that I have lost the prevsious conversation thread within my chat window, but also I get at least two such conversation saving emails. In some situations I even get three or more, it's lots of weird emails, partially with the same content....
    - from what I know it's not possible at whole to send kind of an offline chat. For example in such a way that the server keeps the chat for a certain amount of time and delivers it once the recipient goes online again. OK, there is the chat rooms functionality, this is nice but it does not solve the issue.
    - in the conversations tab of the client I never have had a single entry, do not know whether this is a configuration issue or how it is supposed to work.

    Is there really on better option to save chat history but this dump emails creation thing?

    kind regards,
    Dieter Tontsch
    mobileX AG
    Wednesday, October 21, 2015 10:29 AM

Answers

  • Hi Dieter,

    Conversation history is saved with the Exchange server since early versions of Lync\OCS.
    If you don't have an Outlook client, Lync\S4B wold use your Exchange EWS directories to save and retrieve conversation history.

    You can see this when you check the clients' Configuration Information. It should say:
    EWS Information: EWS Status OK.
    This means that the clients can communicate with Exchange directly.

    If you don't see anything on your client's Conversations tab this could indicate a possible configuration issue, but you might also disabled that via the client policy.

    Additionally, on Skype for Business, you can now save conversation history on the server.

    See these links for additional info:

    https://technet.microsoft.com/en-us/library/gg398300.aspx

    https://technet.microsoft.com/EN-US/library/dn985897.aspx

    Wednesday, October 21, 2015 10:49 AM
  • Hi Dieter,

    Lync and S4B clients use the same discovery process as Outlook clients, however, they can't read the users' AD attributes so they completely rely on the Autodiscover process.

    The reason you're getting Conversation History to your Outlook is your MAPI connection, but you lose that if you have no Outlook installed on that machine or if you're working from another computer.

    The best way to resolve this would be to first confirm your EWS directories are configured correct. This is critical for all S4B-Integration scenarios.

    For the S4B clients to communicate directly with your Exchange server, add an Autodiscover.domain.com DNS A record if you don't have one already. You'll also have to confirm the certificate on your Exchange server have the Autodisocver SAN. You don't have to enable Outlook Anywhere for this to work.

    Once you complete this configuration your clients will be able to communicate with the EWS directories and retrieve the required information.

    Hope this helps.

    Wednesday, October 21, 2015 6:06 PM

All replies

  • Hi Dieter,

    Conversation history is saved with the Exchange server since early versions of Lync\OCS.
    If you don't have an Outlook client, Lync\S4B wold use your Exchange EWS directories to save and retrieve conversation history.

    You can see this when you check the clients' Configuration Information. It should say:
    EWS Information: EWS Status OK.
    This means that the clients can communicate with Exchange directly.

    If you don't see anything on your client's Conversations tab this could indicate a possible configuration issue, but you might also disabled that via the client policy.

    Additionally, on Skype for Business, you can now save conversation history on the server.

    See these links for additional info:

    https://technet.microsoft.com/en-us/library/gg398300.aspx

    https://technet.microsoft.com/EN-US/library/dn985897.aspx

    Wednesday, October 21, 2015 10:49 AM
  • Hi Yoav,

    thanks for that. EWS seems to not be correctly configured with our Skype since I get the following:

    Interne EWS-URL;;--;
    Externe EWS-URL;;--;
    EWS-Informationen;;EWS wurde nicht vollständig initialisiert

    .;

    Sorry, it#s German, but the EWS-Information status says something like EWS was not fully initialized.

    However, EWS as itself works for our Exchange, I can browse https://mailserver-url/EWS/Exchange.asmx, I get a login prompt and after that I see Services.wsdl xml output in the browser. Also, we use EWS for Dynamics CRM Email Router autmated Email-Archiving from Exchagne inbox to Dynamics CRM... 

    Also, my chat history is saved into my Exchange Inbox folder... Any idea what's wrong, Is there a place in Skype for Business where I need to configure EWS internal and external URL? Or do I miss some DNS setting?

    We run Exchange 2010 SP3.

    cheers,

    Dieter

    Wednesday, October 21, 2015 4:11 PM
  • Hi Dieter,

    Lync and S4B clients use the same discovery process as Outlook clients, however, they can't read the users' AD attributes so they completely rely on the Autodiscover process.

    The reason you're getting Conversation History to your Outlook is your MAPI connection, but you lose that if you have no Outlook installed on that machine or if you're working from another computer.

    The best way to resolve this would be to first confirm your EWS directories are configured correct. This is critical for all S4B-Integration scenarios.

    For the S4B clients to communicate directly with your Exchange server, add an Autodiscover.domain.com DNS A record if you don't have one already. You'll also have to confirm the certificate on your Exchange server have the Autodisocver SAN. You don't have to enable Outlook Anywhere for this to work.

    Once you complete this configuration your clients will be able to communicate with the EWS directories and retrieve the required information.

    Hope this helps.

    Wednesday, October 21, 2015 6:06 PM
  • It looks like we still have issues with AutoDiscover and SfB, even though I have double-checked my configuration by following these articles http://lyncuc.blogspot.ca/2013/01/lync-and-exchange-web-services-ews-and.html and http://lyncvoice.blogspot.in/2015/01/troubleshooting-ews-issues-in-lync-2013.html. We run Exchange 2010 Sp3 on-permise.

    I have all three DNS entries in internal and external DSN as well (however, I only talk about internal access yet:
    autodiscover.domain.name CNAME exchangeserver(CAS)
    _autodiscover._tcp.domain.name SRV 0 0 443 exchangeserver(CAS)
    ewsurl.domain.name A exchangeserver (CAS)

    I also can access https://<smtpdomain>/autodiscover/autodiscover.xml and https://EWSURL/ews/exchange.asmx which then redirects me to https://EWSURL/ews/Services.wsdl as described unter troubeshooting sectoin in http://lyncuc.blogspot.ca/2013/01/lync-and-exchange-web-services-ews-and.html

    But in SfB client I still get:
    Interne EWS-URL;;--;
    Externe EWS-URL;;--;
    EWS-Informationen;;EWS not deployed;

    Get-AutodiscoverVirtualDirectory in Exchange PowerShell gives me:
    [PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory |fl
    RunspaceId                      : a6ec0b1b-0c4d-4081-a297-4d3f161fd0f2
    Name                            : Autodiscover (Default Web Site)
    InternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
    ExternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
    LiveIdSpNegoAuthentication      : False
    WSSecurityAuthentication        : True
    LiveIdBasicAuthentication       : False
    BasicAuthentication             : True
    DigestAuthentication            : False
    WindowsAuthentication           : True
    MetabasePath                    : IIS://EX1.mobileX.intra/W3SVC/1/ROOT/Autodiscover
    Path                            : C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover
    ExtendedProtectionTokenChecking : None
    ExtendedProtectionFlags         : {}
    ExtendedProtectionSPNList       : {}
    Server                          : EX1
    InternalUrl                     : https://ex1.mobilex.intra/autodiscover/autodiscover.xml
    ExternalUrl                     : https://mailgate.mobilexag.net/autodiscover/autodiscover.xml


    We do connect via MAPI to Outlook, but this is not the best approach as I was told.
    Any ideas what can be still wrong?

    We are talking about the domain mobilexag.de - everthing should be published correct via DNS

    kind regards,
    Dieter Tontsch
    mobileX AG
    Thursday, October 22, 2015 11:58 AM
  • Hi Dieter,

    Have you any logs from the client? This could be a proxy issue (if you're using one), and if your autodiscover A record points to an external IP address it might be unreachable.

    I'd recommend sing a tool like Fiddler to collect the client logs and examine them to see any errors.

    Thursday, October 22, 2015 12:15 PM
  • Thanks,

    unfortunatelly we neither use a proxy, nor does the autodiscover point to an unreachable IP. 

    I will dig further, thanks.

    But I am asking myself why is there URLS empty and EWS not deployed. One thin is that the EWS (and autodiscover URL) might not be reachable, but another thing is the provisioning of the URL itself. Where does this come?

    Dieter

    Thursday, October 22, 2015 12:44 PM
  • Finally we used fiddler to figure out that by some reason autodiscover only supported http get, but no post. Since this is  a SOAP request, it was http post. We have recreated the autodiscover virtual direcotry in IIS and now it works fine with EWS /Autodiscover.

    Thanks, Dieter


    Sunday, October 25, 2015 4:35 PM