尧图网页设计 
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 阵列整体表现从部署到日常使用都还算从容。具体可以参照下表角色CPU内存磁盘说明单机一体部署4 核以上16GB 起步系统盘 100GB数据盘 200GB 以上PoC 和小规模生产可用Web 前端4 核以上16GB系统盘 100GB跑 IIS、应用池后端应用4 核16GB系统盘 80GB跑异步服务、沙盒SQL Server8 核以上32GB 以上数据盘独立 RAID数据库性能的关键报表服务器4 核16GB系统盘 80GBSSRS 独立部署时磁盘这块我要多说一句C 盘尽量不要放数据库文件日志文件和数据库文件也不要挤在同一块盘上不然等数据量起来以后IO 竞争会直接反映到用户操作延迟上。再看软件版本。Dynamics 365 Server v9.0 对底层环境有明确要求我在部署前整理了一份在真实环境中验证过的组合操作系统Windows Server 2016Windows Server 2012 R2 也可以但 2016 更稳数据库SQL Server 2016 SP2 或 SQL Server 2017.NET Framework4.6.2 以上我用的是 4.7.2Web 服务器IIS 10Windows Server 2016 自带域环境Active Directory必须报告服务SQL Server Reporting ServicesSSRS随 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 在安装过程中会要求你提供多个服务账户这些账户的权限、密码策略、委派方式都会直接影响安装结果。我当时规划的账户清单大概是这样账户名按企业规范调整账户用途所需权限svc_crm_install安装部署账户域普通用户、本机管理员svc_crm_apppool应用程序池账户IIS_IUSRS 成员、CRM 安装目录读写svc_crm_async异步服务账户服务登录权限、SQL 连接权限svc_crm_sandbox沙盒服务账户服务登录权限svc_crm_report报表服务账户SSRS 访问权限、CRM 报表文件夹权限svc_crm_emailEmail Router 账户邮箱访问权限、Exchange 或 SMTP 权限对这些账户有几点必须提前做好密码要符合域密码策略并且记录好下次修改的时间点。不要图省事让所有服务账户共用一个账号后续想隔离权限的时候会非常痛苦。所有服务账户必须拥有“作为服务登录”的权限。安装向导理论上会自动配置但有些域策略默认禁止普通账户作为服务登录导致服务启动失败。后面第 5 节我会专门讲那个“以一种访问权限不允许的方式做了一个访问”的报错。如果企业域控制器启用了“密码必须符合复杂性要求”并且还有“定期更换密码”的策略需要提前评估是否给服务账户开例外或者在密码到期前有一个明确的变更流程。Dynamics 365 的服务账户密码改起来并不像 IIS 应用池那么简单涉及部署管理器和多个 Windows 服务最好提前规划。2.3 网络、端口与防火墙规划单服务器部署时网络规划相对简单主要关注本机防火墙和 SQL Server 的 TCP/IP 协议。多服务器部署时就要仔细梳理端口了。我常用的端口规划如下服务端口备注Dynamics 365 Web 前端80 / 443HTTP/HTTPSSQL Server1433数据库连接SSRS80 / 443报表访问异步服务可选随机端口一般走内部网络Email Router25 / 587SMTP 出站Dynamics 365 服务间的 NetTCP自定义多服务器部署时用如果 Web 前端和 SQL Server 不在同一台机器记得在 SQL Server 的配置管理器里启用 TCP/IP 协议并在防火墙放行 1433 端口。这里有一个经常被忽略的点Windows 防火墙默认会拦截 SQL Server 的端口需要新建入站规则放行而且要同时放行 1433 和 1434SQL 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_AICI 是大小写不敏感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 SP2SSRS 是 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 DeployWeb 部署工具它用于 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 发布服务W3SVCSQL Server Reporting Services4.2 部署管理器从部署管理员到组织创建安装完成后桌面上会出现“Dynamics 365 部署管理器”快捷方式实际上是一张 MMC 管理单元。打开它的第一件事是确认当前用户已经是部署管理员。如果不是右键“部署管理员”把当前账户或专用的管理员账户添加进去这一步相当于授予后续管理组织的最高权限。部署管理器左侧有几个节点部署管理员、组织、服务器、报表服务器、许可证。比较常用的操作是右键“组织”节点选择“新建组织”。创建组织向导需要填写的信息包括组织名称系统内部使用的逻辑名只能用字母、数字和下划线建议简写例如 ContosoSales。这个名称会出现在数据库前缀、报表 URL 上起得不好后面很麻烦。显示名称用户登录后看到的名称可以包含空格和中文。基础语言v9.0 支持多语言组织默认可以选择简体中文或英语一个组织的基础语言在创建后不能直接更改。货币组织默认货币后续可在系统中增加多币种。SQL Server 名称和数据库名称向导会默认生成一个数据库名例如 ContosoSales_MSCRM可以手动改。这里需要确保 SQL Server 所在位置正确避免跨网络创建数据库时超时。排序规则向导会自动带出 SQL Server 的默认排序规则不要手动改成和 SQL Server 不一致的值不然创建过程必定报错。报表服务器如果还没配好报表可以暂时跳过但不推荐。没有报表服务器系统里的内置报表全部不可用会影响销售和客服人员的使用。点击确定后组织状态会显示“正在创建”持续时间可能在 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 的核心是先配置“入站/出站配置文件”邮箱的连接信息就在这里维护支持 Exchange Server 和 POP3/SMTP 两种模式。每个用户邮箱需要在 Dynamics 365 中启用并关联到配置文件。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里没有这个账户的权限。我的排查顺序是这样打开“服务”管理器找到启动失败的 Dynamics 服务在“登录”标签页里确认是不是使用了自定义服务账户而不是“本地系统账户”。如果用了自定义账户用本地安全策略secpol.msc里的“本地策略 - 用户权限分配 - 作为服务登录”把这个服务账户加进去。检查服务账户是不是被域策略锁定了“拒绝作为服务登录”。企业安全基线里有时会加这种拒绝规则优先级高于允许规则。检查相关目录的文件权限。Dynamics 365 默认安装目录是 C:\Program Files\Microsoft Dynamics 365\服务账户至少要对该目录有读取和执行权限日志目录要有写入权限。改完权限后不要直接在“服务”里重启最好用命令 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 之间延迟太高脚本执行超时很正常。解决思路是把组织数据库创建过程中用到的网络开销降到最低部署时尽量让应用服务器和数据库服务器在同一网段。检查 SQL Server 安装路径和数据文件路径是否在 IO 性能足够的存储上。机械硬盘跑组织初始化会非常慢至少要用 SSD。如果向导里没有具体的超时时间配置可以先用 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 中的应用池配置问题。我的排查顺序是先单独访问 SSRS 的报表管理器地址确认 SSRS 服务能正常打开。如果 SSRS 也打不开优先检查 SSRS 服务账户权限和报表服务是否启动。确认 Reporting Extensions 已正确安装到 SSRS 服务器上。可以在部署管理器里测试报表服务器连接如果测试失败重新运行安装介质选择“Reporting Extensions”组件修复。检查 IIS 应用程序池的运行账户。Dynamics 365 网站使用的应用池账户必须对 C:\Program Files\Microsoft Dynamics 365 有读取权限并且不能和报表应用池冲突。如果你改了默认应用池运行账户记得也要在部署管理器里更新对应的配置。查看事件查看器中的应用程序日志重点找 Exception 和 HTTP 500 相关的记录。很多情况下报表 500 的真实异常会同时写入 Dynamics 365 的跟踪日志目录默认路径是 C:\Program Files\Microsoft Dynamics 365\Trace\。我在一个项目里遇到过报表页面 500最后发现是 SSRS 配置的“服务账户”密码过期导致 SSRS 服务本身挂掉了但 Dynamics 365 前端没有直接报“SSRS 不可用”而是返回了一个泛化的 500。所以排查报表问题时先把 SSRS 服务重启一下再打开发布页面看看是否恢复往往能省很多时间。5.4 其他高频部署问题速查表除了上面几个典型场景下面这些我遇到或听说过的问题也值得收藏遇到时可以快速定位。现象可能原因解决建议安装向导的环境检查不通过提示缺少 IIS 功能IIS 角色模块不全按第 3.3 节的清单安装 ASP.NET、ISAPI、Windows 认证等创建组织一直停留在“正在创建”状态数据库脚本执行慢检查磁盘 IO确认 SQL Server 无阻塞耐心等待或调大超时访问网站出现“HTTP 503 Service Unavailable”应用程序池停止查看应用池运行账户和密码使用服务账户启动数据库连接提示“找不到网络路径”SQL Browser 服务未启动或端口不通启用 TCP/IP放行防火墙 1433/1434系统登录总是弹 Windows 认证框且失败Kerberos SPN 冲突或时间不同步检查服务器时间、清理重复 SPN异步服务停止等待的邮件不发送服务账户密码过期或队列阻塞更新服务账户密码重启异步服务报表无法显示提示“数据源凭据无效”报表连接账户权限不对使用 svc_crm_report 账户配置数据源授予组织数据库读权限安装完成后找不到部署管理器未安装部署工具组件重新运行安装介质勾选“部署工具”6. 部署完成后的调优与日常维护部署和创建组织之后项目并不算真正结束。稳定运行才是目标尤其是本地部署模式下没有云平台帮你看护底层设施Dynamics 365 On-Premise 的日常巡检和调优完全依靠企业自己的运维团队。这里分享几个我在上线后常用的维护动作。6.1 数据库维护与备份策略Dynamics 365 v9.0 至少会创建两类数据库配置数据库MSCRM_CONFIG和组织数据库OrganizationName_MSCRM。如果开启了沙盒功能可能还有专用的沙盒组织数据库。备份时这些库必须一起备份否则恢复到别的服务器上可能因为配置库和组织库不一致导致无法启动。数据库的备份策略我是这样做的每日全量备份组织数据库和配置数据库保留最近 7 天。每 15 分钟做一次事务日志备份如果业务允许用于缩短恢复时间目标。每周执行一次索引碎片整理和统计信息更新放在周末凌晨低峰期。索引碎片化严重时Dynamics 365 的列表查询会越来越慢用户会明显感觉到页面转圈。定期检查数据库文件增长设置避免文件自动增长频繁导致 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 脚本管理部署配置并把组织数据库的备份做到可移植测试的程度这样以后无论是升级还是迁云都能省出大量的验证时间。希望这篇部署体验能给你一些实质性帮助。你要是也在做同类部署欢迎带着具体问题来交流。 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 阵列整体表现从部署到日常使用都还算从容。具体可以参照下表角色CPU内存磁盘说明单机一体部署4 核以上16GB 起步系统盘 100GB数据盘 200GB 以上PoC 和小规模生产可用Web 前端4 核以上16GB系统盘 100GB跑 IIS、应用池后端应用4 核16GB系统盘 80GB跑异步服务、沙盒SQL Server8 核以上32GB 以上数据盘独立 RAID数据库性能的关键报表服务器4 核16GB系统盘 80GBSSRS 独立部署时磁盘这块我要多说一句C 盘尽量不要放数据库文件日志文件和数据库文件也不要挤在同一块盘上不然等数据量起来以后IO 竞争会直接反映到用户操作延迟上。再看软件版本。Dynamics 365 Server v9.0 对底层环境有明确要求我在部署前整理了一份在真实环境中验证过的组合操作系统Windows Server 2016Windows Server 2012 R2 也可以但 2016 更稳数据库SQL Server 2016 SP2 或 SQL Server 2017.NET Framework4.6.2 以上我用的是 4.7.2Web 服务器IIS 10Windows Server 2016 自带域环境Active Directory必须报告服务SQL Server Reporting ServicesSSRS随 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 在安装过程中会要求你提供多个服务账户这些账户的权限、密码策略、委派方式都会直接影响安装结果。我当时规划的账户清单大概是这样账户名按企业规范调整账户用途所需权限svc_crm_install安装部署账户域普通用户、本机管理员svc_crm_apppool应用程序池账户IIS_IUSRS 成员、CRM 安装目录读写svc_crm_async异步服务账户服务登录权限、SQL 连接权限svc_crm_sandbox沙盒服务账户服务登录权限svc_crm_report报表服务账户SSRS 访问权限、CRM 报表文件夹权限svc_crm_emailEmail Router 账户邮箱访问权限、Exchange 或 SMTP 权限对这些账户有几点必须提前做好密码要符合域密码策略并且记录好下次修改的时间点。不要图省事让所有服务账户共用一个账号后续想隔离权限的时候会非常痛苦。所有服务账户必须拥有“作为服务登录”的权限。安装向导理论上会自动配置但有些域策略默认禁止普通账户作为服务登录导致服务启动失败。后面第 5 节我会专门讲那个“以一种访问权限不允许的方式做了一个访问”的报错。如果企业域控制器启用了“密码必须符合复杂性要求”并且还有“定期更换密码”的策略需要提前评估是否给服务账户开例外或者在密码到期前有一个明确的变更流程。Dynamics 365 的服务账户密码改起来并不像 IIS 应用池那么简单涉及部署管理器和多个 Windows 服务最好提前规划。2.3 网络、端口与防火墙规划单服务器部署时网络规划相对简单主要关注本机防火墙和 SQL Server 的 TCP/IP 协议。多服务器部署时就要仔细梳理端口了。我常用的端口规划如下服务端口备注Dynamics 365 Web 前端80 / 443HTTP/HTTPSSQL Server1433数据库连接SSRS80 / 443报表访问异步服务可选随机端口一般走内部网络Email Router25 / 587SMTP 出站Dynamics 365 服务间的 NetTCP自定义多服务器部署时用如果 Web 前端和 SQL Server 不在同一台机器记得在 SQL Server 的配置管理器里启用 TCP/IP 协议并在防火墙放行 1433 端口。这里有一个经常被忽略的点Windows 防火墙默认会拦截 SQL Server 的端口需要新建入站规则放行而且要同时放行 1433 和 1434SQL 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_AICI 是大小写不敏感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 SP2SSRS 是 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 DeployWeb 部署工具它用于 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 发布服务W3SVCSQL Server Reporting Services4.2 部署管理器从部署管理员到组织创建安装完成后桌面上会出现“Dynamics 365 部署管理器”快捷方式实际上是一张 MMC 管理单元。打开它的第一件事是确认当前用户已经是部署管理员。如果不是右键“部署管理员”把当前账户或专用的管理员账户添加进去这一步相当于授予后续管理组织的最高权限。部署管理器左侧有几个节点部署管理员、组织、服务器、报表服务器、许可证。比较常用的操作是右键“组织”节点选择“新建组织”。创建组织向导需要填写的信息包括组织名称系统内部使用的逻辑名只能用字母、数字和下划线建议简写例如 ContosoSales。这个名称会出现在数据库前缀、报表 URL 上起得不好后面很麻烦。显示名称用户登录后看到的名称可以包含空格和中文。基础语言v9.0 支持多语言组织默认可以选择简体中文或英语一个组织的基础语言在创建后不能直接更改。货币组织默认货币后续可在系统中增加多币种。SQL Server 名称和数据库名称向导会默认生成一个数据库名例如 ContosoSales_MSCRM可以手动改。这里需要确保 SQL Server 所在位置正确避免跨网络创建数据库时超时。排序规则向导会自动带出 SQL Server 的默认排序规则不要手动改成和 SQL Server 不一致的值不然创建过程必定报错。报表服务器如果还没配好报表可以暂时跳过但不推荐。没有报表服务器系统里的内置报表全部不可用会影响销售和客服人员的使用。点击确定后组织状态会显示“正在创建”持续时间可能在 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 的核心是先配置“入站/出站配置文件”邮箱的连接信息就在这里维护支持 Exchange Server 和 POP3/SMTP 两种模式。每个用户邮箱需要在 Dynamics 365 中启用并关联到配置文件。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里没有这个账户的权限。我的排查顺序是这样打开“服务”管理器找到启动失败的 Dynamics 服务在“登录”标签页里确认是不是使用了自定义服务账户而不是“本地系统账户”。如果用了自定义账户用本地安全策略secpol.msc里的“本地策略 - 用户权限分配 - 作为服务登录”把这个服务账户加进去。检查服务账户是不是被域策略锁定了“拒绝作为服务登录”。企业安全基线里有时会加这种拒绝规则优先级高于允许规则。检查相关目录的文件权限。Dynamics 365 默认安装目录是 C:\Program Files\Microsoft Dynamics 365\服务账户至少要对该目录有读取和执行权限日志目录要有写入权限。改完权限后不要直接在“服务”里重启最好用命令 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 之间延迟太高脚本执行超时很正常。解决思路是把组织数据库创建过程中用到的网络开销降到最低部署时尽量让应用服务器和数据库服务器在同一网段。检查 SQL Server 安装路径和数据文件路径是否在 IO 性能足够的存储上。机械硬盘跑组织初始化会非常慢至少要用 SSD。如果向导里没有具体的超时时间配置可以先用 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 中的应用池配置问题。我的排查顺序是先单独访问 SSRS 的报表管理器地址确认 SSRS 服务能正常打开。如果 SSRS 也打不开优先检查 SSRS 服务账户权限和报表服务是否启动。确认 Reporting Extensions 已正确安装到 SSRS 服务器上。可以在部署管理器里测试报表服务器连接如果测试失败重新运行安装介质选择“Reporting Extensions”组件修复。检查 IIS 应用程序池的运行账户。Dynamics 365 网站使用的应用池账户必须对 C:\Program Files\Microsoft Dynamics 365 有读取权限并且不能和报表应用池冲突。如果你改了默认应用池运行账户记得也要在部署管理器里更新对应的配置。查看事件查看器中的应用程序日志重点找 Exception 和 HTTP 500 相关的记录。很多情况下报表 500 的真实异常会同时写入 Dynamics 365 的跟踪日志目录默认路径是 C:\Program Files\Microsoft Dynamics 365\Trace\。我在一个项目里遇到过报表页面 500最后发现是 SSRS 配置的“服务账户”密码过期导致 SSRS 服务本身挂掉了但 Dynamics 365 前端没有直接报“SSRS 不可用”而是返回了一个泛化的 500。所以排查报表问题时先把 SSRS 服务重启一下再打开发布页面看看是否恢复往往能省很多时间。5.4 其他高频部署问题速查表除了上面几个典型场景下面这些我遇到或听说过的问题也值得收藏遇到时可以快速定位。现象可能原因解决建议安装向导的环境检查不通过提示缺少 IIS 功能IIS 角色模块不全按第 3.3 节的清单安装 ASP.NET、ISAPI、Windows 认证等创建组织一直停留在“正在创建”状态数据库脚本执行慢检查磁盘 IO确认 SQL Server 无阻塞耐心等待或调大超时访问网站出现“HTTP 503 Service Unavailable”应用程序池停止查看应用池运行账户和密码使用服务账户启动数据库连接提示“找不到网络路径”SQL Browser 服务未启动或端口不通启用 TCP/IP放行防火墙 1433/1434系统登录总是弹 Windows 认证框且失败Kerberos SPN 冲突或时间不同步检查服务器时间、清理重复 SPN异步服务停止等待的邮件不发送服务账户密码过期或队列阻塞更新服务账户密码重启异步服务报表无法显示提示“数据源凭据无效”报表连接账户权限不对使用 svc_crm_report 账户配置数据源授予组织数据库读权限安装完成后找不到部署管理器未安装部署工具组件重新运行安装介质勾选“部署工具”6. 部署完成后的调优与日常维护部署和创建组织之后项目并不算真正结束。稳定运行才是目标尤其是本地部署模式下没有云平台帮你看护底层设施Dynamics 365 On-Premise 的日常巡检和调优完全依靠企业自己的运维团队。这里分享几个我在上线后常用的维护动作。6.1 数据库维护与备份策略Dynamics 365 v9.0 至少会创建两类数据库配置数据库MSCRM_CONFIG和组织数据库OrganizationName_MSCRM。如果开启了沙盒功能可能还有专用的沙盒组织数据库。备份时这些库必须一起备份否则恢复到别的服务器上可能因为配置库和组织库不一致导致无法启动。数据库的备份策略我是这样做的每日全量备份组织数据库和配置数据库保留最近 7 天。每 15 分钟做一次事务日志备份如果业务允许用于缩短恢复时间目标。每周执行一次索引碎片整理和统计信息更新放在周末凌晨低峰期。索引碎片化严重时Dynamics 365 的列表查询会越来越慢用户会明显感觉到页面转圈。定期检查数据库文件增长设置避免文件自动增长频繁导致 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 脚本管理部署配置并把组织数据库的备份做到可移植测试的程度这样以后无论是升级还是迁云都能省出大量的验证时间。希望这篇部署体验能给你一些实质性帮助。你要是也在做同类部署欢迎带着具体问题来交流。