1. 项目概述与部署背景1.1 为什么选择Dynamics 365 On-Premise v9.0聊到Dynamics 365 On-Premise Server v9.0部署我得先交代下背景。这些年微软在Dynamics 365产品线上的策略很明显云版本Online是主推方向但本地部署版本一直没砍掉原因也很简单还有大量企业对数据主权、网络隔离、合规性有硬性要求尤其是制造业、金融、政府项目或者跨国企业的中国分公司数据不能出境就是刚需。所以本地版v9.0依然有非常稳定的落地场景。v9.0这个版本是微软在2017到2018年之间的本地主推版本和它之前的8.x相比内部架构有了不少变化。最核心的一点是v9.0把Web API统一到了OData v4.0协议前端客户端的用户体验也向云版本对齐。这个版本也是第一个完全支持.NET 4.6.2、SQL Server 2016组合推荐的本地版本。对于准备从老版本比如2011、2013、2015升级上来的团队来说v9.0是一个承上启下的关键节点。我这次部署的目标环境是这样一套配置Windows Server 2016标准版作为操作系统SQL Server 2016 SP2作为数据库引擎Dynamics 365 Server v9.0本地版作为应用服务。因为不需要高可用和负载均衡拓扑相对简单单台应用服务器加单台数据库服务器域环境使用现有AD身份认证采用AD Federation ServicesADFS联合认证。整体属于典型的“标准起步型”部署适合中型企业首次从老版本迁移或新项目搭建。1.2 部署前必须想清楚的几个核心问题在真正动手装Dynamics 365 On-Premise之前我建议每一个负责人先把这个版本的三层概念理清楚。这是整个部署体验里最容易踩坑的第一步也是“为什么后期问题少”的分水岭。Dynamics 365 Server v9.0本地版本本质上是“应用程序服务器”它主要承载的是组织Organization、解决方案、工作流、插件逻辑等应用层能力对外提供Web服务。SQL Server角色极其重要Dynamics 365的业务数据、配置数据、审计数据全部落在SQL Server里数据库层的设计直接决定了性能上限。身份认证层ADFS/本地AD不是可选项v9.0本地标准推荐是ADFS Claims认证这一点很多人第一次部署时会忽略。如果只是单机体验可以用AD集成认证先跑通但生产环境建议直接上ADFS否则后面组织部署、Outlook插件、移动端接入都会出现认证问题。我在规划时采用的方案是ADFS用于Web端和客户端的联合登录AD域账号作为底层身份源SQL Server使用专用服务账号运行Dynamics应用池账号与SQL账号分离。这套方案虽然前期配置多一步但后期维护和排障会轻松很多。说白了部署Dynamics最怕的就是“贪快图省”前期把认证和权限模型搭得干净后面所有功能模块才能稳定跑。2. 环境准备与安装前置条件2.1 硬件与软件配置清单先说结论Dynamics 365 Server v9.0对硬件的要求并不算极端但也不能太小气。微软官方文档给的最低配置是8GB内存、四核CPU、80GB磁盘但那仅仅是“能装起来”的门槛。我的建议是这样基于我自己以及周边几个项目的实测角色CPU内存磁盘备注Dynamics 应用服务器8核32GB200GB SSD操作系统和程序文件分开SQL Server 数据库服务器8核32GB500GB SSD数据和日志分开磁盘ADFS 服务器4核8GB80GB可与应用服务器复用测试环境域控制器4核16GB120GB必须提前准备我这次测试环境是单机承载应用、ADFS、SQL三个角色32GB内存、8核CPU跑起来在并发用户数低于50人时完全流畅。但如果你要做性能测试或者生产环境建议严格按照上表的物理或虚拟机角色隔离。软件层面必须按这个清单准备Windows Server 2016标准版务必打全最新补丁SQL Server 2016 SP2建议直接装SP2或以上补丁否则后面报表服务安装可能报错Dynamics 365 Server v9.0安装介质从微软批量许可服务中心下载ISOADFS角色Windows Server自带不需要单独安装包Visual C Redistributable 2015部分报表组件依赖.NET Framework 4.6.2系统自带或离线安装包报表扩展组件SQL Server Reporting Services 20162.2 域环境与DNS规划Dynamics 365 On-Premise和域环境的关系比SharePoint还要紧密。原因在于整个认证链路是Kerberos 声明Claims如果域环境有问题后面所有操作都会连锁报错。部署前一定要把这几个基础配置核对清楚域功能级别建议至少Windows Server 2012 R2以上方便ADFS正常注册和证书使用。DNS记录为应用服务器、ADFS服务器分别创建稳定的A记录不要用IP地址乱配。Dynamics对主机名非常敏感主机名一旦变更后配置缓存和数据库里的URL全部要跟着改。服务账号创建专用服务账号如svc_dynamics、svc_sql、svc_adfs并配置好“密码永不过期”和委派权限。千万不要用域管理员直接跑服务安全问题不说后面修改密码时整个应用都会挂。证书规划ADFS和Dynamics的HTTPS通信都需要证书。测试环境可以用AD CS自主签发的证书但必须确保该证书在服务器本地受信任且名称和访问URL完全匹配。实际操作中我遇到很多人在这一步直接用IP地址装结果到配置ADFS时发现token端点IP和证书域名对不上又重来。所以这里重点提醒主机名和证书规划是部署Dynamics的前置条件没有任何捷径可走。你花30分钟把DNS和证书理清楚后面省下的时间至少是3小时起步。2.3 SQL Server安装与配置要点SQL Server在Dynamics部署中不是“装完即可”而是有多个关键配置要提前做好。我这次用的是SQL Server 2016 SP2标准版整个过程比较顺利但有几个点必须注意排序规则Dynamics 365本地版要求SQL Server使用Latin1_General_CI_AI或兼容的排序规则。这个和中文环境关系很大如果装SQL时选了默认的Chinese_PRC_CI_AS后面创建组织时大概率报“排序规则不匹配”。这个坑我见过不少。服务账号SQL Server服务和SQL Agent服务都建议用专用域账号运行并给账号在数据目录上授予完全控制权限。Dynamics在创建数据库时会用安装时指定的账户执行大量SQL任务权限不够会直接失败。混合模式或Windows认证安装时选择“Windows 认证模式”即可Dynamics应用服务器会通过应用池账号连接数据库。内存配置在SQL Server实例中建议设置最大服务器内存为物理内存的80%左右避免操作系统和Dynamics应用因为内存争抢出现奇怪问题。装完SQL后记得到“SQL Server配置管理器”里确认TCP/IP协议已启用因为Dynamics连接数据库默认走1433端口如果你装了但没启用TCP/IP后面会等超时然后报“无法连接数据库服务器”。3. 部署实操与关键环节实现3.1 安装Dynamics 365 Server v9.0的完整流程准备工作就绪后正式开始Dynamics 365 Server v9.0的安装。整个安装包是向导式界面分为几个大步骤先检查必备组件再选择部署角色接下来配置服务账号、站点、身份认证方式最后完成安装并运行配置向导。下面把关键环节拆开讲。第一步挂载ISO镜像运行SetupServer.exe。安装程序会先检查“必备组件”如果缺失会提示安装。常见的缺失项包括.NET Framework 4.6.2、Visual C Redistributable等。我建议直接检查完一次性补装不要反复重启再去点下一步。第二步选择“安装Dynamics 365 Server”。安装界面里有一个“选择角色”的选项这里要区分清楚Server角色包含完整功能前端Web、异步服务、沙盒处理服务、部署管理工具等而仅工具角色只安装部署管理器和命令行工具。完整部署必须选“Server”。第三步配置服务账户。这一步是整个安装中我建议最谨慎的地方。安装向导会要求你设置Dynamics应用程序池的账户这里有两个常见选择一是使用“NetworkService/本地系统账户”二是使用专用域账号。测试环境用NetworkService可以跑通但生产环境强烈建议专用域账号。因为异步服务、沙盒服务、部署服务都需要在域环境中访问SQL和ADFS使用NetworkService会导致跨服务器访问受限后面你会不断遇到权限类报错。第四步配置网站设置。安装向导会让你绑定Dynamics站点的端口和HTTPS证书。我在测试环境使用了https://crm.contoso.local作为访问地址绑定443端口。这一步核心是如果使用HTTPS证书必须已经安装在本机“证书本地计算机→个人”目录下且私钥与当前安装账户可访问。第五步等待安装完成。中间过程会创建Microsoft Dynamics 365相关的Windows服务如MSCRMAsyncService、MSCRMSandboxService、MSCRMDeploymentService等以及部署数据库MSCRM_CONFIG。安装完成后打开部署管理器确认服务器状态显示“已启用”。3.2 配置身份认证ADFS联合认证的完整步骤v9.0本地版的重头戏是认证。我之所以反复提醒ADFS是因为很多人在第一次部署时没有认真对待这一层直接用AD集成认证跑通后面每次客户端登录都提示“登录失败:failed to start login server: 以一种访问权限不允许的方式做了一个访问套接字”回头再折腾ADFS反而浪费时间。ADFS联合认证的核心逻辑是这样Dynamics不再直接校验AD账号密码而是把认证请求重定向到ADFS服务器ADFS验证AD账号后向Dynamics颁发一个安全令牌。Dynamics通过信任该令牌来确认用户身份。这个模式好处很多多点登录、多系统单点登录、集中管理密码策略也避免了Dynamics直接接触域账号安全问题。配置步骤在ADFS服务器上安装ADFS角色Windows Server 2016的服务器管理器→添加角色和功能→AD FS部署类型选择“独立联合服务器”或“联合服务器场”。申请并绑定一个HTTPS证书到ADFS站点证书名称务必和ADFS对外访问地址一致比如sts.contoso.local。在ADFS管理控制台创建“信赖方信任”信赖方标识Identifier写Dynamics的实体ID通常是访问URL加/。配置信赖方信任的签名规则和转换规则最核心的是把Name ID映射成AD的userPrincipalName或sAMAccountNameDynamics需要从令牌里解析出唯一用户标识。回到Dynamics部署管理器右键“部署属性”选择“身份认证”选项卡填入ADFS的元数据地址通常是https://sts.contoso.local/FederationMetadata/2007-06/FederationMetadata.xml和Dynamics站点的登录地址。整个过程比较容易出错的是第4步规则配置。很多人卡在“登录失败:login server error: token exchange failed: token endpoint returned status 40”或“failed to start login server”基本都是规则没有正确映射用户标识或者证书名称对不上导致令牌交换失败。我建议在配置规则前先在浏览器里访问ADFS元数据地址确认证书和端点完全正常再继续下一步。3.3 创建组织Organization与部署报表服务Dynamics安装完成后系统中还没有任何业务组织。你需要通过“部署管理器”→“组织”节点新建一个组织。创建组织类似初始化一个业务系统实例它会指定一个SQL Server实例作为宿主并且在其中创建多个数据库包括组织数据库、日志数据库等。创建组织的关键配置名称组织的唯一名称比如CRM_Production建议不要用中文或特殊字符。SQL Server实例填写数据库服务器实例名点击测试连接确保前面步骤里准备的账号能正常访问。数据库排序规则安装Dynamics的排序规则会自动匹配SQL实例但如果SQL实例排序规则不统一组织创建会报错。我在SQL Server 2016 SP2环境下保持默认值直接通过。报表服务器URL如果你想使用Dynamics内置的报表功能需要在SQL Server上安装SSRSReporting Services并配置报表服务器URL。v9.0在创建组织时会检查报表环境如果发现没有SSRS组织能创建成功但报表功能不可用。这个要注意报表扩展组件必须在运行Dynamics安装向导前就装好否则安装程序不会自动检测到新的SSRS实例。组织创建过程耗时取决于服务器性能一般5到15分钟。等待时不要关闭窗口否则可能会留下半初始化的数据库后续清理会麻烦很多。4. 常见问题与排查技巧实录4.1 SQL Server连接不稳定与登录失败问题这类问题是本地部署出现频率最高的。我整理了三个典型场景全部是我实际遇到过且解决了的问题场景一Dynamics安装完成后Web端访问页面长时间转圈后报错“无法连接数据库”排查思路先确认SQL Server的TCP/IP协议是否启用然后确认Dynamics服务的应用池账号对SQL Server是否具有登录权限。最常见的修复是在SQL Server中显式创建登录名并赋予dbcreator和securityadmin权限。千万不要只给public角色否则组织创建会中途失败。场景二ADFS登录页面可以打开但输入账号密码后提示“登录失败:failed to start login server”这个报错在Windows Server上比较典型原因往往有两个。第一个是Dynamics异步服务或Web服务的端口被防火墙拦截导致ADFS无法回调Dynamics站点。第二个是ADFS使用的SSL证书强度不够Windows Server 2016对证书密钥长度和安全策略更严格。我建议统一使用1024位以上证书最好2048位并且确保证书链完整根证书和中间证书都在服务器受信任列表中。场景三SQL Server报“the last packet sent successfully to the server was 0 milliseconds ago”这种情况多数是网络层面不稳定或SQL实例连接数超限。Dynamics在并发压力下会频繁建立SQL连接如果SQL最大连接数设置过小就会间歇性出现“最后一个数据包发送成功”的报错。解决方案是在SQL Server实例的高级属性中将“最大并发连接数”调整为0表示不限制同时检查交换机、防火墙对1433端口是否有连接数限制。4.2 常用排查工具与诊断命令在实际部署中快速定位问题比盲目重装重要得多。这里分享几个我反复使用的工具和命令都是免费且有效的Dynamics部署管理器第一排查入口。查看服务器状态、组织状态是否“已启用”任何失灵先从状态颜色判断。事件查看器Windows日志中的应用程序日志和Dynamics相关日志会记录详细错误堆栈。ADFS错误通常在AD FS/Admin日志里SQL连接失败则会在MSSQLSERVER日志中体现。PowerShell命令Dynamics v9.0自带了部署相关的PowerShell模块可以用Get-CrmOrganization、Get-CrmDeploymentSetting等命令快速检查部署配置。SQL Server Profiler如果怀疑SQL层面问题可以用SQL Profiler监控Dynamics发出的SQL语句辅助判断有哪些语句执行超时或出错。网络抓包工具如WiresharkADFS令牌交换失败时用Wireshark抓包看HTTP状态码和重定向链路定位是哪个环节被拦截或跳转失败。我印象里最深刻的一次排障是ADFS登录页面一直正常但登录后Dynamics站点返回403查了半天没有任何组件报错。最后用F12开发工具看到请求指向的URL是http://而站点是https://原来是Dynamics站点绑定设置里外部访问URL的协议被我误配成http导致令牌回跳时走了明文端口。这种问题不用抓包光看表面真不容易发现。4.3 运维阶段必须注意的备份与恢复策略本地部署的Dynamics 365 Server v9.0备份策略比云版本更依赖团队自己扛。我强烈建议形成一套固定的备份清单至少包含两块信息数据库备份Dynamics部署数据库MSCRM_CONFIG、组织数据库OrganizationName_MSCRM、日志数据库OrganizationName_MSCRM_log都要定期备份。这三者是业务数据的核心少一个都不完整。应用配置备份Dynamics服务器的配置可以通过部署管理器导出ADFS的配置建议使用ADFS PowerShell命令Export-AdfsDeploymentSQLScript导出备份。证书备份HTTPS证书和ADFS令牌签名证书都需要导出pfx备份且在恢复时注意私钥权限。恢复演练这块我在真实环境里做过一次完整恢复从零搭建一台新应用服务器然后通过数据库还原Dynamics部署管理器关联组织的方式成功把整套环境拉起来。整个过程其实并不复杂核心是把新部署服务器的名称、证书、ADFS配置保持一致再指向同一个SQL Server实例即可。只要能保证SQL数据库和ADFS完整应用服务器几乎可以无损重建。4.4 安装过程中容易被忽略的冷门细节最后聊几个冷门但重要的细节这些在官方文档里都有但不踩坑的话没人会主动注意。时区设置Dynamics服务器、SQL Server、ADFS服务器的系统时区要保持一致建议全部用UTC8。时区不一致会导致令牌有效期判断错乱用户登录后很快掉线。虚拟内存/页面文件Windows Server 2016在内存占用高时如果页面文件配置太小Dynamics异步服务会频繁崩溃。建议页面文件设置为物理内存的1.5倍左右。杀毒软件排除目录如果有第三方杀毒软件务必将Dynamics安装目录、SQL数据目录、ADFS日志目录加入白名单。杀毒软件扫描会导致数据库文件被临时锁住报出各种莫名奇怪的IO异常。不要在同一台服务器上同时安装多个Dynamics版本v8.x和v9.0的部署管理器可能冲突即使使用不同数据库实例也会因为Web服务端口和程序集版本产生潜在问题。升级补丁问题v9.0之后的积累更新建议按顺序打不要跳版本。跳版本虽然偶尔能装上但组织升级时的数据迁移脚本可能因为缺少中间版本导致失败。5. 部署完成后的功能验证与使用建议5.1 快速验证部署是否成功部署完成后不建议立刻开始业务配置先做三轮小验证确保基本盘稳固。第一轮验证Web登录。浏览器访问https://crm.contoso.local输入AD域账号确认ADFS跳转、令牌签发、Dynamics组织加载都正常。登录成功后能进入默认的Dashboards界面说明应用服务器和数据库链路已经通。第二轮验证Dynamics桌面客户端。安装Office的Dynamics 365客户端配置组织URL确认能通过同一套认证机制登录并看到数据。这一步能暴露Web端检测不到的问题比如客户端服务发现、跨域会话等。第三轮验证异步工作流和插件运行。在系统中创建一个简单的流程如自动分配记录触发一次运行查看异步服务日志有没有异常。如果异步服务没有报错说明后台处理链路通畅这对后续自定义开发至关重要。5.2 与SQL Server、ADFS的日常协同优化在持续使用中三者之间的配合还有很多可以优化的地方。以SQL Server为例Dynamics的数据库表很多组织数据库可能有几千张表索引维护和统计信息更新非常重要。建议每周末执行一次全库索引重建和更新统计信息避免系统运行三个月后查询越来越慢。ADFS方面建议定期检查ADFS的签名证书是否临近过期。ADFS证书过期时用户登录会直接失败而且错误提示不怎么明显。我个人的习惯是设置证书监控提前一个月收到提醒然后安排维护窗口轮换证书。另外Dynamics异步服务的队列积压情况也值得监控。如果发现大量异步操作卡在“等待”状态优先检查Sandbox服务是否启用以及服务账号对队列数据库的访问是否正常。排障时可以直接在部署管理器里右键异步服务查看运行状态确认不再需要手动处理冷门任务让系统自动完成即可。5.3 后续扩展方向从单服务器到农场架构如果你的业务规模预期会增长建议提前了解从当前单服务器拓扑升级到多服务器农场的路径。Dynamics 365 Server v9.0支持前端服务器和后台服务器分离部署前端服务器承载Web和应用后台服务器承载异步服务、沙盒服务。将来用户量大了可以把不同角色分散到多台机器上并在最前方加负载均衡器。SQL Server也可以升级为AlwaysOn可用性组实现更高可用性。部署模式上Dynamics同时提供了“规模扩展”和“故障转移”两种理念前者靠增加服务器数量提升性能后者通过冗余避免单点故障。这套演进思路和当初你决定从Online回归On-Premise的考量是一脉相承的——自己掌握基础设施同时也需要自己掌握扩容和容灾能力。以我个人的经验来看Dynamics 365 On-Premise v9.0部署最大的价值其实不在安装本身而在部署过程中被迫建立的“全局思维”。你必须同时理解Windows服务、SQL数据库、ADFS认证、DNS证书、ITSM运维规则这几个不同层级的事情才能保证整套系统稳定运行。这个过程虽然磨人但走完一遍之后你对企业级本地应用的理解深度会有质的提升。如果是在测试环境练手别怕报错报错越多的部署收获越多。