企业官网建设流程全解析

简介：面向在Windows Server 2012上安装或维护.NET Framework 3.5的系统管理员和旧版应用运维人员，这份SxS镜像资源包用于解决系统默认未启用该框架、通过Windows Update下载组件容易失败，以及内网服务器无法直连外网时安装受阻或服务开启异常等常见问题。压缩包共1569个文件，约101.69MB，包含720个dll、180个resx、84个exe，以及60个config、56个sql、66个aspx、22个ascx、50个browser等类型；其中运行库、配置描述、资源文件和旧版Web应用组件相互配合，便于按目录快速定位所需组件并核对SxS依赖是否完整。已有10501人学习下载。包内附使用说明，可配合DISM命令将安装源指向解压后的sxs目录，离线启用NetFx3，减少联网下载失败与反复排错；对缺少完整ISO、防火墙策略严格或需要批量部署的服务器环境，提供了较直接的组件来源和可复用的排错思路。

1. 从一台卡在「正在下载」的服务器说起

上周又碰到一台 Windows Server 2012，业务方装的是十年前的老报表系统，安装程序第一句就是「需要 .NET Framework 3.5」。同事在服务器管理器里勾上这个功能，进度条停在「正在下载所需文件」，十几分钟后弹 0x800f0906。跑老 IIS 应用、老 ERP 客户端、老打印服务的机器上，这几乎是标配场景，而 Windows Server 2012 安装 .NET 3.5 的翻车率明显高于 2008 R2 时代——从 2012 开始它变成按需功能，二进制不再预置在系统盘，而是躺在安装介质的 sources\sxs 目录里。手里有 sxs 镜像资源包，十分钟能结束；没有，就只能在报错里打转。下面这套流程是我在 2012 和 2012 R2 上反复走通的做法，新手能照抄，踩过 0x800f081f 的人也能看清参数取舍。

2. 定版本和备介质：2012、2012 R2 的 sxs 不能互相顶替

这一步比命令本身重要。我见过太多人把 DISM 敲得滚瓜烂熟，结果源拿错了版本，命令跑完照样报错，然后开始怀疑人生。装 .NET 3.5 失败的原因里，镜像版本不匹配能占到一半以上，而且它不会给你一句「版本不对」的提示，只会扔一个 0x800f0906 让你自己猜。

2.1 sxs 镜像资源包为什么能绕开在线下载

.NET Framework 3.5 是 2006 年前后随 Windows Vista / Server 2008 一代发布的东西，到 Windows 7 / Server 2008 R2 时代还是系统自带的。微软从 Windows 8 / Server 2012 开始把它改成了「按需功能」（Features on Demand）：系统盘里只保留一个功能壳子，功能名 NetFx3，真正的组件负载被挪到安装介质的 sources\sxs 目录下，用到的时候再展开。这么做的原因不复杂——镜像体积、补丁维护成本、默认攻击面，三样都要控制。

所谓「sxs 镜像资源包」，本质就是那堆 on-demand 组件的拷贝。sxs 这个名字来自 WinSxS（Windows Side-by-Side），也就是组件存储，.NET 3.5 的多版本共存机制就依赖这套东西。只要你给的源目录和当前系统的组件版本对得上，DISM 就是纯本地安装，一个网络包都不用发。

顺带澄清一个常见的误解：不少人以为必须先装 .NET 4.x 才能装 3.5。实际情况是两条并行线，CLR 2.0 和 CLR 4.0 各跑各的，先后顺序无所谓。反倒是装完 3.5 之后建议重启一次，因为组件展开后要重新注册一遍，不重启在某些 IIS 场景下会出现「功能显示已安装、应用池里却没有 v2.0」的玄学现象。

2.2 版本对照表：文件名一样，内容不一样

这是血泪经验里最值钱的一行。2012、2012 R2、2016 的 sxs 目录里，cab 文件名长得几乎一模一样，肉眼根本分不出来，但它们的组件版本号和哈希完全不同，DISM 校验的就是这个。

整个 sxs 目录体积不大，通常只有几十兆，比一个累积补丁还小，所以拷贝、校验、随镜像分发都不费劲。真正费劲的是记错版本。我一般会在目录里放一个 readme.txt，写明「本目录对应 6.3.9600」，省得半年后自己都忘了这份包是给谁准备的。

还有一个容易忽略的点：Server 2012 的 install.wim 里通常有多个索引（Standard、Datacenter，以及带不带 GUI 的 Core 版本），但 sxs 目录本身不区分索引，取哪个索引挂载都能拿到同一份组件。所以提取 sxs 的时候不用纠结索引选几，选一个能正常挂载的就行。

2.3 装前五件事，少一件都可能白跑

把这几条落成一条命令，我习惯在每台机器上先跑一遍：

# 版本号是选镜像的唯一依据，6.2 对应 2012，6.3 对应 2012 R2 Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture # 看 NetFx3 当前是 Available 还是 Installed Get-WindowsFeature -Name Net-Framework-Core | Select-Object Name, InstallState # 系统盘至少留 2 GB，组件展开和日志都要占地方 Get-PSDrive C | Select-Object Used, Free

Get-ComputerInfo里的 WindowsVersion 是 6.2 / 6.3 这种内核号，OsBuildNumber 是 9200 / 9600，两个一起看基本不会认错。Get-WindowsFeature只有 Server 版本才有，客户端系统得退回dism /online /get-featureinfo /featurename:NetFx3，输出里的 State 字段是同一个意思。空间那条别嫌啰嗦，我确实遇到过系统盘只剩 800 MB 的机器，DISM 跑到 60% 掉头，报错信息还特别含糊。

2.4 介质形态有三种，处理方式不一样

手上拿到的可能是 ISO，也可能只有别人拷出来的 install.wim，还可能是一个已经解压好的 sxs 目录，三种情况操作不同。

ISO 最省事，直接挂载就能用，路径就是<盘符>:\sources\sxs。

只有 install.wim 的话，先把 wim 挂到临时目录再取源：

:: /ReadOnly 保证挂载期间不会误改原镜像 dism /Mount-Image /ImageFile:D:\ISO\sources\install.wim /Index:2 /MountDir:C:\mnt\wim /ReadOnly :: 挂载点下的 sources\sxs 就是我们要的源 dir C:\mnt\wim\sources\sxs

/Index:2是按常见镜像的索引顺序举的例子，实际索引号用dism /Get-WimInfo /WimFile:...先看一眼。挂载完记得dism /Unmount-Image /MountDir:C:\mnt\wim /Discard卸掉，不然临时目录会一直被占着，下次挂载直接报「目录非空」。

已经是解压好的 sxs 目录，重点转成完整性检查：目录下应该直接是一堆 cab 和 mum 文件，而不是再套一层 sources\sxs。多套一层是最常见的路径错误，看到C:\sxs\sources\sxs这种结构，DISM 一定找不到源。

3. DISM 落地：三条命令覆盖在线、离线、批量三种场景

介质备好之后，真正动手的部分其实不长。核心就一条 DISM 命令，另外两条是它在不同场景下的变体。参数不多，但每一个都有它存在的理由，写错了不会报语法错，只会给你一个错误的失败结果。

3.1 挂载镜像并确认源路径

# 需要管理员权限；ISO 要放在本地磁盘，UNC 路径挂载会失败 $iso = Mount-DiskImage -ImagePath "D:\ISO\server2012r2.iso" -PassThru $vol = $iso | Get-Volume $src = "$($vol.DriveLetter):\sources\sxs" Write-Output "源路径: $src" Get-ChildItem $src | Select-Object Name, Length

Mount-DiskImage的-PassThru是为了拿到返回对象，不然这个 cmdlet 什么都不输出，后面取盘符就没法接。Get-Volume拿到的是挂载后的卷，DriveLetter属性就是盘符，别硬编码成 E:，因为机器上光驱、数据盘占用的字母每台都不一样。

如果机器跑在虚拟化平台上，直接把 ISO 挂到虚拟光驱更简单，进系统后看到的是一个普通光驱，路径同样是<盘符>:\sources\sxs。两种方式效果一致，选顺手的。

Get-ChildItem那一步别省。它同时起到两个作用：确认目录存在，以及确认里面确实有 cab 文件。目录空着、或者只放了一个说明文档的情况，我见过不止一次。

3.2 DISM 主命令与四个参数的含义

:: /Online 表示操作当前正在运行的系统 :: /FeatureName:NetFx3 是 .NET 3.5 的功能名，写成 NetFx35 会直接报找不到 :: /All 会连带启用父功能和依赖项 :: /Source 指向本地 sxs 目录，/LimitAccess 禁止回落到 Windows 更新 dism /online /enable-feature /featurename:NetFx3 /all /source:E:\sources\sxs /limitaccess

输出解读也有讲究。进度条从 0.0% 走到 100%，最后一行是「操作成功完成」，但下面通常还有一句「重新启动 Windows 以完成该操作」。这句话不是客套，组件展开完成后要重新注册一遍，不重启的话某些依赖场景（尤其是 IIS）会表现为「功能装了但用不了」。

/All这个参数值得单独说。.NET 3.5 不是一个孤零零的功能，它下面挂着若干子组件，比如跟 WCF、MSMQ 相关的部分。只启用主功能不启用父功能，DISM 不会报错，但应用跑起来会缺东西，然后你会花很长时间去查应用本身的问题，实际上根子在安装参数上。

3.3 PowerShell 与服务器管理器两条替代路径

命令行敲腻了可以用 PowerShell，语义一样，写法更顺手：

# -Source 只接受目录路径，不能指向单个 cab 文件 # 路径末尾不要带反斜杠，某些版本上会因此报「源文件找不到」 Install-WindowsFeature -Name Net-Framework-Core -Source "C:\sxs" -Restart

-Restart会自动重启，适合无人值守的批量脚本。手工操作的时候我一般不加，先看清楚输出再决定什么时候重启。-Source的路径规则和 DISM 的/Source完全一致，区别只是 PowerShell 写错路径时报错信息更友好一点。

服务器管理器那条 GUI 路径是：添加角色和功能 → 基于功能安装 → 勾选 .NET Framework 3.5 → 在下方「指定备用源路径」里填C:\sxs。GUI 有个坑：如果之前失败过一次，向导会记住失败状态，重新打开也直接跳到错误页，得把向导整个关掉再重开，或者干脆改用命令行。这也是我后来基本不碰 GUI 的原因，出问题的时候看不到中间过程。

3.4 无光驱、无外网：把 sxs 落到本地固定路径

很多生产机器没有光驱，也不允许临时挂载外部介质，那就把 sxs 复制到本地一个固定目录，一次到位，后面重装系统还能用。

:: 目录名短一点，路径里不要有中文和空格，省得后面到处转义 mkdir C:\sxs :: /E 含空目录，/COPY:DAT 只复制数据、属性和时间戳，不带 ACL robocopy E:\sources\sxs C:\sxs /E /COPY:DAT

robocopy比copy靠谱的地方在于它能处理长路径和大量小文件，而且/COPY:DAT这个组合刻意不复制 ACL——从镜像里继承来的权限有时候会带一些奇怪的拒绝项，装的时候不报错，事后排查能耗掉半天。复制完用Get-ChildItem C:\sxs | Measure-Object数一下文件数量，跟源目录对得上再往下走。

批量场景下，把 sxs 放到文件服务器的共享目录，再用组策略统一指过去，比每台机器拷一份省事。但这里有个必须提前处理的问题：访问共享的是计算机账户，不是登录的用户账户。共享权限和安全权限里都得给Domain Computers读权限，只给用户组是没用的，装的时候照样报找不到源。

4. 组策略与备用源：让服务器别再去 Windows 更新找组件

命令能跑通不代表环境就对了。域环境里，组策略会在 DISM 之上再盖一层规则，有些机器上/LimitAccess明明写了，系统还是尝试联网，最后超时失败——问题就出在这一层。

4.1 组策略里那一项到底管什么

路径是：计算机配置 → 管理模板 → 系统 → 指定 Windows 更新或 Windows Server Update Services 中可选组件安装和组件修复的设置。

这项策略控制两件事：安装可选组件时去哪找负载，以及组件损坏时去哪找修复源。启用之后有三档可选：

• 从不尝试从 Windows 更新下载负载
• 仅当本地源不可用时才尝试
• 总是尝试

内网机器一律选第一档，然后在「备用源文件路径」里填本地目录或 UNC 路径。选第二档的话，本地源路径写错的时候系统会安静地去联网，然后超时失败，报错信息完全不提源路径的事，排查方向直接被带偏。

对应的注册表位置是：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing] "LocalSourcePath"="C:\\sxs" "RepairContentServerSource"=dword:00000002

LocalSourcePath就是备用源目录，注意注册表里反斜杠要转义成双写。RepairContentServerSource的值 2 表示从不联系 Windows 更新，跟组策略里的第一档对应。改完注册表要重启相关服务或者直接重启机器，光刷新策略有时候不生效。

4.2 WSUS 环境下为什么照样失败

这是另一个高频误区：以为内网有 WSUS，可选组件就能从 WSUS 拉下来。实际上 WSUS 的产品分类里不承载按需功能的组件负载，它管的是补丁和更新，不是功能组件。域内机器默认把更新源指向 WSUS，DISM 找不到负载就报 0x800f0906 或者 0x800f0954，后者基本就是「被 WSUS 策略接管了」的意思。

处理办法只有一条：本地源 + 组策略锁定，让 DISM 根本不去问更新服务。/LimitAccess能拦住 DISM 自己的联网行为，但拦不住组策略层面的强制，所以两边都要配。配完gpupdate /force刷一遍，再用gpresult /h report.html确认策略真的落到这台机器上了，别只看组策略管理控制台里配了。

SCCM 环境同理，软件更新点不分发功能组件，指望它解决 .NET 3.5 的安装是不现实的。

4.3 把 NetFx3 直接打进 install.wim

如果一批机器都要装，与其每台跑一遍命令，不如在镜像层面解决。离线集成的方式是把 install.wim 挂起来，装上功能，再提交回去。

:: 挂载镜像到临时目录，这次是可写挂载，不能加 /ReadOnly dism /Mount-Image /ImageFile:D:\ISO\sources\install.wim /Index:1 /MountDir:C:\mnt\wim :: 在离线镜像里启用 NetFx3，源还是指向 sxs 目录 dism /Image:C:\mnt\wim /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\ISO\sources\sxs /LimitAccess :: 提交改动并卸载，/Commit 才会真正写回 wim dism /Unmount-Image /MountDir:C:\mnt\wim /Commit

三处的区别要看清：/Image:后面跟的是挂载目录，不是 wim 文件；离线集成不需要/Online；卸载时/Commit和/Discard二选一，写错了改动就白做。集成完的镜像体积会涨几十兆，换来的是新机器装完系统就自带 3.5，部署脚本能少一步。

同一个 wim 里有多个索引的话，每个索引都要单独挂载、单独集成，不能只处理一个就以为全好了。

5. 排查与避坑：.NET 3.5 安装失败的五种真实成因

报错码就那么几个，但每个背后的成因差别很大。下面这几条是我这些年真实撞过的，按「现象 → 原因 → 解决」记下来，遇到同类问题可以直接对号入座。

5.1 错误码速查

5.2 五条踩坑记录

第一条：2016 的机器拿了 2012 R2 的包

现象：命令执行到一半报 0x800f0906，源路径明明是对的，Test-Path也返回 True。

原因：cab 文件名一样，但组件版本号不同，DISM 校验的是版本和哈希，不是文件名。2016 是 10.0.14393 内核，拿 6.3.9600 的组件过去必然对不上。

解决：先Get-ComputerInfo确认 OsBuildNumber，再去找对应版本的镜像。这一步没有捷径，版本对不上就是装不了。从那以后我拿到任何 sxs 包，第一件事是在目录里放一个记录版本号的文本文件。

第二条：目录多套了一层，路径看着对其实不对

现象：把资源包解压到C:\sxs，执行命令报 0x800f081f，提示找不到源文件。

原因：压缩包里自带一层sources\sxs结构，解压后实际路径变成了C:\sxs\sources\sxs，而命令里写的是C:\sxs。

解决：Get-ChildItem C:\sxs看一眼，如果输出的是一个 sources 目录而不是一堆 cab 文件，就把路径改成C:\sxs\sources\sxs，或者把里面的内容整体上提一层。这个错误特别隐蔽，因为路径本身确实存在，只是层级不对。

第三条：UNC 共享路径所有机器都失败

现象：sxs 放在文件服务器共享上，组策略也指过去了，全公司机器统一报找不到源。

原因：访问共享的是计算机账户。共享权限里只给了域用户读权限，机器账户过不去。

解决：共享权限和安全权限里都加上Domain Computers的读取权限。改完不用重启，客户端重新执行安装即可。这类权限问题在单机上永远复现不了，只有放到域环境里才暴露。

第四条：提示装好了，IIS 应用池里还是没有 v2.0

现象：DISM 输出「操作成功完成」，Get-WindowsFeature也显示 Installed，但 IIS 应用池的 .NET CLR 版本下拉里只有 v4.0。

原因：两个可能。一是没重启，组件注册没完成；二是 IIS 场景下还需要 ASP.NET 相关的子功能，光装 NetFx3 不够。

解决：先重启一次再看。还是没有的话，把 ASP.NET 3.5 相关功能一起装上，然后在对应版本的框架目录里跑aspnet_regiis -i注册脚本。顺序不能反，先装框架再注册，反过来注册会失败。

第五条：报 0x800f0907，说被策略阻止

现象：所有参数都写了，包括/LimitAccess，仍然报策略阻止。

原因：组策略里的「指定 Windows 更新或 WSUS 中可选组件安装和组件修复的设置」配成了「总是尝试」，或者RepairContentServerSource的值跟预期不符。命令行参数管不了组策略。

解决：把策略改成「从不尝试」，gpupdate /force刷新，再重新执行安装。改完用gpresult /h导一份报告确认，别只信控制台里显示的状态。

5.3 日志才是黑匣子，别靠猜

安装失败的详细信息都在两个地方：%windir%\Logs\CBS\CBS.log和%windir%\Logs\DISM\dism.log。前者几十万行起步，肉眼翻是自虐，直接过滤关键字：

# 抓最近与 NetFx3 相关的记录，比从头翻高效得多 Select-String -Path "$env:windir\Logs\CBS\CBS.log" -Pattern "NetFx3|netfx3" | Select-Object -Last 40 # DISM 日志里能看到它实际用了哪个源路径 Select-String -Path "$env:windir\Logs\DISM\dism.log" -Pattern "source|Source" | Select-Object -Last 20

CBS 日志里会明确写出「找不到组件」「版本不匹配」这类信息，比外层那个错误码精确得多。dism.log 则能告诉你它到底去哪个路径找的源——很多时候你以为配了 C:\sxs，日志里显示的却是别的地方，那就是组策略覆盖了命令行参数。

组件存储本身损坏的情况也有，表现为反复失败、错误码乱跳。这种时候先跑dism /online /cleanup-image /startcomponentcleanup清理一遍，再sfc /scannow扫一次系统文件，实在不行上dism /online /cleanup-image /restorehealth，但后者需要能连到更新源，内网机器要提前配好/Source。

6. 装完怎么验证：三条命令确认 NetFx3 真的能用

装完不验证，等于没装。DISM 说成功只是第一步，功能是不是真的可用，得从三个层面各查一遍。

第一层看功能状态：

# InstallState 必须是 Installed，RestartNeeded 是 No 才算彻底完成 Get-WindowsFeature -Name Net-Framework-Core | Select-Object Name, InstallState, RestartNeeded

第二层看注册表探针，这层能绕开功能管理器的显示：

# Install 值为 1 表示 3.5 的运行时确实落地了，SP 值能看出补丁级别 Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" | Select-Object Install, SP, Version

第三层是实际跑一下。IIS 场景最直观的判断是打开应用池的 .NET CLR 版本下拉，能看到 v2.0 就说明框架被识别了。没有 IIS 的机器，随便找个依赖 3.5 的老程序跑一遍，或者用 PowerShell 加载一个 2.0 时代的程序集看看会不会报错。

三层都对上，才算真的装完。只查第一层的话，会漏掉「功能标记写了但组件没展开全」的情况，这种半成功状态最难查，因为所有表层信息都显示正常。

从那以后我每次装完 .NET 3.5，都会把这三条命令连着重启前后各跑一遍，确认RestartNeeded从 Yes 变成 No 才收工。看起来多花两分钟，比事后在一台「看起来装好了」的机器上排查应用问题省事得多。希望帮到你。

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