简介针对微软现代操作系统已移除PowerShell 2.0而导致的旧版数据库安装兼容性问题这份代码包面向需要安装SQL Server 2008 R2的系统管理员与运维人员给出了完整的前置环境修复思路。资源以zip形式分发共3个文件包括html操作说明文档、inscode核心脚本以及gitignore辅助文件整体大小仅6KB。文档详细指导用户下载并解压ps2DLC.zip然后以管理员身份运行PowerShell将执行策略修改为RemoteSigned或Bypass再执行loadGAC.ps1脚本把PowerShell 2.0必需的组件注册到全局程序集缓存中从而模拟出系统缺失的运行环境。该流程可有效绕过系统更新带来的兼容性障碍不仅适用于SQL Server 2008 R2也能帮助解决其他依赖PowerShell 2.0的软件安装问题其中的排查思路与脚本调用方法对理解旧软件在新系统上的兼容性处理也颇具启发。当前已有2334人学习下载适合需要在较新操作系统上部署旧版数据库服务的技术人员参考是一份小巧但非常实用的工具包。1. 安装 SQL Server 卡在“PowerShell 2.0 未安装”这一步不是玄学是检查项在较真装 SQL Server 装到一半安装向导突然弹出一个“PowerShell 2.0 is not installed”的检查报错环境检查列表里亮起一个红叉很多人的第一反应是“这玩意儿也值得拦我装数据库”——然后就开始乱猜是不是系统缺补丁、是不是安装包损坏、是不是得重装系统。其实都不用这个报错是 SQL Server 安装规则里的一个硬检查项背后涉及的是系统兼容性和 PowerShell 运行环境的版本对齐问题。说白了SQL Server 的安装向导和后续的配置管理工具都建立在 PowerShell 之上从 2012 版本开始检查“是否存在 PowerShell 2.0”就成了默认安装的准入条件过不了这一关后面点多少次“下一步”都是白费。这篇笔记要解决的问题就一个遇到这个检查项怎么在最短时间内让它通过。适合正在新装 SQL Server 2012/2014/2016 或者被系统兼容性折腾得焦头烂额的运维和开发也适合那些在 Windows Server 系列上做数据库环境交付、想把安装过程固化成脚本的人。下面从原理讲到实操再讲几个我实际踩过的坑。2. 为什么 SQL Server 安装偏要绑定 PowerShell 2.0检查项背后的设计逻辑2.1 安装规则“PowerShell 2.0”到底在查什么SQL Server 安装向导在进入正式安装之前会跑一组系统配置检查System Configuration Check其中有一项叫“PowerShell 2.0”。这一项看起来只是在确认你有没有装 PowerShell但实际上它检查的是两件事一是 Windows 系统里是否注册了 PowerShell 2.0 引擎二是这个引擎能否被 SQL Server 安装进程正常调用。PowerShell 从 3.0 开始成为 Windows 8 / Windows Server 2012 的内置组件但 2.0 引擎并不是被 3.0 直接覆盖掉了。Windows 上可以同时存在多个版本引擎PowerShell 2.0 Engine 作为一个独立的功能项在 Windows 7 / Windows Server 2008 R2 上默认开启到了 Windows Server 2012 上则默认关闭需要手动添加到系统里。SQL Server 2012 到 2016 的安装程序在执行某些配置操作时会调用 PowerShell 2.0 引擎来处理而不是调用系统当前默认的 PowerShell 版本——这就是为什么你明明在 PowerShell 里敲$PSVersionTable看到的是 5.1安装向导还是提示 2.0 缺失。安装过程中使用 PowerShell 2.0 引擎不是为了给你提供交互式命令行而是为了执行 SQL Server 安装中心内置的脚本任务。这些脚本在安装阶段被编译成 PowerShell 命令由安装程序在后台拉起一个运行空间Runspace来执行。如果系统里没有注册 PowerShell 2.0 引擎这个运行空间创建失败安装程序就会判定环境不满足要求。2.2 哪些 SQL Server 版本会被这个检查卡住这个检查项并不是所有 SQL Server 版本都会触发。SQL Server 2012 是第一个把 PowerShell 深度集成进安装流程的版本所以 2012、2014、2016 这三个版本的安装向导对 PowerShell 2.0 的要求是硬性的即使在 Windows Server 2016 上装 SQL Server 2016也会检查这个引擎是否存在。SQL Server 2017 和 2019 安装时对 PowerShell 2.0 不再做强制检查但后续的一些管理功能比如 SQL Agent 的 PowerShell 作业步骤仍然依赖系统具备合适的 PowerShell 环境。SQL Server 2022 则更进一步官方要求的最小 PowerShell 版本已经和 Windows 自带的版本对齐不再需要单独启用 2.0 引擎。所以这条检查项的实际影响范围是Windows Server 2008 R2、2012、2012 R2、2016 这几代系统上安装 SQL Server 20122016。Windows Server 2008非 R2比较特殊它默认最高只能跑 PowerShell 2.0反而没有这个问题Windows Server 2012 开始系统自带了 PowerShell 3.0 或更高版本需要你把 2.0 引擎当做一个 Windows 功能单独开起来这一关就成了系统兼容性上最容易翻车的地方。2.3 我建议的选型思路先确认补的到底是引擎还是功能面对这个报错网上能找到不少做法有人让你去微软官网下载一个叫 Windows Management Framework 的补丁包有人让你用 DISM 命令把 PowerShell 2.0 功能打开。这里我建议先分清楚一个边界Windows Management Framework 是包含 PowerShell 引擎以及相关管理组件的官方安装包而你实际需要的是一个能够在系统里注册 2.0 运行引擎的能力。在 Windows 7 / Windows Server 2008 R2 上PowerShell 2.0 是随系统自带的不需要单独安装所谓“启用”更多是确认它没有被卸载。在 Windows Server 2012 及以上版本直接用系统本身的“启用 Windows 功能”界面或者 DISM 命令就能把 PowerShell 2.0 引擎加回来比下载 WMF 再安装要干净得多。原因在于 Windows Management Framework 的安装包在不同系统版本上需要匹配不同的版本号装错了不仅无法解决环境检查还可能把系统的 PowerShell 状态弄得更乱出现后续的配置工具连不上的问题。3. 把环境检查变成一把过启用 PowerShell 2.0 的具体操作与脚本3.1 先确认当前系统上 PowerShell 的真实状态不要急着动手改先看清楚环境现状后面少走弯路。打开一个 PowerShell 命令行窗口执行版本查询命令确认当前系统默认的 PowerShell 版本信息。这一步的主要目的是确认你的系统里是否已经存在多个版本的引擎以及当前运行的 PowerShell 是从哪个路径加载出来的。# 查看当前 PowerShell 版本 $PSVersionTable # 输出结果中重点看 PSVersion 和 CLRVersion 两项 # PSVersion: 显示当前运行的 PowerShell 引擎版本 # CLRVersion: 显示公共语言运行时版本PowerShell 2.0 对应 CLR 2.0执行之后如果显示的结果里PSVersion是 5.1只能说明你当前打开的会话运行在 5.1 引擎上并不能说明系统里有没有 2.0。检查 2.0 引擎是否存在需要走另外一条路直接看系统的 Windows 功能注册状态# 在管理员权限下执行查看已安装的 Windows 功能 Get-WindowsOptionalFeature -Online -FeatureName *PowerShell* # 输出结果中关注 FeatureName 为 PowerShell2.0 的行 # State 为 Enabled 说明功能已启用 # State 为 Disabled 说明功能存在但未启用需要后续开启这段命令是我每次处理 SQL Server 安装环境时必做的第一步。需要注意Get-WindowsOptionalFeature只在 Windows Server 2012 及以上的系统上可用如果是在 Windows Server 2008 R2 上这条路就观察不到得用注册表去看引擎是否注册。其实 2008 R2 基本不会遇到缺 2.0 的情况真正需要关注的就是 2012 以后的系统。3.2 用 DISM 启用 PowerShell 2.0 引擎这一步的操作与参数确认状态之后如果你看到State是Disabled就可以直接启用。这里我不用图形界面的“启用 Windows 功能”优先选择 DISM因为我们写脚本交付环境的时候图形界面没法固化DISM 命令放进脚本直接执行一遍效果完全一样。# 需要在管理员权限的 PowerShell 中执行 # 启用 PowerShell 2.0 引擎功能 dism /Online /Enable-Feature /FeatureName:PowerShell2.0 /NoRestart # /Online: 直接操作当前运行的 Windows 系统 # /Enable-Feature: 启用指定功能 # /FeatureName: 指定功能名称这里是 PowerShell2.0 # /NoRestart: 操作完成之后不强制重启 # 执行结果会显示 The operation completed successfully.这一条命令执行完系统会提示操作成功。但我必须提醒你注意一点/NoRestart参数只是不立即强制重启不代表后续不需要重启。PowerShell 2.0 引擎的注册表信息和程序集注册不会立即生效SQL Server 安装向导在做环境检查时是在一个新的进程里加载引擎的如果不重启新进程可能仍然读不到刚注册的引擎导致你明明成功了安装检查还是给你红叉。3.3 启用两个子功能容易漏掉的 PowerShell 2.0 子项在实际系统上PowerShell 2.0 在功能清单里不是一个孤立的项目它包含两个子功能PowerShell 2.0 Engine和PowerShell 2.0 ISE。前面的dism命令指定/FeatureName:PowerShell2.0时实际上是把引擎和 ISE 一起处理了但有一些系统在开启过程中会出现子功能状态不一致的情况引擎起来了ISE 还是禁用状态这时候 SQL Server 安装检查也可能会失败。更稳妥的做法是分别启用这两个子功能# 启用 PowerShell 2.0 引擎 dism /Online /Enable-Feature /FeatureName:PowerShell2.0 /NoRestart # 启用 PowerShell 2.0 ISE dism /Online /Enable-Feature /FeatureName:PowerShell2.0-ISE /NoRestart # 两条命令执行完再确认一次状态 dism /Online /Get-FeatureInfo /FeatureName:PowerShell2.0 dism /Online /Get-FeatureInfo /FeatureName:PowerShell2.0-ISEPowerShell2.0-ISE这个子功能的作用并不是给 SQL Server 用而是为了后续你在服务器上写脚本调试时手边有一个可用的图形化脚本编辑工具。SQL Server 安装检查本身盯着的是引擎但既然要交付一套完整的数据库环境我一般会顺手把 ISE 一起打开省得以后运维同事上去发现脚本编辑器都没有还要临时去查命令。两条命令的顺序是有讲究的先启引擎再启 ISE因为后者依赖前者的运行环境。3.4 重启之后用两组命令验证环境是否真的就绪重启服务器这一步不能省。很多从 Windows Server 2012 时代一路走过来的运维都有这个习惯功能装完立即重启因为 PowerShell 引擎注册需要更新 PATH 环境变量和程序集缓存不重启的话新进程拿到的还是旧的环境块。重启后重新登录执行验证# 验证 2.0 引擎是否可用 powershell.exe -Version 2.0 -Command $PSVersionTable # 输出结果中 PSVersion 显示为 2.0说明引擎可被调用 # 如果提示 Windows PowerShell 2.0 is not installed说明注册未生效第一组验证通过后再检查功能状态# 再次确认 Windows 功能状态 Get-WindowsOptionalFeature -Online -FeatureName PowerShell2.0 # State 应为 Enabled # 如果 State 还是 Disabled说明前面的启用过程没有真正完成需要看错误信息整个流程走完SQL Server 安装向导再运行一次环境检查那一栏的“PowerShell 2.0”会自动变成绿色对勾。如果还是红的往下看避坑章节大概率是踩了那几个经典的坑。4. 避坑与常见问题排查四条踩烂了的弯路4.1 现象dism 提示成功但 SQL Server 检查仍然是红叉这个情况我遇到不止一次而且是好几台服务器都这样。dism 命令执行完屏幕上明明白白显示The operation completed successfully也重启过了进系统以后再次用Get-WindowsOptionalFeature查State 确实已经是 Enabled。但 SQL Server 安装向导环境检查列表里PowerShell 2.0 那一条依然是红叉。原因SQL Server 安装程序在检查这一项时候用的不是 PowerShell 引擎本身而是通过 WMI 查询系统注册表里的SCM条目同时检查%SystemRoot%\System32\WindowsPowerShell\v1.0\目录下是否存在powershell.exe对应的 2.0 配置。有些系统上安全策略会阻止安装程序从注册表读取PowerShellVersion键值导致系统层面已经注册成功但 SQL Server 这边的 WMI 查询被拦截读取返回空。解决我一般会在这个判断失败的情况下用一条命令手动确认注册表键值是否存在直接绕过 WMI 层去验证# 检查注册表中记录的 PowerShell 2.0 引擎状态 Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine -Name PowerShellVersion # 如果系统里注册了多个版本这里会看到多个类似路径的注册表项 # 重点关注的是 PowerShellVersion 字符串中是否包含 2.0要是注册表里能看到 2.0 的注册信息那基本可以判定 SQL Server 安装程序是卡在一个瞬时状态上。最省事的办法是再执行一次 SQL Server 安装向导有些服务器在第一次失败时会残留一个临时日志锁第二次跑时锁释放了检查项自己就过了。如果再不行把 SQL Server 安装目录下的SqlSetup\临时文件夹删掉重跑一次。4.2 现象Windows Server 2012 上启用时报 0x800F081E 错误另外一台服务器Windows Server 2012用 dism 启用 PowerShell 2.0 的时候直接报了个错误码 0x800F081E翻译成人话是“找不到指定的源文件”。一开始还以为是命令拼错检查了几遍没问题最后才发现是系统安装源的镜像文件没有在服务器上保留。原因Windows Server 2012 启用功能时默认从本地 Windows 目录里的WinSxS组件存储取源文件但有些服务器在交付时被人为清理过这个目录释放 C 盘空间或者是从模板克隆出来的虚拟机组件存储里面根本没有对应的 2.0 引擎文件dism 就会尝试从 Windows Update 拉取补丁源拉不到就报这个错。解决需要把系统的安装镜像挂载到服务器上或者指定一个包含install.wim的本地目录作为源再加Source参数# 挂载系统镜像后指定源目录执行启用 dism /Online /Enable-Feature /FeatureName:PowerShell2.0 /Source:X:\Sources\sxs /LimitAccess /NoRestart # /Source: 指定功能源文件的路径 # /LimitAccess: 限制只在指定源中查找避免去 Windows Update 等待超时这个坑在 Windows Server 2012 R2 上也经常出现特别是从旧机器用工具迁移到虚拟机里的环境。遇到 0x800F081E 先别排查权限直接找镜像源文件比在系统里翻半天日志有用得多。4.3 现象SQL Server 配置管理器打不开提示“无法连接到 WMI 提供程序”PowerShell 2.0 的环境检查通过之后SQL Server 装是装上去了但没过多久打开 SQL Server Configuration Manager 的时候连接管理单元直接报错说“无法连接到 WMI 提供程序”。这个问题被很多人当成 SQL Server 服务故障来处理折腾服务拉起来也没用根子不在那。原因SQL Server 安装过程本身就依赖 PowerShell 2.0 来注册 WMI 命名空间我在前面专门提到 ISE 子功能容易漏掉这个坑就是从那里埋下来的。只启用了引擎没有启用 ISE 的情况下SQL Server 安装程序往 WMI 里写配置类时某个 PowerShell 脚本组件没有在系统里完成注册导致配置管理器对应的 WMI 类无法正确实例化。解决回到 3.3 那个步骤把PowerShell2.0-ISE这个子功能补上重启后重新打开配置管理器。如果这一步做完还是报同样的提示再去 SQL Server 的安装目录下重新运行一下SqlLocalDB的配置脚本但大多数情况下补上 ISE 重启就已经恢复正常了。这个坑的特点是不装 SQL Server 发现不了因为普通系统上 ISE 用不到只有 SQL Server 的 WMI 提供程序会对这个功能做依赖检查。4.4 现象配置脚本在 Server Core 上跑不起来有一台 Windows Server 2016 Server Core没有图形界面纯命令行操作用同样的 dism 命令把 PowerShell 2.0 启用了重启后跑 SQL Server 安装向导环境检查全部通过安装也没问题。但安装完以后 SQL Server Agent 启动失败看日志说是执行某个 PowerShell 脚本期间出错。原因Server Core 模式下没有完整的 PowerShell ISE 组件支持我一开始也是按图形界面的习惯把功能启用列表当成一回事后来对比了一下发现 Server Core 上根本没有 2.0-ISE 这个子功能的概念。SQL Server Agent 在启动时会对 PowerShell 作业子系统做一次初始化这次初始化会检查环境中是否存在可用的 PowerShell 运行空间Server Core 里启用的功能路径不完整导致这个检查报错。解决在 Server Core 上用 Server Manager 的命令行版本sconfig和 dism 结合确认当前系统实际可用的功能列表不以图形服务器为标准。实际做法是# 在 Server Core 上查看实际开放的 PowerShell 相关功能 dism /Online /Get-Features /Format:Table | findstr /i PowerShell # 对比结果中是否有 PowerShell2.0 # Server Core 上这一项的正常存在形式会有所不同注意看状态列如果这个检查发现在 Server Core 上根本无法完整启用 PowerShell 2.0我会直接换一个思路去解决环境兼容性问题——不要在 Server Core 上强拼 SQL Server 的老版本把 SQL Server 版本往上调一级2017 或者 2019 对 PowerShell 2.0 的依赖已经去掉在新版本上跑 Server Core 反而更省事。有些兼容性问题的正解是升级不是硬磕。5. 把“过检查”变“常态”固化验证脚本与静默安装参数的一步到位走到这里环境检查已经过了SQL Server 也装上了但如果接下来你要给多台服务器交付同样的环境每次都手动执行dism、重启、再检查工作量还是很大。我一般会把前面这套动作固化成一段 PowerShell 脚本只要机器是 Windows Server 2012 以上版本跑一遍就能完成启用和验证再配合 SQL Server 安装的静默参数一台新服务器从裸机到数据库就绪可以控制在半小时以内。# 保存在 enable-powershell2.ps1 中以管理员身份执行 # 脚本用途启用 PowerShell 2.0 引擎并输出验证结果 $Feature Get-WindowsOptionalFeature -Online -FeatureName PowerShell2.0 -ErrorAction Stop if ($Feature.State -ne Enabled) { Write-Host 状态未启用开始启用 PowerShell 2.0... dism /Online /Enable-Feature /FeatureName:PowerShell2.0 /NoRestart | Out-Null dism /Online /Enable-Feature /FeatureName:PowerShell2.0-ISE /NoRestart | Out-Null Write-Host 启用完成系统需要重启后才能生效。 } else { Write-Host 状态已启用无需处理。 } # 验证引擎可被调用 $TestResult powershell.exe -Version 2.0 -Command $PSVersionTable.PSVersion.ToString() 21 if ($TestResult -match ^2\.0) { Write-Host 验证通过PowerShell 2.0 引擎可正常调用。 } else { Write-Host 验证异常引擎不可调用请重启系统后重试。 }脚本逻辑上做了一个判断分流如果功能已经启用直接进入验证环节不重复执行启用命令如果未启用则依次打开引擎和 ISE。ErrorAction Stop是让Get-WindowsOptionalFeature在查询失败时直接抛出错误而不是返回一个空对象避免后面的调用走空。验证调用是走一个独立的powershell.exe -Version 2.0进程如果系统注册搞定且重启完成这里会打印 2.0 字样如果没重启大概率得到的是报错文本脚本会提示你重启后重试。验证通过之后SQL Server 的安装可以走无人值守模式用/Q配合参数文件把 PowerShell 2.0 这个检查项提前在脚本端过关# SQL Server 安装程序静默安装参数示例 setup.exe /Q /IACCEPTSQLSERVERLICENSETERMS /CONFIGURATIONConfigurationFile.iniConfigurationFile.ini里建议把SQLCOLLATION、SQLSYSADMINACCOUNTS和FEATURES等关键项提前写好安装向导在静默模式下不会再交互询问。/IACCEPTSQLSERVERLICENSETERMS是必须的不加这个安装会直接退出不给你解释的机会。这套组合打下来新机器的环境准备时间大概十几分钟主要是在等重启。从那以后我只要在这类旧系统上部署 SQL Server都会强制走一遍“查功能状态 → 启用 → 重启 →-Version 2.0验证”的流程不管安装向导报不报错四步都不省。因为环境检查的坑往往不在第一台机器上出现而在交付到第三、第四台时突然蹦出来到时候再回头排查浪费的时间远比现在多得多。这篇整理就算给你留个后悔药装之前把检查项摸透装的时候一次过希望帮到你。本文还有配套的精品资源点击获取
SQL Server安装报错PowerShell 2.0未安装？环境检查与启用实操指南
简介针对微软现代操作系统已移除PowerShell 2.0而导致的旧版数据库安装兼容性问题这份代码包面向需要安装SQL Server 2008 R2的系统管理员与运维人员给出了完整的前置环境修复思路。资源以zip形式分发共3个文件包括html操作说明文档、inscode核心脚本以及gitignore辅助文件整体大小仅6KB。文档详细指导用户下载并解压ps2DLC.zip然后以管理员身份运行PowerShell将执行策略修改为RemoteSigned或Bypass再执行loadGAC.ps1脚本把PowerShell 2.0必需的组件注册到全局程序集缓存中从而模拟出系统缺失的运行环境。该流程可有效绕过系统更新带来的兼容性障碍不仅适用于SQL Server 2008 R2也能帮助解决其他依赖PowerShell 2.0的软件安装问题其中的排查思路与脚本调用方法对理解旧软件在新系统上的兼容性处理也颇具启发。当前已有2334人学习下载适合需要在较新操作系统上部署旧版数据库服务的技术人员参考是一份小巧但非常实用的工具包。1. 安装 SQL Server 卡在“PowerShell 2.0 未安装”这一步不是玄学是检查项在较真装 SQL Server 装到一半安装向导突然弹出一个“PowerShell 2.0 is not installed”的检查报错环境检查列表里亮起一个红叉很多人的第一反应是“这玩意儿也值得拦我装数据库”——然后就开始乱猜是不是系统缺补丁、是不是安装包损坏、是不是得重装系统。其实都不用这个报错是 SQL Server 安装规则里的一个硬检查项背后涉及的是系统兼容性和 PowerShell 运行环境的版本对齐问题。说白了SQL Server 的安装向导和后续的配置管理工具都建立在 PowerShell 之上从 2012 版本开始检查“是否存在 PowerShell 2.0”就成了默认安装的准入条件过不了这一关后面点多少次“下一步”都是白费。这篇笔记要解决的问题就一个遇到这个检查项怎么在最短时间内让它通过。适合正在新装 SQL Server 2012/2014/2016 或者被系统兼容性折腾得焦头烂额的运维和开发也适合那些在 Windows Server 系列上做数据库环境交付、想把安装过程固化成脚本的人。下面从原理讲到实操再讲几个我实际踩过的坑。2. 为什么 SQL Server 安装偏要绑定 PowerShell 2.0检查项背后的设计逻辑2.1 安装规则“PowerShell 2.0”到底在查什么SQL Server 安装向导在进入正式安装之前会跑一组系统配置检查System Configuration Check其中有一项叫“PowerShell 2.0”。这一项看起来只是在确认你有没有装 PowerShell但实际上它检查的是两件事一是 Windows 系统里是否注册了 PowerShell 2.0 引擎二是这个引擎能否被 SQL Server 安装进程正常调用。PowerShell 从 3.0 开始成为 Windows 8 / Windows Server 2012 的内置组件但 2.0 引擎并不是被 3.0 直接覆盖掉了。Windows 上可以同时存在多个版本引擎PowerShell 2.0 Engine 作为一个独立的功能项在 Windows 7 / Windows Server 2008 R2 上默认开启到了 Windows Server 2012 上则默认关闭需要手动添加到系统里。SQL Server 2012 到 2016 的安装程序在执行某些配置操作时会调用 PowerShell 2.0 引擎来处理而不是调用系统当前默认的 PowerShell 版本——这就是为什么你明明在 PowerShell 里敲$PSVersionTable看到的是 5.1安装向导还是提示 2.0 缺失。安装过程中使用 PowerShell 2.0 引擎不是为了给你提供交互式命令行而是为了执行 SQL Server 安装中心内置的脚本任务。这些脚本在安装阶段被编译成 PowerShell 命令由安装程序在后台拉起一个运行空间Runspace来执行。如果系统里没有注册 PowerShell 2.0 引擎这个运行空间创建失败安装程序就会判定环境不满足要求。2.2 哪些 SQL Server 版本会被这个检查卡住这个检查项并不是所有 SQL Server 版本都会触发。SQL Server 2012 是第一个把 PowerShell 深度集成进安装流程的版本所以 2012、2014、2016 这三个版本的安装向导对 PowerShell 2.0 的要求是硬性的即使在 Windows Server 2016 上装 SQL Server 2016也会检查这个引擎是否存在。SQL Server 2017 和 2019 安装时对 PowerShell 2.0 不再做强制检查但后续的一些管理功能比如 SQL Agent 的 PowerShell 作业步骤仍然依赖系统具备合适的 PowerShell 环境。SQL Server 2022 则更进一步官方要求的最小 PowerShell 版本已经和 Windows 自带的版本对齐不再需要单独启用 2.0 引擎。所以这条检查项的实际影响范围是Windows Server 2008 R2、2012、2012 R2、2016 这几代系统上安装 SQL Server 20122016。Windows Server 2008非 R2比较特殊它默认最高只能跑 PowerShell 2.0反而没有这个问题Windows Server 2012 开始系统自带了 PowerShell 3.0 或更高版本需要你把 2.0 引擎当做一个 Windows 功能单独开起来这一关就成了系统兼容性上最容易翻车的地方。2.3 我建议的选型思路先确认补的到底是引擎还是功能面对这个报错网上能找到不少做法有人让你去微软官网下载一个叫 Windows Management Framework 的补丁包有人让你用 DISM 命令把 PowerShell 2.0 功能打开。这里我建议先分清楚一个边界Windows Management Framework 是包含 PowerShell 引擎以及相关管理组件的官方安装包而你实际需要的是一个能够在系统里注册 2.0 运行引擎的能力。在 Windows 7 / Windows Server 2008 R2 上PowerShell 2.0 是随系统自带的不需要单独安装所谓“启用”更多是确认它没有被卸载。在 Windows Server 2012 及以上版本直接用系统本身的“启用 Windows 功能”界面或者 DISM 命令就能把 PowerShell 2.0 引擎加回来比下载 WMF 再安装要干净得多。原因在于 Windows Management Framework 的安装包在不同系统版本上需要匹配不同的版本号装错了不仅无法解决环境检查还可能把系统的 PowerShell 状态弄得更乱出现后续的配置工具连不上的问题。3. 把环境检查变成一把过启用 PowerShell 2.0 的具体操作与脚本3.1 先确认当前系统上 PowerShell 的真实状态不要急着动手改先看清楚环境现状后面少走弯路。打开一个 PowerShell 命令行窗口执行版本查询命令确认当前系统默认的 PowerShell 版本信息。这一步的主要目的是确认你的系统里是否已经存在多个版本的引擎以及当前运行的 PowerShell 是从哪个路径加载出来的。# 查看当前 PowerShell 版本 $PSVersionTable # 输出结果中重点看 PSVersion 和 CLRVersion 两项 # PSVersion: 显示当前运行的 PowerShell 引擎版本 # CLRVersion: 显示公共语言运行时版本PowerShell 2.0 对应 CLR 2.0执行之后如果显示的结果里PSVersion是 5.1只能说明你当前打开的会话运行在 5.1 引擎上并不能说明系统里有没有 2.0。检查 2.0 引擎是否存在需要走另外一条路直接看系统的 Windows 功能注册状态# 在管理员权限下执行查看已安装的 Windows 功能 Get-WindowsOptionalFeature -Online -FeatureName *PowerShell* # 输出结果中关注 FeatureName 为 PowerShell2.0 的行 # State 为 Enabled 说明功能已启用 # State 为 Disabled 说明功能存在但未启用需要后续开启这段命令是我每次处理 SQL Server 安装环境时必做的第一步。需要注意Get-WindowsOptionalFeature只在 Windows Server 2012 及以上的系统上可用如果是在 Windows Server 2008 R2 上这条路就观察不到得用注册表去看引擎是否注册。其实 2008 R2 基本不会遇到缺 2.0 的情况真正需要关注的就是 2012 以后的系统。3.2 用 DISM 启用 PowerShell 2.0 引擎这一步的操作与参数确认状态之后如果你看到State是Disabled就可以直接启用。这里我不用图形界面的“启用 Windows 功能”优先选择 DISM因为我们写脚本交付环境的时候图形界面没法固化DISM 命令放进脚本直接执行一遍效果完全一样。# 需要在管理员权限的 PowerShell 中执行 # 启用 PowerShell 2.0 引擎功能 dism /Online /Enable-Feature /FeatureName:PowerShell2.0 /NoRestart # /Online: 直接操作当前运行的 Windows 系统 # /Enable-Feature: 启用指定功能 # /FeatureName: 指定功能名称这里是 PowerShell2.0 # /NoRestart: 操作完成之后不强制重启 # 执行结果会显示 The operation completed successfully.这一条命令执行完系统会提示操作成功。但我必须提醒你注意一点/NoRestart参数只是不立即强制重启不代表后续不需要重启。PowerShell 2.0 引擎的注册表信息和程序集注册不会立即生效SQL Server 安装向导在做环境检查时是在一个新的进程里加载引擎的如果不重启新进程可能仍然读不到刚注册的引擎导致你明明成功了安装检查还是给你红叉。3.3 启用两个子功能容易漏掉的 PowerShell 2.0 子项在实际系统上PowerShell 2.0 在功能清单里不是一个孤立的项目它包含两个子功能PowerShell 2.0 Engine和PowerShell 2.0 ISE。前面的dism命令指定/FeatureName:PowerShell2.0时实际上是把引擎和 ISE 一起处理了但有一些系统在开启过程中会出现子功能状态不一致的情况引擎起来了ISE 还是禁用状态这时候 SQL Server 安装检查也可能会失败。更稳妥的做法是分别启用这两个子功能# 启用 PowerShell 2.0 引擎 dism /Online /Enable-Feature /FeatureName:PowerShell2.0 /NoRestart # 启用 PowerShell 2.0 ISE dism /Online /Enable-Feature /FeatureName:PowerShell2.0-ISE /NoRestart # 两条命令执行完再确认一次状态 dism /Online /Get-FeatureInfo /FeatureName:PowerShell2.0 dism /Online /Get-FeatureInfo /FeatureName:PowerShell2.0-ISEPowerShell2.0-ISE这个子功能的作用并不是给 SQL Server 用而是为了后续你在服务器上写脚本调试时手边有一个可用的图形化脚本编辑工具。SQL Server 安装检查本身盯着的是引擎但既然要交付一套完整的数据库环境我一般会顺手把 ISE 一起打开省得以后运维同事上去发现脚本编辑器都没有还要临时去查命令。两条命令的顺序是有讲究的先启引擎再启 ISE因为后者依赖前者的运行环境。3.4 重启之后用两组命令验证环境是否真的就绪重启服务器这一步不能省。很多从 Windows Server 2012 时代一路走过来的运维都有这个习惯功能装完立即重启因为 PowerShell 引擎注册需要更新 PATH 环境变量和程序集缓存不重启的话新进程拿到的还是旧的环境块。重启后重新登录执行验证# 验证 2.0 引擎是否可用 powershell.exe -Version 2.0 -Command $PSVersionTable # 输出结果中 PSVersion 显示为 2.0说明引擎可被调用 # 如果提示 Windows PowerShell 2.0 is not installed说明注册未生效第一组验证通过后再检查功能状态# 再次确认 Windows 功能状态 Get-WindowsOptionalFeature -Online -FeatureName PowerShell2.0 # State 应为 Enabled # 如果 State 还是 Disabled说明前面的启用过程没有真正完成需要看错误信息整个流程走完SQL Server 安装向导再运行一次环境检查那一栏的“PowerShell 2.0”会自动变成绿色对勾。如果还是红的往下看避坑章节大概率是踩了那几个经典的坑。4. 避坑与常见问题排查四条踩烂了的弯路4.1 现象dism 提示成功但 SQL Server 检查仍然是红叉这个情况我遇到不止一次而且是好几台服务器都这样。dism 命令执行完屏幕上明明白白显示The operation completed successfully也重启过了进系统以后再次用Get-WindowsOptionalFeature查State 确实已经是 Enabled。但 SQL Server 安装向导环境检查列表里PowerShell 2.0 那一条依然是红叉。原因SQL Server 安装程序在检查这一项时候用的不是 PowerShell 引擎本身而是通过 WMI 查询系统注册表里的SCM条目同时检查%SystemRoot%\System32\WindowsPowerShell\v1.0\目录下是否存在powershell.exe对应的 2.0 配置。有些系统上安全策略会阻止安装程序从注册表读取PowerShellVersion键值导致系统层面已经注册成功但 SQL Server 这边的 WMI 查询被拦截读取返回空。解决我一般会在这个判断失败的情况下用一条命令手动确认注册表键值是否存在直接绕过 WMI 层去验证# 检查注册表中记录的 PowerShell 2.0 引擎状态 Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine -Name PowerShellVersion # 如果系统里注册了多个版本这里会看到多个类似路径的注册表项 # 重点关注的是 PowerShellVersion 字符串中是否包含 2.0要是注册表里能看到 2.0 的注册信息那基本可以判定 SQL Server 安装程序是卡在一个瞬时状态上。最省事的办法是再执行一次 SQL Server 安装向导有些服务器在第一次失败时会残留一个临时日志锁第二次跑时锁释放了检查项自己就过了。如果再不行把 SQL Server 安装目录下的SqlSetup\临时文件夹删掉重跑一次。4.2 现象Windows Server 2012 上启用时报 0x800F081E 错误另外一台服务器Windows Server 2012用 dism 启用 PowerShell 2.0 的时候直接报了个错误码 0x800F081E翻译成人话是“找不到指定的源文件”。一开始还以为是命令拼错检查了几遍没问题最后才发现是系统安装源的镜像文件没有在服务器上保留。原因Windows Server 2012 启用功能时默认从本地 Windows 目录里的WinSxS组件存储取源文件但有些服务器在交付时被人为清理过这个目录释放 C 盘空间或者是从模板克隆出来的虚拟机组件存储里面根本没有对应的 2.0 引擎文件dism 就会尝试从 Windows Update 拉取补丁源拉不到就报这个错。解决需要把系统的安装镜像挂载到服务器上或者指定一个包含install.wim的本地目录作为源再加Source参数# 挂载系统镜像后指定源目录执行启用 dism /Online /Enable-Feature /FeatureName:PowerShell2.0 /Source:X:\Sources\sxs /LimitAccess /NoRestart # /Source: 指定功能源文件的路径 # /LimitAccess: 限制只在指定源中查找避免去 Windows Update 等待超时这个坑在 Windows Server 2012 R2 上也经常出现特别是从旧机器用工具迁移到虚拟机里的环境。遇到 0x800F081E 先别排查权限直接找镜像源文件比在系统里翻半天日志有用得多。4.3 现象SQL Server 配置管理器打不开提示“无法连接到 WMI 提供程序”PowerShell 2.0 的环境检查通过之后SQL Server 装是装上去了但没过多久打开 SQL Server Configuration Manager 的时候连接管理单元直接报错说“无法连接到 WMI 提供程序”。这个问题被很多人当成 SQL Server 服务故障来处理折腾服务拉起来也没用根子不在那。原因SQL Server 安装过程本身就依赖 PowerShell 2.0 来注册 WMI 命名空间我在前面专门提到 ISE 子功能容易漏掉这个坑就是从那里埋下来的。只启用了引擎没有启用 ISE 的情况下SQL Server 安装程序往 WMI 里写配置类时某个 PowerShell 脚本组件没有在系统里完成注册导致配置管理器对应的 WMI 类无法正确实例化。解决回到 3.3 那个步骤把PowerShell2.0-ISE这个子功能补上重启后重新打开配置管理器。如果这一步做完还是报同样的提示再去 SQL Server 的安装目录下重新运行一下SqlLocalDB的配置脚本但大多数情况下补上 ISE 重启就已经恢复正常了。这个坑的特点是不装 SQL Server 发现不了因为普通系统上 ISE 用不到只有 SQL Server 的 WMI 提供程序会对这个功能做依赖检查。4.4 现象配置脚本在 Server Core 上跑不起来有一台 Windows Server 2016 Server Core没有图形界面纯命令行操作用同样的 dism 命令把 PowerShell 2.0 启用了重启后跑 SQL Server 安装向导环境检查全部通过安装也没问题。但安装完以后 SQL Server Agent 启动失败看日志说是执行某个 PowerShell 脚本期间出错。原因Server Core 模式下没有完整的 PowerShell ISE 组件支持我一开始也是按图形界面的习惯把功能启用列表当成一回事后来对比了一下发现 Server Core 上根本没有 2.0-ISE 这个子功能的概念。SQL Server Agent 在启动时会对 PowerShell 作业子系统做一次初始化这次初始化会检查环境中是否存在可用的 PowerShell 运行空间Server Core 里启用的功能路径不完整导致这个检查报错。解决在 Server Core 上用 Server Manager 的命令行版本sconfig和 dism 结合确认当前系统实际可用的功能列表不以图形服务器为标准。实际做法是# 在 Server Core 上查看实际开放的 PowerShell 相关功能 dism /Online /Get-Features /Format:Table | findstr /i PowerShell # 对比结果中是否有 PowerShell2.0 # Server Core 上这一项的正常存在形式会有所不同注意看状态列如果这个检查发现在 Server Core 上根本无法完整启用 PowerShell 2.0我会直接换一个思路去解决环境兼容性问题——不要在 Server Core 上强拼 SQL Server 的老版本把 SQL Server 版本往上调一级2017 或者 2019 对 PowerShell 2.0 的依赖已经去掉在新版本上跑 Server Core 反而更省事。有些兼容性问题的正解是升级不是硬磕。5. 把“过检查”变“常态”固化验证脚本与静默安装参数的一步到位走到这里环境检查已经过了SQL Server 也装上了但如果接下来你要给多台服务器交付同样的环境每次都手动执行dism、重启、再检查工作量还是很大。我一般会把前面这套动作固化成一段 PowerShell 脚本只要机器是 Windows Server 2012 以上版本跑一遍就能完成启用和验证再配合 SQL Server 安装的静默参数一台新服务器从裸机到数据库就绪可以控制在半小时以内。# 保存在 enable-powershell2.ps1 中以管理员身份执行 # 脚本用途启用 PowerShell 2.0 引擎并输出验证结果 $Feature Get-WindowsOptionalFeature -Online -FeatureName PowerShell2.0 -ErrorAction Stop if ($Feature.State -ne Enabled) { Write-Host 状态未启用开始启用 PowerShell 2.0... dism /Online /Enable-Feature /FeatureName:PowerShell2.0 /NoRestart | Out-Null dism /Online /Enable-Feature /FeatureName:PowerShell2.0-ISE /NoRestart | Out-Null Write-Host 启用完成系统需要重启后才能生效。 } else { Write-Host 状态已启用无需处理。 } # 验证引擎可被调用 $TestResult powershell.exe -Version 2.0 -Command $PSVersionTable.PSVersion.ToString() 21 if ($TestResult -match ^2\.0) { Write-Host 验证通过PowerShell 2.0 引擎可正常调用。 } else { Write-Host 验证异常引擎不可调用请重启系统后重试。 }脚本逻辑上做了一个判断分流如果功能已经启用直接进入验证环节不重复执行启用命令如果未启用则依次打开引擎和 ISE。ErrorAction Stop是让Get-WindowsOptionalFeature在查询失败时直接抛出错误而不是返回一个空对象避免后面的调用走空。验证调用是走一个独立的powershell.exe -Version 2.0进程如果系统注册搞定且重启完成这里会打印 2.0 字样如果没重启大概率得到的是报错文本脚本会提示你重启后重试。验证通过之后SQL Server 的安装可以走无人值守模式用/Q配合参数文件把 PowerShell 2.0 这个检查项提前在脚本端过关# SQL Server 安装程序静默安装参数示例 setup.exe /Q /IACCEPTSQLSERVERLICENSETERMS /CONFIGURATIONConfigurationFile.iniConfigurationFile.ini里建议把SQLCOLLATION、SQLSYSADMINACCOUNTS和FEATURES等关键项提前写好安装向导在静默模式下不会再交互询问。/IACCEPTSQLSERVERLICENSETERMS是必须的不加这个安装会直接退出不给你解释的机会。这套组合打下来新机器的环境准备时间大概十几分钟主要是在等重启。从那以后我只要在这类旧系统上部署 SQL Server都会强制走一遍“查功能状态 → 启用 → 重启 →-Version 2.0验证”的流程不管安装向导报不报错四步都不省。因为环境检查的坑往往不在第一台机器上出现而在交付到第三、第四台时突然蹦出来到时候再回头排查浪费的时间远比现在多得多。这篇整理就算给你留个后悔药装之前把检查项摸透装的时候一次过希望帮到你。本文还有配套的精品资源点击获取
