LTSC装商店并不难：离线包+PowerShell完整实操指南

简介Windows 10 Enterprise LTSC精简版往往会裁剪掉应用商店同时可能伴随wsappx进程CPU占用过高、输入法无提示框等困扰。这套离线整合包正是面向此类场景主要针对系统管理员、运维工程师以及希望在LTSC环境中使用UWP应用的普通用户通过一键脚本完整恢复商店及其依赖组件。压缩包共16个文件核心为6个appx与4个appxbundle分别对应商店应用、VCLib运行库、NET Native框架、Xbox Identity Provider等必要模块4个xml文件用于系统部署时的配置识别另附Add-Store.cmd自动化安装脚本和README说明文档整体仅68.16MB部署轻便。目前已有2176人学习下载在LTSC应用商店修复方向上有一定参考意义。使用时只需解压并以管理员身份执行Add-Store.cmd随后可运行WSReset.exe重置商店缓存即可让应用商店正常出现在开始菜单中同时明显降低wsappx进程的后台占用输入法提示框问题也能一并解决。资源内各文件命名清晰版本号明确便于在离线环境下挑选所需组件也适合系统封装爱好者将其整合进自定义镜像实现批量预装。1. 为什么 LTSC 用户反而最需要商店一个看似矛盾的问题公司机房里几乎清一色部署了 Windows 10 Enterprise LTSC稳定、干净、没有 UWP 全家桶是我这类运维心里的白月光。可一旦有人要装 Windows Terminal、新版计算器或 Office 的某些扩展整个运维群就会开始问同一个问题Windows 10 Enterprise LTSC 增加应用商店到底能不能做到能但前提是你要搞清楚 LTSC 2019 和 LTSC 2021 的差异不要拿网上的通用脚本硬套。这篇文章就按我自己做企业桌管的流程从组件原理、离线安装、镜像提取到排错把这条路完整走一遍。读完你不仅能装出能打开的商店还能顺手避开至少五个会让你重做系统的坑。2. 动手先看两个大版本LTSC 2019 与 LTSC 2021 的商店机制差异2.1 LTSC 为什么默认不带商店预配包与当前用户注册表的关系很多人以为 LTSC 缺商店只是删了几个快捷方式实际不是。Windows 在制造镜像时会把一批 Appx 包写进install.wim的Windows\SystemApps目录再由预配配置决定新用户首次登录时注册哪些包。普通企业版的预配里带着微软商店全套而 LTSC 从源头就砍掉了Microsoft.WindowsStore的 Provisioned Package所以新账号里没有商店入口后台也没有商场的服务连接。这类被“预配”的包和传统的 MSI 安装完全不同它不会出现在控制面板的卸载列表里检查它只能用 PowerShell# 先看当前系统大版本和内部版本号 winver # 列出当前用户名下已注册的 Appx 包过滤出与商店相关项 Get-AppxPackage -AllUsers | Select-Object Name, Version, Architecture, PackageFullName # 查看系统镜像预配了哪些 Appx 包正常情况下 LTSC 里找不到 WindowsStore Get-AppxProvisionedPackage -Online | Where-Object { $_.PackageName -match Store }第 2、3 条命令是排查工作的照妖镜。Get-AppxPackage -AllUsers能显示某个账号下是否残留半死不活的 Store 注册信息Get-AppxProvisionedPackage则告诉我们镜像里有没有可用的基线包。如果你在 LTSC 2021 里执行第二条命令却看到Microsoft.WindowsStore说明这台机器不是纯正 LTSC或者被前任管理员塞过商店后面排错路径会完全不同。提示不要一上来就装包。先确认自己是 1809 还是 21H2因为两者的 VCLibs 和 .NET Native 依赖版本不通用直接混用安装大概率报“目标平台”错误。这个问题我会在第五章单独讲。2.2 两个大版本的实际差异不是所有商店包都适合你官方“老坛酸菜版”这里虽然叫 LTSB 2016我们通常说 LTSC注意不要混用概念。LTSC 2019 对应 Windows 10 1809商店可以装但依赖包比较旧UI.Xaml 2.8 这类新依赖会导致装完闪退。LTSC 2021 对应 21H2商店主体版本更高同时微软对包签名和依赖链要求也更严格。对比项Windows 10 Enterprise LTSC 2019Windows 10 Enterprise LTSC 2021对应版本号180921H2商店主包版本上限相对旧别用新 UWP 包硬上支持较新的 Store 包VCLibs 依赖14.0.29xxx 以下14.0.30xxx 以上更稳UI.Xaml 依赖用 2.2 版本别追 2.8用 2.8 时也要确认包架构Install-SystemApp 命令可以成功需要先补独立依赖加固康 后续累积更新商店可能被重置同左但概率略低这个表是我在维护几十台不同版本 LTSC 拼出来的结论。简单说你手里如果是 win10 ltsc 2019 原版镜像那装商店的路径和 2021 几乎一样但下载安装包时一定要选面向 1809 的版本否则后面所有操作都白做。2.3 装之前先做好三件准备管理员权限、体系结构、孤儿注册项以管理员身份打开 PowerShell不要用普通用户执行Add-AppxPackage否则新用户登录后商店根本看不到。确认$env:PROCESSOR_ARCHITECTURE是 AMD64 还是 ARM64包架构不对安装必失败。检查是否有残留 Store 注册项有先清理再安装。# 如果存在旧版本或安装失败的残留先摘除再重装 Get-AppxPackage -Name Microsoft.WindowsStore -AllUsers | Remove-AppxPackage -AllUsers # 顺手清理 Provisioned 层面的记录避免新用户登录时被旧签名干扰 Get-AppxProvisionedPackage -Online | Where-Object { $_.PackageName -match Store } | Remove-AppxProvisionedPackage -Online -AllUsers很多人到这里会纠结清了会不会把之前装好的应用也删掉会而且你应该让它删除。LTSC 装商店的常见翻车现场就是因为残留注册项把新包拦住了。这个过程等同于给房子重新刮腻子先铲掉墙面再刷漆别想偷懒。准备到这一层就可以去拿商店包了。3. 离线包安装用 Add-AppxPackage 把商店搬进 LTSC3.1 先找齐五件套商店主包与四个依赖包LTSC 增加应用商店最靠谱的方式不是在线点击而是离线安装一整组 Appx 包。商店本身是一个 AppxBundle它还需要几个基础依赖包才能跑起来。缺少任何一个都会在安装或首次启动时报各种不友善的错误。文件类别命名特征别死记版本号作用商店主包Microsoft.WindowsStore_*_x64__8wekyb3d8bbwe.AppxBundle商店本体VCLibsMicrosoft.VCLibs.140.00_*_x64__8wekyb3d8bbwe.AppxVC 运行库大部分 UWP 都依赖它.NET Native FrameworkMicrosoft.NET.Native.Framework.2.2_*.AppxUWP 编译运行基础.NET Native RuntimeMicrosoft.NET.Native.Runtime.2.2_*.Appx与 Framework 配套UI.XamlMicrosoft.UI.Xaml.2.8_*_x64__8wekyb3d8bbwe.Appx新版商店界面必需这些包从哪里来常见做法是去一个能按链接拉微软官方包的站点填商店链接或者找一台版本接近的全新 Windows 10 机器从它的C:\Program Files\WindowsApps目录里拷出来复用。我一般倾向后者因为同版本系统的包互认性最好。下载好的所有文件放到同一个目录比如C:\store目录里不要有其它无关 Appx 文件避免命令混乱。3.2 安装命令实例一次性把依赖一起注册进去# 定义包目录和主包路径 $storePath C:\store $bundle $storePath\Microsoft.WindowsStore_22301.1401.9.0_x64__8wekyb3d8bbwe.AppxBundle # 按依赖顺序列出依赖包 $deps ( $storePath\Microsoft.VCLibs.140.00_14.0.30704.0_x64__8wekyb3d8bbwe.Appx, $storePath\Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe.Appx, $storePath\Microsoft.NET.Native.Runtime.2.2_2.2.28604.0_x64__8wekyb3d8bbwe.Appx, $storePath\Microsoft.UI.Xaml.2.8_8.2203.10001.0_x64__8wekyb3d8bbwe.Appx ) # 安装主包同时把依赖包注入 Add-AppxPackage -Path $bundle -DependencyPath $deps -ForceApplicationShutdown这里的-DependencyPath一次性解决了顺序问题-ForceApplicationShutdown保证没有正在运行的商店或相关 UWP 进程拦截部署。如果你看到脚本跑完没有任何输出基本就是成功了如果出现红字报错请直接跳到第五章找对应条目。参数说明-Path指向 AppxBundle也就是商店本体-DependencyPath接收一个包列表系统会先装依赖再装主包-ForceApplicationShutdown类似普通软件的“关闭正在运行的安装程序”在公司远程维护时非常有效。注意不要对旧系统使用-AllUsers参数加主包LTSC 2019 上这样做容易把包注册到 System 账户而当前用户依然看不到商店图标。3.3 验证安装结果别只看图标出现安装完成后用以下命令确认包状态是 Ok# 检查商店包是否注册成功Status 应为 Ok Get-AppxPackage -Name Microsoft.WindowsStore | Select-Object Name, Version, InstallLocation, Status # 直接拉起商店测试首次启动是否闪退 Start-Process shell:AppsFolder\Microsoft.WindowsStore_8wekyb3d8bbwe!Microsoft.WindowsStore如果商店能弹出来并看到登录界面这说明前一步成功。但还有一个隐性检查点Get-AppxPackage里如果Status不是Ok而是PackageManagerStage或DependencyMissing那说明安装过程中依赖并没有真正生效应用能开但会时不时抽风。这时候补跑一次wsreset.exe -i让系统重新建立当前用户的商店缓存。wsreset.exe -i在带序号后缀的 1809 以上版本里比普通双击 wsreset 可靠得多。普通wsreset只是清缓存而带-i参数会把商店重新注册到当前设备。这就是我后续维护里最常用的后悔药。4. 用普通 Windows 10 镜像“过继”商店离线包拿法与企业批量补装4.1 从纯净 ISO 里提取商店而不是随便下个别人的打包件上一章的依赖包最稳妥的来源其实是 Windows 10 的常规 ISO。你手里的 win10 ltsc 2021 原版镜像没有商店但同版本的 Windows 10 商业版或教育版镜像里有。公司如果只有 LTSC 的授权文件可以偶尔去官方镜像站拿一份常规版本提取包不必在每台机器上装完整版。挂载 ISO 后商店相关的 Appx 包通常不在Windows\SystemApps里直接以散包形式摆着而是在sources\sxs或 WIM 内的共享存储体中。最直接的方法是把 WIM 挂载成目录再翻# 用 dism 把 install.wim 挂载到 C:\win10mount dism /Mount-Image /ImageFile:D:\sources\install.wim /Index:1 /MountDir:C:\win10mount挂载后# 找到 Microsoft.WindowsStore 的 SystemApps 目录把它复制到目标目录 $systemStorePath C:\win10mount\Windows\SystemApps\Microsoft.WindowsStore_* Copy-Item $systemStorePath C:\store -Recurse -Force # 依赖包在 Windows\WinSxS 里检查但更直接的方式是看同目录下有没有 appx 包 Get-ChildItem C:\win10mount\Windows\SystemApps -Directory | Where-Object { $_.Name -match VCLibs|NET.Native|UI.Xaml }这里要泼盆冷水从镜像里抓出来的包并不保证能直接安装因为 WinSxS 里的文件可能是以组件库形式存在而不是标准的.Appx文件。所以我在实际工作中会优先使用常规 Windows 10 软件包下载站点选好对应语言和架构拉取完整的 AppxBundle 包集。镜像提取更适合用来对照版本号和确认文件签名不适合作为唯一文件来源。4.2 批量部署到多台 LTSC用 PowerShell 脚本跑一遍安装清单企业里不太可能一台台双击安装。我习惯把上一章的安装命令做成参数化脚本配合$deps文件清单跑$storeRoot \\192.168.1.20\company\store\ltsec $bundle Get-ChildItem $storeRoot\*.AppxBundle | Where-Object { $_.Name -match WindowsStore } $deps Get-ChildItem $storeRoot\*.Appx | Sort-Object Name if ($bundle) { Add-AppxPackage -Path $bundle.FullName -DependencyPath $deps.FullName -ForceApplicationShutdown } else { Write-Error 没有找到商店主包请检查共享目录 }这段脚本的逻辑很直白先在共享目录里找主包再按文件名排序把依赖包全部塞进去。有几个坑要提醒Sort-Object Name不是依赖顺序如果你把 VCLibs、.NET Native、UI.Xaml 放在一起安装顺序由系统决定但你会发现它同样能成功因为商店包在部署阶段会自动解析依赖。真正不能乱的是前面那两个 .NET Native 包必须同时提供少了其中一个会直接报依赖错误。公司内网机器如果禁用了 PowerShell 执行策略先执行Set-ExecutionPolicy -Scope Process Bypass -Force。批量安装完建议重启机器的AppReadiness服务或者干脆重启所有客户端。AppReadiness 负责在用户登录时布置 Appx 注册状态不重启时偶尔会出现应用打不开。4.3 安装后的“后悔药”wsreset -i 到底什么时候用很多运维第一次接触这参数是在商店安装失败后被导着跑wsreset.exe -i。它在 LTSC 上的准确含义是尝试重新安装 Microsoft Store并清除商店缓存。装完正常时双击商店能打开就别碰它一旦出现首页白屏、无限装转圈再执行才算对症。# 在 1809 后的系统里用 -i 重新注册商店 wsreset.exe -i这个命令在 LTSC 上的实际作用等于把商店 Appx 重新拉回标准状态相当于把之前手动的Remove-AppxPackageAdd-AppxPackage合并成一条命令。但它依赖本地已有的商店包存在如果你已经把包删干净了这命令只会干瞪眼。所以我的建议是安装后把C:\store这个目录保留在客户端本地或网络共享里不要立刻删。后续补包、修依赖都会回到这个目录它就是这台机器的“商店备份快照”。5. 避坑五个 LTSC 安装商店的真实现场与排查方法5.1 安装时报 TargetPlatform 不匹配“指定的包需要更高的目标平台”现象执行Add-AppxPackage时出现红色错误提示“需要更高的 TargetPlatform”或类似“The package requires a higher target platform”的英文报错。原因你拿的这个商店包或依赖包是面向更新的 Windows 10 版本甚至 Windows 11 编译的。LTSC 2019 的系统 API 集不够新承载不了新包的 manifest 写入。解决换包版本不换系统。win10 ltsc 2019 就去找 1809 时期的商店包别去追新版 UI。如果一定要用新版商店特性唯一的出路是全新安装 win11 ltsc 或 Windows 11 IoT Enterprise LTSC但那已超本文范围。5.2 商店图标出现但点击白屏日志里找不到崩溃模块现象安装一切正常商店在开始菜单能看到点开后窗口一片白等几秒自动关闭事件查看器里没有明确错误码。原因依赖库里缺少 VCLibs 桌面版或 UI.Xaml 的某个平台包常见于只装了商店主包和通用依赖、漏了Microsoft.VCLibs.140.00.UWPDesktop的情况。解决回到C:\store把 UWPDesktop 后缀的 VCLibs 也拉进来重新执行一次Add-AppxPackage -DependencyPath。这条我认为比装完瞎点右键更有效。补齐后不要重启再用Start-Process拉一次商店大多数白屏都被这步治好。5.3 商店能打开但下载应用时一只卡“正在等待下载”现象商店主界面正常搜索某个 UWP 应用后安装按钮一直停在“正在等待”网络也通浏览器访问外网没有任何问题。原因商店下载走的是 Microsoft Store 的推送机制它高度依赖 Background Intelligent Transfer ServiceBITS和 Windows Update 服务。LTSC 的优化脚本为了关更新往往顺手把 BITS 服务也禁用了商店就成了无源之水。解决把 BITS 和 Windows Update 服务改为手动触发或自动启动并立即启动 BITSSet-Service -Name BITS -StartupType Manual Start-Service BITS注意别把 Windows Update 设成禁用设成手动即可满足商店要求。这个方法对 LTSC 特别实用因为你在系统更新里完全不必开启自动下载BITS 照样能工作。5.4 安装完成后其他账号看不到商店现象管理员账号装了商店用普通员工域账号登录后开始菜单里没有商店图标Get-AppxPackage也查不到。原因Add-AppxPackage默认只注册到当前用户的Context并不会广播到其他已存在用户。LTSC 企业环境里我们通常用用户配置文件漫游或新用户不断创建问题就会集中爆发。解决先对当前用户做一次Add-AppxPackage -Scope AllUsers或者改用Add-AppxProvisionedPackage -Online把商店写进预配以后新用户登进来都会有ADD-AppxPackage -Path $bundle.FullName -DependencyPath $deps.FullName -Scope AllUsers -ForceApplicationShutdown如果-Scope AllUsers报错就先运行Add-AppxProvisionedPackage它会要求你提供一个包含所有依赖的完整目录命令细节和上一条脚本类似。做这步后企业域里已经存在的用户还需要在他们自己账号下跑一次Get-AppxPackage -Name Microsoft.WindowsStore | Remove-AppxPackage再重新注册但这个请求一般少见可以交给客户端登录脚本处理。5.5 累积更新后商店被系统“卸磨杀驴”现象LTSC 装好商店用了两三个月某天运维例行推送 10 月或 11 月累积更新后部分机器商店图标消失或者打开时变成“此应用无法打开”。原因这是 LTSC 系统的真实脾气。微软对 LTSC 的承诺是“不提供商店应用更新”作为一个基座操作系统Windows Update 在重建索引时不保留商店的注册状态。某些补丁释放时会把Microsoft.WindowsStore标记为非受支持组件重新拉黑。解决这是最难受却也最常见的现场。我的习惯是不要在 LTSC 上依赖商店为长期稳定服务而是把它当成“临时取货窗口”需要装什么 UWP 工具先开商店装完用完可以不管。补丁翻车后直接重跑一次第 3 章的安装命令五分钟恢复不需要重做系统。切记保留好C:\store目录那就是你的后悔药。6. 让商店长期住在 LTSC 里的一个技巧维护脚本与包清单绑定最后聊一个我在十几台 LTSC 机房设备的验证方法这套方法落后但不花哨。我会把C:\store\packages.json作为包清单文件存住安装日期、包版本、依赖路径后续补包不用再去翻历史记录。验证脚本如下$manifest Get-Content C:\store\packages.json | ConvertFrom-Json $missing () foreach ($pkg in $manifest.Packages) { $find Get-AppxPackage -Name $pkg.Name -ErrorAction SilentlyContinue if (-not $find) { $missing $pkg } } if ($missing.Count -gt 0) { Write-Host 缺少以下包即将自动补装 $missing | Format-Table Add-AppxPackage -Path $manifest.Bundle -DependencyPath $manifest.Deps -ForceApplicationShutdown } else { Write-Host 商店组件完整无需干预 }这个脚本的智慧在于不直接判断“商店图标是否存在”而是一次性核对所有依赖清单。很多翻车在表面看起来是“商店能开”但某个依赖包已经被更新悄悄移除了这时脚本会先一步拉起后台的补包流程。我在第一次给 LTSC 加商店时也踩过 TargetPlatform 的坑浪费过一个下午重做镜像。后来经验告诉我商店对 LTSC 而言永远是一个“外挂”而不是“原生组件”定期检查、保留安装包目录、把安装脚本留在客户端里比指望微软的官方更新更靠谱。换句话说把这套流程写进运维手册再发生补丁后丢商店的情况你也能在五分钟内平移到新用户而不是让整条产线等你重刷系统。希望帮到你。本文还有配套的精品资源点击获取