[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 260
  • Last Modified:

Lync 2010 autodicover and EWS problem

¿my primary domain is domain1.com, which is used for both SMTP and SIP address.
everything in Lync has been working ok, including MAPI and EWS connection to Exchange.
Long story short, we have  few users need to use different SMTP address as primary (domain2.com)

Since it's only a few users, I don't like do too much changes in system such as introducing new domain, etc.
These users have primary SMTP address of user@domain2.com, secondary SMTP user@domain1.com, and SIP address user@domain1.com.

All good, except I cannot get the EWS to work, getting error 'EWS Not Deployed' on Configufation info.
Have tried quite a few things including DisableEmailComparison check on client side (via registry key) and also server side (using Set-CsClientPolicy).
Since everything is already working for other "normal" users who has matching SMTP and SIP address, I don't think solution like "Set-organizationConfig -EwsEnabled $true - EwsApplicationAccessPolicy EnforceBlockList" will help.

I also created a host file to point autodiscover.domain2.com to the Exchange server, and can open https://autodiscover.domain2.com/autodiscover/autodiscover.xml and https://autodiscover.domain2.com/ews/exchange.asmx, which gives certificate error prompt because we don't have cert installed on the exchange virtual directory for domain2.com
Saying that, I guess configuring autodiscovery SRV record (as suggested on many other threads) won't help.

From the client log .ETL file, I can see this:

<O_TRC><ADR>0x00109168</ADR>HttpSendRequest failed. Server=autodiscover.domain2.com, Path=/autodiscover/autodiscover.xml</O_TRC>
<O_TRC><ADR>0x00000000</ADR>GetServerCert failed with 0x80072f06</O_TRC>
<O_TRC><ADR>0x0328F800</ADR>Server is autodiscover.domain2.com not trusted, hr=0x80072f06.</O_TRC>

Looks like the certificate is what causing the issue?
I can think of 2 possible solutins:
a. forcing Exchange autodiscover and EWS to support http
b. create new virtual directory on Exchange for domain2, and have cert installed.

However, I tried not to change anything on the Exchange side. Since this is only 3-4 users we are talking about, I don't mind if I have to manually configure something on the client side.
Can you think of any other solution or work around? Or please let me know if my analysis above is incorrect and I may have missed something.
1 Solution
Simon Butler (Sembee)ConsultantCommented:
If you are getting an SSL prompt, that will stop everything else from working as it cannot cope.
The easist solution would be to add autodiscover for the second domain to the SSL certificate.

If this is just for internal traffic, then you should be able to modify the DNS and lync configuration to use the name on the SSL certificate.

Cliff GaliherCommented:
Multiple exchange domains means a UCC/SAN certificate. It is one of the few times this is required no generally I feel people recommend them more than necessary, but this is a rare exception. Replace your certificate and your problem will clear right up.
william_pAuthor Commented:
yes agree. replacing the cert, problem solved. should be as simple as that, but unfortunately what i was looking for is a way to do it differently.

what i am currently doing is:
1. on client, using host file, point autodiscover.domain2.com to a reverse proxy server
2. on reverse proxy, install cert for autodiscover.domain2.com issued by our internal CA and publish a rule for autodiscover.domain2.com, and forwarding to the CAS server. CAS server trusts the internal CA.

and now i can see Lync shows EWS status ok, and found the EWS URL!
I'll do some more test.
Seth SimmonsSr. Systems AdministratorCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.

Featured Post

Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now