企业官网建设流程全解析

简介：这份详细图解面向金蝶K/3系统实施、运维人员及企业IT管理员，针对K/3 V12.3服务器在新环境中安装配置流程复杂、组件顺序和环境要求易混淆的问题，提供可对照查阅的操作指南。资源包仅含1个doc文件，约1.97MB，内容按光盘说明、安装方式与顺序、数据库服务部件、中间层服务部件、WEB服务部件、客户端部件、自定义组合安装、自动部署及常见问题分析等模块组织，并给出数据库服务器硬件配置建议、操作系统与数据库引擎支持范围等关键参数。目前已有4815人学习，适合部署前核对环境、安装时确认组件先后关系，以及遇到配置异常时按章节排查，也可作为企业内部分享和交接的参考资料，尤其适合首次搭建测试或生产环境时逐项对照，减少重复试错。

1. 环境检测一跑就红叉：K/3 V12.3 卡在安装第一步的真实原因

K/3 V12.3 的安装流程有个很反直觉的设计：安装盘塞进去它不让你装，先让你换资源盘跑一遍环境检测，检测不过就一个红叉挂在那儿，也不告诉你到底缺什么。我见过最折腾的一次，某公司的实施同事在新服务器上反复重装系统三遍，最后发现问题只是“应用程序服务器”里那两个勾没点。这套详细图解把四个服务部件的检测项、组件开关、配置文件路径全按步骤拆开，也是我后来自查 K/3 安装配置时最常翻的一份资料。这篇按最容易翻车的顺序讲：环境检测为什么红、数据库服务部件装完连不上、中间层加密服务变成演示版、Web 和客户端登录不了，每一段都给根因和能直接照做的验证命令。

2. 环境检测不通过：COM+、网络 DTC 和资源盘的四个必查项

2.1 红叉到底在查什么：装了不等于注册了

环境检测不是一个“看看文件在不在”的工具，它读的是注册表里的组件注册状态和服务运行状态。所以“我明明装了 IIS，检测还是红叉”这种情况特别常见——装了不等于注册了，注册了不等于启用了。检测项大致分四类：操作系统版本与补丁级别、IIS 与 ASP.NET 注册、应用程序服务器里的网络 COM+ 访问和网络 DTC 访问、数据库引擎版本与排序规则。

关键是这四类不是每个部件都查。装数据库服务部件，主要看操作系统和数据库引擎两项；装中间层服务部件，看操作系统和应用程序服务器；装 WEB 服务部件，还要多看 IIS 和 ASP.NET。我一般会先确认自己在检测界面选的是哪个部件，再决定补什么组件——有次一个 A 同学按“服务器全量”的标准把 IIS、ASP.NET 全补齐了，结果他只是装客户端，检测项压根不看这些，白折腾一下午。

操作系统这一层有两个硬性约束容易被忽略：Windows Server 2008 只支持完全安装，服务器核心安装（Server Core）不在支持范围，装上去检测必红；Windows 2000 系列虽然列在支持范围里，但 MSDTC 效能偏低会拖垮整体性能，新环境没有理由再用。另外 Windows Server 2003 打 SP2 之后有个补丁必须补上，后面第 4 章会专门说它。

2.2 应用程序服务器没开：两个勾的正确点法

中间层和 WEB 部件的绝大多数红叉都出在这一步。操作路径是：控制面板 → 添加/删除 Windows 组件 → 勾选“应用程序服务器” → 点“详细资料”，在弹出来的列表里勾上“启用网络 COM+ 访问”和“启用网络 DTC 访问”。如果这台机器还要装 WEB 或人力资源部件，同一个详细资料列表里再加“ASP.NET”和“Internet 信息服务（IIS）”。

这里最典型的翻车姿势是只勾了外层“应用程序服务器”就点确定。外层勾选只是把骨架装上，里面的网络访问开关默认是关的，检测读到的就是“COM+ 存在但不可远程访问”，照样红叉。Windows 2008 的路径不一样，是服务器管理器 → 角色 → 添加“应用程序服务器”角色，再单独添加 IIS 角色和 ASP.NET，勾选位置换了但逻辑一样。

勾完之后用命令行确认一遍，比在图形界面里靠记忆核对可靠得多：

:: 1) MSDTC 服务是否在跑，启动类型是不是自动 sc qc msdtc sc query msdtc :: 2) RPC 端点映射端口 135 是否在监听，中间层和数据库跨机时这一步必须通 netstat -ano | findstr ":135" :: 3) IIS 的 W3SVC 是否启动，只有 WEB/HR 部件才需要看这一条 sc query W3SVC

sc qc看的是配置（启动类型），sc query看的是当前状态，两个都要看——服务是“自动”但当前停着，说明它启动失败了，光改启动类型没用。netstat那条里的 135 是 RPC 端点映射端口，跨机部署时中间层要靠它找数据库上的 DTC 事务协调器，这条不通后面账套管理一定连不上，早点发现比装完再回头查省事。

2.3 DTC 勾了还是报错：MSDTC 的安全配置和日志

网络 DTC 访问勾上只是打开了开关，MSDTC 自身的安全配置没配好，跨机事务照样失败。配置入口在：控制面板 → 管理工具 → 组件服务 → 组件服务 → 计算机 → 我的电脑 → 右键属性 → MSDTC 选项卡 → 安全配置。里面要确认“网络 DTC 访问”勾上，并且入站、出站、事务管理器通信这几项按实际部署形态选对（中间层和数据库在同一台机器上时，这几项反而不该开得太宽）。

多网卡服务器上还有个隐蔽的坑：MSDTC 会自己挑一张网卡做通信，挑到内网管理口或者一块没配路由的网卡，表现就是“配置全对、事务就是不通”。这种情况要在 MSDTC 的网络设置里明确指定使用哪张网卡。

如果 DTC 服务直接起不来，日志损坏是常见原因，我一般按下面的顺序修，前提是业务已经停机：

:: 停掉 DTC 服务 net stop msdtc :: 重置 MSDTC 日志文件（会重建本地事务日志，务必在停机窗口内执行） msdtc -resetlog :: 重新启动服务并确认状态 net start msdtc sc query msdtc

-resetlog只重建日志，不清理已有事务数据，但它对正在进行的事务是破坏性的，所以不能在线做。做完之后别急着点下一步，先用sc query msdtc确认状态是 RUNNING，然后回到环境检测重新跑一遍——DTC 相关的检测项是运行时探测，不是读配置，服务没好它会一直红。

2.4 资源盘切不过去、检测反复失败的处理顺序

K/3 V12.3 是三张盘：安装盘（安装程序、演示账套、资源包、用户手册）、资源盘（检测后缺的系统组件安装程序）、用户手册盘。检测提示缺部件时程序会让你换资源盘，但一台机器只有一个光驱，来回复制镜像是最容易出错的动作。三种安装方式里，DVD 本机安装最快但换盘最频繁；光驱共享网络安装省事，但共享光驱的盘符可能变；把两张盘拷到硬盘固定目录再共享，是现场最稳的做法，路径固定、可重复使用，也不会因为光驱被别的程序占用而失败。

正确的复跑顺序是：先跑环境检测 → 按提示装完所有缺失部件 → 再跑一次环境检测确认全绿 → 最后换安装盘正式装 K/3。中途跳步是另一个高频错误，缺三个部件只装了两个就去装主程序，装到一半会报组件注册失败，比一开始就报错更难查。

还有一条写在文档开头但几乎所有人都会忽略：安装前退出正在运行的第三方软件，包括杀毒软件和相关防火墙，装完再启用。检测阶段被拦截的表现是“明明装完了，重新检测还是红叉”，因为组件注册那一步被拦掉且没有任何提示，是个彻底的黑匣子。

3. 数据库服务部件：排序规则、版本支持和装完连不上

3.1 排序规则定死在安装那一刻，装完改不了

非简体中文环境下最典型的报错是数据库服务器排序规则不符。K/3 要求 SQL Server 的排序（Collation）为Chinese_PRC_CI_AS，其中 CI 表示大小写不敏感，AS 表示重音敏感。英文版或其它语言版的 SQL Server 默认排序一般是SQL_Latin1_General_CP1_CI_AS，装完 K/3 连上去写数据会出各种字符比较、排序、唯一约束的怪问题，严重的时候数据库服务器直接不能正常工作。

要命的地方在于：排序在实例安装完成后不能更改。SQL Server 2005/2008 在安装向导里有一步可以设置排序，SQL Server 2000 则必须走自定义安装才能改，默认安装一路回车就定死了。我一般装完 SQL Server、还没装 K/3 之前就先查一次：

-- 一次查清排序规则、版本类型和补丁版本，装 K/3 之前必须确认 SELECT SERVERPROPERTY('Collation') AS ServerCollation, SERVERPROPERTY('Edition') AS Edition, SERVERPROPERTY('ProductVersion') AS ProductVersion, SERVERPROPERTY('ProductLevel') AS ProductLevel;

三个字段各有用途：Collation必须是Chinese_PRC_CI_AS，不是就趁早重装实例，别等装完 K/3 再发现；Edition用来确认是 Standard 还是 Enterprise，标准版和企业版在支持矩阵里的待遇不一样；ProductVersion配合ProductLevel判断补丁是否到位，SQL Server 2005 要求至少 SP3。

已经装错了排序怎么办？两种做法：一是重建实例（数据还没导进去的时候最省事），二是装一个指定了Chinese_PRC_CI_AS的命名实例，让 K/3 连新实例。第二种做法在多实例环境里很常见，代价是实例名变了，后面中间层配连接时要跟着改。

3.2 版本与平台矩阵：哪些组合能装，哪些装了也白装

数据库引擎这一层是有明确支持矩阵的，不在矩阵里的版本不承诺能跑。把关键几条列出来对照着看：

两条经验：一是 SQL Server 2005/2008 的标准版没有 2GB 物理内存这个限制，可以放心用，被这条限制卡住的只有 SQL Server 2000 标准版；二是上了 SQL Server 2008 又打算用商业分析模块的，要在数据库服务器上额外装“SQL Server 2005 向后兼容组件”，它是 SQL Server 2008 功能包的一部分，不装的话商业分析的相关功能起不来，报错信息还跟数据库连接沾边，很容易查偏方向。

平台架构上还有个容易忽略的分支：64 位 IA64 架构的数据库服务器不支持数据库服务部件安装，影响的是第 4 章要讲的账套新建、备份、恢复这三类操作——它们不能在中间层做，必须直接通过 SQL Server 完成，其它功能不受影响。64 位 x64 架构没有这个限制，所以新采购服务器时选 x64 而不是 IA64，能省掉一堆绕路操作。

3.3 装完连不上库：实例名、TCP 协议和 1024 字节包

数据库服务部件装完，中间层配账套时连不上库，按链路顺序查三段：名字对不对、协议通不通、网络质量够不够。

名字这一段，命名实例要带实例名，默认实例可以直接写主机名或 IP；SQL Server 用非默认端口时，客户端要写成“IP,端口”的形式。协议这一段，SQL Server 默认可能没启用 TCP/IP，只在本地命名管道上监听，本机测着好好的，跨机就通不了。网络质量这一段文档给了明确指标：延时小于 20ms、丢包小于 0.1%，测试基准是 1024 字节的包。

:: 1) 用文档规定的 1024 字节包打 50 个，看平均延时和丢包率 ping -l 1024 -n 50 10.0.0.21 :: 2) 测数据库端口是否可达（默认实例 1433），通不了先查防火墙和 TCP/IP 协议 telnet 10.0.0.21 1433 :: 3) 命名实例要靠 1434 的 SQL Browser 找端口，这条也要通 telnet 10.0.0.21 1434

-l 1024是把包大小定成 1024 字节，小包能通不代表大包能通，MTU 不匹配、链路质量差这些问题只有大包才暴露；-n 50是打 50 个包，够统计出丢包率，打压测别只打 4 个就下结论。telnet 那条测的是 TCP 层可达性，返回空白屏说明端口通了，返回“连接失败”就是被防火墙、SQL Server 网络协议或者端口配置挡住了，此时别去翻 K/3 的日志，问题根本不在 K/3 这一层。

存储这块也有个常被跳过的建议：数据盘做 RAID10，并至少建两个 LUN 分别放生产数据库和临时数据库（TempDB）。TempDB 和业务库抢同一块盘，并发一上来 I/O 排队，表现是“白天卡、晚上顺”，很容易被误判成 K/3 中间层的性能问题。

3.4 容量规划对不上，后面全是玄学问题

文档给的配置建议是按并发数和数据库实体大小分档的，处理器核心数从 2 核起步，4 核对应 100 并发以内或数据库实体 10GB 以内，8 核对应 100 到 200 并发或 10 到 20GB，16 核对应 200 到 400 并发或 20 到 40GB；内存同理，2GB 是底线，4GB、8GB、16GB 按同样档次往上走。这些数字不是随便写的，它决定了后面所有“偶发卡顿”“月末结账跑不动”的解释空间。

现场最常见的是拿一台退役的办公服务器凑合：2 核 2GB 起步，刚好卡在最低线上，装的时候一切正常，一上并发就开始出现各种查不出原因的慢。这种时候回头看配置档位，比在中间层上反复调参数有用得多。存储空间也一样，文档给数据库服务器的最低空闲是 10GB、推荐 50GB 以上，装完系统加 SQL Server 再留出日志增长空间，10GB 那条线基本不够用。

4. 中间层服务部件：注册失败、加密服务演示版、账套管理打不开

4.1 加密服务一直是演示版：虚拟机里的中间层几乎必踩

中间层加密服务不支持在虚拟机里运行，VMWare、Virtual PC 这类环境都算。加密服务在虚拟机中会一直以演示版方式运行，License 文件也导不进去。表现就是：许可文件明明导了、提示也成功了，进系统还是演示版，单据量受限制，重启服务还是老样子，一点变化都没有。

这个坑的恶劣之处在于它不报错。装的时候一切顺利，组件注册也过了，只有加密服务这一项不工作，新手会怀疑是许可文件坏了、版本对不上、机器码算错了，来回换文件换到怀疑人生。其实只要确认中间层所在的操作系统是不是虚拟机，答案当场就出来了。

处理方法只有一条：中间层放在物理机上。虚拟机可以用来装其它中间层组件做测试，加密服务这一项在虚拟化环境里没有绕过去的办法。已经部署在虚拟机上的，要么迁到物理机，要么把加密服务单独放到一台物理机上。规划阶段把这条写进部署方案，比上线后返工便宜太多。

4.2 中间层组件注册失败：时机、权限和被静默打断的自动注册

安装中间层服务部件完成后会自动运行一次“注册中间层组件”，正常流程下不需要手工干预。但这一步被安全软件拦掉、或者安装程序权限不够时，它会静默失败，装完看起来一切正常，实际组件没注册，账套管理打开后各种异常。

手工补注册的路径是：程序 → 金蝶 K3 → 金蝶 K3 服务器配置工具 → 中间层组件注册。执行前确认两件事：当前登录账号是本机系统管理员，且是以管理员身份运行（用户账户控制没把它降权）。这两个条件缺一个，注册会走到一半失败，日志里给的信息也很含糊。

组件注册和账套注册是两件事，很多人搞混：组件注册是把中间层自身的服务组件注册到系统里，账套注册是把已有的账套信息登记到中间层让它认识这个账套。顺序必须是先组件注册、再账套管理里新建或恢复或注册账套。反过来做，账套注册会报找不到中间层服务。

4.3 账套管理连不上库：DTC、补丁号和端口三重门

中间层和数据库分在两台机器上时，账套管理连不上库有三个高频原因，按排查成本从低到高排：补丁没打、DTC 不通、端口被挡。

补丁这一条很具体：中间层服务器的操作系统如果是 Windows Server 2003 并且打了 SP2，必须额外安装微软补丁 KB936296，不打的话组件注册和连接数据库都会出异常。这个补丁不在 K/3 安装包里，装完系统补丁级别又刚好停在 SP2 的时候，最容易漏。

:: 1) 查 KB936296 是否已安装，有输出说明打了，空白说明没打 wmic qfe list brief | findstr 936296 :: 2) 从中间层测到数据库的 RPC 端点，跨机部署必查 telnet 10.0.0.21 135 :: 3) 看本机 DTC 状态，做跨机事务时两边都得是 RUNNING sc query msdtc

wmic qfe list brief列的是系统已安装的更新列表，配合findstr精确匹配补丁号，比在“添加或删除程序”里翻列表快得多。telnet到 135 端口这一步在跨机部署里几乎是必查项，DTC 的通信起点就是它，不通的话后面所有配置都是白做。查到这一步还没问题的，再回头去看第 3 章 3.3 节的端口和实例名，别在中间层上反复重装。

4.4 WEB 与中间层分离部署：一个配置文件里的 localhost

WEB 服务器和中间层分开部署是常见架构，这时人力资源客户端登录会失败，报服务不可用或者连不上。根因通常不在 IIS，也不在加密服务，而在一个配置文件里写死的localhost。

用记事本打开Kingdee\K3ERP\KDHRAPP\IISServer\server\Kingdee.K3.HR.Server.exe.config，里面有一段：

<!-- webservice 的路径，分离部署时必须指向中间层，不能是本机回环地址 --> <add key="k3hrwebservice" value="http://localhost/k3hrwebservice/" />

改成：

<!-- 把 localhost 换成中间层服务器的实际 IP，站点部署在哪台机器就指向中间层 --> <add key="k3hrwebservice" value="http://10.0.0.31/k3hrwebservice/" />

改完不是保存就行，必须重启 KDHRHost 服务让配置生效：

:: 重启人力资源宿主服务，让配置文件里新的服务地址生效 net stop KDHRHost net start KDHRHost :: 确认服务状态是 RUNNING sc query KDHRHost

localhost在单机部署时没问题，一旦 WEB 和中间层分家，它指向的就是 WEB 服务器自己，而那台机器上根本没有这个 Web 服务，请求自然全落空。这类问题的排查成本极低但发现成本很高，因为报错信息只说服务不可用，不会告诉你地址指错了。我现在的习惯是：只要是分离部署，装完先把这个配置文件打开看一遍，别等用户来报障。

5. 常见问题与避坑：五条现场踩出来的记录

5.1 安装阶段的三条：安全软件、光驱共享、管理员权限

现象一：安装到一半报文件写入失败或直接回滚。原因基本都是杀毒软件和防火墙在装的过程中拦截了文件释放和服务注册，而安装程序对这类拦截没有清晰提示。解决方式很直接：装之前把第三方安全软件全部退出，装完再启用。文档里这句话写得很靠前，但现场跳过它的人不在少数。

现象二：走光驱共享网络安装，检测时能找到资源盘，装的时候报路径不存在。原因是共享光驱的盘符在别的机器上会重新映射，安装程序记的是第一次访问时的路径。解决办法是把安装盘和资源盘一起拷到硬盘上的固定目录（比如D:\K3SETUP\），再共享这个目录，用 UNC 路径访问。顺带一句：文档写明了“装完再启用第三方软件”，别装完忘了开防火墙就上生产。

现象三：环境检测怎么跑都红，重装系统都没用。常见原因是当前账号不是本机系统管理员，或者用户账户控制把检测程序降权了，检测读不到组件和服务的真实状态，读不到就按“缺失”处理。解决方式是本机管理员登录，右键以管理员身份运行安装程序。这类“检测不准”的问题比“真的缺组件”更难查，因为它会让你一直往错的方向补组件。

5.2 运行阶段的两条：HR 客户端平台和 32 位浏览器

现象四：Web 和中间层分开部署后，HR 客户端平台登录报服务不可用。原因就是 4.4 节那个配置文件里的localhost。解决方式：改成中间层 IP，重启 KDHRHost 服务。这条坑的迷惑性在于，同一台机器上打开站点首页是正常的，只有登录才失败，容易让人往账号权限方向查。

现象五：64 位 Windows 上 HR/Web 站点打不开或者功能缺失。K/3 的 HR/Web 客户端只支持 32 位浏览器，IE6 SP1/SP2、IE7、IE8 的 32 位版本在支持范围内。64 位 Windows 内置两套 IE，默认调用的虽然是 32 位版，但从某些入口点进去的可能是 64 位那套，表现就是页面加载异常。做法是明确从开始菜单里的 32 位 Internet Explorer 入口打开。普通 K/3 GUI 客户端不需要浏览器，这条只对 HR/Web 客户端成立。

客户端配置这一层还有两个容易被忽略的底线：空闲磁盘 4GB 是底线、推荐 8GB，内存 512MB 是底线、推荐 1GB。现场经常出现“客户端打开就转圈”，查到最后是机器只有 4GB 空间，临时文件和缓存一写就满。

6. 快速定位：一张对照表和三条验证路径

装 K/3 这类多部件系统，最耗时间的不是解决问题，是判断问题出在哪一层。四个部件（数据库、中间层、WEB、客户端）任何一层没配好，表现都是“用不了”，报错还都长得差不多。我后来自查时固定用一张对照表先分层，再动手：

第一条验证路径是链路验证，用命令代替猜测。中间层到数据库这一段，ping -l 1024 -n 50看延时和丢包，telnet IP 135看 RPC 通不通，telnet IP 1433看数据库端口通不通，三条命令跑完，问题在网络上还是在配置上基本就分清了。

第二条路径是状态验证，看服务而不是看界面。sc query msdtc、sc query W3SVC、sc query KDHRHost这三条覆盖了跨机事务、Web 站点和 HR 服务三个关键点，服务是 STOPPED 的时候界面上的任何配置都没意义。

第三条路径是配置验证，重点看三个位置：SQL Server 的排序规则、Kingdee.K3.HR.Server.exe.config里的服务地址、以及中间层组件有没有真正注册过。这三处都是“写错了不报错、只是不工作”的地方，出问题时的排查成本远高于直接看一眼。

从那以后我每次碰这类多部件部署，都强制走一遍顺序：装之前先确认操作系统版本和补丁级别，装完 SQL Server 先查排序规则，装完中间层先确认组件注册和加密服务状态，最后再动 Web 和客户端。这套顺序不是为了规范，是因为跳过任何一步，后面都要花几倍时间从“用不了”倒推回“哪一步没做”。希望帮到你。

本文还有配套的精品资源，点击获取