![如何解决 Exchange 的自动发现 (xml) 以及任何特殊客户端（如具有复杂 DNS 配置的 Windows 通信应用程序 [HxTsr.exe]）的问题？](https://linux22.com/image/769669/%E5%A6%82%E4%BD%95%E8%A7%A3%E5%86%B3%20Exchange%20%E7%9A%84%E8%87%AA%E5%8A%A8%E5%8F%91%E7%8E%B0%20(xml)%20%E4%BB%A5%E5%8F%8A%E4%BB%BB%E4%BD%95%E7%89%B9%E6%AE%8A%E5%AE%A2%E6%88%B7%E7%AB%AF%EF%BC%88%E5%A6%82%E5%85%B7%E6%9C%89%E5%A4%8D%E6%9D%82%20DNS%20%E9%85%8D%E7%BD%AE%E7%9A%84%20Windows%20%E9%80%9A%E4%BF%A1%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%20%5BHxTsr.exe%5D%EF%BC%89%E7%9A%84%E9%97%AE%E9%A2%98%EF%BC%9F.png)
对于搜索引擎来说，上下文元素：
- Exchange 在线
- Office 365 / Microsoft 365 --> 特定 Outlook --> outlook.office.com
- Windows 的邮件和日历应用程序 [HxTsr.exe，“microsoft.windowscommunicationsapps”]
- Apex 域名重定向至 www.~
- Cloudflare DNS
- 使用 Cloudflare 工作者
- HSTS，也适用于子域名
- [Azure] 条件访问正在阻止旧式身份验证方法。（“基本身份验证”。）
- autodiscover.domain.tld 的 cname 已针对 autodiscover.outlook.com 配置。正如预期的那样，Cloudflare 的技巧已针对此记录禁用。
- Cloudflare 为大多数域名提供 SSL，除了 autodiscover.domain.tld。
现在不良行为：
在这种情况下，自动发现功能不适用于“windowscommunicationsapps”，此后称为“问题客户端”或“客户端”。它适用于最新的 Windows 版 Outlook，这很可能是因为更现代的内置自动发现方法跳过了传统的自动发现方法。
有问题的客户端会加载并提示输入基本身份验证密码，然后提示输入用户名和域，然后显示错误，并可以选择转到高级并再次输入所有内容，包括服务器。之后，在我记得以服务器身份输入后outlook.office365.com，它会提示用户使用 Microsoft 的现代身份验证窗口。
出了什么问题：
客户端尝试检索https://rootdomain.tld/autodiscover/autodiscover.xml。（在 cloudflare 防火墙的日志中看到。）
它被重定向到https://www.rootdomain.tld/autodiscover/autodiscover.xml。（见于MS 的工具。
由于 Cloudflare 工作器的配置复杂，客户端最初并未收到 404 错误。它只是不断地加载。在变体配置中，专用的 Cloudflare 工作器返回了 404 页面；它并未解决问题。
问题是发生了太多事情。
- http 被重定向到 https。
- 根（顶点）已重定向至www.domain.tld/$1和
- autodiscover.~ 应该解析为 autodiscover.outlook.com，但由于某种原因未提供 xml。（Microsoft 的工具向我显示了：
测试主机 autodiscover.juramento.nl 上的 TCP 端口 443，以确保其正在监听并打开。
指定的端口可能被阻止、未在监听或者未产生预期的响应。
- 自动发现任务的下一步是在 autodiscover.domain.tld 上寻找重定向，并找到了
https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
假设有问题的客户端还没有走到这一步，并且过早放弃了自动发现任务。我不确定 autodiscover.domiain.tld:443 处的 GET 请求是否应该为 Exchange Online 发送错误，但重定向按预期工作，并且一旦 Microsoft 的工具发现https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml一切正常，直到由于条件访问中阻止了旧式身份验证方法而导致预期的基础身份验证错误。
问题：
- 为什么该客户端无法快速连接到Exchange / Office 365？
- 为什么这个客户端要求进行基本身份验证？
- 为什么自动发现对该域不起作用？
- 自动发现实际上一步步做了什么？
- 我们可以做些什么来缩短自动发现步骤并帮助原来有问题的客户？
- 我该怎么做才能快速修复 Exchange Online 的自动发现问题？
答案1
尖端
- 请创建一个额外的测试帐户。
- 使用https://testconnectivity.microsoft.com/tests/Eas/input作为健全性检查。
- 这次测试https://testconnectivity.microsoft.com/tests/O365Eas/input比较聪明，但并没有模仿问题客户的行为。
解决方案
我使用了 Cloudflare DNS，添加了转发规则来转发这个特定的不存在的资源：
https://apexdomain.tld/autodiscover/autodiscover.xml
到
https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
这大大缩短了自动发现链。（经微软工具确认。）因此，它还限制了可能出错的事情的数量。
有问题的客户端现在可以根据需要非常快速地显示现代身份验证窗口。
笔记
- 我禁用了 Cloud Worker 为 发送 404 错误
https://apexdomain.tld/autodiscover/autodiscover.xml，尽管我让它继续工作，https://www.domain.tld/autodiscover/autodiscover.xml尽管我再也看不到到达那里的链了。访问此 URI 的唯一原因是由于 www. 转发规则的顶点。所以我刚刚发现它也可以删除此路由 ;)，但对于测试用例的记录，它在测试期间一直处于活动状态。 - 我不知道 Cloudflare 规则是否优先于 Cloudflare Worker 路由。无论如何，您都应该将它们配置为异或。
我发现自动发现的复杂性很麻烦。很多事情都可能出错。讽刺的是，自动发现机制非常复杂，人们可以创建自动发现的自动发现配置来自动加载要加载的位置开始特定域的自动发现。:/
- 就在发帖之前，我在自动搜索框中找到了一条参考关注帖子。创意楼主也遇到过类似问题，包括443端口错误，解决办法也类似，只是位置不同（反向代理）。
令我困惑的是，该帖子没有出现在我的谷歌搜索结果中，但我很高兴看到我们的一些观察和解决方案重叠。^^
来源
https://practical365.com/fixing-autodiscover-root-domain-lookup-issues-mobile-devices/
相关阅读：