☰
Windows 10 LTSC 离线补装 Edge 与微软应用商店指南
2026/10/1 5:01:45 网站建设 项目流程

折腾 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 2019LTSC 2021
内核版本180921H2
内部版本号1776319044
微软商店包需匹配 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, Path

3. 微软应用商店的完整安装实操

3.1 依赖包到底有哪些,为什么必须先装

微软商店不是一个独立的小程序,它是一堆积木搭起来的。商店本体负责界面和分发,真正干活的是下面这一层框架。如果你不先装框架直接上商店本体,结果就是商店进程起来了,但一渲染界面就崩,或者连登录页都出不来。

把这些依赖包按用途分一下类,心里有个谱:

包名作用是否必需
Microsoft.VCLibs.140.00C++ 运行时,多数 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.8XAML 界面框架,多版本并存必需
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 上各走过好几遍,从最早的到处找包、装一次崩一次,到现在基本一次成型。真正让我少走弯路的不是某个神奇的脚本,而是把"版本对号、依赖齐全、服务活着"这三件事在动手前确认清楚。至于装完之后那些策略调优,慢慢来就行,属于锦上添花的部分,不影响核心功能落地。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询