企业官网建设流程全解析

最近看到不少人在转载 Dynamics 365 On-Premise Server v9.0 部署相关的内容，恰好我自己也刚把一套本地环境从零完整走了一遍，正好把整个部署体验记录下来。这篇文章主要写给正准备上手本地版 v9.0、尤其是之前只部署过老版 Dynamics CRM 的人看，也会涉及一些多机部署时需要留意的点。本地版和云端最大的区别在于：所有组件都要自己装、自己配、自己维护，部署过程中会遇到不少官方文档里没有细讲的问题，下面这些内容基本就是我在实际环境里一步一步验证过的结论。

1. 部署前的需求确认：从软件要求到实际场景的取舍

1.1 为什么要选本地版 v9.0 而不是云端

Dynamics 365 现在主推云订阅，但本地部署的需求一直没有消失。数据合规要求、内网隔离、定制深度太大、或者单纯不想被订阅模式绑定的企业，仍然会把 On-Premise 版本作为首选。v9.0 这个版本在本地版里算是一个分水岭：组件形态比老版本清晰了不少，安装包统一成一个 Server 安装程序，但角色拆分依然保留，数据库结构也从原来 Dynamics CRM 时代的多库结构变成了更集中的部署库加组织库的结构。

如果你是第一次接触 v9.0，心理上要先接受一个现实：它不是"双击下一步"就能跑起来的软件，而是一整套依赖 Windows Server、IIS、SQL Server、SSRS 甚至 Active Directory 的系统工程。我在实际部署前先花了一整天把官方文档里的部署要求整理成表格，尤其是 SQL Server 版本、排序规则、服务账号权限这几项，因为这些早期没定清楚，后面每一步都会回来找你麻烦。

1.2 官方要求清单与实际环境的差异

官方文档对硬件和软件的要求写得比较精简，但真到部署环境里，你还要额外确认不少细节。我整理了一份实际部署时最关键的核对点：

还有一个容易被忽略的点：v9.0 安装向导在检查环境时，会校验 .NET Framework 版本和 PowerShell 执行策略。如果服务器之前跑过别的应用，IIS 里可能已经有占用 443 端口的站点，或者 PowerShell 被锁成了 Restricted，这些都会让你的环境检查失败。我在部署前把所有角色功能和 Windows 更新都打齐，省去了一堆不必要的报错。

2. 环境准备的关键细节：账号、权限、SQL Server 版本

2.1 服务账号与 SQL Server 权限规划

整个部署过程中，权限问题占了报错原因的一大半。安装 Dynamics 365 Server 的账号必须同时满足三个条件：本地 Administrators 组成员、SQL Server 的 sysadmin 固定服务器角色成员、以及在 Active Directory 中拥有读取域属性的权限。任何一条不满足，安装向导都会在不同阶段抛出误导性很强的错误。

我当时就在服务账号这一步踩了坑：用了一个普通的域用户跑安装程序，前面文件复制都很顺利，结果到了创建配置数据库的时候就报"insufficient privileges"。排查下来发现这个账号只有 SQL Server 的 public 角色，别说 sysadmin，连建库权限都没有。解决起来倒不复杂：把账号加进 sysadmin 角色，重新跑一次安装，之后再把 sysadmin 收回。但要记住，安装完成后 Dynamics 365 的部署服务账号本身还需要 SQL Server 的 dbcreator 和 securityadmin 权限，这样才能后续创建组织库和分配权限。

提示：安装账号和运行服务账号最好分开。安装账号临时提升权限，装完降权；运行服务账号用专用的域账号，并设置密码永不过期。

2.2 磁盘与内存的取舍

很多人部署前只盯着 CPU 和内存，忽略了磁盘布局。Dynamics 365 Server v9.0 装上之后，安装目录、日志目录、SQL 数据文件、报表缓存这几块会分散在不同的地方。我建议至少分三个逻辑盘：一个放安装程序和解压包，一个放 SQL Server 数据文件，一个放日志和备份。原因很简单——SQL Server 的日志文件增长非常快，尤其是创建组织库和跑查询索引的时候，日志盘满了整个系统都会卡死。

内存方面，官方给出的最低 8GB 确实能跑，但装完 SQL Server、Web 应用、异步服务、搜索服务之后，物理内存基本就被吃光了。我在测试环境用 16GB，运行起来明显顺畅很多。SQL Server 的 max server memory 建议提前设置一个上限，比如物理内存 16GB 就限制 SQL Server 最多用 12GB，给 IIS 和部署服务留点余量。

2.3 容易被忽略的 IIS 和证书准备

Dynamics 365 Server 的前端角色本质上是挂在 IIS 下的一个 Web 应用。安装程序虽然会自己创建站点和应用池，但如果你在部署前对 IIS 做了什么加固，比如删掉了默认文档、禁用了匿名认证、或者调整了应用程序池的标识类型，后面很可能出现站点起来但打开白屏的情况。

证书这块，测试环境最省事的做法是生成一张自签名证书并导入到信任根证书存储区，然后在安装时跳过证书验证。生产环境稳妥的做法是申请一张包含服务器 FQDN 名称的正式证书，否则禁用 TLS 1.0 或启用了严格证书吊销检查的环境里，IIS 站点会频繁报警。别忘了把证书的私钥授予运行 Dynamics 365 应用池的服务账号，否则即使 IIS 配置了 HTTPS 绑定，解密时依然会失败。

3. 安装环节的主要节点：拓扑选择与配置库

3.1 单机与多机的拓扑选择

v9.0 支持三种典型拓扑：单机 All-in-One、双机拆分前端和后端、多机分布式（把部署服务器、前端服务器、后端服务器、搜索服务拆到不同机器）。我这次用的是单机拓扑，因为规模不大，但对生产环境来说，至少要前后端分离，这样 Web 端的请求压力和异步服务的工作负载才不会互相干扰。

三种拓扑的对比：

无论选择哪种拓扑，有一点是共通的：整个部署体系里一定有一个"部署服务器"角色，它是所有安装程序的引用源。单机拓扑里部署服务器就是本机；多机拓扑里，其他机器安装时会指向这台机器来读取部署配置。实际部署时最容易搞错的是：把 SQL Server 实例跟部署数据库混为一谈。部署数据库（MSCRM_CONFIG）只是存放组织信息、服务器角色和许可证数据，实际的业务数据都在各个组织数据库里，两者别弄混。

3.2 安装向导的实际运行过程

安装 Dynamics 365 Server 有两种路径：图形化向导和命令行安装。图形化向导更直观，命令行则更适合多机批量部署。我这次采用图形化向导，整体流程如下：

1. 运行 setup.exe，选择"Install Dynamics 365 Server"。
2. 输入产品密钥。本地版必须有密钥，这是和云端版很大的一个区别。
3. 选择要安装的服务器角色。单机拓扑直接把所有角色勾上。
4. 指定部署服务器名称。装第一台时填本机，后续机器填已有部署服务器的计算机名。
5. 配置服务账号和密码。这里要填的是 Dynamics 365 运行服务账号，不是本地系统账号。
6. 指定配置数据库的 SQL Server 实例和数据库名称。数据库文件位置可以自定义路径。
7. 环境检查通过后开始安装，整个文件复制和组件注册大概需要二十到四十分钟。

如果你偏好命令行方式，可以参考这个思路，用/install参数指定角色，配合一个 XML 配置文件把所有账号和 SQL 实例信息写进去。命令行方式的好处是同样的配置可以重复使用，在多台前端服务器上做一致性部署非常高效。

注意：安装过程中不要手动去 IIS 管理器里删改站点，安装程序会动态创建和注册多个应用池以及虚拟目录，手动干预很容易导致部署状态不一致。

3.3 部署管理器中的组织创建

Dynamics 365 Server 安装完成只是第一步，真正意义上的"可用系统"要在部署管理器里创建组织之后才算数。安装完成后，打开部署管理器，能看到部署服务器的状态。右击服务器名称，选择"新建组织"，然后填写：

• 组织名称：建议只使用字母、数字、下划线，不要带空格。
• SQL Server 实例名：填写承载组织数据库的实例。
• 数据库名称：系统会自动生成一个组织名_MSCRM格式的数据库，也可以手动指定。
• 排序规则选择：这个要慎重，创建后改排序规则非常麻烦，最好在创建前就按业务需求确定。
• 报告服务器 URL：如果还没配好 SSRS，可以先留空，后续在部署管理器里修改组织属性再补上。

组织创建过程会跑一段数据初始化脚本，几百张表的建表和初始数据导入都在这个阶段完成。如果你发现创建进度长时间卡在某个百分比，优先检查 SQL Server 的日志盘空间和 TempDB 增长配置，很多卡住都是磁盘拥堵导致的。

4. 第一次部署的踩坑记录与排查链路

4.1 第一个拦路虎：加密组件权限

第一次安装时，程序跑到"正在配置加密组件"这一步就中断了，日志里提示无法创建加密文件。从安装日志往回翻，定位到一句关于"Crypto"目录访问失败的记录。我检查了 Dynamics 365 安装目录下的相关文件夹，发现安装账号对这个目录没有写入权限——服务器上之前部署过其他软件，修改了安装目录的 ACL，安装程序创建的加密密钥文件写不进去。

排查链路是这样的：

1. 在安装日志目录%ProgramData%\Microsoft\Dynamics 365\Server\log下找到最新的安装跟踪文件。
2. 搜索 "error" 和 "denied" 关键字，很快锁定加密组件目录路径。
3. 打开该目录的"安全"属性，确认当前安装账号是否有"修改"权限。
4. 手动给安装账号添加完全控制权限，重新启动安装程序，问题消失。

这个坑看似简单，但排查起来费了一些时间，因为位置在很深的子目录里，而且错误信息本身只说"无法创建对象"，不会直接告诉你权限不够。

4.2 SQL Server 连接不上的经典案例

第二次做完环境准备，安装程序在验证配置数据库时又报了无法连接 SQL Server。这次我先没有急着重试，而是用 SQL Server Management Studio 手工连接同一个实例，结果是正常的。这就说明问题不在 SQL Server 本身，而是安装向导连接时的上下文有差异。

排查过程如下：

• 查了 Windows 防火墙，发现 1433 端口确实开放了，TCP/IP 也已经启用。
• 发现服务器上安装了默认实例和命名实例两个 SQL Server，而 Dynamics 365 安装向导解析命名实例的端口时依赖 SQL Browser 服务，这个服务当时是停止状态。
• 启动 SQL Browser 服务，并把启动类型改成自动，重新执行环境检查，连接测试顺利通过。

这提醒我一个很重要的经验：使用命名实例部署 Dynamics 365 时，一定要确认 SQL Browser 服务已经启动，同时保证防火墙放行了 UDP 1434 端口。如果用默认实例，反而不会遇到这个问题，所以很多运维人员建议 SQL Server 直接用默认实例来部署。

4.3 部署管理器打不开与站点无法访问的问题

安装完成、组织也创建好之后，我以为事情结束了，结果访问 Web 应用站点时报 404，打开部署管理器也一直转圈。最后发现是端口绑定问题：Dynamics 365 的前端站点默认监听 443 端口，但另一套老系统占用了 443，安装程序就自动把 Dynamics 365 的应用站点绑定到了 5555 端口，而安装时没有明显提示。

排查思路：

1. 打开 IIS 管理器，查看 Dynamics 365 相关站点的"绑定"信息，确认 SSL 端口。
2. 如果端口被占用，就去看端口占用进程，决定是释放原端口还是给 Dynamics 365 改绑新端口。
3. 修改绑定后，需要同步更新部署管理器里记录的前端 URL。

另一个常见情况是自签名证书没有被服务器信任。部署管理器访问自带一个 Windows 窗体刷新操作，它会用当前用户的信任链去校验证书，如果证书无效，界面就一直处于加载状态。把自签名证书导入"受信任的根证书颁发机构"存储区之后，问题可以迅速解决。

5. 报表扩展与附属组件的后续配置

5.1 SSRS 报表服务器扩展

Dynamics 365 本地版的标准报表基于 SQL Server Reporting Services 提供。部署完 Dynamics 365 Server 后，报表功能不会自动可用，需要单独安装 SSRS，然后在部署管理器里把组织关联到一个报表服务器。

SSRS 版本要和 SQL Server 对应，如果 SQL Server 是 2016/2017/2019，SSRS 最好用同版本号。部署时会有几个细节：

• SSRS 服务账号需要有组织数据库所在 SQL Server 实例的读取权限。
• SSRS 自身的 Web 服务 URL 必须能被 Dynamics 365 服务账号访问。
• 在部署管理器里填写报表服务器 URL 时，地址要精确到报表服务器的虚拟目录根路径，不带ReportServer反而是经常报错的写法。

我在配置报表扩展时遇到的问题也很有代表性：SSRS 装好了，Dynamics 365 组织属性里也填了 URL，但打开报表页面一直提示无法访问报表服务器数据库。检查后发现 SSRS 的加密密钥和报表服务账号不匹配，因为我在安装 SSRS 之后又改过服务账号密码。解决方案是用报表服务器配置管理器重新创建加密密钥，并重新指定服务账号，之后报表功能完全正常。

5.2 本地搜索与邮件集成的注意事项

v9.0 的搜索功能比老版本智能了一些，但本地部署默认的全文搜索还是基于 SQL Server 的全文索引配合一个独立的搜索服务。部署完成后要确认搜索服务的 Windows 服务是否在运行，并在系统里跑一次全量爬网，否则搜索框里什么都查不到。

配置搜索时有一个小细节很容易被忽略：搜索服务账号必须要有对组织数据库所在目录的读取权限，因为建立全文索引时需要读取表数据。如果搜索爬网日志里频繁出现访问拒绝，先检查这个账号在 SQL Server 实例上的登录映射。

邮件集成方面，本地版可以选择传统的 Email Router（邮件路由器）或者基于服务的服务器端同步。新项目我建议直接用服务器端同步，因为它的配置基本都在 Dynamics 365 客户端界面里完成，不像 Email Router 还要在服务器上安装组件并维护独立的配置文件。邮件集成本身不算部署环节，但它和邮箱服务器、Exchange 服务器的连通性一样依赖网络和服务账号的委派权限，部署完系统后尽早把邮件配置跑通，能提前发现很多权限相关问题。

6. v9.0 本地体验的总结与建议

6.1 一次完整部署的时间与资源感知

我这次从环境准备、软件安装、组织创建、报表扩展到最终能正常登录系统，前后用了整整两个工作日。如果你对这套技术栈已经很熟，也许一个工作日能收工，但第一次部署一定要留足时间。

资源占用上，一台 16GB 内存、4 核 CPU 的服务器，装完 SQL Server、Dynamics 365 Server、SSRS 之后，内存占用大概稳定在 10GB 到 12GB。CPU 在部署和创建组织阶段会持续跑高，这是正常的，不需要为此担心。磁盘空间总共消耗了约 50GB，这还不算后续备份文件、日志文件的持续增长。

6.2 给后来人的一些建议

回顾整个部署过程，我觉得最值得强调的经验可以归纳成几条：

• 无论遇到什么报错，第一件事永远是翻安装日志。日志文件默认放在%ProgramData%\Microsoft\Dynamics 365\Server\log下，搜索error关键字通常比搜索报错弹窗里的文字更有效。
• 服务账号规划要在部署前完成，而不是部署中。账号的 SQL Server 权限、IIS 权限、文件系统权限，一旦中途调整，很可能牵连到已经装好的组件。
• 多机部署时，账号委派是最容易出问题的环节。前端服务器和后端服务器之间通信用的是 Windows 认证，提前在域控里设置好约束委派，能避免大量随机性故障。
• 如果是在生产环境升级到 v9.0，强烈建议先在测试环境完整演练一遍导入升级的流程。不同的历史版本，升级时候选的规则和步骤会有些差异，直接拿生产环境试错风险太大。
• 备份问题一定要提前规划。创建组织库之后，整个系统是否可恢复完全取决于备份策略，而不是 Installation 之后的状态。

坦白讲，Dynamics 365 On-Premise Server v9.0 的部署门槛不算低，但它的文档体系、组件划分和日志规范都是成体系的，只要按顺序做好准备，每一个坑都有迹可循。后续如果再部署第二套环境，我会直接在命令行安装模板里把 SQL 实例、服务账号、证书路径全部固化下来，用同样的脚本在测试和生产环境重复执行，相信整个流程能缩短到三到四个小时。