简介：针对Windows Server 2012 R2及各类云服务器中安装.NET Framework 3.5时常见报错（如提示找不到源文件、需通过“源”选项指定位置），这份亲测有效的离线修复资源包提供了完整备选方案，面向运维工程师与系统管理员，尤其适合无法使用Windows Update或缺少系统镜像的离线环境。包内共含1568个文件，以dll、resx、exe、config、sql、aspx等为主要类型：dll为运行时核心组件，config与sql用于配置和数据库支持，aspx等则可能对应Web相关模块。压缩包99.19MB，便于拷贝至目标服务器。目前已有10328人学习下载，证明该方案经过大量同类场景验证。资源内含完整的安装源文件与依赖项，用户无需联网或额外挂载系统镜像，按照压缩包目录结构即可定位所需内容，从而绕开源文件缺失的报错。该资源对排查SQL Server部署或系统组件异常时的依赖问题也有参考价值。
1. 前置检查就翻车：SQL Server安装被.NET 3.5卡住
在Windows Server 2012上部署SQL Server，前置检查报「需要安装.NET Framework 3.5」——这个卡点我碰到过太多次了。服务器平时运行得好好的，一进SQL Server安装向导就被拦在最前面，错误码0x800F0906转圈半天，愣是不肯装上。你要是图省事，直接去服务器管理器勾选.NET 3.5功能，多半又碰上Windows Update连不上，最后不是装了个半吊子，就是把系统组件状态搞得更乱。这就是一份排错笔记：先分清几个高频报错码背后的真实原因，再用DISM离线把功能装扎实，最后把SQL Server安装和后续验证里的坑一个个踩平。
2. 为什么装不上：Server 2012的.NET 3.5机制与三个高频报错码
在动手之前，得先弄明白一件事：为什么这个功能在Server 2012上这么难装。很多服务器管理员的第一反应是「下载一个.NET 3.5安装包装上」，但这个思路从一开始就走偏了。下面从机制开始拆。
2.1 默认不带：.NET 3.5在Server 2012里是「半隐藏」功能
Windows Server 2012默认只把.NET 4.x作为系统组件装好，.NET 3.5在「添加角色和功能向导」里虽然看得到，但默认状态是「未安装」。你勾选它并点下一步，系统要做的不是把组件直接解压出来，而是先在本地组件存储（WinSxS目录）里找NetFx3的cab包。本地没有这份cab，启用动作就会自动转向Windows Update去下载。
这里有个让人踩坑的细节：向导里的勾选动作本身不代表已装好，它只是触发了「启用」流程。整个流程依赖两个来源——本地的sources\sxs目录和Windows Update。生产服务器如果禁了出网，或没挂安装镜像，这个流程就悬在「正在下载更新…」上，转圈半小时后给你一个0x800F0906。SQL Server的安装程序也是一样的逻辑：它的系统配置检查器检测到NetFx3功能State不是Enabled，就判定环境不满足要求，把安装向导直接拦下。这里要记住：SQL Server要的不是「.NET 3.5运行时能用」，而是Windows功能状态被标记为「已启用」。
再补一个常见误区：有人跑到外网下载dotNetFx35setup.exe，双击安装完，回来看功能开关还是灰的，SQL Server照样卡。原因在于Server 2012里的.NET 3.5功能包含的不只是运行时的那些dll，还包含与系统组件存储、注册表、以及Windows功能API层面的联动。普通安装包走的是应用程序级注册方式，它不会去动Windows功能开关，也不会往WinSxS里补充组件。所以你觉得自己装好了，系统却不认。在Server 2012上，正经做法是DISM或服务器管理器里的功能启用，而不是外网下载的安装包。
2.2 0x800F0906：更新通道走不通，在线启用卡死的真实原因
现象很典型：在服务器管理器或DISM里启用NetFx3，进度条卡住，最后报0x800F0906。触发条件集中在三类：服务器没有外网权限、Windows Update服务被组策略禁用、或网络代理拦住了下载请求。
这个错误码的本质是「启用功能时找不到可用的源」。它不是文件损坏，也不是权限不够，就是下载通道的问题。我遇到过的场景很一致：服务器能出公网，但安全软件把系统代理改成了一个不通的内网代理地址，下载请求全部超时；更多时候是内网服务器压根没有外网路由，系统连Windows Update超时后抛出这个码。
先跑这两条命令，把网络因素和源文件因素分开：
# 查看系统代理状态，确认是否被改成了不通的代理 netsh winhttp show proxy # 手动触发一次Windows Update检测 wuauclt /detectnow第一句看当前系统代理有没有被动过，第二句手动触发一次Windows Update检测，然后去事件查看器看失败记录。如果确认是网络问题，就别跟在线安装死磕，直接走第3章的离线方式。另外检查一下Windows Update服务本身：
# 查看Windows Update服务启动类型 Get-Service wuauserv如果StartType是Disabled，先把服务设为Manual并启动，再决定是走在线还是离线。
提醒一句：不要反复重试在线启用。每次重试系统都会长时间停在下载状态，占用资源不说，中途手动取消还有可能把功能服务弄到「已卸载但残留」的半状态，后面处理起来更麻烦。
2.3 0x800F081F与0x800F0954：源文件缺失与组策略干扰要分清
0x800F081F这个码我见过最多的是在DISM指定/source时路径写错。比如把ISO里的sources\sxs拷到D盘后，路径写成D:\sources而漏掉了sxs这一层，DISM在指定位置找不到NetFx3.cab，马上报0x800F081F。它和0906的区别在于：0906是「系统连下载源都没有就上网找，结果网络不通」；081F是「你自己指定了源，但源不对」。处理思路是反着来的。
0x800F0954在高管控生产环境里很有代表性。组策略里有一条「指定Windows安装程序搜索顺序（Server 2008及以后）」被管理员指向内网WSUS服务器。启用功能时，系统优先去WSUS取文件，但WSUS地址不可达或者没有同步.NET 3.5的相关补丁，于是报0x800F0954。它和0906不一样：0906是干脆连不上公网，0954是组策略强制你的功能启用走内网指定通道，而你绕不过去。处理办法是两个方向：先改正组策略里那条设置，或者直接用/LimitAccess参数掐断DISM对Windows Update和WSUS的搜索。
三个错误码用一张表收着，排查时先对号入座：
| 错误码 | 一句话根因 | 典型触发场景 | 首选排查方向 |
|---|---|---|---|
| 0x800F0906 | 在线更新通道不可达 | 服务器无外网权限、代理不通 | 检查代理与Windows Update服务 |
| 0x800F081F | 指定源路径无效或缺失 | /source目录写错、sxs不完整 | 确认NetFx3.cab存在且版本匹配 |
| 0x800F0954 | 组策略强制走内网更新源但不可达 | WSUS地址失效或未同步 | 检查组策略，或加/LimitAccess绕开 |
这几个码有时会交织出现。比如先报0906，你把本地源补上后又报081F，这太正常了，说明前一个问题被绕过，后一个问题浮出水面。我还遇到过更连串的：先报0x800F0954，把组策略那条改回Not Configured后，跑DISM又变成0x800F0906，说明策略是绕开了，但公网还是不通。最后加/LimitAccess走离线，一条命令通过。按表逐项消就对了。
3. 离线安装.NET 3.5：DISM命令与sxs源文件调度
核心思路就一句话：告诉DISM别上网，从本地sxs里拿源文件。下面把整个流程拆开说，从命令到源文件准备再到验证。
3.1 一条DISM命令：/source指向本地sxs目录
直接给结论。只要有与当前系统相同版本、相同语言的Server 2012安装镜像，取到它的sources\sxs目录，就能完全离线启用：
# 启用NetFx3并强制禁用Windows Update源 dism /online /enable-feature /featurename:NetFx3 /all /source:C:\sxs /LimitAccess命令参数逐个说清楚：
- /online：表示操作对象是当前正在运行的操作系统。
- /enable-feature：启用指定的Windows功能。
- /featurename:NetFx3：功能名固定叫NetFx3，大小写不敏感。
- /all：连同父功能一并启用。.NET 3.5上层还可能涉及WCF HTTP激活等子项，不加/all有时候会留下部分未启用的残留。
- /source:C:\sxs：告诉DISM去哪里找NetFx3.cab。路径建议放在无空格、无中文的目录下。
- /LimitAccess：禁止DISM自动访问Windows Update或WSUS。这是离线安装的关键，不加它，即使给了/source，DISM仍可能尝试联网。
这条命令看起来长，其实核心只有两个点：/featurename:NetFx3是目标，/LimitAccess是手段。中间那个/source只是把源文件位置交代清楚。生产环境里我一般把这条命令和后续的验证命令放在同一个脚本里执行，减少人工输错的概率。
执行后看到「操作成功完成」，基本就成了一半。如果报0x800F081F，回到第2章那张表，先检查路径和文件。命令一定要在管理员权限的PowerShell或命令行里执行，普通权限会被直接拒绝。
提示：为什么不用服务器管理器的图形向导？远程桌面会话里那个向导渲染慢，报错还很笼统，只给一句「无法完成」，不告诉你具体是哪个源不可达。DISM至少把错误码摆在明面上，配合上面的表一眼就知道该调路径还是调策略。线上环境建议只用命令行。
3.2 没有现成sxs？从ISO里整目录拷出来
手里只有ISO时，常见做法是先挂载：
# 挂载系统镜像，挂载后会分配一个盘符 Mount-DiskImage -ImagePath "D:\ISO\WindowsServer2012_x64.iso" # 把sources\sxs整目录拷到本地，DISM源路径指向这里 Copy-Item E:\sources\sxs C:\sxs -Recurse挂载成功后系统会给它分配一个盘符，比如E:。接着把3.1命令里的/source改成C:\sxs再跑。
有人会问，能不能不拷，直接让/source指向E:\sources\sxs？有些环境确实行，但我踩过一次域策略收紧的场，DISM访问光盘介质时被过滤驱动拦了，报「拒绝访问」。所以现在的习惯是：先花半分钟把sxs拷到本地磁盘，顺手看下NetFx3.cab在不在，省得来回折腾。
版本匹配要单独拎出来说。Server 2012和Server 2012 R2是两个不同的系统，sxs组件不互通。用R2的sxs往2012上装，DISM就算不报错，后续系统更新时也可能出问题。想确认ISO版本，可以加载后用这条命令看镜像信息：
# 查看install.wim的版本信息，确认与目标系统匹配 dism /get-wiminfo /wimfile:E:\sources\install.wim没有图形环境或不方便挂载的，直接用解压工具把ISO里的sources\sxs文件夹拖出来也行。拷出来后先看一眼文件夹里有没有NetFx3.cab，没有就是镜像没选对。
注意：Server 2012与Server 2012 R2的sxs组件不互通，跨系统版本的源文件宁可不用。
3.3 验证别靠直觉：State为Enabled才算数
装完后的验证不能只看「服务器管理器里是绿的」，我一般跑两条命令相互确认：
# 查看NetFx3功能状态，State应为Enabled dism /online /get-featureinfo /featurename:NetFx3 # 服务器管理器视角确认，Installed应为True Get-WindowsFeature -Name NET-Framework-Core第一条是权威判断，输出里State字段为Enabled才是真正激活。如果显示Disabled或Enable Pending，说明功能还没彻底装好。第二条在带图形界面的Server 2012上可用，Installed字段为True才踏实。两条命令输出一致，再进SQL Server安装向导就稳了。
补充一个细节：DISM的/online操作一般不需要重启。但如果系统提示需要重启才能完成，别拖，重启后再跑一次get-featureinfo确认State没变回Disabled。如果出现这种提示还硬要拖到SQL Server安装向导里，SQL Server装到一半系统重启会更尴尬。
4. 避坑记录：.NET 3.5安装中最常翻车的5个场景
下面这几个坑覆盖了我遇到的绝大部分「装不上」案例，每一条按现象、原因、解决三步来写，方便你对照。如果你时间只够看一章，就把这一章过一遍，大概率能直接命中你的问题。
4.1 坑一：勾了IIS的ASP.NET 3.5就以为搞定了
现象：在服务器管理器里勾选IIS下的「ASP.NET 3.5」，向导显示安装成功，可SQL Server的前置检查照样提示需要.NET Framework 3.5。
原因：IIS那个选项是角色服务下的一个子功能，它依赖NetFx3，但不等于把NetFx3本身启用完整。向导可能只处理了与ASP.NET相关的部分，Windows功能层面NetFx3的State仍然不是Enabled。
解决：回命令行用dism /online /enable-feature /featurename:NetFx3 /all /source:C:\sxs /LimitAccess把核心功能补上。IIS那个勾选留着不碍事，但不能拿它当替身。装完用get-featureinfo确认State，别再看服务器管理器里的勾选状态了。
4.2 坑二：/source指到ISO根目录，系统报0x800F081F
现象：我把整个ISO盘符E:\直接当成/source，DISM报0x800F081F。
原因：/source要找的是sxs这个子目录，不是ISO根目录。NetFx3.cab藏在sources\sxs下，给错层级DISM自然扑空。
解决：先确认目录结构。标准路径是C:\sxs\NetFx3.cab或E:\sources\sxs\NetFx3.cab。拷到本地之前先看一眼文件在不在，用dir一秒钟就确认的事，别等DISM跑半天再报错。
4.3 坑三：sxs源和系统版本不匹配
现象：同一份sxs在A机器装好了，换到另一台同样写「Server 2012」的机器上就报错或中途退出。
原因：版本号里的差别比表面大。Server 2012和Server 2012 R2是不同系统；标准版、数据中心版虽然镜像通常一致，但系统累积更新的状态不同，组件完整性要求也不同。网上找的「万能sxs包」最不靠谱。
解决：用同版本、同语言、同来源的安装镜像提取sxs。可以用dism /get-wiminfo /wimfile:E:\sources\install.wim确认镜像版本后，再决定是否使用。如果现场找不到镜像，宁可先把服务器的累积更新列表翻出来，找一台补丁级别一致的机器处理，也不要随便在网盘上下sxs包。
4.4 坑四：在线启用一直转圈，停了又不给结果
现象：没加/LimitAccess的DISM或服务器管理器，长时间停在启用进度界面，进程还在，但等了20分钟没变化。
原因：系统在试图连接Windows Update下载，而服务器要么没外网权限，要么代理配置指向一个不通的内网代理地址。这不是DISM自身卡死，是网络层的问题。
解决：先中断操作，执行netsh winhttp show proxy看代理设置。代理设置如果是某个脚本地址，先确认该地址在当前网络可达——这种情况常出现在笔记本带入内网后没还原代理配置，服务器上也有概率遇到。确认无法出网后，就不要跟在线通道耗，走离线：挂ISO、拷sxs、加/LimitAccess。我在生产环境处理这类问题时，如果两分钟内没有进入实际安装状态，直接就掐掉重来。
4.5 坑五：重启后功能消失，SQL Server又报缺失
现象：第一次启用NetFx3，get-featureinfo显示Enabled，重启服务器后再看变成Disabled，SQL Server的前置检查重新报错。
原因：这类情况多数是系统曾经被第三方工具或旧安装包改动过组件注册信息。功能层面的开关和实际组件状态不一致，某次系统更新或清理把残留状态校正回去了。
解决：重新走一遍离线DISM启用，这次完成后不要再用任何第三方修复工具动Windows功能。验证以dism /online /get-featureinfo /featurename:NetFx3为准，别只信服务器管理器的勾选框。如果反复出现，再跑一次sfc /scannow查系统文件完整性，扫描完后再启用一次。
5. SQL Server联动：装好.NET 3.5之后的验证与安装顺序
装完.NET 3.5之后，有些人心急火燎直接开SQL Server安装向导，结果又被别的检查项卡住。这一章专门讲SQL Server侧的联动：从检查规则开始，到安装顺序，再到装完后的落地验证。
5.1 SQL Server前置检查的硬规则：为什么绕不过去
现象是SQL Server安装向导在「安装规则」步骤直接失败，检查项文字类似「此操作需要安装.NET Framework 3.5，请安装此功能并重新运行检查器」。
原因分析：SQL Server安装程序自身的引导逻辑和部分托管组件依赖系统级.NET Framework 3.5功能，这个检查是安装规则的一部分，硬编码在安装器里。别想改注册表跳过检查，我见过有人强行跳过，装完实例能启动，但数据库引擎的CLR功能、SQL Server代理的某些任务会在特定场景下莫名失败，排查起来比老老实实装.NET 3.5痛苦得多。
正确做法：先装功能，再跑SQL Server安装向导。顺序错了，SQL Server装到一半如果系统环境发生变化，可能需要回滚，留下一个装了一半的实例。注意在装完.NET 3.5后、启动SQL Server向导前，把系统更新里严重待重启的项目也处理掉，避免SQL Server安装过程中系统自动重启。
再补一个常见误操作：有人在SQL Server安装介质里翻出NDP或REDIST目录下的.NET运行时安装包，直接装上想骗过前置检查。这些装的是应用程序级运行时，不改Windows功能状态，检查该失败还是失败。
5.2 推荐的安装顺序：先功能后实例，一步步走
把完整顺序摆出来：
- 管理员PowerShell里执行离线DISM启用NetFx3，/source指向本地sxs、加/LimitAccess。
- 用get-featureinfo确认State为Enabled。
- 进入SQL Server安装中心，选择「安装」→「全新独立实例」或「向现有实例添加功能」。
- 在「安装规则」页确认所有检查通过，看到.NET 3.5那一项由失败变成通过。
- 继续完成功能选择、实例配置、服务账户等步骤。
- 安装完成后重启服务器，检查实例服务状态。
这个顺序里的2和4是关键节点。2没有通过之前，后面的检查没有意义；4只要有一项不过，SQL Server安装程序就停在当前步骤，给你一个不太好读的失败摘要。
第2步的意义在于把问题隔离在SQL Server之外。如果State已经Enabled，SQL Server仍然报缺失，那不是.NET没装，而是Windows功能状态和实际文件不一致。这个时候优先跑sfc /scannow修复系统，等扫描完成后再重试SQL Server安装，而不是反复重装SQL Server。sfc /scannow在Server 2012上会跑一段时间，期间服务器资源占用升高，生产环境建议窗口期操作。
另外说一句命名实例：不管你要装的是默认实例还是命名实例，前置检查的逻辑完全一样，.NET 3.5这道坎不会因为实例类型不同而消失。不要抱「我装的是新版本SQL Server所以不查3.5」的幻想，检查规则看的是目标操作系统的Windows功能状态，不是SQL Server的版本号。
5.3 落地验证：服务状态与日志检查
装完SQL Server后，重启是必须的。重启后我用这条命令扫服务状态：
# 扫描所有SQL相关服务，确认MSSQLSERVER等处于Running Get-Service | Where-Object { $_.Name -like "MSSQL*" -or $_.Name -like "SQL*" }默认实例的服务名是MSSQLSERVER，命名实例是MSSQL$实例名，SQL代理是SQLSERVERAGENT。输出里这些服务的Status如果是Running，基本盘就稳了。如果Status是Stopped，先去看系统事件日志，重点找Service-specific相关的错误记录。
再补一道检查：打开事件查看器，清除应用程序日志后重启SQL服务，等一两分钟，观察有没有.NET相关的Error记录。如果出现类似「无法加载System.Runtime」或「CLR加载失败」的日志，说明.NET功能开关虽然开了，底层运行时文件仍有问题，需要回补修复。
SQL Server配置管理器里也能看到实例运行状态，图标是绿色箭头就是正常。如果服务列表里根本没有MSSQL相关条目，说明实例创建失败，别修服务了，先翻安装日志看是哪一步失败。这一步做完，整个「装.NET 3.5 → 装SQL Server」流程才算真正闭环。
6. 再遇到这类问题：快速定位.NET 3.5安装故障的排查顺序
遇到「无法安装.NET 3.5」的报错，别直接重试，先做三件事：认错误码、验sxs文件、查镜像匹配。顺序不对会浪费大量时间。
先认错误码。0x800F0906是通道问题，优先查网络和代理；0x800F081F是源路径问题，优先查NetFx3.cab；0x800F0954是策略问题，优先查组策略。速查表在这里：
| 错误码 | 第一反应 | 一手验证命令 | 首选解法 |
|---|---|---|---|
| 0x800F0906 | 在线更新通道不通 | netsh winhttp show proxy | 转离线安装，加/LimitAccess |
| 0x800F081F | 源路径不对 | dir C:\sxs\NetFx3.cab | 修正/source路径，确认sxs存在 |
| 0x800F0954 | 组策略强制走内网更新源 | rsop.msc 查看策略结果 | 改正组策略，或加/LimitAccess绕开 |
再验sxs文件。不管报什么错误，先确认本地有没有可用的sxs。我习惯在服务器上固定放一个C:\sxs目录，镜像提取完就往里丢。这次要确认的是文件真实存在于预期路径，别靠记忆猜。
然后验证镜像与系统的匹配。用dism /get-wiminfo /wimfile:<镜像路径>看install.wim版本，再和服务器当前版本对比。Server 2012的.NET 3.5源文件必须在对应版本的镜像里取，版本差一点都不认。
从那以后，我每次在Server 2012上装SQL Server前都会强制走一遍这个顺序：先get-featureinfo看NetFx3，再决定要不要离线装，装完再确认一次。这几分钟的前置检查，帮我省掉了后面一整个下午跟安装回滚搏斗的时间。后来我把整套流程和离线sxs的准备工作整理成一个zip，就是标题里那个settled_.net3.5install.zip，新环境直接照走，不用每次翻文档。希望帮到你。
本文还有配套的精品资源，点击获取
