折腾 LTSC 的人基本都经历过同一个瞬间:系统装完,干净得像一间刚交房的毛坯屋,开机内存占用低得让人心里发慌,可等你真要用电脑干活了,才发现角落里那个 IE 图标已经是个摆设,而 WIN10 LTSC 本身压根没带 EDGE 和微软应用商店。这两样东西一个管上网,一个管装应用,缺了它们,LTSC 就从"精简高效"变成了"精简到没法用"。这篇东西就是我这几年前后在多台 LTSC 机器上把 EDGE 和微软应用商店装回去的完整记录,包括版本对应关系、依赖包的安装顺序、离线包怎么挑、装完怎么调优,以及中途遇到的一堆报错怎么排查。不管你是刚用 LTSC 2019 还是 LTSC 2021,是想给虚拟机里的测试环境补全功能,还是给公司老机器做一次性部署,这里的步骤都能直接抄。
1. 先想清楚 LTSC 为什么把这两样东西拿掉了
1.1 LTSC 的定位决定了它天生不带商店和新版浏览器
LTSC 全称 Long-Term Servicing Channel,翻译过来就是长期服务通道,它的设计目标跟普通消费版 Windows 完全是两条路。普通家庭版、专业版追求的是功能新鲜、更新频繁、生态完整,所以商店、Edge、Cortana、各种 UWP 应用一股脑全塞进去;而 LTSC 面向的是收银机、工控机、医疗设备、银行柜台这类"装好了就别动"的场景,官方希望它三年五年不折腾,所以把一切跟"持续联网消费内容"沾边的东西全砍了。
微软应用商店本身就是一个内容分发入口,它会拉着后台服务、自动更新、账号体系一起进来,这跟 LTSC 追求的"安静"是冲突的。Edge 同理,它自带更新器、后台常驻进程、启动增强这些东西,在服务器和工控环境里属于不受欢迎的变量。所以你在 LTSC 上找不到它们,不是系统坏了,是官方有意为之。
理解了这一点,后面所有操作的心态就顺了:我们做的是"手动把消费版的能力移植到长期服务版上",而不是"修复一个缺失功能"。这两种心态的区别在于,前者你得自己负责后续的更新和兼容,后者你会指望系统自己搞定。指望系统自己搞定的人,最后往往卡在商店闪退上出不来。
提示:LTSC 不带商店和 Edge 属于正常设计,不是系统精简过度,也不是镜像被人动过手脚。先接受这个前提,再动手。
1.2 LTSC 2019 和 LTSC 2021 的差异决定了后续所有细节
这是最容易翻车的地方。很多人从网上随便抓一套商店安装包就往系统里灌,结果装完白屏、闪退、下载报错,八成是包和系统内核版本对不上。LTSC 2019 基于 Windows 10 1809 内核,LTSC 2021 基于 21H2 内核,两者虽然都叫 LTSC,但底层差了好几个大版本,商店包、依赖框架、Edge 版本的支持范围都不一样。
我把这两者的关键差异整理成一张表,动手前先对号入座:
| 项目 | LTSC 2019 | LTSC 2021 |
|---|---|---|
| 内核版本 | 1809 | 21H2 |
| 内部版本号 | 17763 | 19044 |
| 微软商店包 | 需匹配 1809 的旧版商店 | 可用较新的商店包 |
| .NET Native 框架 | 2.x 系列 | 2.2 系列更完整 |
| UI.Xaml 依赖 | 2.4 及以下为主 | 2.4 / 2.8 均可 |
| Edge 官方支持 | 仍在内核支持范围内 | 支持良好 |
看着差不多,实际动手时差得很远。LTSC 2019 上你如果硬塞一个 21H2 时代的商店包,大概率表现为商店能打开但加载不出来内容,或者点下载立刻报错。所以第一步不是找包,是确认自己的系统到底是哪一版。命令行敲winver,弹窗里的版本号和内部版本号一看便知,别靠记忆,别靠卖家描述。
1.3 你到底需不需要把商店装回来
不是所有人都有必要装商店。如果你这台 LTSC 就是当纯办公机用,Edge 装好、Office 装好、输入法和常用工具装好,其实能覆盖九成需求。商店更多解决的是这几个问题:某些应用只有商店版本(比如部分 HEVC 视频扩展、终端、部分系统级解码器)、需要商店里的应用来做硬件识别或驱动辅助、需要 WSL 相关组件、或者你就是想用商店里那种自动更新的省心体验。
先花两分钟想清楚你的真实需求,再决定装不装。如果只是为了"看起来完整"而装,后面你会被商店的更新、缓存、登录问题折腾得够呛;但如果真的有应用依赖它,那这一趟就值得走。我个人的判断标准很简单:只要系统里出现过一个"只能从商店装"的软件,我就把商店装上;如果一个都遇不到,我就只补 Edge,省下大把维护精力。
2. 动手前的准备工作,比动手本身更重要
2.1 三个系统服务必须先确认活着
商店和 Edge 都依赖一组后台服务,如果这些服务被人为禁用或者优化软件关掉了,你包装得再对也没用。重点盯这几个:AppXSvc(应用部署服务)、ClipSVC(客户端许可服务)、InstallService、LicenseManager,以及负责下载的Windows Update 服务。
打开services.msc,挨个确认启动类型不是"禁用"。如果被改过,右键属性把启动类型调回"手动"或"自动",然后手动点一次启动。这里要特别注意一点:有些所谓的"LTSC 优化脚本"会把 Windows Update 整个关掉,理由是"LTSC 不需要更新",但这种做法会直接让商店下载链路断掉,装完商店也是废的。
还有Windows Defender相关服务,不建议为了省事直接关掉系统防护。你后面要往系统里侧载包,本来就属于比较敏感的操作,留着一层防护反而能在包来源不明时给你提个醒。真要排查干扰,临时排除安装目录即可,别整个关。
注意:动手前先在"设置"里确认网络时间是自动同步的。系统时间偏差过大,证书校验会失败,表现就是商店能连上但装不上。
2.2 版本号、架构、语言三者必须全部对齐
这是我见过最多的翻车原因,没有之一。下载商店包和依赖包时,你至少要核对三个维度:系统内部版本号(17763 还是 19044)、CPU 架构(x64 还是 ARM64)、包语言(zh-cn 还是 neutral)。
arch 这块一般不会错,现在绝大多数机器是 x64。语言这块很多人忽略:商店本体通常是 neutral(中立语言)的,无所谓;但依赖框架包有的只有特定语言版本,你下成 en-us 的 VCLibs,在某些系统上能装上,但会在后续拉取应用时出问题。稳妥做法是优先选 neutral 或与你系统语言一致的包。
版本号这块最容易出错的是 UI.Xaml 和 .NET Native 这两个框架。同一台机器上往往需要多个版本的 UI.Xaml 并存,比如 2.4 和 2.8 同时装,因为不同的应用依赖不同版本。你要是只装一个,就会出现"部分应用能装、部分应用装不上"的诡异现象。所以别嫌麻烦,把依赖包一次性下齐。
2.3 离线包从哪里拿、怎么验证完整性
获取途径上,我一般走两条路。第一条是从官方提供的应用包分发渠道拿,适合追求省事的;第二条是从一台已经正常安装了商店的同版本系统上提取,位置在C:\Program Files\WindowsApps,但这个目录默认受保护,需要先拿到所有权和完全控制权限才能复制出来,操作起来有门槛,适合动手能力强的人。
提取的时候有个关键点:别只复制商店本体,要把和它一起的依赖目录也翻一遍。WindowsApps 里那一堆带版本号后缀的文件夹,就是各个框架的安装源,把Microsoft.VCLibs、Microsoft.NET.Native.Framework、Microsoft.NET.Native.Runtime、Microsoft.UI.Xaml、Microsoft.Services.Store.Engagement、Microsoft.StorePurchaseApp这些一并以管理员身份复制出来,才算拿全。
拿到包之后,强烈建议算一遍哈希再往系统里灌。用Get-FileHash对每个包算 SHA256,和你来源处提供的值比对。这一步看着多余,但包在下载或复制过程中损坏的概率比你想的高,而损坏的包安装时报的错往往非常含糊,白白浪费你半小时排查。
Get-ChildItem "C:\Store\*.appx" | Get-FileHash -Algorithm SHA256 | Format-Table Hash, Path3. 微软应用商店的完整安装实操
3.1 依赖包到底有哪些,为什么必须先装
微软商店不是一个独立的小程序,它是一堆积木搭起来的。商店本体负责界面和分发,真正干活的是下面这一层框架。如果你不先装框架直接上商店本体,结果就是商店进程起来了,但一渲染界面就崩,或者连登录页都出不来。
把这些依赖包按用途分一下类,心里有个谱:
| 包名 | 作用 | 是否必需 |
|---|---|---|
| Microsoft.VCLibs.140.00 | C++ 运行时,多数 UWP 应用的基础 | 必需 |
| Microsoft.VCLibs.140.00.UWPDesktop | 桌面桥应用的 C++ 运行时 | 建议 |
| Microsoft.NET.Native.Framework.2.2 | .NET 原生编译框架 | 必需 |
| Microsoft.NET.Native.Runtime.2.2 | .NET 原生运行时 | 必需 |
| Microsoft.UI.Xaml.2.4 / 2.8 | XAML 界面框架,多版本并存 | 必需 |
| Microsoft.Services.Store.Engagement | 商店统计与反馈组件 | 建议 |
| Microsoft.StorePurchaseApp | 商店内购组件 | 建议 |
| Microsoft.WindowsStore | 商店本体 | 必需 |
这里的逻辑关系是:VCLibs 和 .NET Native 是地基,UI.Xaml 是承重墙,商店本体是屋顶。你不可能先盖屋顶再打地基。安装顺序错了,AppXSvc 会在注册阶段直接报依赖缺失,错误码通常是 0x80073D02 或者 0x80073CF3。
还有一个容易被忽略的点:VCLibs 和 UWPDesktop 是两个不同的包,名字像,来源不同,用途也不同。前者给纯 UWP 应用用,后者给从桌面打包过来的应用用。装商店本身可能只需要前者,但你想装的那些第三方应用很可能需要后者,一次性装齐省得来回折腾。
3.2 用 Add-AppxPackage 按顺序侧载
准备好包之后,用管理员身份打开 PowerShell。注意是 PowerShell,不是 CMD,Add-AppxPackage是 PowerShell 的 cmdlet,CMD 里没有这个命令。
先切换到包所在目录,然后按依赖顺序一个个装:
Set-Location "C:\Store" Add-AppxPackage -Path ".\Microsoft.NET.Native.Runtime.2.2_2.2.28604.0_x64__8wekyb3d8bbwe.appx" Add-AppxPackage -Path ".\Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe.appx" Add-AppxPackage -Path ".\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe.appx" Add-AppxPackage -Path ".\Microsoft.VCLibs.140.00.UWPDesktop_14.0.33728.0_x64__8wekyb3d8bbwe.appx" Add-AppxPackage -Path ".\Microsoft.UI.Xaml.2.4_2.42007.9001.0_x64__8wekyb3d8bbwe.appx" Add-AppxPackage -Path ".\Microsoft.UI.Xaml.2.8_8.2310.30001.0_x64__8wekyb3d8bbwe.appx" Add-AppxPackage -Path ".\Microsoft.Services.Store.Engagement_10.0.19011.0_x64__8wekyb3d8bbwe.appx"注意上面的版本号只是示例,你手里的包版本号会跟这个不一样,写命令时以你实际下载到的文件名为准,别照抄。
依赖装完之后,再装商店本体。商店本体是 appxbundle 格式,文件名类似Microsoft.WindowsStore_xxxxx_neutral_~_8wekyb3d8bbwe.appxbundle。其实还有一种更省事的写法,用-DependencyPath参数把依赖一次性挂上去:
Add-AppxPackage -Path ".\Microsoft.WindowsStore_12107.1001.11.0_neutral_~_8wekyb3d8bbwe.appxbundle" ` -DependencyPath ".\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe.appx", ` ".\Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe.appx", ` ".\Microsoft.NET.Native.Runtime.2.2_2.2.28604.0_x64__8wekyb3d8bbwe.appx"这种写法在包比较齐的时候更稳,因为它让系统自己去判断依赖是否满足,而不是靠你手工排序。如果中途报错,报错信息里会明确指出缺哪个依赖,照着补就行。
如果包比较多,也可以写个循环批量装:
Get-ChildItem "C:\Store" -Filter *.appx | ForEach-Object { try { Add-AppxPackage -Path $_.FullName -ErrorAction Stop Write-Host "OK: $($_.Name)" -ForegroundColor Green } catch { Write-Host "FAIL: $($_.Name) -> $($_.Exception.Message)" -ForegroundColor Red } }加try/catch是为了让某个包失败时不要中断整个流程,方便你最后统一看哪些包没装上。
提示:安装过程中如果弹出"部署操作被阻止",检查一下是不是有组策略或者注册表项禁用了旁加载。管理员账户下默认是允许的,但有些被深度优化过的系统会把这个开关关掉。
3.3 脚本方案和手动方案的取舍
网上流传着一批专门给 LTSC 补商店的脚本,通常做法是内置一堆安装包,运行后自动按顺序侧载。这类脚本的优点很明显:省去了找包、对版本、排序的麻烦,适合批量给多台机器部署。但缺点同样明显:脚本里打包的商店版本是固定的,如果你的系统内核比脚本新或者比脚本旧,成功率就会打折。
我的做法是分场景选:单台机器、追求可控,就手动装,每一步都能看到结果,出问题也好定位;批量部署、机器配置统一,就用脚本,但前提是所有机器的内核版本和补丁级别基本一致,并且事先在一台机器上验证通过。
用脚本时有个必须做的动作:先把脚本打开看一遍,重点看它到底动了哪些服务、写了哪些注册表项。有些脚本为了"保证成功",会顺手关掉系统的自动更新或者某些安全组件,这种副作用你在生产环境里是承受不起的。脚本帮你省的是敲命令的时间,不是替你承担风险。
3.4 装完之后的验证清单
装完别急着高兴,做几项验证再收工。第一,在开始菜单搜索"商店",确认能搜到、能打开、能正常加载首页。第二,随便挑一个免费小应用点安装,看能不能走完下载和安装全程,这一步是真正的试金石——商店界面能打开不代表下载链路通。第三,装完之后重启一次,再打开商店确认没变成白屏,因为有些依赖注册是在重启后才真正生效的。
如果首页加载正常但下载始终转圈,回过去查第 2.1 节那几个服务,尤其是 Windows Update 和 AppXSvc。如果应用能下载但装不上,去查依赖包是不是缺了某一个 UI.Xaml 版本。这一步的排查顺序是固定的:先服务,再依赖,最后网络,别乱换方向。
4. Edge 的安装与版本选择
4.1 优先选企业版离线包,而不是在线安装器
Edge 的获取方式有好几种,在线安装器、消费者版离线包、企业版离线 MSI。在 LTSC 这种环境里,我的第一选择永远是企业版离线 MSI,原因有三点。
第一,企业版 MSI 不依赖当前系统的网络环境,装的时候不会因为连不上更新服务器而卡住。第二,它支持完全静默安装,参数可控,适合脚本批量部署。第三,装完之后它能配合组策略做集中管理——关闭自动更新、关闭启动增强、限制后台行为,这些在企业场景和精简系统场景里都是刚需。在线安装器虽然文件小,但它装完之后的行为你几乎控制不了。
版本选择上,LTSC 2019 内核是 1809,LTSC 2021 是 21H2,两者都在 Edge 的支持范围内,直接下企业版最新的稳定通道离线包就行。但要避开一个坑:网上很多所谓的"Edge 离线包"其实是给 Windows 7 和 8.1 用的老版本,那份东西装在 Win10 上会出现"Edge 已过期"的提示,因为它的更新通道早就停了。看到有"已过期"提示,基本就是包装错了。
4.2 静默安装的参数和批量部署写法
拿到MicrosoftEdgeEnterpriseX64.msi之后,用管理员命令行执行:
msiexec /i "MicrosoftEdgeEnterpriseX64.msi" /qn这一条走的是完全静默,不弹任何界面。如果你想在装的时候顺手做点定制,可以带参数:
| 参数 | 作用 |
|---|---|
/qn | 完全静默,无界面 |
/qb | 基础界面,显示进度条 |
DONOTCREATEDESKTOPSHORTCUT=true | 不创建桌面快捷方式 |
DONOTCREATETASKBARSHORTCUT=true | 不创建任务栏图标 |
INSTALLDIR="D:\Edge" | 指定安装目录 |
比如我想装到非系统盘、还不留桌面图标,可以这么写:
msiexec /i "MicrosoftEdgeEnterpriseX64.msi" /qn INSTALLDIR="D:\Program Files\Edge" DONOTCREATEDESKTOPSHORTCUT=true装完之后验证一下:
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --version能正常输出版本号就说明装好了。这一步别跳过,有些机器上 MSI 会因为权限问题静默失败但退出码看起来是正常的。
4.3 装完必须做的几件事
Edge 装完只是开始,默认配置下它会启动增强、后台常驻、侧边栏一起上,在 LTSC 这种追求安静的系统上会显得很吵,内存占用也容易被人诟病。我一般会用注册表策略把这些行为压下去。
以管理员身份运行 PowerShell:
$edgePol = "HKLM:\SOFTWARE\Policies\Microsoft\Edge" New-Item -Path $edgePol -Force | Out-Null New-ItemProperty -Path $edgePol -Name "StartupBoostEnabled" -Value 0 -PropertyType DWord -Force New-ItemProperty -Path $edgePol -Name "BackgroundModeEnabled" -Value 0 -PropertyType DWord -Force New-ItemProperty -Path $edgePol -Name "SleepingTabsEnabled" -Value 1 -PropertyType DWord -Force New-ItemProperty -Path $edgePol -Name "HubsSidebarEnabled" -Value 0 -PropertyType DWord -Force这四项分别对应:关掉启动增强、关掉关闭窗口后继续后台运行、开启标签页休眠、关掉侧边栏。标签页休眠这个尤其值得开,你同时开二三十个页面的时候,不活跃的页面会被挂起,能省下可观的物理内存。至于网上常说的"Edge 吃内存",多数情况不是 Edge 本身的问题,而是扩展装太多加上所有标签页都在跑脚本,把休眠打开、精简扩展,观感会好很多。
如果还想控制 Edge 的更新节奏,可以在HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate下面设置AutoUpdateCheckPeriodMinutes,把它调大一点,减少后台频繁检查。但我不建议直接关掉更新,浏览器是天天面对外部内容的软件,长期不更新风险很大。压节奏可以,停更新不行。
注意:策略注册表写在 HKLM 下的 Policies 路径,重启浏览器后生效。想恢复默认,把对应键值删掉即可,不会影响已经安装的程序本体。
5. 常见问题与排查速查表
5.1 商店类问题:白屏、闪退、下载报错
商店打开是白屏或者一直转圈,最常见的原因是依赖框架没装全,尤其是 UI.Xaml 只装了一个版本。先去"设置 - 应用"里看看已安装的应用列表,确认那几个框架是不是都在。如果都在还白屏,试试重建商店缓存:运行wsreset.exe,它会清掉商店的临时缓存并自动重新打开商店,能解决相当一部分加载异常。
点安装立刻失败,报 0x80073D02,说明系统认为依赖缺失。这时候不要猜,直接用 PowerShell 查看当前已注册的包列表,逐项对照:
Get-AppxPackage | Where-Object { $_.Name -like "*Store*" -or $_.Name -like "*VCLibs*" -or $_.Name -like "*Native*" } | Select-Object Name, Version, Architecture看输出里缺哪个,补装哪个。装完之后如果商店还是老状态,可以重新注册一次商店本体:
Get-AppxPackage -AllUsers Microsoft.WindowsStore | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml" }下载过程中断、反复重试,先查 Windows Update 服务是不是被禁用了,再查 DNS。商店的下载走的是系统分发链路,DNS 解析不稳定会直接体现为下载卡死。把 DNS 换成公共解析服务试试,很多时候比到处改 hosts 有效。
5.2 Edge 类问题:已过期、打不开网页、自动弹页
Edge 提示"已过期",说明装的是停止维护的老版本。这种情况别犹豫,直接卸载重装企业版最新离线包:
msiexec /x "MicrosoftEdgeEnterpriseX64.msi" /qn卸载完再重新装上。注意卸载时用原来的 MSI 文件,否则可能卸不干净。
Edge 打不开某些网页,先确认是网络问题还是渲染问题。同一个网址换系统自带的网络诊断工具试试,如果别的程序能访问,那多半是 Edge 自己的问题,最常见的是扩展冲突。用msedge.exe --disable-extensions启动一次,如果能开,就是扩展的问题,逐个排查即可。
Edge 一开就自动弹出某个页面,检查两处:一是启动时恢复上次会话的设置,二是默认主页和启动页有没有被改。在设置里把"启动时"改成打开新标签页,同时检查是不是有扩展在劫持启动行为。
Edge 同时打开很多网页后卡顿,除了前面说的标签页休眠,还要检查扩展数量。很多人装了十几个扩展,每个都在后台跑脚本,内存自然压不住。保留真正在用的,其余的禁用。
5.3 一份错误代码速查表
我把这几年在 LTSC 上装商店和 Edge 时遇到的高频错误码整理成一张表,遇到时直接对照,能省下大量搜索时间:
| 错误码 | 大概率原因 | 处理方向 |
|---|---|---|
| 0x80073D02 | 依赖包缺失 | 补装 VCLibs / .NET Native / UI.Xaml |
| 0x80073CF3 | 包与系统版本不匹配 | 核对内核版本,换对应版本的包 |
| 0x80073CF9 | 应用部署服务异常 | 重启 AppXSvc,重试安装 |
| 0x80072EFD | 下载链路连不上 | 查更新服务、DNS、系统时间 |
| 0x00000194 | 证书或时间校验失败 | 同步系统时间,重新下载包 |
| 0x803F8001 | 商店缓存损坏 | 运行 wsreset.exe 清缓存 |
| 0x800704CF | 网络配置或网络位置不可用 | 检查 DNS 与网络配置,排查 hosts 改动 |
这张表里的原因都写过实际依据,不是拍脑袋。比如 0x80073CF3 我遇到过两次,一次是给 LTSC 2019 灌了 21H2 的商店包,一次是给 x64 系统装了 ARM64 的依赖包,都是典型的版本或架构错配。
6. 装完之后怎么长期维护
6.1 更新通道的取舍
商店和 Edge 装回来以后,它们会各自走自己的更新通道,这跟 LTSC "长期不折腾"的初衷有点冲突。我的处理原则是分层:安全相关的更新保留,功能性的更新按需。Edge 保持自动更新,因为它每天要面对外部网页,这个风险不能省;商店的自动更新可以保留,但可以在商店设置里关掉"自动更新应用"的开关,改成手动,避免半夜偷偷下载占带宽。
Windows Update 本身不建议整个关掉,但可以设置使用时段、暂停一段时间,这些都比直接禁用服务温和,也不会把商店的下载链路一起干掉。见过太多人为了"纯净"把更新通道全堵死,结果几个月后想装个商店应用,发现连下载都跑不起来。
6.2 把这一整套配置固化下来
如果你要给多台机器装,最有价值的做法是把这一整套流程固化成一个可重复的脚本包:把依赖包、商店包、Edge 离线 MSI 放在同一个目录下,写一个 PowerShell 脚本按顺序执行,中间加日志输出。这样下次部署新机器,一条命令走完,不用再回忆当初装到第几步。
脚本里建议加上这几个动作:安装前检查系统内部版本号并给出提示、安装前检查关键服务状态、每一步输出成功或失败、安装完成后自动跑一次版本验证。这几行代码加进去,脚本的可靠性会明显提升,尤其是给别人用的时候,出问题能一眼看出卡在哪。
6.3 几个我踩过的坑,直接告诉你
第一个坑:不要用"最新版"这个思维去选商店包。LTSC 2019 上装最新商店包,界面能出来但功能残缺;要用相对保守、明确支持 1809 的版本。选包的原则是"匹配优先,新旧其次"。
第二个坑:提取 WindowsApps 里的包时别忘了权限。直接复制会失败,需要先拿到该目录的所有权,改完权限复制完再把权限改回去。这一步操作要谨慎,改错权限会让系统本身的应用也出问题。嫌麻烦就别走提取路线,用官方分发渠道的包更省心。
第三个坑:第三方优化工具会把你的成果抹掉。有些工具会定期"恢复系统默认",顺手把你装好的商店卸载掉。装完商店和 Edge 之后,检查一下机器上有没有这类工具,有的话把它对应用管理的部分关掉。
第四个坑:虚拟机里装要注意磁盘和内存。在虚拟机中装 LTSC 再补商店和 Edge,建议至少给到 4GB 内存和 40GB 磁盘,否则商店加载和 Edge 多标签会卡得你怀疑人生。给虚拟机做快照定在"装完商店和 Edge 之后"这个点,后面玩坏了随时回滚。
第五个坑:装完 Edge 别忘了确认默认浏览器。LTSC 里默认可能是 IE,Edge 装好之后要去设置里把默认应用改过来,否则你点任何链接还是往 IE 里跳。在 Windows 设置的应用默认值页面里,把 HTTP、HTTPS、HTM、HTML 这几项都指到 Edge 上才算完整。
这套流程我在 LTSC 2019 和 LTSC 2021 上各走过好几遍,从最早的到处找包、装一次崩一次,到现在基本一次成型。真正让我少走弯路的不是某个神奇的脚本,而是把"版本对号、依赖齐全、服务活着"这三件事在动手前确认清楚。至于装完之后那些策略调优,慢慢来就行,属于锦上添花的部分,不影响核心功能落地。