As we got into the trial we found some users with Outlook 2013 had single sign on (NTLM) while others were prompted for authentication. This also effected Lync as the UCMAPI service connects to Exchange via Outlook, so Lync was also prompting for credentials when the user logged in. While a password prompt is acceptable for external use, we were not happy with this for internal devices.
Clients that were prompted for authentication were able to single sign on to rpcproxy and EWS with Internet Explorer, so the problem didn't seem server based.
Hours were invested trying to resolve this problem, so of the fixes we attempted were:
- Packet tracing
- IIS log tracing
- Re-creating RPC and EWS directories
- Changing authentication in the Outlook client
- Changing authentication on exchange virtual directories
- Changing IIS authentication
- Adding exchange domains to local intranet zone in Internet Explorer
- Bypassing load balancers
- Client based registry hacks
- Client application re-installation
The Resolution
We were nearly at the point of building a second Exchange environment for testing when we made a breakthrough, I almost feel embarrassed admitting the problem, group policy.
Our legacy Exchange 2010 group policy was set up for RPC internally and https Outlook Anywhere externally, however we never set the MSSTD field, in fact we implicitly removed it with GPO.
As soon as we set the MSSTD field to one of the SAN names of the certificate (wildcards certificates are also fine), the Outlook client single sign on worked perfected and Lync stopped asking for authentication on sign in.
Hopefully you don't waste as much time as we did on this problem.
lll▷bet365 - Thakasino
ReplyDeleteBet365. bet365: The world's favourite online sports william hill betting company. The most comprehensive In-Play service. Watch Live Sport. Live bet365 Streaming available on 메리트카지노 desktop,