单机SMC2.0部署排错：9%加固报错与SQL Server安装升级

简介：面向华为视讯会议系统实施与运维人员的单机SMC2.0部署参考文档，聚焦操作系统与数据库环境的选型、安装及升级，解决版本兼容判断和现场落地问题。压缩包内含1个docx文件，约11.66MB，以图文步骤组织内容。文档覆盖Windows Server 2012 R2配SQL Server 2014 Express SP2、Windows Server 2016配SQL Server 2016 Express SP2、Windows Server 2019配SQL Server 2019 Express三套组合，并补充SQL Server 2008 Express SP2升级路径、数据库管理工具说明及操作系统与SMC推荐版本附录。其价值在于把安装前准备、数据库配置和典型故障处理串成完整链路，FAQ部分涉及不支持当前操作系统、安装到9%报错、VC2017依赖失败、.NET Framework与SQL Server安装包缺失、BCP路径异常、数据库连接超时、证书导入失败等十余类问题，便于对照排查。目前已有752人学习，适合需要完成单机部署和升级排障的初、中级实施人员参考。

1. 安装到 9% 就报错：单机 SMC2.0 的部署为什么总卡在装机和装库

单机 SMC2.0 部署最容易翻车的环节，不是业务配置，是装机和装库这两步最不起眼的活。典型现场：Windows Server 装完、SQL Server 跑通，双击安装包，进度条走到 9% 停住，弹出「无法在当前操作系统应用系统加固」。回头看系统信息，版本对得上、补丁也打了、重启三次还是 9%。这类检查把操作系统版本、补丁顺序、计算机名、登录账户、防火墙状态全揉进同一个判断点，任何一项不满足，都只给你一句相同的提示。

这份单机 SMC2.0 操作系统和数据库安装指导，把 Windows Server 2012 R2、2016、2019 三套组合的装机步骤、SQL Server Express 的安装与升级路径，以及 18 条典型安装升级失败的处理方法收在一起。下面按「现象—根因—怎么改」拆开写，对着进度条停住的位置直接翻对应章节即可。

2. 装系统这一步就翻车：SMC 不支持当前操作系统与 9% 加固报错

装机环节的报错有个共同特点：提示语和真实原因基本对不上。「SMC 不支持当前操作系统」这句话，可能是版本真的不对，也可能是装成了 Server Core、语言包不匹配、补丁没打全。我一般的顺序是先把版本、安装类型、补丁、计算机名这四项过一遍，再去看安装日志——9% 那个检查点，判断依据就是这四项，日志里翻不到更多信息，因为它根本没走到写详细日志的阶段。

2.1 三套组合先对表，安装类型选错等于白装

支持的组合只有三套，不能交叉。2019 配 2014 Express、2016 配 2019 Express 这类搭配都不在推荐范围内，报错往往出现在很后面的数据库连接阶段，排查成本翻倍。

操作系统	数据库	现场适用说明
Windows Server 2012 R2 标准版	SQL Server 2014 Express SP2	存量现场居多，补丁步骤最长
Windows Server 2016 标准版	SQL Server 2016 Express SP2	折中方案，升级路径清晰
Windows Server 2019 标准版	SQL Server 2019 Express	新装优先选这套

安装类型是第一个坑。安装向导里会列出Server Core Installation和Server with a GUI两个选项，必须选带 GUI 的那个。Server Core 没有图形界面，SMC 安装程序调不起必要的交互组件，装到一半会以各种莫名其妙的方式失败，而且提示语完全指不到根因上。安装方式选「自定义：仅安装 Windows」，已有分区全部删除后重新格式化，C 盘建议不少于 80G——数据库文件、安装临时文件、日志都往 C 盘落，空间不够时数据库创建会直接失败。

整个系统安装过程大概 90 分钟，中途会多次自动重启，属于正常现象，不要去手动断电干预。另外有一条容易被忽略：数据库的排序规则和语言要跟操作系统语言保持一致，中文系统配英文实例，后面创建数据库、执行脚本时都可能因为排序规则冲突报错。

装完系统先别急着装数据库，把补丁打完。顺序错了，9% 的加固检查就会拦下来。

2.2 补丁顺序错一个，9% 就给你加固失败

9% 处提示「无法在当前操作系统应用系统加固」，绝大多数情况不是系统版本不支持，是补丁没按顺序打全。加固脚本会读系统版本号、补丁级别、语言区域，任何一个不匹配就中止，提示语统一成这一句。

2012 R2 这套的补丁必须按下面的顺序逐个双击安装，中间提示重启就重启，重启后从下一个继续：

1. Windows8.1-KB2919442-x64.msu
2. Windows8.1-KB2919355-x64.msu
3. KB2932046、KB2959977、KB2937592、KB2938439、KB2934018（属于 KB2919355 之后的连续更新）
4. NDP472-KB4054530-x86-x64-AllOS-ENU.exe（.NET Framework 4.7.2）

安装时有四条硬规矩：补丁存放路径不能包含中文字符，否则部分 .msu 双击后直接没反应；必须严格按顺序装，跳着装会出现「前置更新未安装」；提示需要重启就先重启；如果提示The update is not applicable to your computer或xxxx is already installed on this computer，说明这个补丁已经在了，跳过继续下一个，不要反复重试。全部装完后重启一次系统，再开始装数据库。

装完可以用命令核一遍，省得靠记忆：

# 列出本次关心的几个补丁是否命中，InstalledOn 为空说明没装上 Get-HotFix | Where-Object { $_.HotFixID -in @('KB2919442','KB2919355','KB2932046','KB2959977','KB2937592','KB2938439','KB2934018') } | Select-Object HotFixID, InstalledOn # 单独确认 .NET Framework 版本：Release 461808 对应 4.7.2，低于这个值说明没装到位 Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' | Select-Object Version, Release

Get-HotFix走的是 Win32_QuickFixEngineering，部分 .msu 补丁不会出现在列表里，所以它返回空不代表没装，还要配合「更新历史记录」界面一起看。Release这个 DWORD 值才是判断 .NET 版本的可靠依据：461808 是 4.7.2，461814 是 4.7.2 之后的修订，低于 461808 就必须补装 NDP472 那个包。这条命令我每次装完系统都会跑一遍，比翻控制面板快。

2.3 计算机名和登录用户名撞了，同样卡在 9%

安装到 9% 报「计算机名和当前登录用户名一致」，看着像玄学，其实是判断逻辑撞车了。安装脚本会用当前登录账户名去匹配实例目录和服务账户，当计算机名恰好等于登录用户名时，两段判断走岔，脚本直接终止。

两条命令就能确认：

:: 输出当前计算机名 hostname :: 输出当前登录账户，格式为 计算机名或域名\用户名 whoami

如果hostname返回administrator，而whoami返回administrator\administrator，就是中招了。改法很简单，改名重启，用内置管理员账户重新登录再跑安装：

# 计算机名建议大写英文加数字，不超过 15 个字符，不要用中文 Rename-Computer -NewName "SMC-NODE01" -Restart

改名的几个注意点：不要与administrator、admin、sa这类内置账户同名；不要带下划线和特殊符号，部分脚本解析会出问题；改完必须重启，只改不重启等于没改。改完名之后，之前创建的本地用户如果还叫原来的名字，也要一并改掉，否则同一个判断还会再触发。

2.4 0x800F0906：.NET 3.5 装不上，后面全卡住

数据库管理工具安装到特性检查阶段，会要求系统具备 .NET Framework 3.5。手动去「服务器管理器 → 添加角色和功能」勾选时，常见报错是0x800F0906、0x800F081F、0x800F0907，本质都是同一个原因：系统默认不从 Windows Update 拉取 .NET 3.5 的源文件，或者更新源被策略挡住了。

解决办法是挂载同版本的系统镜像，把sources\sxs目录当成安装源：

:: D: 换成你实际挂载 ISO 的盘符，sources\sxs 是镜像里的 .NET 3.5 组件目录 dism /online /enable-feature /featurename:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

/All表示同时启用该功能的父功能，/Source指定组件源路径，/LimitAccess阻止 DISM 联网找 Windows Update——内网环境不加这个参数会卡很久然后超时失败。执行完回到安装向导点「重新运行」，状态从「警告」变成「已通过」再继续。

装完 .NET 3.5 之后，管理工具的安装才能真正往下走。这一步的顺序不能反：先装 3.5 再装管理工具，中间不要插其他安装动作。

3. 数据库这一步最会骗人：sa 登录超时、BCP 找不到与实例名踩空

SQL Server Express 是免费版，有三个默认行为决定了后面一半的报错：实例名固定为SQLEXPRESS、TCP/IP 协议默认不启用、安装包不自带管理工具。装的时候一路点「默认」很爽，装完 SMC 连不上就开始抓瞎。这一章按报错出现的先后顺序排。

3.1 规则检查里的「防火墙 警告」不是提示，是阻断

SQL Server 安装的规则检查页面，如果「Windows 防火墙」这一项显示「警告」，很多人会点下一步硬装，结果装到一半失败。这个警告不是走过场的提示，安装过程需要临时开命名管道、共享内存和端口监听，防火墙拦下来就是直接失败。

部署阶段最省事的做法是先关防火墙，装完再开回来：

:: 关闭所有配置文件的防火墙（部署阶段临时操作） netsh advfirewall set allprofiles state off :: 确认当前状态，三个配置文件都应为 OFF netsh advfirewall show allprofiles state

装完之后必须恢复，不要图省事一直关着：

:: 恢复防火墙 netsh advfirewall set allprofiles state on :: 如果只想放行数据库端口，用这条替代全关 netsh advfirewall firewall add rule name="SQL1433" dir=in action=allow protocol=TCP localport=1433

回到规则检查页面点「重新运行」，等「Windows 防火墙」变成「已通过」再往下。如果关了防火墙仍然警告，检查是不是装了第三方安全软件，它拦的是同一个层面，netsh关不掉。

3.2 混合模式与 sa：登录超时的第一层根因

数据库引擎配置那一步，一定要选「混合模式」，并设置 sa 密码。选了「Windows 身份验证模式」，本机用 Windows 账户能连，但 SMC 服务是用 sa 连的，后面必然报登录超时。这个坑新装时埋下，往往到联调阶段才暴露。

装完先验证登录模式：

-- 返回 0 表示混合模式，1 表示仅 Windows 身份验证 SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') AS OnlyWinAuth; -- 确认实例版本与位数 SELECT @@VERSION;

如果返回 1，改注册表后重启服务生效：

-- 2 表示混合模式，1 表示仅 Windows 身份验证 EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'LoginMode', REG_DWORD, 2;

改完用服务管理器重启MSSQL$SQLEXPRESS，再测连接：

:: 用 sa 账户连一次，能返回 1 说明认证链路通了 sqlcmd -S .\SQLEXPRESS -U sa -P "你的sa密码" -Q "SELECT 1"

这一步要分清两类报错：提示「登录超时已过期」是网络层或实例层没通，跟密码无关；提示「登录失败，用户名或密码错误」才是凭据问题。前者去查 TCP/IP 协议和端口，后者去查 sa 是否启用、密码是否被改过。把这两类混在一起排查，是最常见的绕远路。

TCP/IP 没启用也会表现为超时。查一下协议状态：

# MSSQL12 对应 SQL Server 2014，2016 是 MSSQL13，2019 是 MSSQL15 Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL12.SQLEXPRESS\MSSQLServer\SuperSocketNetLib\Tcp' | Select-Object Enabled

Enabled为 0 时改成 1 并重启实例，或者在 SQL Server 配置管理器里把 TCP/IP 状态改成「已启用」。改完用netstat -ano | findstr :1433确认端口真的在监听，别只看配置。

3.3 BCP 不是默认路径：安装脚本调不到命令行工具

安装到中途报「BCP 不是默认路径导致安装失败」，这个报错很直白，但容易误判成数据库没装好。实际上 SMC 安装过程中会调用bcp.exe批量导入初始数据，它按固定路径去找这个可执行文件。如果 SQL Server 装到了非默认盘，或者系统 PATH 被其他软件改过，就找不到。

先定位：

:: 看当前 PATH 里能不能解析到 bcp where bcp

正常情况下应该返回类似C:\Program Files\Microsoft SQL Server\110\Tools\Binn\bcp.exe的路径，110 对应 SQL Server 2014，2016 是 130，2019 是 150。如果返回「找不到文件」，就手动补进系统 PATH：

:: 把 Binn 目录追加到系统级 PATH，/M 表示写系统变量，需要管理员权限 setx PATH "%PATH%;C:\Program Files\Microsoft SQL Server\110\Tools\Binn" /M

/M是关键参数，不加只影响当前用户，而安装程序是以服务账户身份跑的，读不到用户级变量。改完必须新开一个命令行窗口验证，旧窗口的环境变量是快照，不会刷新。

:: 新窗口里验证，能打印出版本和用法说明就算通过 bcp /?

一个提醒：setx写入的 PATH 长度上限是 1024 字符，PATH 本来就很长的机器会被截断，症状是重启后一堆命令都找不到。这种情况下改用图形界面「系统属性 → 环境变量」编辑，或者直接改注册表，别用setx。

3.4 The net service has not been started：实例名、服务名、浏览器三件事

报The net service has not been started, please check!，字面意思是网络服务没起来，实际要检查三样东西：数据库实例服务、SQL Browser 服务、实例名写法。

# 一次看清三个相关服务的状态和启动类型 Get-Service -Name 'MSSQL$SQLEXPRESS','SQLBrowser','SQLSERVERAGENT' | Select-Object Name, Status, StartType

MSSQL$SQLEXPRESS是实例本身，必须 Running；SQLBrowser负责 UDP 1434 上的实例名解析，命名实例.\SQLEXPRESS能不能被解析到全靠它；SQLSERVERAGENT在 Express 版本里本来就不存在，它显示为缺失是完全正常的，安装程序不会因为它失败——很多人看到这里三条里少一条，以为装漏了，反复重装，纯属浪费时间。

启动并设为自启：

# 实例服务设自动并拉起 Set-Service -Name 'MSSQL$SQLEXPRESS' -StartupType Automatic Start-Service -Name 'MSSQL$SQLEXPRESS' # SQL Browser 同样设自动，命名实例解析依赖它 Set-Service -Name 'SQLBrowser' -StartupType Automatic Start-Service -Name 'SQLBrowser'

服务起来之后如果还报同样的错，问题多半在实例名写法上。默认实例写.或(local)，命名实例写.\SQLEXPRESS或主机名\SQLEXPRESS，写成localhost:SQLEXPRESS这种混搭格式，解析必然失败。接线的时候统一用.\SQLEXPRESS最省心，机器改名也不受影响。

另外提一句管理工具：Express 安装包不带 SSMS，需要单独装。管理工具的版本要跟实例版本匹配，用 2008 的 Management Studio 连 2019 的实例，界面能开但很多对象看不到，排查问题时容易得出错误结论。

4. 升级比新装更折腾：脚本执行失败、证书卡住与状态不一致

升级是在已有数据上动刀，失败之后不能像新装那样删库重来。这一章的报错集中在升级流程的中后段，共同点是表面上提示一个动作失败，真实原因在几步之前。

4.1 从 2008 Express SP2 升到 2014 Express SP2：先确认能升

原位升级有明确边界：目标实例名必须与源实例一致，排序规则必须一致，跨度过大（比如 2005 直升 2014）需要先升到中间版本过渡。升级前把这两项记下来，出问题时能省掉大量猜测：

-- 记录实例名、排序规则、兼容级别，升级前后对比用 SELECT name, collation_name, compatibility_level FROM sys.databases WHERE name IN ('master','SMC');

升级前必须备份SMC库和master。备份不是走流程，master里存着登录账户和实例级配置，升级中途失败时它是唯一的后悔药。

升级完成的验证分两步，先看版本，再看数据完整性：

-- 确认已到目标版本 SELECT @@VERSION; -- 检查数据库逻辑与物理一致性，有错误会直接列出来 DBCC CHECKDB('SMC') WITH NO_INFOMSGS;

兼容级别可以保留原值，也可以提到 120（对应 2014）。提上去之后降不回来，所以顺序是：先备份、再验证业务、最后才调级别。

-- 提升到 2014 兼容级别，执行前确保备份可用 ALTER DATABASE SMC SET COMPATIBILITY_LEVEL = 120;

升级完成后管理工具也要同步换成对应版本，否则连上去看不到新版本的系统视图，会误判成升级没成功。

4.2 执行 ViewAndStoredprocedure.sql 失败：先单独跑一遍脚本

升级到某一步弹出「执行脚本 ViewAndStoredprocedure.sql 失败」，安装程序只告诉你失败，不告诉你为什么。四种常见原因：执行账户权限不足、旧库里残留同名视图或存储过程、数据库兼容级别过低导致语法不支持、脚本文件路径含中文或被安全软件锁住。

脱离安装程序单独跑一遍，错误信息会完整很多：

:: -d 指定目标库，-b 遇错立即返回非零，-o 把完整输出写到日志 sqlcmd -S .\SQLEXPRESS -U sa -P "你的sa密码" -d SMC ^ -i "D:\smc\script\ViewAndStoredprocedure.sql" ^ -b -o "D:\smc\log\vsp.log"

-b这个参数很关键，不加的话 sqlcmd 遇到错误继续往下执行，日志里全是噪音，看不出真正断在哪一句。打开vsp.log，最后一段报错就是根因。

如果是对象已存在的冲突，先查再决定删不删：

-- 按名称查对象，确认类型是视图(V)还是存储过程(P) SELECT name, type_desc, create_date, modify_date FROM sys.objects WHERE name IN ('V_ConfList','P_GetConfInfo');

删之前务必确认这些对象不是业务在用的，升级脚本一般会用CREATE OR ALTER或者先 DROP 再建，如果它没做这层保护，说明旧对象来自更早的版本残留，可以清理。权限问题则简单，把执行账户加到sysadmin角色，跑完再移出。

4.3 导入证书失败与卡在导入证书环节

安装提示导入证书失败，或者升级卡在导入证书那一步长时间不动，根因通常不在证书文件本身，而在三个周边条件：私钥权限没给到数据库服务账户、证书文件被安全软件锁住、机器名与证书主题不匹配。

先看本地计算机的个人存储里到底有没有这张证书：

:: 列出本地计算机「个人」存储中的证书，看主题和有效期 certutil -store My

图形界面打开certlm.msc更直观，注意是certlm不是certmgr，前者是本地计算机存储，后者是当前用户存储，装错位置等于没装。

用 pfx 文件导入并指定密码：

:: -f 强制覆盖同名证书，-p 后面是 pfx 密码，My 是存储区 certutil -f -p "证书密码" -importPFX My "D:\smc\cert\smc.pfx"

导入成功只是第一步，还要把私钥权限授予数据库服务账户，否则 SMC 读取证书时仍然报失败。操作路径：certlm.msc里右键证书 → 所有任务 → 管理私钥 → 添加NT SERVICE\MSSQL$SQLEXPRESS，给「读取」权限。

卡住不动的情况，按顺序查三件事：安全软件是否在扫描证书目录（现象是每次到这一步都刚好卡在同一个位置）、系统时间是否偏差过大（w32tm /resync强制同步一次）、证书主题里的主机名跟当前计算机名是否一致（换过机器名的场景必查）。

4.4 数据库状态和文件状态不一致，以及升级谈出来的认证密码框

「数据库状态和文件状态不一致」这个提示，指的是数据库在实例里的登记状态跟磁盘上的文件对不上。一条查询就能定位：

-- state_desc 出现 RECOVERY_PENDING / SUSPECT 就是异常状态 SELECT name, state_desc, user_access_desc FROM sys.databases;

RECOVERY_PENDING大多是文件路径变更或权限丢失导致的，先尝试让库上线：

ALTER DATABASE SMC SET ONLINE;

失败就去读 SQL Server 错误日志，里面会明确写出是哪个文件打不开、错误码是多少。Express 版的日志在C:\Program Files\Microsoft SQL Server\MSSQL12.SQLEXPRESS\MSSQL\Log\ERRORLOG。文件确实丢失的情况下，只能从备份还原，没有别的路。

升级过程中弹出输入认证密码框，是因为升级程序要连旧库，读到的口令与新环境不一致。这时候要么输入原认证密码，要么用 Windows 身份验证先重置 sa 密码再继续：

-- 重置 sa 密码并启用账户，仅限本地维护窗口使用 ALTER LOGIN sa WITH PASSWORD = '新的强密码'; ALTER LOGIN sa ENABLE;

重置前先确认没有其他业务正在用旧密码连这个实例，改完立刻同步给所有依赖方，否则只是把故障挪了个位置。

5. 避坑清单：安装包缺组件、VC2017 x86 失败与不断重启

下面五条是现场复现率最高的，每一条都按「现象 → 原因 → 解决」写，遇到时直接对号入座。

5.1 安装包中未携带 .NET Framework 4.7.2 导致安装报错

现象：安装启动后很快报缺组件，提示需要 .NET Framework 4.7.2，安装无法继续。

原因：SMC 安装包默认不内嵌 .NET Framework 安装文件，它只做检测。离线环境或者内网机器访问不到外部源时，检测必然失败。

解决：提前把NDP472-KB4054530-x86-x64-AllOS-ENU.exe拷到服务器上手工装完。装之前确认系统补丁已经打完，顺序反了会提示「此更新不适用于你的计算机」。装完用注册表Release值确认到位（461808 及以上），再启动 SMC 安装程序。如果现场有多台机器，把这个包装进系统镜像或装机脚本里，比一台台补省事得多。

5.2 安装包中未携带 SQL Server 2014 Express SP2 安装包

现象：安装程序走到数据库准备阶段直接失败，日志里提示找不到数据库安装源。

原因：与上一条同源，安装包只负责检测实例是否存在，不负责替你装数据库。它期望在指定目录下找到 Express 安装文件，目录为空就直接报错。

解决：先把 SQL Server 2014 Express SP2 的安装介质下载好，放到安装程序约定的目录下，或者先手工把数据库装完并确认实例可连，再跑 SMC 安装。手工装的那一次，务必记住三件事：实例名用默认SQLEXPRESS、认证模式选混合、sa 密码记牢。这三项在后面的安装流程里会被反复读取，改起来很麻烦。

5.3 Install VC2017 x86 depend files 失败

现象：安装到依赖组件阶段，报Install VC2017 x86 depend files失败。

原因：系统上已经装了更高版本的 VC++ 运行库，安装器执行静默安装时返回 3010（需要重启）或 1638（已存在更高版本），安装器把非零返回码一律当成失败处理。

解决：手工装一次，看清返回码：

:: /quiet 静默 /norestart 不自动重启，返回 0 或 3010 都算成功 vc_redist.x86.exe /quiet /norestart echo %ERRORLEVEL%

返回 3010 表示装上了但需要重启，重启后重跑 SMC 安装即可；返回 1638 表示已有更高版本，这种情况下 32 位运行库其实已经具备，可以在确认C:\Windows\SysWOW64下存在对应 dll 后继续安装。注意必须装 x86 版本，只装 x64 不解决问题，因为 SMC 的部分组件是 32 位的。

5.4 安装过程中不断重启

现象：安装程序每走到某一步就触发重启，重启后重新开始，如此循环。

原因：系统存在挂起的文件重命名操作，或者 Windows Update 正在后台安装更新。安装器检测到系统处于「待重启」状态就强制重启，重启后状态没清掉，继续循环。

解决：先把系统恢复到干净状态。

# 查看是否有挂起的重命名操作，输出非空说明有 Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -Name PendingFileRenameOperations -ErrorAction SilentlyContinue # 临时停掉更新服务，避免安装期间被后台更新打断 Stop-Service wuauserv Set-Service wuauserv -StartupType Disabled

处理完重启一次，确认系统不再提示「需要重启以完成安装」，再开始装 SMC。装完后把更新服务的启动类型改回Manual，别一直关着。

5.5 安装过程中提示访问某厂商文件夹失败

现象：安装中提示无法访问某厂商名称的文件夹，安装中断。

原因：三个方向——安装账户对该目录没有完全控制权限；上一次安装失败留下了残留目录，属主变成了别的账户；安全软件把目录锁住，读取时被拒绝。

解决：先以管理员身份运行安装程序，排除权限不足这个最粗的可能；然后检查目录是否存在残留，存在就改名备份而不是直接删，万一需要回滚还能用；最后把该目录的完全控制权限显式授予安装账户和SYSTEM。安全软件如果开了实时防护，安装期间临时关闭，装完再打开。判定顺序建议从上往下，因为管理员运行的成本最低，先排除它。

6. 快速定位：从进度条位置和日志倒推的三步法

装 SMC 这类多阶段安装程序，定位效率最高的办法不是逐条读报错，而是先确定它「死在哪一段」。我的习惯是三步：

第一步看进度条位置。9% 段只做操作系统和环境的检查，对应第 2 章那四项；进到依赖组件、数据库准备阶段，问题基本在运行库和服务上；进入脚本执行和证书导入，问题在数据库权限和证书存储。位置定了，排查范围立刻缩小一半。

第二步看日志。安装器的日志目录下会有逐步输出，数据库相关的错误则去 SQL Server 的ERRORLOG。看日志有个技巧：从最后一行往前翻，找到第一条非「重试」「等待」的记录，那才是根因，后面的都是它的连锁反应。

第三步用最小命令验证假设，不要靠猜。下面这张对照表是我遇到时直接查的：

报错关键词	最可能的根因	一条命令验证
无法应用系统加固	补丁未按序打全	Get-HotFix | ? HotFixID -like 'KB2919*'
计算机名和用户名一致	主机名与登录账户同名	hostname与whoami对比
The net service has not been started	实例或 Browser 服务未起	Get-Service 'MSSQL$SQLEXPRESS'
登录超时已过期	TCP/IP 未启用或端口不通	netstat -ano | findstr :1433
BCP 不是默认路径	PATH 缺 Tools\Binn	where bcp
导入证书失败	私钥权限未授予服务账户	certutil -store My
状态和文件状态不一致	文件丢失或权限不足	SELECT state_desc FROM sys.databases

验证通过之后就改一处、验一处，别一次动三个地方。安装类故障最怕的就是同时改配置又改权限，最后好了也不知道是哪一步起的作用，下次遇到照样抓瞎。

血泪经验是：装之前先把「版本、补丁、计算机名、sa 密码」这四项写成一张纸贴在机柜上，装的时候逐项打勾。从那以后我每次做单机部署，都强制在装系统后、装库前各跑一遍环境核查脚本，宁可多花十分钟，也不要在 9% 那里反复重启一整天。希望帮到你。

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