简介：面向 Windows Server 2012 系统管理员与运维人员的 .NET Framework 3.5 离线安装镜像包，专门应对系统默认未启用该框架、在线更新拉取失败，或服务器无外网、缺少完整安装介质时出现的 .NET 3.5 安装失败与服务无法开启等问题，也适用于隔离网络和严格防火墙环境下的补装场景。压缩包共收录 1569 个文件，整体约 101.69MB，以 dll、resx、exe 等框架运行与资源文件为主，并含 config、sql、aspx 等配套组件，覆盖 WPF、WCF、WF 等旧版应用依赖，目录按 SxS 源组织，可作为 DISM 离线源调用。包内附使用说明 txt，能帮助读者确认 SxS 源路径、完成 NetFx3 功能启用并核验安装状态，同时为安装报错提供排查线索；目录结构集中、组件齐全，便于在无完整安装介质时快速定位所需文件，减少反复下载与等待。目前已有 10498 人学习下载，适合需要为老旧业务系统补装框架、快速排错与离线部署的读者参考。
1. 那台没有外网的服务器，卡在一条 0x800F0906 上
上个月帮一个做产线设备集成的朋友排查一台内网机器：Windows Server 2012，装一套老的上位机采集软件，安装向导第一步就弹「此应用需要 .NET Framework 3.5」。他照网上教程打开服务器管理器勾选 .NET Framework 3.5，进度条走两下就回滚，报 0x800F0906；换成 PowerShell 敲 .net 3.5 安装命令，结果一模一样。这其实是 .net3.5 安装失败的经典形态：机器根本拿不到安装源，和外网是否连通关系不大。
这份 window server 2012 的--sxs镜像资源包解决的就是这一环：把安装介质里sources\sxs目录下的按需功能载荷单独拎出来，做成一个可以拷进内网、挂到共享盘、随系统镜像一起分发的本地源，让dism /online /enable-feature /featurename:NetFx3 /source:... /limitaccess这条命令能真正跑通。它适合三类人：机房完全隔离、补丁服务器策略很严、以及手上一堆必须吃 3.5 运行时的老工控软件要交付的运维和集成同学。
2. 先把 --sxs 的机制搞清楚：为什么勾选会失败
2.1 按需功能与 SxS 目录的配对逻辑
从 Windows 8 / Server 2012 这一代开始，.NET Framework 3.5 的运行库就不再默认躺在系统盘里了。系统安装完成后，C:\Windows\WinSxS里只保留了一个「功能占位」的清单（manifest），真正的二进制载荷（payload）被挪到了安装介质的sources\sxs目录下。这个设计叫 Features on Demand，按需功能：你不用就不占空间，你要用，就得给它一个「源」。
所以勾选那个复选框的时候，系统实际做的是三件事：读功能清单 → 发现本地没有载荷 → 回头去找源。默认的源顺序是先本地介质，再 Windows Update。内网机器连不上更新服务器，第三步必然超时，回滚，报 0x800F0906。这也是为什么很多人以为「联网就能装」——在能出公网的机器上确实能装上，因为它悄悄从更新服务器把几百兆载荷拉下来了；一旦断网，同样的操作就废了。
--sxs这个说法严格讲不是参数，而是习惯叫法，指的是把sources\sxs作为 DISM 的/Source传进去。真正起作用的参数是/Source和/LimitAccess，前者告诉系统载荷在哪，后者明确禁止系统再回头去碰 Windows Update。两个一起用，才是一次干净、可预期、不依赖网络的离线安装。
有一点得先记住：sxs 目录里的 cab 不是通用件，它带版本和架构属性。拿到一个包里microsoft-windows-netfx3-ondemand-package.cab这类文件，它能装到哪个系统上，是写死在包里的元数据决定的，不是靠文件名猜的。这个特性决定了后面一大半的坑。
2.2 三条安装通道的失败对照
实际现场能走的路就三条，我把它们对应的现象整理成一张表，对号入座比盲试快得多：
| 通道 | 典型命令/入口 | 前置条件 | 常见失败码 | 根因 |
|---|---|---|---|---|
| Windows Update | 服务器管理器勾选 /Install-WindowsFeature不带-Source | 能访问更新服务器 | 0x800F0906、0x8024402C | 载荷下不下来，被 WSUS 拦截或网络不通 |
| WSUS 内部源 | 组策略指向内部更新服务 | WSUS 已批准按需功能产品 | 0x800F0907、0x800F0906 | 内部源没同步该功能，或策略强制只能走内部源 |
| 离线 sxs 源 | dism /online /enable-feature /featurename:NetFx3 /all /source:X:\sxs /limitaccess | 载荷版本与系统匹配 | 0x800F081F、0x800F0906 | 路径指错、目录空、版本错配 |
第一列和第二列的共同点是「依赖别人」：要么依赖公网，要么依赖内部更新服务的管理员配合。第三列是把依赖捏在自己手里，代价是你得保证包是对的。资源包的价值就在这里，它把不可控的网络因素换成了可控的文件校验。
2.3 版本对齐：6.2 和 6.3 的包不能互换
这是我见过最多人栽的地方。Windows Server 2012 的内核版本是 6.2.9200，Server 2012 R2 是 6.3.9600，两者虽然名字只差一个 R2，但 sxs 载荷完全不通用。把 2012 R2 光盘里的sources\sxs拷给 2012 用，命令会跑，进度条会动，最后大概率给你一个 0x800F081F，日志里写的是源文件与目标系统不匹配。
反过来也一样，而且更难发现：有的机器是 2012 装了 R2 的功能更新包，systeminfo里显示的版本号还在 6.2，这时候你按版本号选包也可能错。稳妥的做法是同时看两个值：
# 一次看全：产品名、内部版本号、安装类型 Get-ComputerInfo -Property WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture # 再确认一次系统盘对应的版本键值 Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object ProductName, CurrentBuild, CurrentBuildNumber参数说明：WindowsProductName给的是营销名称（是否带 R2 一眼看清），OsBuildNumber是真正的判定依据，7600 段是 2008 R2，9200 段是 2012，9600 段是 2012 R2。两个值对不上就说明系统被改过，这时候不要急着装，先把补丁栈理清楚，否则后面会出现装上了但应用起不来的怪事。
还有一个容易忽略的点是架构。x64 系统要 x64 的载荷，sources\sxs里通常同时存在 amd64 和 x86 的组件，DISM 会自己挑，前提是你给的是完整目录而不是手动挑出来的单个 cab。所以我一律建议整个sxs目录原样拷贝，不要自作聪明地筛文件。
3. 把资源包落地：DISM 与 PowerShell 两条路
3.1 先验包：sxs 目录该有什么、怎么对版本
拿到资源包，先别急着敲命令。一个可用的 sxs 目录，最低限度要能通过下面这个检查：目录里存在按需功能载荷文件，且文件大小不是 0。有些从网络上下来的 ISO 为了压体积，sources\sxs里是空的或者只有一两个占位文件，这种包用了也白用。
# 1) 列出 sxs 目录内容，确认有实体载荷 Get-ChildItem -Path 'D:\sxs' -File | Select-Object Name, @{N='SizeMB';E={[math]::Round($_.Length/1MB,2)}} | Sort-Object SizeMB -Descending # 2) 直接问 DISM 这个目录能不能当源用（不会改系统，只是探测） dism /online /enable-feature /featurename:NetFx3 /source:D:\sxs /limitaccess /Quiet第一段只是看清单，正常情况下能看到若干 cab 文件，其中带netfx3字样的那个是主力。第二段看着像真的在装，其实加/Quiet之后失败也会立刻返回错误码，适合快速探路；如果不放心，把/Quiet换成/Get-FeatureInfo也行，但那条命令不能带/Source，只能验证功能状态。我一般的顺序是：先Get-ChildItem看文件，再跑一次真正的安装，出错直接去看日志，比反复试探快。
如果手上的 ISO 的sxs目录是空的，还能从install.wim里把载荷抠出来。这一步很多人不知道，但确实管用：
# 只读挂载安装镜像的第一个索引，把 sxs 载荷复制出来 New-Item -ItemType Directory -Path C:\mount\wim -Force | Out-Null dism /Mount-Wim /WimFile:E:\sources\install.wim /Index:1 /MountDir:C:\mount\wim /ReadOnly # 在挂载出来的离线系统里按关键字筛 netfx3 相关组件 Get-ChildItem 'C:\mount\wim\Windows\WinSxS' -Recurse -Filter '*netfx3*' | Select-Object FullName, @{N='SizeMB';E={[math]::Round($_.Length/1MB,2)}} # 用完必须卸载，/Discard 表示不保存任何改动 dism /Unmount-Wim /MountDir:C:\mount\wim /Discard参数说明：/Index:1对应 install.wim 里的第一个映像，多版本 ISO 里 1 号通常是 Standard 或 Core，取 sxs 载荷跟具体 SKU 无关，只要大版本对得上就行。/ReadOnly是保护措施，防止误改镜像；/Discard是不写回，卸载后 WIM 文件保持原样。筛出来的文件按原目录结构拷到一个新建的sxs文件夹里，就能当源用了。
3.2 DISM 命令行安装与参数逐项拆解
真正安装就一条命令，但每个参数都有讲究，少一个结果可能完全不同：
# 从本地 sxs 目录启用 .NET 3.5，禁止回源到 Windows Update # 路径不要带引号之外的斜杠写法，反斜杠结尾也别加 dism /online /enable-feature /featurename:NetFx3 /all /source:D:\sxs /limitaccess逐项说：
/online表示操作当前运行的系统，不是离线镜像。如果你是在 WinPE 里给别的系统盘装，得用/image:C:\指定挂载路径，这是两套完全不同的用法，混淆了会报「找不到指定的路径」。
/enable-feature是动作，配套还有/disable-feature、/get-features。
/featurename:NetFx3是功能名。Server 端在 PowerShell 里叫NET-Framework-Core，DISM 里叫NetFx3，两个名字指同一个东西，别混用。
/all会一并启用父功能。.NET 3.5 在功能树上有依赖项，不带/all有时会留下「已启用但残缺」的状态，应用照样报错。这个参数我从来不加思考地带上。
/source:D:\sxs指向载荷目录。最常见的低级错误是指到D:\或者D:\sources，DISM 会找不到子目录里的 cab。另一个隐性问题是路径里有空格或中文，DISM 对这类路径的处理不算稳，我一般把包放在根目录下的纯英文短路径里。
/limitaccess阻止系统去联系 Windows Update。不加这个，即使你给了源，系统在某些策略下仍会尝试联网，一旦超时就会把整个安装拖成失败，错误码还看不出来是网络问题。
装完给个进度百分比和「操作成功完成」，这时候别急着交付，先看功能状态：
# 确认功能状态是 Enabled，而不是 Enable Pending dism /online /get-featureinfo /featurename:NetFx3如果显示State : Enable Pending，说明需要重启才生效，这在 Server Core 上尤其常见。重启前不要下结论说装失败。
3.3 PowerShell 等价写法与功能名对照
命令行在某些自动化框架里不好拼装，PowerShell 更顺手。注意 Server 和客户端用的模块压根不是一套：
# Server 2012 / 2012 R2：走 ServerManager 模块，功能名 NET-Framework-Core Install-WindowsFeature -Name NET-Framework-Core -Source 'D:\sxs' -Restart # 客户端系统（Win8/8.1/10 同代）：走 DISM 模块，功能名 NetFx3 Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source 'D:\sxs' -LimitAccess -NoRestart参数说明：-Source在Install-WindowsFeature里可以直接给目录，PowerShell 会自己找；-Restart是允许自动重启，如果不想打断业务就去掉，改成手动挑时间。Enable-WindowsOptionalFeature的-All等价于/all，-LimitAccess等价于/limitaccess，-NoRestart等价于不自动重启。
功能名这块单独列一张表，省得每次翻文档：
| 用途 | DISM 功能名 | PowerShell 名称 | 所属模块 |
|---|---|---|---|
| .NET 3.5 运行时 | NetFx3 | NET-Framework-Core | ServerManager |
| .NET 3.5 完整功能集 | NetFx3 / NET-Framework-Features | NET-Framework-Features | ServerManager |
| WCF HTTP 激活（3.5） | WCF-HTTP-Activation | NET-WCF-HTTP-Activation | ServerManager |
| WCF 非 HTTP 激活（3.5） | WCF-NonHTTP-Activation | NET-WCF-NonHTTP-Activation | ServerManager |
| ASP.NET 3.5 支持 | NetFx3-ASP-NET | NET-Framework-ASPNET | ServerManager |
一个实操提醒：Install-WindowsFeature的-Source只对「按需功能」类有效，对内置功能会直接忽略而不报错，所以命令返回成功不代表源被用上了。判断方法是看它有没有走网络——-Source生效时整个过程是秒级的，如果卡了几十秒再成功，多半是偷偷联网了。
3.4 组策略与注册表指定备用源（批量场景）
单台机器拷个包就完事，几十上百台就得换个思路。组策略里有一个专门管这件事的入口：计算机配置 → 管理模板 → 系统 → 指定可选组件安装和组件修复的设置。启用之后填两个值：备用源文件路径（指向共享盘上的 sxs 目录），以及「从不尝试从 Windows 更新下载修复内容」。
对应的注册表在HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing，批量下发脚本化更省事：
# 批量指向共享盘上的 sxs 源，适合加进开机脚本或配置管理工具 $regPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing' if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force | Out-Null } # 备用源路径，用 ExpandString 支持环境变量，方便多环境复用 Set-ItemProperty -Path $regPath -Name 'LocalSourcePath' ` -Value '\\fileserver\deploy\sxs' -Type ExpandString # 关闭「回源到 Windows Update」的行为 Set-ItemProperty -Path $regPath -Name 'UseWindowsUpdate' -Value 2 -Type DWord # 回读确认写入生效 Get-ItemProperty -Path $regPath | Select-Object LocalSourcePath, UseWindowsUpdate参数说明：LocalSourcePath支持 UNC 路径，但要求执行安装的账户对该共享有读权限——用 SYSTEM 账户跑计划任务时权限会丢，这是个高频坑，建议提前用net use或给机器账户授权。UseWindowsUpdate的数值语义在不同补丁级别下表述不完全一致，我一般先在测试机用组策略界面配一遍，再把注册表导出比对，比自己猜数值靠谱。共享目录本身建议只读挂载，避免有人误删。
组策略落地之后，新装机器连命令都不用敲，服务器管理器里勾选就能直接从共享盘取包。代价是共享盘不能挂，所以关键环境我还是会在本地磁盘留一份副本作为兜底。
4. 避坑与排查：五类高频翻车的现象、原因和解法
4.1 0x800F0906 / 0x800F081F / 0x800F0907 三兄弟
这三个码长得像，含义完全不同，混着处理只会浪费时间。
现象一：0x800F0906，提示「无法下载源文件」。原因：压根没给源，或者给了但系统没认。最常见的是路径指错一级——给的是D:\而不是D:\sxs，或者 sxs 目录是空的。解决：先用Get-ChildItem确认目录里有 cab 文件，再把完整路径带进/source，同时确保/limitaccess在场。如果路径没问题还是这个码，去看C:\Windows\Logs\DISM\dism.log尾部，它会明确写「找不到文件 xxx」，照着文件名回去找。
现象二：0x800F081F，提示「找不到源文件，请检查用于安装该功能的源」。原因：包版本或架构与系统不匹配。这是版本错配的典型表现。解决：核对系统内部版本号（9200 还是 9600），换对应大版本的 sxs。还有个隐蔽情况是只拷了 cab 没拷配套的清单文件，DISM 认不出包，也会报这个。解决方式是整目录拷贝，不要挑单个文件。
现象三：0x800F0907，提示「组策略不允许从 Windows Update 下载」。原因：域策略强制只能走内部源，而内部源没有这个功能。解决：优先按 3.4 的方式配本地源；实在不行联系域管理员在测试 OU 里临时放开策略，装完再挪回去。生产机上直接改注册表绕过策略是下策，下一次策略刷新就回去了。
4.2 WSUS 把备用源顶掉
现象：所有步骤都对，源也给了，还是失败，而且失败得特别慢。原因出在 WSUS 客户端策略。当机器被配置为使用内部更新服务器（UseWUServer置 1），所有原本发往 Windows Update 的请求都被重定向到 WSUS，而 WSUS 默认不会同步「按需功能」这类产品，于是请求打到内部服务器上被拒，DISM 等到超时才回滚。
# 看一眼 WSUS 客户端策略有没有接管更新通道 Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' ` -Name UseWUServer -ErrorAction SilentlyContinue | Select-Object UseWUServer返回 1 就说明接管了。解决思路不是去改 WSUS 策略（会影响整机补丁合规），而是让 DISM 完全不碰网络：/source加/limitaccess一起上。如果还是不放心，可以在执行安装的那个会话里临时把UseWUServer置 0，装完立刻改回 1——但这是我最后才用的手段，因为中间任何一次策略刷新都可能把值写回去，容易出现「这次成功下次失败」的玄学。
4.3 镜像版本错配与取包姿势的坑
现象：装到一半失败，或者装成功了但应用一启动就报「无法加载运行时」。前者的原因在 4.1 讲过，后者更阴——用客户端系统（Win8/8.1）的 sxs 载荷给 Server 2012 装，某些文件能对上，功能状态显示 Enabled，但组件版本对不上，老应用一调就崩。
还有一种情况是从install.wim取包时索引选错。多版本 ISO 的install.wim里 1 号索引往往是最小安装（Server Core），2 号以后才是带桌面的版本。取 sxs 载荷跟索引关系不大，但如果你同时还从里面取了别的东西，就容易混。我的习惯是取完包之后单独建一个目录，只放 sxs 相关内容，不给后续操作留混淆空间。
解决的核心就一句：sxs 的来源必须是同一大版本、同一架构的安装介质。宁可多下一个 ISO，也别凑合。
4.4 装完还报错：WCF 激活与 .NET 3.5 服务开启
现象：NetFx3状态已经是 Enabled，注册表里版本号也在了，但应用还是起不来。这时候问题往往不在运行时本身，而在依赖它的子功能没开。老工控软件里有一大类是 WCF 服务宿主，靠 HTTP 激活转发请求，光有运行时不够。
# .NET 3.5 的 WCF 激活是独立功能，需要单独启用 dism /online /enable-feature /featurename:WCF-HTTP-Activation /all /source:D:\sxs /limitaccess dism /online /enable-feature /featurename:WCF-NonHTTP-Activation /all /source:D:\sxs /limitaccess # 顺带把 ASP.NET 3.5 的注册状态确认一下（在 v2.0.50727 目录下执行） & "$env:windir\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe" -lv参数说明：-lv只做状态查询不做修改，安全；真要注册用-i，但在多版本共存环境里直接-i会覆盖 IIS 的映射，动之前先备份站点配置。很多人搜索「.net 3.5 服务开启」时以为是开某个 Windows 服务，其实 .NET 3.5 本体没有常驻服务，他们真正要的是 WCF 激活和 ASP.NET 注册这一层。
另外别忘了位数。应用如果是 32 位的，Framework和Framework64两个目录下的配置都要对得上，只注册一边就会出现「同一台机器上 A 程序能跑 B 程序不能跑」的怪现象。
4.5 日志怎么读：dism.log 与 CBS.log 的定位顺序
现象：错误码给了，但看不出到底缺哪个文件。原因是没看对日志。安装类问题的日志有两条线：C:\Windows\Logs\DISM\dism.log记录 DISM 层面的动作和参数，C:\Windows\Logs\CBS\CBS.log记录组件安装的细节。排查顺序是先 DISM 后 CBS，因为 DISM 先告诉你哪一步失败，CBS 再告诉你具体哪个文件出问题。
# 看 DISM 日志最后 60 行，错误通常就在尾部 Get-Content 'C:\Windows\Logs\DISM\dism.log' -Tail 60 # 在 CBS 日志里按错误级别和关键字过滤 Select-String -Path 'C:\Windows\Logs\CBS\CBS.log' -Pattern 'Error|0x800f|netfx3' | Select-Object -Last 30小技巧：CBS.log 动辄几百兆，直接Get-Content会卡死机器，用Select-String流式过滤。另外这些日志在安装过程中是被占用的，实时看不方便，我一般等命令返回后再看，或者把它复制一份出来读。
5. 交付前必走的三道验证：从「装上了」到「敢上生产」
装完不等于能用，这是我在交付现场吃过亏之后定下的规矩。第一层验证看功能状态，dism /online /get-featureinfo /featurename:NetFx3返回State : Enabled，注意不是Enable Pending，是 Enabled 且没有待重启标记。
第二层验证看注册表里的实际版本号，功能状态有时候会骗人：
# 版本号在 3.5.30729 这一族，Install 为 1 表示已完成安装 Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5' | Select-Object Version, Install, SP第三层也是最容易被跳过的一层：拿目标应用实跑一次。找个最简单的 3.5 编译的小程序，或者直接用目标软件自己的安装向导走到能启动主界面的那一步。我见过功能状态完美、注册表正常，结果应用一启动就崩在缺少某个 WCF 程序集上——只有实跑能发现。
批量场景下我会把这三层压成一个脚本，跟着部署流程走：先Test-Path共享源可达，再比对OsBuildNumber和源目录里的版本标记，最后执行安装并回读功能状态，任何一步失败就退出非零码，让上层流程停下来。这个脚本里我特意不写自动重启，重启时机交给业务窗口决定。
# 部署前自检：源可达 + 版本对齐 + 功能状态，三步任一失败即中止 $src = 'D:\sxs' if (-not (Test-Path (Join-Path $src '*.cab'))) { throw "源目录无载荷：$src" } $build = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').CurrentBuildNumber if ($build -notin @('9200','9600')) { throw "未覆盖的系统版本：$build" } $state = (Get-WindowsFeature -Name NET-Framework-Core).InstallState if ($state -ne 'Installed') { Install-WindowsFeature -Name NET-Framework-Core -Source $src -ErrorAction Stop }这段脚本里Get-WindowsFeature只在 Server 上可用，客户端系统要换成Get-WindowsOptionalFeature -Online -FeatureName NetFx3。我把它放在部署包根目录，文件名带上适用版本号，避免不同批次的机器拿错包。资源包本身建议在文件服务器上留一份、U 盘里备一份，隔离机房的现场网络状况你永远猜不到。
血泪经验是：有一次赶进度跳过了第二层验证，功能状态显示已启用就直接交付，结果对方业务跑了两天才发现报表模块报错，回头一查是版本号不对，装的是残缺包，只能重装。从那以后我每次离线装 .NET 3.5，都强制把三层验证走一遍，哪怕只是给自己装一台测试机。希望帮到你。
本文还有配套的精品资源，点击获取
