%Exchange install drive%\Microsoft\Exchange server\V15\Logging\OWA\InstantMessaging I checked the logging file location on the Exchange Server for OWA Instant Messaging in the following directory I apologize for such a long writeup, but given that despite my hours and hours and hours spent over months of researching the issue, I hope to provide as much useful and helpful information as possible for any future Googlers/Bingers/DuckDuckGoers/etc.Had an issue recently where OWA integration with Exchange 2013 and Skype for Business was not working and users were failing to sign into IM when using OWA. The only way I've found to date, to use SfB on anything less than 10.12.x, is to essentially MITM yourself, using a proxy application, such as Charles, which will create its own fake certificate which you must trust, to connect. Unfortunately, at this time, there doesn't appear to be a way to wedge in support for 512 algorithms in OSX, and that includes forcibly upgrading/linking openssl. So while browsers and everything else shows that, yes, the certificate is good, valid, unexpired, etc, the low level network stack in OSX, which is used by SfB to initially connect, does not, so it cannot validate that the certificate is valid, thus causing this issue. OS X prior to 10.12 (Sierra) does not *natively* support 512 bit certificate signatures. If on that line, you have something similar to "SHA-512 with RSA Encryption" (forget about the long number afterward), then that is the source of the issue with logging on, and also, activating Office 365 (if you have a company account for it). Expand the "Details" section in that lower pane, and look for the "Signature Algorithm" line, which should be, roughly, the 12th one down. The bottom pane should show some brief certificate info (Issued by, Expires, "This certificate is valid" type message, etc.). Make sure that the selected certificate, in the tree view at the top, is the bottom-most one. Once there, click on the lock to the left of the address in the address bar and click the "Show Certificate" button. When you get the host name, for example, "", go to that address via HTTPS in Safari. This may require getting IT involved to find it, or reviewing the SfB logs. If that matches up, the next step is to check the certificate which is on domain's federation services (ADFS) host. * When signing in with the AD account, you are either a) Given a choice between "Work or school account" or "Personal account), b) usually automatically redirected to the company branded signon page. * Corporate domain is on Azure AD (Active Directory) * Skype for Business 2016 (any version, including latest in the insider "Fast Ring" releases) To be certain it's the same, or similar-enough issue, here's the setup I've been working with (or against it seems): I've been having this issue for quite some time as well, and have been working with a Microsoft Skype for Business (SfB) support engineer on it.
I have users that use MAC Mail for a client and also Outlook for MAC 2016 as a client - the back-end is an Exchange server but I am uncertain as to which version - I think it's Exchange 2012 but I cannot say for sure. My question is has anyone heard of anything that has changed that prevents MAC computers from authenticating to a Skype/Lync back-end?
These credentials are the same that DO authenticate when a user logs on to their computer and email, so I know the network cred is valid. I then installed Skype for Business on my iMAC and a few other MACs (iMAC & MACBook) but Skype is having the same problem as Lync in that no credentials will authenticate. In essence: anything MAC no longer connects to Lync. As new computers have been deployed many of them have no longer been able to authenticate to Lync and even the ones that used to work no longer work. I have run into an issue and wonder if anyone else has seen this or heard of it: about 6 months ago I had a bunch of iMACS using Lync successfully.
0 kommentar(er)
