Dynamics 365本地部署实战：v9.0从环境准备到故障排查

1. 项目背景：为什么还要折腾 Dynamics 365 本地部署

我去年经手了一个 Dynamics 365 On-Premise v9.0 的部署项目。说起来也挺有意思，现在大部分企业都在往云端走，微软主推的也是 Dynamics 365 Online，但偏偏还有一批客户因为数据主权、合规审计、内网隔离等原因，必须把系统放在自己的服务器上。于是 Dynamics 365 On-Premise Server v9.0 就成了一个绕不开的选择。

作为实施顾问和 IT 管理员，如果你接到的任务是“在现有内网环境里把 Dynamics 365 跑起来”，那么这篇部署体验对你应该是很有价值的。它不是一份官方的安装手册，而是我把整个部署过程从头到尾走了一遍之后，把关键步骤、踩过的坑、排查思路都整理出来的实战记录。

先简单交代一下这套系统能做什么：Dynamics 365 v9.0 是微软在 2016 年底到 2017 年间推出的企业级业务管理平台的重要版本，On-Premise 模式下包含销售、客户服务、现场服务等核心模块，数据全部保存在企业自有的 SQL Server 数据库中。v9.0 最明显的变化是引入了 Unified Interface（统一接口），在 PC、平板和手机上都能有不错的浏览体验，同时后台使用了更现代的 Web 资源体系，开发方式也比老版本简洁。对我来说，v9.0 的本地部署像是微软给企业自建机房保留了最后一条完整的产品线，后续 v9.1 虽然也有 On-Premise，但 v9.0 作为很多企业验证本地化能力的起点，至今仍有大量存量部署。

适合什么人看？如果你是第一次部署 Dynamics 365 On-Premise 的实施工程师，或者你正在评估本地部署需要什么样的环境和成本，又或者你已经部署到一半遇到报错想找排查思路，那这篇内容基本覆盖了你会碰到的绝大部分问题。

2. 部署前必须搞定的三件事：软硬件、账户、网络

开始部署之前，我强烈建议先别急着把安装包点开。Dynamics 365 On-Premise 不是一个“下一步安装”就能完事的软件，它的部署链条很长，数据库、IIS、报告服务、异步服务、邮件路由器等每一个环节都是独立的子系统，任何一个前置条件不满足，安装向导都可能在最后一步给你一个莫名其妙的失败。规划这个阶段做得越细，后面越省心。

2.1 硬件配置与软件版本匹配：照着这张表准备不出错

我这次部署用的是单服务器架构，也就是把 Dynamics 365 前端、后端、SQL Server、报表服务都放在同一台物理服务器上。这种架构适合测试环境、小规模生产环境或者 PoC（概念验证）项目。如果用户规模上了几百人，我建议拆成多台服务器：一台 Web 前端，一台应用后端，一台 SQL Server，再加上报表服务器。

先看硬件。官方给出的最低配置比较保守，只有 8GB 内存，但实际跑起来你会发现，SQL Server 自己就会吃掉大半内存，Dynamics 的异步服务、IIS 工作进程再加上报表服务，8GB 根本不够用。我这边生产环境的前端服务器给了 16GB，数据库服务器给了 32GB，磁盘用的 SSD 阵列，整体表现从部署到日常使用都还算从容。具体可以参照下表：

磁盘这块我要多说一句：C 盘尽量不要放数据库文件，日志文件和数据库文件也不要挤在同一块盘上，不然等数据量起来以后，IO 竞争会直接反映到用户操作延迟上。

再看软件版本。Dynamics 365 Server v9.0 对底层环境有明确要求，我在部署前整理了一份在真实环境中验证过的组合：

• 操作系统：Windows Server 2016（Windows Server 2012 R2 也可以，但 2016 更稳）
• 数据库：SQL Server 2016 SP2 或 SQL Server 2017
• .NET Framework：4.6.2 以上，我用的是 4.7.2
• Web 服务器：IIS 10（Windows Server 2016 自带）
• 域环境：Active Directory（必须）
• 报告服务：SQL Server Reporting Services（SSRS），随 SQL Server 一起装
• 客户端：Dynamics 365 for Outlook 可选，浏览器端支持 IE11、Edge、Chrome

需要提醒的是，v9.0 对 SQL Server 2019 的支持是在后续累积更新里才逐渐完善的，如果你所在企业已经标准化了 SQL Server 2019，那建议先把 Dynamics 365 的累积更新打到最新，否则创建组织时很容易碰到兼容性报错。我的习惯是：正式部署前先建一台虚拟机跑一遍安装向导，把版本兼容性验证掉，再上生产。

2.2 服务账户设计：部署失败的重灾区

我见过太多部署失败的例子，最后排查下来不是软件问题，而是服务账户没设计好。Dynamics 365 On-Premise 在安装过程中会要求你提供多个服务账户，这些账户的权限、密码策略、委派方式都会直接影响安装结果。

我当时规划的账户清单大概是这样（账户名按企业规范调整）：

对这些账户，有几点必须提前做好：

1. 密码要符合域密码策略，并且记录好下次修改的时间点。不要图省事让所有服务账户共用一个账号，后续想隔离权限的时候会非常痛苦。
2. 所有服务账户必须拥有“作为服务登录”的权限。安装向导理论上会自动配置，但有些域策略默认禁止普通账户作为服务登录，导致服务启动失败。后面第 5 节我会专门讲那个“以一种访问权限不允许的方式做了一个访问”的报错。
3. 如果企业域控制器启用了“密码必须符合复杂性要求”并且还有“定期更换密码”的策略，需要提前评估是否给服务账户开例外，或者在密码到期前有一个明确的变更流程。Dynamics 365 的服务账户密码改起来并不像 IIS 应用池那么简单，涉及部署管理器和多个 Windows 服务，最好提前规划。

2.3 网络、端口与防火墙规划

单服务器部署时，网络规划相对简单，主要关注本机防火墙和 SQL Server 的 TCP/IP 协议。多服务器部署时就要仔细梳理端口了。我常用的端口规划如下：

如果 Web 前端和 SQL Server 不在同一台机器，记得在 SQL Server 的配置管理器里启用 TCP/IP 协议，并在防火墙放行 1433 端口。这里有一个经常被忽略的点：Windows 防火墙默认会拦截 SQL Server 的端口，需要新建入站规则放行，而且要同时放行 1433 和 1434（SQL Browser，用于服务发现）。

域名和证书方面，如果企业有内部的证书服务（AD CS），我建议直接在一开始就申请一张 Web 服务器证书，把 Dynamics 365 的网站绑定 HTTPS。v9.0 在混合内容、跨域访问这些场景下对 HTTPS 的要求更严格。别等到业务上线了再补证书，那时候改绑定会影响所有用户。

3. 环境搭建：域、SQL Server 与 IIS 的准备

规划完成后，就到了动手环节。很多人会直接把 Dynamics 365 的安装包丢到一台裸服务器上开始装，结果装了半小时才发现 IIS 没装、SQL Server 排序规则不对，只能推倒重来。下面我按照顺序把环境准备阶段的关键步骤和细节讲清楚。

3.1 域环境与时间同步：别小看这两件事

Dynamics 365 On-Premise 的完整部署强依赖 Active Directory。倒不是说它不能用工作组的机器，而是安装向导在很多环节会直接调用 AD 来创建服务主体名称（SPN）、配置 Kerberos 委派、识别部署服务账户的权限，没有域环境这些操作都会失败。

服务器加域之后，第一件事就是确认时间同步。Windows 域环境默认会通过域控制器同步时间，但如果服务器开启了错误的 NTP 服务，或者域控制器的默认同步源失效，服务器时间漂移超过 5 分钟，Kerberos 认证就会开始报错，表现症状是：安装向导能跑，但浏览 Dynamics 365 页面时频繁弹登录框，或者异步服务悄悄失效。我排查过这类问题，最后发现是物理服务器的 BIOS 时间不准。别让这种低级错误消耗大半天时间。

3.2 SQL Server 2016 安装与排序规则设置

SQL Server 的安装基本都是走图形向导，但有三个设置会影响 Dynamics 365 的部署：

第一，排序规则（Collation）。Dynamics 365 v9.0 官方推荐的排序规则是 Latin1_General_CI_AI，CI 是大小写不敏感，AI 是重音不敏感。企业如果已经在其他地方用了 Chinese_PRC_CI_AS 之类的排序规则，Dynamics 365 组织数据库会强行要求与配置数据库一致，而且排序规则一旦确定，后期很难改。我建议在 SQL Server 安装时就指定 Latin1_General_CI_AI，可以省去后期切换的麻烦。

第二，身份验证模式。Dynamics 365 的安装向导默认走 Windows 身份验证来连接 SQL Server，但也建议勾选混合模式，因为某些第三方工具、报表组件或开发调试环节会用到 SQL 账号。安装向导在这一步会让你设置 sa 密码，别跟服务账户密码搞混。

第三，全文搜索和 Reporting Services。Dynamics 365 需要 SQL Server 的全文索引能力，安装 SQL Server 时必须勾选“全文和语义提取搜索”功能。同时，SSRS 也要在安装过程中选上，并启动服务。我用的是 SQL Server 2016 SP2，SSRS 是 Native 模式，相对简单。如果你用 SQL Server 2017 及以上，SSRS 默认是 Power BI Report Server 模式，这种模式对 Dynamics 365 v9.0 的兼容性不好，需要在安装时选择 Native 模式。这个坑我见过好几个人踩，这里先给你提个醒。

3.3 IIS 角色与前置组件补全

在 Windows Server 2016 上，用“服务器管理器”添加“Web 服务器（IIS）”角色。默认的 IIS 安装并不包含 Dynamics 365 所需的全部功能，我在部署时勾选的模块包括：

• 常见 HTTP 功能：默认即可
• 运行状况和诊断：HTTP 日志、请求监视器、跟踪
• 性能：静态内容压缩
• 安全性：请求筛选、Windows 身份验证、基本身份验证（视需要）
• 应用程序开发：ASP.NET 4.6/4.7、ISAPI 扩展、ISAPI 筛选器、.NET 扩展性
• 管理工具：IIS 管理控制台

另外一个必须单独安装的组件是 Web Deploy（Web 部署工具），它用于 Dynamics 365 安装程序发布网站和同步内容。如果没装，安装程序在配置 Web Site 那一步会报“无法找到 Web Deploy”之类的错误。可以在微软官网下载 Web Deploy 3.6，装完以后重启一下服务器，确保环境变量生效。

.NET Framework 4.7.2 我也在 IIS 安装之前就装好了。Dynamics 365 v9.0 的很多代码基于 .NET Framework 4.x 运行，旧版本 4.5/4.6 可能会在部署过程中报“此程序集由比当前加载的运行时更新的运行时生成”的错误。这四个环境准备步骤做完，再用安装向导自带的环境检测，通常就能顺利通过了。

4. Dynamics 365 Server v9.0 安装与组织部署

环境准备得差不多以后，真正的高潮来了：安装 Dynamics 365 Server 本身并创建组织。这一步我会按实际操作顺序来写，尽量把每一步背后的原因也讲明白，这样你在下次遇到类似问题时能更快定位。

4.1 安装向导逐步拆解

把 Dynamics 365 Server v9.0 的安装 ISO 挂载后，进入 Server 目录，选择对应架构的 SetupServer.exe（默认是 amd64）。这里不建议用根目录的自动运行程序，直接进 Server 目录启动，可以少踩一些“组件缺失”的坑。

安装向导的第一步是接受许可协议，然后要求输入产品密钥。企业采购的许可证可以在经销商渠道或 Microsoft 365 管理门户中查到这个密钥。如果没有密钥也可以先用试用密钥跑通流程，但是要注意试用和正式的部署数据库在后续升级时可能涉及许可转换，建议在测试环境单独验证。

接着选择安装位置和功能组件。向导会列出以下主要组件：

• Dynamics 365 Server：核心服务器组件，包含 Web 应用和部署工具，必须勾选
• 部署工具：提供 PowerShell 模块和命令行工具，建议勾选
• Reporting Extensions：如果要在报表服务器上安装报表扩展，需要单独勾选

选择服务账户的环节是整个向导里最需要小心的。向导会让你填写“应用程序池账户”“异步服务账户”“沙盒服务账户”等，这些就是我们之前规划的 svc_crm_apppool 之类的域账户。填写时有几个细节：

• 服务账户一定要用“域名\用户名”的格式，不要只写用户名
• 密码不能为空，且必须符合域密码策略
• 安装向导会尝试自动配置这些账户的“作为服务登录”权限，如果失败会给出警告，但是不会中止安装，等服务启动时才暴露问题

接下来是网站配置。向导默认会新建一个站点并绑定 80 端口，如果你本机已经装了其他 Web 应用，建议先用不同的端口或独立主机头。v9.0 的安装程序支持多种绑定方式，但生产环境我建议直接用 HTTPS 绑定。如果证书还没申请好，可以先以 HTTP 方式完成部署，后续在 IIS 里补 HTTPS 再改权力认证配置。

选择数据库那一页，填写 SQL Server 名称和实例名。如果 SQL Server 就在本机，可以用本地主机名或机器名\实例名。这里要注意：SQL Server Browser 服务必须启动，否则向导无法识别命名实例。页面上还会要求填写“部署管理员”的账户，我习惯直接把当前执行安装的域账户填上去，后面再用部署管理器补充其他管理员。

所有信息填完后，向导会先执行先决条件检查，再开始安装。安装过程大概 10 到 30 分钟，取决于服务器性能。期间如果某个服务安装后没有启动成功，向导不一定立刻报错，所以安装完成后最好主动打开“服务”管理器，确认下列服务处于“正在运行”状态：

• Dynamics 365 异步处理服务
• Dynamics 365 沙盒处理服务
• Dynamics 365 监控服务
• World Wide Web 发布服务（W3SVC）
• SQL Server Reporting Services

4.2 部署管理器：从部署管理员到组织创建

安装完成后，桌面上会出现“Dynamics 365 部署管理器”快捷方式（实际上是一张 MMC 管理单元）。打开它的第一件事，是确认当前用户已经是部署管理员。如果不是，右键“部署管理员”，把当前账户或专用的管理员账户添加进去，这一步相当于授予后续管理组织的最高权限。

部署管理器左侧有几个节点：部署管理员、组织、服务器、报表服务器、许可证。比较常用的操作是右键“组织”节点，选择“新建组织”。

创建组织向导需要填写的信息包括：

1. 组织名称：系统内部使用的逻辑名，只能用字母、数字和下划线，建议简写，例如 ContosoSales。这个名称会出现在数据库前缀、报表 URL 上，起得不好后面很麻烦。
2. 显示名称：用户登录后看到的名称，可以包含空格和中文。
3. 基础语言：v9.0 支持多语言组织，默认可以选择简体中文或英语，一个组织的基础语言在创建后不能直接更改。
4. 货币：组织默认货币，后续可在系统中增加多币种。
5. SQL Server 名称和数据库名称：向导会默认生成一个数据库名，例如 ContosoSales_MSCRM，可以手动改。这里需要确保 SQL Server 所在位置正确，避免跨网络创建数据库时超时。
6. 排序规则：向导会自动带出 SQL Server 的默认排序规则，不要手动改成和 SQL Server 不一致的值，不然创建过程必定报错。
7. 报表服务器：如果还没配好报表，可以暂时跳过，但不推荐。没有报表服务器，系统里的内置报表全部不可用，会影响销售和客服人员的使用。

点击确定后，组织状态会显示“正在创建”，持续时间可能在 20 到 40 分钟。这个阶段实际上是在执行几百个数据库脚本并初始化系统元数据，期间不要去强制关闭部署管理器，也不要重启 SQL 服务。我见过有人等得不耐烦直接关掉，结果组织处于“失败”状态，最后只能删掉重建，浪费更多时间。

组织创建成功后，部署管理器的“组织”节点下会出现该组织的条目，状态为“已启用”。这时候用浏览器访问 http://服务器名/orgname，如果能看到登录页，恭喜你，核心部署已经通了。

4.3 报表服务与 Email Router 集成

组织创建完成后，下一步就是配置报表服务。如果 SQL Server Reporting Services 跟 Dynamics 365 不在同一台机器上，需要单独在报表服务器上运行安装介质，选择安装 Reporting Extensions。安装完成后，回到部署管理器，右键“报表服务器”，添加报表服务器名称或订阅地址，关联到对应实例，然后测试连接。

有一个经验：SSRS 服务账户和 Dynamics 365 报表服务账户都需要对报表目录有访问权限，而且 SSRS 的“身份验证类型”如果是“Windows 集成安全性”以外的设置，Dynamics 365 报表可能无法正常显示。我在实施时直接把 SSRS 的验证保持为 Windows 集成，并在部署管理器里用 svc_crm_report 账户配置报表连接，报表预览就正常了。

Email Router（电子邮件路由器）的安装独立于 Dynamics 365 Server，安装介质里单独提供了安装包。它负责处理 Dynamics 365 的入站和出站邮件，比如创建电子邮件活动和跟踪邮件往来。配置 Email Router 的核心是：

1. 先配置“入站/出站配置文件”，邮箱的连接信息就在这里维护，支持 Exchange Server 和 POP3/SMTP 两种模式。
2. 每个用户邮箱需要在 Dynamics 365 中启用并关联到配置文件。
3. Email Router 服务会定时侦测邮件，并把邮件转换为 Dynamics 365 的活动记录。

Email Router 的经典问题是 SMTP 认证失败。很多企业邮件网关禁用了明文 25 端口的 SMTP，改成 587 带 TLS。Dynamics 365 Email Router 老版本对 STARTTLS 支持不够好，v9.0 版本已经改善，但仍建议先在邮箱服务器上用一个专用测试账号验证 SMTP 参数，避免配置完以后整个组织的邮件都静默失败。

4.4 PowerShell 方式部署：无界面场景的参考

如果你的企业讲究自动化，或者需要在多台服务器上重复部署，可以用部署工具提供的 PowerShell 模块。安装 Dynamics 365 Server 时勾选了“部署工具”后，在 Windows PowerShell 里导入模块：

Import-Module Microsoft.Crm.PowerShell Get-Command -Module Microsoft.Crm.PowerShell

常用的几个 cmdlet 有：

• Get-CrmDeploymentAdministrator：查看当前部署管理员
• Add-CrmDeploymentAdministrator：添加部署管理员
• New-CrmOrganization：创建组织
• Get-CrmOrganization：查看组织状态
• Remove-CrmOrganization：删除组织

我在自动化脚本里创建组织的命令大致是这样：

New-CrmOrganization -Name "ContosoSales" ` -DisplayName "Contoso 销售管理" ` -BaseCurrencyCode "CNY" ` -BaseLanguageCode 2052 ` -SqlServerName "CRM-DB-01" ` -SqlDatabaseName "ContosoSales_MSCRM" ` -SqlCollation "Latin1_General_CI_AI"

注意，BaseLanguageCode 2052 对应简体中文，想看其他语言代码可以在 Dynamics 365 安装目录下的 LCID 文件或官方文档里查。PowerShell 方式能帮你把部署流程固化成脚本，比每次打开图形界面手动点要可靠得多。不过第一次跑通前，还是建议先用图形界面验证一遍参数，避免脚本报错后留下一堆半成品组织。

5. 常见问题排查与避坑实录

前面讲了完整流程，这一节我把自己实际遇到过的、以及帮别人排查过的高频问题整理出来，重点是排查思路，而不仅是结论。很多报错信息虽然长，但核心原因就那么几类。

5.1 “以一种访问权限不允许的方式做了一个访问”排查

这个错误是在 Windows 服务层面非常典型的权限问题，通常出现在 Dynamics 365 异步服务或者相关 Windows 服务启动时。日志里会看到类似这样的内容：

服务“Dynamics 365 异步处理服务”启动失败。failed to start login server: 以一种访问权限不允许的方式做了一个访问。

翻译成人话就是：当前用来启动服务或进程的账户，没有被赋予足够的“以服务方式登录”权限，或者目标文件/注册表键的访问控制列表（ACL）里没有这个账户的权限。

我的排查顺序是这样：

1. 打开“服务”管理器，找到启动失败的 Dynamics 服务，在“登录”标签页里确认是不是使用了自定义服务账户，而不是“本地系统账户”。
2. 如果用了自定义账户，用本地安全策略（secpol.msc）里的“本地策略 -> 用户权限分配 -> 作为服务登录”，把这个服务账户加进去。
3. 检查服务账户是不是被域策略锁定了“拒绝作为服务登录”。企业安全基线里有时会加这种拒绝规则，优先级高于允许规则。
4. 检查相关目录的文件权限。Dynamics 365 默认安装目录是 C:\Program Files\Microsoft Dynamics 365\，服务账户至少要对该目录有读取和执行权限，日志目录要有写入权限。
5. 改完权限后，不要直接在“服务”里重启，最好用命令 iisreset 或者重启一下服务器，确保权限刷新。

这类权限问题很隐蔽，因为报错信息读起来不像权限问题，更像“网络连接被拒绝”。我第一次遇到时，愣是花了一个多小时去检查端口和服务绑定，最后才发现是服务账户的登录权限被域基线策略覆盖了。所以遇到这种错误，先把账户权限放第一位排查。

5.2 创建组织失败与 SQL 权限检查

创建组织的向导里最容易失败的节点有两个：一个是在 SQL Server 上创建数据库时失败，另一个是初始化数据时执行脚本超时。

创建数据库失败，常见的提示是“用户无权在数据库中创建对象”或“无法连接到 SQL Server”。这类问题八成是当前部署账户在 SQL Server 中不是 sysadmin 角色。你在部署管理器里操作创建组织，使用的是部署管理员的 Windows 身份，这个账户必须在 SQL Server 实例中拥有足够的权限。最省事、也最符合 Dynamics 365 官方要求的方式是：给部署管理账户一个 sysadmin 固定服务器角色，或者至少授予 dbcreator 和 securityadmin 权限。生产环境如果要收敛权限，建议用专门的部署账户名，不要用域管理员那类高权限账号。

初始化数据超时的问题，通常和 SQL Server 的性能、磁盘 IO、网络延迟有关。如果跨机房创建组织，SQL Server 和 Dynamics 365 之间延迟太高，脚本执行超时很正常。解决思路是：

1. 把组织数据库创建过程中用到的网络开销降到最低，部署时尽量让应用服务器和数据库服务器在同一网段。
2. 检查 SQL Server 安装路径和数据文件路径是否在 IO 性能足够的存储上。机械硬盘跑组织初始化会非常慢，至少要用 SSD。
3. 如果向导里没有具体的超时时间配置，可以先用 PowerShell 的 New-CrmOrganization，通过 DatabaseTimeout 和 ScriptTimeout 参数调节：

New-CrmOrganization -Name "ContosoSales" -DisplayName "Contoso 销售管理" ` -SqlServerName "CRM-DB-01" -SqlDatabaseName "ContosoSales_MSCRM" ` -DatabaseTimeout 1200 -ScriptTimeout 3600

加大超时只是权宜之计，根本上的解决方式还是优化 SQL Server 的 IO 性能和网络质量。

5.3 报表页面 500 错误与应用池配置

组织创建成功后，有时候打开系统页面正常，但一点击“报表”或“图表”就报 500 错误。这种情况大多数不是 Dynamics 365 本身的问题，而是 SSRS 侧或 IIS 中的应用池配置问题。

我的排查顺序是：

1. 先单独访问 SSRS 的报表管理器地址，确认 SSRS 服务能正常打开。如果 SSRS 也打不开，优先检查 SSRS 服务账户权限和报表服务是否启动。
2. 确认 Reporting Extensions 已正确安装到 SSRS 服务器上。可以在部署管理器里测试报表服务器连接，如果测试失败，重新运行安装介质，选择“Reporting Extensions”组件修复。
3. 检查 IIS 应用程序池的运行账户。Dynamics 365 网站使用的应用池账户必须对 C:\Program Files\Microsoft Dynamics 365 有读取权限，并且不能和报表应用池冲突。如果你改了默认应用池运行账户，记得也要在部署管理器里更新对应的配置。
4. 查看事件查看器中的应用程序日志，重点找 Exception 和 HTTP 500 相关的记录。很多情况下，报表 500 的真实异常会同时写入 Dynamics 365 的跟踪日志目录，默认路径是 C:\Program Files\Microsoft Dynamics 365\Trace\。

我在一个项目里遇到过报表页面 500，最后发现是 SSRS 配置的“服务账户”密码过期，导致 SSRS 服务本身挂掉了，但 Dynamics 365 前端没有直接报“SSRS 不可用”，而是返回了一个泛化的 500。所以排查报表问题时，先把 SSRS 服务重启一下，再打开发布页面看看是否恢复，往往能省很多时间。

5.4 其他高频部署问题速查表

除了上面几个典型场景，下面这些我遇到或听说过的问题也值得收藏，遇到时可以快速定位。

6. 部署完成后的调优与日常维护

部署和创建组织之后，项目并不算真正结束。稳定运行才是目标，尤其是本地部署模式下，没有云平台帮你看护底层设施，Dynamics 365 On-Premise 的日常巡检和调优完全依靠企业自己的运维团队。这里分享几个我在上线后常用的维护动作。

6.1 数据库维护与备份策略

Dynamics 365 v9.0 至少会创建两类数据库：配置数据库（MSCRM_CONFIG）和组织数据库（OrganizationName_MSCRM）。如果开启了沙盒功能，可能还有专用的沙盒组织数据库。备份时这些库必须一起备份，否则恢复到别的服务器上可能因为配置库和组织库不一致导致无法启动。

数据库的备份策略我是这样做的：

1. 每日全量备份组织数据库和配置数据库，保留最近 7 天。
2. 每 15 分钟做一次事务日志备份（如果业务允许），用于缩短恢复时间目标。
3. 每周执行一次索引碎片整理和统计信息更新，放在周末凌晨低峰期。索引碎片化严重时，Dynamics 365 的列表查询会越来越慢，用户会明显感觉到页面转圈。
4. 定期检查数据库文件增长设置，避免文件自动增长频繁导致 IO 抖动。建议把数据文件和日志文件的初始大小和自动增长步长设置成合理值，比如增长 1GB，而不是默认的 10%。

6.2 IIS 与应用程序池调优

Dynamics 365 的 Web 应用运行在 IIS 下，最直接的影响来自应用程序池的回收设置。默认的回收时间是凌晨 3 点，但如果你在这个时间点有批量作业、报表订阅或 Email Router 处理任务，回收会导致一阵短暂的请求排队或 503。我的做法是把应用程序池回收时间错开业务高峰期，并开启“在特定时间回收”而不是“固定间隔”回收，同时把“闲置超时”调大，避免空闲回收过于频繁。

另外就是 IIS 日志。Dynamics 365 访问量大的时候，IIS 日志文件会快速增长。建议单独给日志目录设置一个磁盘配额，并定期归档到备份服务器。如果磁盘满了，IIS 会拒绝写入日志，甚至影响用户访问，这种“慢刀子割肉”式的故障最烦人。

6.3 监控与日志查看建议

On-Premise 系统没有云平台自带的一体化监控，所以我通常会在部署完成后做两件事：

第一，给 Dynamics 365 的 Windows 服务和 SQL Server 服务配置监控告警。不需要多复杂的工具，Zabbix 或者 Prometheus 都可以，关键是盯住四个指标：

• Dynamics 相关 Windows 服务是否保持“正在运行”
• SQL Server 的 CPU、内存、磁盘 IO 是否异常
• IIS 应用进程（w3wp.exe）的内存占用是否持续增长
• 事件查看器里是否出现 Dynamics 365 相关的错误事件

第二，把 Dynamics 365 的跟踪日志（Trace）打开到合适的级别。默认等级可能是关闭或只记录错误，遇到问题时可以临时调到“信息”级别，复现问题后收集日志，分析完再调回来，避免长期开着影响性能。日志目录默认在 C:\Program Files\Microsoft Dynamics 365\Trace\ 下，按天生成文件，命名中带有来源和进程信息。

有一点需要提前知会团队：Dynamics 365 的跟踪日志文件在问题排查时极其有价值，但格式相对复杂，建议配合微软的日志分析工具或社区脚本一起看，别自己用记事本硬啃。

到这里，部署体验的记录基本写完了。最后我想说，Dynamics 365 On-Premise Server v9.0 这套东西，技术栈虽然传统，但部署过程的确很考验一个人的全局把控力。你在服务器上做的每一个账户规划、每一个默认配置的调整，都会在后续的稳定运行中得到验证。

我自己在实际部署中体会最深的是：不要低估服务账户和权限设计的重要性，也不要在一个看起来“无关紧要”的警告中轻易点“下一步”。另外，如果企业后续有升级到 v9.1 或迁移到云端的计划，建议从一开始就用 PowerShell 脚本管理部署配置，并把组织数据库的备份做到可移植测试的程度，这样以后无论是升级还是迁云，都能省出大量的验证时间。希望这篇部署体验能给你一些实质性帮助。你要是也在做同类部署，欢迎带着具体问题来交流。