企业官网建设流程全解析

简介：面向在 Windows Server 2012 上部署旧版应用、却因系统默认未启用 .NET Framework 3.5 而受阻的服务器管理员与运维人员，这份 SxS 镜像资源包提供可离线使用的组件集合，重点解决无法从 Windows Update 稳定获取安装文件、服务器断网或处于严格防火墙环境时的启用难题，也适合排查 .NET 3.5 安装失败与服务开启异常。压缩包共 1569 个文件，约 101.69MB，以 dll、resx、exe、aspx、config、sql 等类型为主，覆盖运行库、资源文件、配置与数据库脚本等配套内容，并附使用说明文本，便于按目录定位所需组件。已有 10501 人学习下载。其价值在于把分散于安装介质 Sources\sxs 的关键组件集中打包，读者可据此完成离线启用、减少对外网源依赖，并借助说明与目录结构理解组件构成，为旧版应用迁移、服务部署和安装排错提供可复用资料。

1. 离线服务器装 .NET 3.5：为什么勾选功能会直接报 0x800F0906

一台内网 Windows Server 2012，跑着某套老业务系统，装 .NET Framework 3.5 时服务器管理器直接甩出 0x800F0906，勾选、确定、重试，红叉还是那个红叉。原因不复杂：从这一代系统开始，.NET Framework 3.5 被改成按需功能，系统里只留一个功能存根，真正的安装载荷放在安装介质的 sources\sxs 目录下，默认安装源指向在线更新。机器出不了网，自然拉不到这部分内容。window server 2012 安装 net3.5 的 --sxs 镜像资源包，就是给这种场景准备的：把安装介质里的 sxs 目录当作本地源，用 DISM 把 NetFx3 缺的那部分载荷补回去。适合内网运维、离线交付、老系统迁移，以及被 .NET 3.5 安装失败反复折腾过的人。读完至少能做到两件事：第一次就装通，装不通时知道该看哪两个日志。

2. 拆开 --sxs 的机制：DISM 到底去镜像里找哪个 cab

2.1 存根与载荷分离：按需功能改的是哪一层

理解 --sxs 的前提，是先接受一个事实：从 Windows 8 / Windows Server 2012 这一代开始，系统不再把 .NET Framework 3.5 的运行时二进制预装进本地组件存储（也就是 WinSxS），而是只保留功能清单和存根。你在服务器管理器里看到的 ".NET Framework 3.5 (包括 .NET 2.0 和 3.0)" 那一行，本质上是一个声明：这个功能存在，可以启用，但请自备安装源。

安装介质里的 sources\sxs 目录，装的就是这份载荷，文件名形如microsoft-windows-netfx3-ondemand-package.cab，体积通常在一百多 MB 量级。DISM 执行/enable-feature时，第一步读功能清单确认依赖关系，第二步按/source指定的路径去找对应 cab，第三步把 cab 展开并登记进组件存储。整个过程里，DISM 不会"智能判断"你给的是不是对的版本——它只做路径拼接和文件查找，找到就装，找不到就回一个 0x800F0906 或者 0x800F081F。这一点很关键，后面第四章的绝大多数报错，根子都在"它没找到"或"找到了但对不上"。

顺带说一句，Server 2012 的安装介质里 sxs 目录只有一份，不区分中英文，也没有单独的 x86 包，因为系统本身只有 x64 版本。但 2012 和 2012 R2 的 sxs 目录不能混用，版本号对不上，DISM 会明确拒绝。我用dir先看一眼目录里有什么：

:: 挂载 ISO 后确认 sxs 目录内容，常见做法是先看文件名前缀 dir D:\sources\sxs\*.cab /b

输出的文件名里如果出现netfx3-on-demand-package，说明这份介质是对的；如果只能看到其他组件的 cab，那多半是精简过的介质，或者你指向了错误的目录层级。命令本身没什么参数，/b只是去掉表头和摘要，方便后面写脚本做字符串匹配。真正需要留意的是路径——很多人挂载完 ISO 直接写D:\sources而不是D:\sources\sxs，DISM 会往下递归找一层但找不到就报错，这是第一类低级翻车。

2.2 三条安装路径的差别与选型

装 .NET 3.5 这件事，能走的路其实有三条，适用场景差别很大。我一般按"有没有外网、机器有几台、能不能接受版本偏差"三个维度来选。

默认在线路径最省事，但也是最容易失败的：只要机器受到组策略或 WSUS 管控，或者防火墙没有放行对应端点，DISM 就卡在"正在下载"上，最后给你一个看不出所以然的错误码。第三方打包安装器在应急时确实能跑通，但它替换了系统的组件登记流程，后续做系统修复（DISM /RestoreHealth）时可能出现"组件存储与安装记录不一致"，这类问题排查起来非常难受，血泪经验是能不用就不用。

--sxs这条路的优势是干净：载荷来自原厂介质，登记流程走的还是系统自己的 DISM，装完之后功能状态、组件存储、后续补丁全都一致。代价是版本必须严格对齐。我在实际交付里基本只走这一条，因为内网机器通常没得选。

2.3 DISM 与 PowerShell 的等价命令逐项拆解

最常用的一条命令长这样：

:: 以管理员身份运行，将 NetFx3 从本地 sxs 目录安装 dism /online /enable-feature /featurename:NetFx3 /all /source:D:\sources\sxs /limitaccess

逐个参数说清楚，因为后面所有排错都绕不开这几个开关：

• /online：作用于当前正在运行的系统。与之相对的是/image，用于离线挂载的 WIM 或 VHD。很多人抄命令时把这两个搞混，结果对着一个已经挂载的镜像改了半天，回头发现自己其实想装的是本机。
• /enable-feature：启用功能。对应的反向操作是/disable-feature。
• /featurename:NetFx3：.NET Framework 3.5 在 DISM 里的功能名就是 NetFx3，不带点号不带空格。写成NetFramework3.5会直接被判为未知功能。
• /all：一并启用父功能。.NET 3.5 下面挂着 WCF、WCS 等子项，不加这个参数有时会留下"父功能已启用、子项未启用"的半吊子状态，业务程序调用 WCF 时才开始报错，隐蔽性很强。
• /source:D:\sources\sxs：载荷路径。这里要写目录，不是写某个 cab 文件。
• /limitaccess：禁止 DISM 连接在线更新源。这个参数在内网环境里几乎是必加的，否则即使你给了本地源，DISM 仍可能先尝试联网，然后在超时后返回一个误导性的错误码。

PowerShell 侧有两套等价写法，看系统版本和习惯选：

# 写法一：WindowsOptionalFeature 系列，语义与 DISM 一一对应 Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -Source "D:\sources\sxs" -LimitAccess # 写法二：Server 专用的 WindowsFeature 系列，参数更少，日志更集中 Install-WindowsFeature -Name Net-Framework-Core -Source "D:\sources\sxs"

写法一的参数和 DISM 完全对齐，-LimitAccess同样生效，适合需要精确控制行为的场景。写法二的Net-Framework-Core是服务器管理器里那个功能在 PowerShell 中的名字，注意它和 DISM 的NetFx3不是同一个标识符，混用会提示找不到功能。写法二没有-LimitAccess这个开关，行为上更接近"给定源就用给定源"，在纯内网环境下反而省心。两条命令我都用过，批量脚本里更倾向写法二，因为返回对象里直接带Success和RestartNeeded属性，做结果汇总时不用再解析文本。

2.4 版本、语言与架构的三重对齐

这一节是我认为最该被写进操作手册、但绝大多数教程都略过的部分。sxs 安装失败的原因里，"版本不对齐"能占到一半以上。

第一重是版本号。Server 2012 的内部版本是 6.2，2012 R2 是 6.3，两者的 sxs 载荷不通用。手上如果同时有这两代介质，务必在挂载后先确认：

# 查看当前系统版本与架构，确认与介质一致 Get-ComputerInfo | Select-Object OsName, OsVersion, OsArchitecture # 或者用更轻的命令，老系统上兼容性更好 systeminfo | findstr /C:"OS 名称" /C:"OS 版本" /C:"系统类型"

Get-ComputerInfo在 2012 上可用，但首次执行会慢几秒，因为它要拉一圈 CIM 类。批量脚本里我一般用systeminfo配合findstr，虽然输出要解析，但快且不依赖 PowerShell 版本。

第二重是语言。.NET 3.5 的功能载荷本身是语言中立的，但安装介质里的 sxs 目录在部分语言版本上会额外带语言包目录（形如sxs\zh-cn）。如果你是从英文介质里提取的 sxs，装到中文系统上一般没问题；反过来如果系统装了语言包而源里缺对应资源，可能出现"功能启用成功但界面语言回退"。这个坑不致命，但会被业务方当成 bug 报上来。

第三重是架构，这一条在 2012 上基本不用管，因为系统只有 x64。但如果你是在 32 位系统上折腾同一套流程（比如更老的 2008），就必须确认源和目标架构一致，否则会出现"文件已复制但注册失败"的玄学现象。

把这三重对齐做完，再执行安装命令，成功率会高出一个量级。我现在的习惯是：挂载 ISO 之后不急着敲 DISM，先花三十秒跑上面两条检查，把版本号和 sxs 目录内容都看一眼，这三十秒能省掉后面半小时的日志排查。

3. 从挂载 ISO 到服务开启：一次装通的四步与验证点

3.1 挂载介质与确认 sxs 目录完整性

第一步永远是把安装介质挂到一个稳定的盘符上。物理机可以插盘，虚拟机直接挂 ISO，云主机就把镜像文件传到本地再挂载。挂载之后先确认盘符，别凭记忆写 D 盘——服务器上光驱、数据盘、备份盘一堆，盘符漂移是常事。

# 列出所有卷，找到挂载的安装介质（通常文件系统为 CDFS 或 UDF） Get-Volume | Where-Object DriveType -eq 'CD-ROM' | Format-Table DriveLetter, FileSystemLabel, Size # 确认 sxs 目录存在且非空 $src = 'D:\sources\sxs' Test-Path $src (Get-ChildItem $src -Filter *.cab).Count

Get-Volume在 2012 上可用，输出里的DriveType为CD-ROM的那一项就是挂载点。第二段代码做两件事：确认路径存在，以及数一下 cab 文件数量。数量不用记具体值，但如果是 0，说明你挂的不是完整介质，或者指向了错误的层级。这一步看似多余，实际上能挡掉相当一部分"命令没错但就是装不上"的情况——很多时候问题根本不在命令，而在源本身是残的。

如果服务器上不方便长期占用一个盘符，可以把 sxs 目录整个拷到本地固定路径，比如C:\Install\sxs，之后的安装都指向这个路径。拷贝时用robocopy比copy稳，它会保留目录结构并且对长路径更宽容：

:: 把 sxs 目录复制到本地固定路径，便于后续复用 robocopy D:\sources\sxs C:\Install\sxs /E /R:2 /W:2

/E表示包含空目录，/R:2是失败重试两次，/W:2是每次重试间隔两秒。这两个重试参数在光盘介质上意义不大，但如果源是网络共享，默认的百万次重试会让你以为命令卡死了。

3.2 图形界面路径：服务器管理器里的那个隐藏链接

不是所有人都愿意敲命令，图形界面也能走通，但入口藏得比较深，第一次用的人大概率找不到。

路径是：服务器管理器 → 添加角色和功能 → 一路下一步到"功能"页 → 勾选.NET Framework 3.5 (包括 .NET 2.0 和 3.0)→ 继续下一步到"确认安装所选内容"页。关键就在这一页：页面上有一行蓝色小字"指定备用源路径"，点开之后弹出一个输入框，把D:\sources\sxs填进去，再点安装。

这个链接的位置很不直观，因为它不在勾选功能的那个页面，而在最后的确认页。不少人勾完功能直接点"安装"，然后看着进度条走到一半弹错误，回头找设置源的地方又找不到，最后只能去搜错误码。我的建议是：只要机器没有外网，进向导的第一件事就是把备用源路径填好，别等到报错再回头。

还有一点，图形界面走完之后，功能状态和命令行装的是同一套东西，没有区别。所以如果批量做，没必要两个方式都学，把命令记住就行。

3.3 命令行安装与日志定位

正式安装就用第二章那条命令，加上日志路径便于事后追溯：

:: 启用 NetFx3，指定本地源并禁止联网，同时把 DISM 日志单独落到临时目录 dism /online /enable-feature /featurename:NetFx3 /all ^ /source:C:\Install\sxs /limitaccess ^ /LogPath:C:\Temp\netfx3-install.log

^是 cmd 的续行符，写成一行也行，分行只是为了看清楚参数。/LogPath会把本次操作的详细日志单独写一份，不和系统默认的C:\Windows\Logs\DISM\dism.log混在一起。批量部署时这个参数非常有用，因为默认日志是追加写的，几十台机器的日志混在一份文件里根本没法看。

命令执行完，进度条走到 100% 只代表 DISM 这一层结束，不代表功能真的可用。我见过进度条跑完、返回"操作成功完成"，但业务程序一启动就报Could not load file or assembly的情况——原因是功能主体装上了，子项没跟上。所以下一步的验证不能省。

3.4 装完之后：功能状态、注册表与服务三处验证

验证分三层，从粗到细。

第一层看功能状态：

# 查看 .NET 3.5 功能是否已安装，以及其子项状态 Get-WindowsFeature -Name Net-Framework-Core | Select-Object Name, InstallState Get-WindowsFeature -Name Net-Framework-Core | Select-Object -ExpandProperty SubFeatures

InstallState应该是Installed。第二行展开子功能，重点看WCF-HTTP-Activation、WCF-NonHTTP-Activation这几个，如果业务系统走 WCF 服务，这些子项必须一起开。这一步就是很多人说的"装完了但服务开不起来"的根源。

第二层看注册表与运行时目录：

:: 确认 .NET 3.5 的注册表项与运行时目录都存在 reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v Install dir "%windir%\Microsoft.NET\Framework\v3.5\vbc.exe" /b

注册表Install值为1表示安装完成；vbc.exe存在说明编译器组件到位。这两项一起看，比单看功能状态更可靠，因为功能状态是 DISM 自己记的账，注册表是运行时真正认的账。

第三层是实际跑一个依赖 .NET 3.5 的程序。最轻量的办法是用系统自带的csc.exe编译一个空控制台程序：

:: 用 .NET 3.5 自带的编译器编译一个最小程序，验证运行时可用 echo public class P { public static void Main() { System.Console.WriteLine("ok"); } } > C:\Temp\t.cs "%windir%\Microsoft.NET\Framework\v3.5\csc.exe" /out:C:\Temp\t.exe C:\Temp\t.cs C:\Temp\t.exe

输出ok就说明整条链路通了。这个测试看着土，但它验证的是"编译 + 运行"两件事，比任何状态查询都有说服力。我现在的习惯是每装完一台就顺手跑一遍，十秒钟的事，能避免交付之后被叫回去返工。

4. 安装失败的排查：五类报错、根因与对应解法

4.1 现象：0x800F0906，进度条走到一半中断

原因：DISM 在指定的源路径下没找到匹配的载荷，或者找到了但文件不完整。触发条件通常是三种——路径写错层级、介质是精简版、ISO 挂载后盘符变了。

解决：先确认路径，Test-Path加Get-ChildItem数一下 cab 数量；再确认版本，用 2.4 节的命令比对系统版本和介质版本；最后确认这个 sxs 目录是从完整 ISO 的sources下拷的，而不是从某个第三方"精简包"里解出来的。我遇到过最离谱的一次是同事把sources目录整个改名成了source，命令里的路径没跟着改，DISM 报的就是这个码，查了半小时才发现是拼写问题。

4.2 现象：0x800F081F，明确提示"找不到源文件"

原因：源路径本身是有效的，但里面缺目标功能对应的 cab，或者 cab 的版本与当前系统不匹配。这个码比 0906 更具体，它意味着 DISM 已经成功读取了源目录，只是没找到对得上的东西。

解决：用dir D:\sources\sxs\*.cab /b | findstr /I "netfx"直接过滤，确认netfx3-on-demand-package是否存在。如果没有，换介质；如果有但版本对不上，换同版本号的原厂介质。这里要强调一遍：Server 2012 和 2012 R2 的 sxs 不能互换，即使只差一个小版本号，DISM 也会拒绝。曾经有人拿 2012 R2 的介质给 2012 装，报的就是 081F，然后怀疑是介质损坏，换了好几份 ISO，其实从一开始方向就错了。

4.3 现象：0x800F0907，提示组策略阻止了该操作

原因：这台机器处在某个域策略或本地策略的管控下，策略强制要求按需功能只能从指定的更新源获取，而你给的本地源被策略覆盖了。这个报错最容易被误判成"源有问题"，因为它看起来和前面两个码很像。

解决：先确认策略状态，看本地策略里"指定可选组件安装和组件修复的设置"这一项是否被启用并指向了某个内部更新源。如果有，两个选择：临时在本地策略里把备用源路径加上你的 sxs 目录，或者直接申请策略例外。我一般不在服务器上硬改域策略，而是把 sxs 路径加进策略的备用源里，这样既满足管控要求，又能离线装。改完之后gpupdate /force刷新一次，再重试安装。

4.4 现象：0x80073701，安装到 80% 左右回滚

原因：系统组件存储本身有问题，DISM 在写入新组件时和现有记录冲突。这类错误和 sxs 源无关，换多少份介质都没用，属于系统健康度问题。

解决：先跑系统文件检查，再跑组件存储修复，两条命令按顺序来：

:: 先修文件，再修组件存储，顺序不能反 sfc /scannow dism /online /cleanup-image /restorehealth

/restorehealth默认会尝试联网获取修复源，如果机器没外网，需要额外加/source:和/limitaccess，指向同一个 sxs 目录。这两条命令跑完通常要十几分钟，别中途打断。修完之后重新执行安装，同一份介质往往就能过了。这个坑我踩过一次，当时以为是介质版本问题，换了三份 ISO，最后发现是系统自身组件存储有损坏，纯属白折腾。

4.5 现象：功能显示已安装，但业务程序仍报程序集加载失败

原因：主体功能装上了，子功能没启用，或者程序依赖的是 .NET 2.0/3.0 的特定程序集而当前只开了 NetFx3 主项。还有一种情况是 32 位程序在 64 位系统上运行，加载的是Framework而非Framework64下的程序集，目录结构不同。

解决：先把子功能全部展开确认一遍，重点看 WCF 系列；再用corflags或者任务管理器确认业务程序的位数；最后对照程序集加载失败的详细信息，看它到底在找哪个版本目录下的哪个 dll。经验上，.NET 3.5 安装失败和.NET 3.5 服务开不起来这两个诉求，很多时候不是安装问题，而是子功能没勾全。批量部署时把子功能清单固化进脚本，能省掉大量返工。

5. 批量落地：把 sxs 安装写成能跑一百台的脚本

5.1 前置检测：版本、功能状态、源可用性三查

单台机器可以手工确认，批量就必须把检查写成代码。脚本的第一段永远不是安装，而是检测——检测目标机器是不是同一代系统、功能是不是已经装过、源路径在目标机器上是否可达。

# 批量前置检测：读取服务器列表，逐台确认系统版本与功能状态 $servers = Get-Content .\servers.txt $report = foreach ($s in $servers) { $os = (Get-CimInstance -ComputerName $s -ClassName Win32_OperatingSystem).Version $feat = (Get-WindowsFeature -ComputerName $s -Name Net-Framework-Core).InstallState [pscustomobject]@{ Server = $s OSVersion = $os # 6.2.x 为 2012，6.3.x 为 2012 R2 NetFx3 = $feat # Installed / Available / Removed NeedWork = ($feat -ne 'Installed') } } $report | Format-Table -AutoSize $report | Export-Csv .\netfx3-survey.csv -NoTypeInformation -Encoding UTF8

逐段说明。Get-CimInstance拿Win32_OperatingSystem.Version，返回的是四段式版本号，6.2开头对应 2012，6.3开头对应 2012 R2，这个判断比看系统名称字符串稳，因为名称在不同语言版本里不一样。Get-WindowsFeature -ComputerName需要目标机开启 WinRM 并且当前账号有权限，如果环境里没开，就退化成用Invoke-Command逐台跑本地命令。NeedWork这一列是给后续批量操作做过滤用的，把已装的机器排除掉，避免重复执行。

导出的 CSV 有两层用途：一是给交付文档留底，二是如果后面安装失败，可以拿这份数据和失败清单做比对，快速定位是"本来就装过"还是"装失败了"。这个习惯是从一次事故里学来的——当时一批机器重跑安装脚本，有两台报错，查了半天才发现它们本来就是装好的，报错是重复启用导致的，纯属自己吓自己。

5.2 安装脚本：参数化、带日志、能回滚判断

检测通过之后就进入安装。安装脚本的核心是三件事：路径参数化、日志落盘、结果可控。

# 批量安装 NetFx3，源路径参数化，逐台记录日志与结果 param( [string]$ServerList = '.\servers.txt', [string]$SourcePath = 'C:\Install\sxs', [string]$LogDir = 'C:\Temp\netfx3-logs' ) if (-not (Test-Path $LogDir)) { New-Item -ItemType Directory -Path $LogDir | Out-Null } $results = foreach ($s in Get-Content $ServerList) { $log = Join-Path $LogDir "$s.log" try { # 先在目标机上确认源路径可访问，避免把网络问题误判成安装失败 $ok = Invoke-Command -ComputerName $s -ScriptBlock { param($p) Test-Path (Join-Path $p '*.cab') } -ArgumentList $SourcePath if (-not $ok) { [pscustomobject]@{ Server = $s; Result = 'SourceMissing'; Detail = $SourcePath } continue } $r = Invoke-Command -ComputerName $s -ScriptBlock { param($p) Install-WindowsFeature -Name Net-Framework-Core -Source $p } -ArgumentList $SourcePath [pscustomobject]@{ Server = $s Result = if ($r.Success) { 'OK' } else { 'Failed' } Detail = "RestartNeeded=$($r.RestartNeeded)" } } catch { [pscustomobject]@{ Server = $s; Result = 'Error'; Detail = $_.Exception.Message } } } $results | Format-Table -AutoSize $results | Export-Csv .\netfx3-result.csv -NoTypeInformation -Encoding UTF8

几个设计点值得展开。第一，源路径的检查放在目标机上执行，而不是在发起端检查，因为发起端能看到路径不代表目标机能访问。第二，Install-WindowsFeature返回的对象里有Success和RestartNeeded，直接拿来判断结果，不用解析文本输出。第三，整个循环用try/catch包住，单台失败不影响后续机器——批量脚本最忌讳的就是第一台报错导致后面九十多台全不执行。第四，结果统一导出成 CSV，交付时可以直接作为验收材料。

SourcePath默认值我写的是本地路径C:\Install\sxs，前提是每台机器上都提前拷贝好了。如果源在网络共享上，路径要写成 UNC 形式，并且注意Install-WindowsFeature在远程执行时的双跳问题——这是另一个坑，简单说就是发起端、目标机、文件服务器三方认证，最容易卡在权限上。规避办法是提前把 sxs 推到每台目标机的本地磁盘，代价是占一百多 MB 空间，换来的是流程稳定。

5.3 结果汇总与失败机器的二次处理

跑完一轮之后，手上应该有两份 CSV：前置检测的netfx3-survey.csv和安装结果的netfx3-result.csv。把两份按服务器名做连接，就能得到一张完整的状态表：哪些是本来就装好的、哪些是这轮装成功的、哪些是失败的。

失败的机器不要急着重跑，先看日志。每台机器的日志按名字分开存，打开对应文件，重点搜三个关键词：0x800F、source、payload。绝大多数失败都能从这三处定位到原因。如果是源问题，重新推一份 sxs 再跑；如果是策略问题，走 4.3 节的流程；如果是组件存储损坏，先修再装。

这套流程我在几个不同规模的环境里用过，机器数量从几台到上百台，脚本结构没变过，只调整了并发和超时参数。真正花时间的从来不是写脚本，而是把每台机器的异常情况归类清楚。所以脚本里那些"看起来多余"的检查、日志、CSV 导出，恰恰是最省时间的部分。

6. 固化备用源路径：让下一次按需功能不再翻镜像

装 .NET 3.5 只是开始。同一台服务器上，后面大概率还要装 .NET 4.x 的某些子项、桌面体验、无线 LAN 服务，这些同样属于按需功能，同样会去在线源找载荷，同样会在离线环境里报 0x800F0906。如果每次都翻出 ISO 挂载、找盘符、敲一遍 DISM，那这套流程就白总结了。

我的做法是把 sxs 目录固化到本地固定路径，再把备用源路径写进策略，让系统在任何按需功能安装和组件修复时都默认走本地源。具体是两步。

第一步，把 sxs 目录拷到每台机器的固定位置，比如C:\Install\sxs，并给它一个不会被清理策略盯上的目录名。别放在C:\Windows\Temp下面，那地方迟早被清理脚本扫掉。

第二步，配置"指定可选组件安装和组件修复的设置"这一项。图形界面路径是：本地组策略编辑器 → 计算机配置 → 管理模板 → 系统 → 指定可选组件安装和组件修复的设置 → 启用，然后在"备用源文件路径"里填C:\Install\sxs。域环境里可以在域策略层面统一配置，新机器入域后自动生效，连脚本都不用跑。

不方便开图形界面的话，注册表方式等价：

:: 固化备用源路径，并设置 Windows Update 回退策略 reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing" /v LocalSourcePath /t REG_EXPAND_SZ /d "C:\Install\sxs" /f reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing" /v UseWindowsUpdate /t REG_DWORD /d 1 /f

LocalSourcePath就是备用源路径，支持环境变量展开。UseWindowsUpdate控制回退行为：设成 0 表示完全不回退到在线源，设成 1 表示本地源不可用时才回退，设成 2 表示优先在线。内网环境我一般设 1——纯离线时它等价于 0，万一哪天机器通了外网，也不至于因为本地源缺文件而彻底装不上。设完记得gpupdate /force刷新一次，然后随便启一个按需功能验证策略是否真的生效。

这里有个细节容易忽略：策略生效之后，DISM /RestoreHealth也会默认使用这个本地源。这既是好事也是风险——好处是系统修复不再依赖外网，坏处是如果你的 sxs 目录版本和当前系统不匹配，修复会失败并给出一个看起来很奇怪的错误码。所以固化路径之后，要在机器上留一份和系统版本严格对应的 sxs，不能随手从别的机器拷一份过来。

从那以后我每交付一台离线服务器，都会在系统装完的第一时间把 sxs 拷到固定路径、把策略写死，再做业务部署。这个动作花不到五分钟，但能省掉后面每一次装功能时的重复劳动，也避免了半夜被叫起来挂 ISO 找盘符的窘境。希望帮到你。

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