简介：面向 Windows 10 LTSC 2019 企业版用户，这份 7z 压缩包用于为默认精简、无应用商店的系统添加 Microsoft Store 组件。LTSC 版本因长期服务定位会移除非核心功能，借助本资源可在离线环境下补全商店及其运行依赖，进而安装便笺、计算器等 UWP 应用。整个操作无需联网，尤其适合内网或受限网络环境。包内共 16 个文件，文件类型包括 6 个 Appx、4 个 AppxBundle、4 个 XML、1 个 CMD 脚本和 1 个 Markdown 说明；Appx/AppxBundle 涵盖 .NET Native Framework/Runtime、VCLibs、Windows Store、StorePurchaseApp、Xbox 身份提供者及 DesktopAppInstaller 等关键模块，CMD 脚本可自动完成组件部署，Markdown 文件提供使用说明，整体约 67.23MB。已有 1552 人浏览学习。对于需要在 LTSC 环境中扩展应用的企业 IT 人员或追求精简稳定系统的个人用户，这套方案覆盖从依赖补齐到商店恢复的完整链路，能直接解决应用缺失问题，并为后续部署更多 UWP 或桌面应用提供可复用的基础。
1. 这个压缩包不是“装商店”，是在给 LTSC 补一条缺失的应用链路
很多人拿到 LTSC 系统后遇到的第一个软钉子并不是软件崩溃，而是：从官网下的 exe 能跑，系统商城却压根不存在，需要商场分发的应用装到一半直接失败，报错信息看不懂，网上搜出来的解释又全是“系统精简版就是这样，别折腾了”。标题里这个 LTSC-Add-MicrosoftStore-2019.7z 解决的就是这个缺口：把微软商店本体连同它依赖的框架包、运行时和服务开关一起打包，用完全离线的姿势补回 LTSC 2019 这类长期服务版系统。它适合两类人：一类是给旧机器或内部测试环境做基础运维的工程师，另一类是开发 UWP 应用但测试机缺少商店分发入口的开发。注意，它补的是“分发入口”，补完之后商店能不能正常下载，还取决于系统服务、账户许可和包版本是否匹配，这不是玄学，而是几个可以逐一排查的环节。这篇文章顺着这个压缩包讲清楚：它打包的是什么、怎么部署、失败时看哪里、以及验证到哪一步才算真正结束。
2. LTSC 2019 砍掉的不是商店图标，而是整条 UWP 依赖链
2.1 商店是 Appx 包，但它依赖的不只是自己
微软商店在 Windows 里的存在形式是一个 Appx 包，包名是 Microsoft.WindowsStore，听起来像是一个独立应用。但如果你把它当成 exe 那样双击安装，会发现它根本跑不起来。原因是商店这个 Appx 包本身只是一个“前台壳”，它的正常运行依赖一批框架包、运行时组件和后台服务，这些组件在普通家庭版、专业版里随镜像预置，而在 LTSC 2019 里被整体省略。
以 LTSC 2019 为例，它的基础内核是 1809 系列，定位是长期服务分支，面向消费者的大量组件都被移除：商店、Xbox 相关身份包、通知推送、语音助理、在线账户联动等全部不在默认基线里。单看商店这个包，它需要一个 UI 框架包来提供渲染层，需要 VC 运行时包来支撑原生库，还需要一个“客户端许可服务”来确认你的下载权限，而这个服务叫 ClipSVC。同样重要的是 AppXSvc，负责处理 Appx 部署请求和依赖解析。这几个服务在普通系统里默认是自动启动的，在 LTSC 里可能被直接禁用，也可能处于“未配置”状态。
所以标题里的 Add-MicrosoftStore 并不是“加一个图标”，而是把这一整套东西补回来。我习惯把这件事叫“铺路”而不是“装应用”：路铺好了，商店和后续的 UWP 应用才能顺着这条链路装进系统。如果只装商店主包不装依赖，最常见的结果是打不开、闪退，或者能打开但点击下载时立刻报错。很多人在这一步开始怀疑资源包有问题，其实错的不是包，而是部署动作不完整。
部署动作不完整的另一个表现是缺少“策略放行”。LTSC 虽然面向企业，但部分批量封装镜像会在组策略里预设“关闭应用商店”的策略。这个策略一旦启用，无论你把商店包装得多完整，图标点开就是白屏或直接提示被组策略阻止。补包之前先花十秒钟检查这项策略，比反复重装包有效得多。
2.2 三种补商店的方式：在线、离线包、镜像预置
给 LTSC 补商店并不是只有这一种做法，我在实际处理中大概把方案分成三类：在线直装、离线资源包、镜像预置。它们的差异主要在于“依赖怎么处理”和“交付给几台机器”。
在线直装听起来最简单，找一个可信来源下载商店的 .appx 安装包，然后执行 Add-AppxPackage。问题在于商店更新时往往还伴随一批框架包版本变化，你下载的主包可能是新版本，而 LTSC 2019 系统里的依赖版本还停在很老的位置，命令执行时大概率报“找不到适用的依赖包”。在线方式只适合那些已经把依赖更新到位的常规系统，对 LTSC 这种缺依赖的系统并不友好。
离线资源包就是标题里这种方案：把商店本体、框架依赖包、部署脚本打成 7z 压缩包。你解压后按顺序把依赖和主包装进去，整个过程不依赖网络，失败时也可以一层层拆开定位。对于单机补漏和测试环境来说，这是三种方案里成功率最高、也最容易重复执行的。它的缺点在后面会提到：存在版本代差，装完后还需要验证。
镜像预置则是企业批量装机才考虑的方式：用 DISM 把商店相关的 Appx 包注入 Windows 镜像，然后统一部署。它的问题是维护成本高，包版本必须跟随镜像基线走，适合几十台以上、有标准镜像管控的团队。个人拿来补一台机器完全没必要。
三种方案的差异可以看这张表：
| 方案 | 依赖处理 | 是否联网 | 典型适用场景 | 门槛 |
|---|---|---|---|---|
| 在线直装 | 依赖单独匹配 | 需要 | 常规系统补商店 | 低，但失败率高 |
| 离线资源包 | 包内自带依赖 | 不需要 | LTSC 单机/测试环境 | 中，需按序部署 |
| 镜像预置 | 在镜像阶段注入 | 准备时可选 | 企业批量交付 | 高，需镜像维护 |
2.3 2019 这个年份，决定了资源包的兼容边界
标题里的 2019 不是随便写的年份，它通常指向两个信息：一是包内商店版本的收集时间，二是面向 LTSC 2019 这个系统基线。LTSC 2019 的版本号停留在 1809，商店包和框架包在编译时都会声明自己支持的最低系统版本。包的目标版本如果远低于当前系统，系统会提示“已存在更高版本”而跳过；如果远高于当前系统，又会出现“部署失败，需要更新的操作系统版本”。
所以这个资源包并不是对所有 LTSC 版本通吃。在 LTSC 2019 刚装完、补丁还比较少的机器上，它的成功率最高；如果机器已经累积更新到很后面的版本，系统自带的框架包可能比资源包里的还新，这时依赖目录里的包会被跳过，商店主包偶尔能装上，但缺失的新版运行时并不会被自动补上。这种情况下，你需要从一台已经自带最新商店的常规系统里导出对应包，而不是反复重跑旧脚本。
这个兼容边界也是这篇文章后面“避坑”章节的引子：很多部署失败不是操作错，而是资源包与系统之间的“代差”造成的。
3. 手工复现一次添加商店的全过程：解压、喂包、服务检查
3.1 解压 7z：先看清包内目录结构再动手
假设你已经拿到了这个压缩包，第一步不是双击某个 install 脚本，而是先解压并把目录结构看一遍。我通常用 7-Zip 的命令行工具处理，这样输出的路径和状态可以留作后续排查依据。
# 进入压缩包所在目录，解压到 D:\LTSCStore cd /d D:\downloads 7z x LTSC-Add-MicrosoftStore-2019.7z -oD:\LTSCStore这里x表示解压并保留目录结构，-o指定输出目录，注意-o和路径之间不要加空格。如果机器上没有安装 7-Zip 的命令行，先在图形界面里把压缩包解开到固定目录，效果一样，只是后面写脚本时路径要改。
解压完成后不要急着执行，打开目录看一眼。常见结构是：一个 PowerShell 脚本或批处理脚本、一个 Store 主目录、一个 Dependencies 依赖目录，有时还会有按架构分的子目录，比如 x64、x86、ARM64。这部分如果被重新整理过，结构可能不同，但核心信息一样：你能分清哪些是主包、哪些是依赖包、脚本是按照什么顺序安装的。
这步要做一个判断：你的系统是 64 位还是 32 位。LTSC 2019 绝大多数是 64 位，如果你用的资源包里同时有 x64 和 x86 依赖，就只装 x64。把 ARM64 的包误装到 x64 系统上，错误信息会显示“架构不匹配”，这类报错如果不看目录结构，很容易被当成压缩包损坏。
3.2 用 Add-AppxPackage 按依赖顺序喂包
我一般不会直接双击资源包里的 install.ps1，因为脚本可能包含一些针对作者自身环境的假定：比如路径写死、包含不必要的系统精简操作、或者用了老版本的参数。更稳妥的做法是自己写一段尽量简单的部署脚本，把依赖先装完，再装商店主包。
下面的示例脚本就是按这个顺序做的：
# 必须以管理员身份运行 PowerShell，否则部署会被拒绝 Set-ExecutionPolicy -Scope Process Bypass -Force # 切换到解压目录 Set-Location "D:\LTSCStore" # 定义依赖目录与商店包目录 $depDir = "D:\LTSCStore\Dependencies" $storeDir = "D:\LTSCStore\Store" # 第一步：先装所有依赖包 Get-ChildItem -Path $depDir -Recurse -File | Where-Object { $_.Extension -in '.appx', '.msix', '.msixbundle' } | Sort-Object Name | ForEach-Object { Write-Host "Installing dependency: $($_.FullName)" Add-AppxPackage -Path $_.FullName -ForceApplicationShutdown } # 第二步：再装商店主包 Get-ChildItem -Path $storeDir -Recurse -File | Where-Object { $_.Extension -in '.appx', '.msix', '.msixbundle' } | Sort-Object Name | ForEach-Object { Write-Host "Installing store package: $($_.FullName)" Add-AppxPackage -Path $_.FullName }这段脚本的逻辑分两段：第一段遍历 Dependencies 目录，把目录内所有扩展名匹配的包依次安装；第二段再去 Store 目录装主包。顺序不能反过来，因为商店主包在部署时会对依赖做解析，如果依赖不存在，命令直接失败。Sort-Object Name在这段脚本里只是让执行顺序看起来有序，它不保证依赖关系的正确性。真正的依赖顺序是脚本作者在组织资源包时就定好的，如果目录名带数字前缀或明显层级，要尊重那个顺序。
-ForceApplicationShutdown的作用是在安装前强制关闭正在占用相关文件的进程。如果你之前尝试打开过商店并且它仍挂在后台，这个参数能避免“文件被占用导致安装中止”。它适合依赖包的安装，商店主包那一段我通常不加，因为主包安装时一般不涉及被进程占用的文件。
Add-AppxPackage的常用参数可以归纳成这张表：
| 参数 | 作用 | 什么时候用到 |
|---|---|---|
| -Path | 指定要部署的 .appx、.msix 或 .msixbundle 文件 | 最常见的安装方式 |
| -Register | 注册 AppxManifest.xml，不重新展开资源 | 从别的机器拷贝已解包的应用目录时 |
| -DependencyPath | 显式指定依赖包路径 | 仅当包声明了依赖且自动解析失败时 |
| -ForceApplicationShutdown | 强制关闭占用文件的进程 | 重装或覆盖安装时使用 |
这里有一个很容易踩的误区：不要把 .msixbundle 解包后逐个安装里面的子包。bundle 文件本身就带架构区分和依赖索引，直接安装整个 bundle 才是正确姿势；拆开装会破坏依赖关系，商店装完后打开也是残缺状态。另外，不要为了部署商店去开启“开发者模式”，它是给开发调试用的，会放宽部署限制，在交付机器上属于多余操作，安全上也划不来。
3.3 部署完成后必须检查的三项：服务、组策略、系统时间
包装完之后，商店不一定就能正常打开。我遇到过多次“部署全部成功，打开白屏”的情况，最后定位到的原因几乎都落在这三项里。
第一项是服务状态。商店运行依赖 AppXSvc 和 ClipSVC，前者负责 Appx 部署，后者负责客户端许可。如果系统之前被优化工具精简过，这两个服务可能被改成禁用。用下面的命令查看并恢复：
# 查看服务状态 Get-Service -Name AppXSvc, ClipSVC | Select Name, Status, StartType # 如果 ClipSVC 被禁用，恢复为自动并启动 Set-Service -Name ClipSVC -StartupType Automatic Start-Service -Name ClipSVC第二项是组策略。检查“计算机配置 → 管理模板 → Windows 组件 → 应用商店”，如果“关闭 Microsoft Store 应用商店”处于“已启用”状态，包装得再完整也是白费。这一步不需要命令行，图形界面里看一眼设置状态就行。
第三项是系统时间。商店连接许可服务时，如果系统时间和实际时间偏差过大，证书校验会失败，表现就是“点下载后一直转圈，最后提示稍后再试”。先把系统时区设为自动，然后手动同步一次时间，再打开商店。很多看起来像网络问题的故障，起因都是这一条。
4. 添加商店的几个翻车现场：现象、原因与排查顺序
4.1 部署失败，提示“找不到适用的依赖包”
现象：执行脚本后很快红字报错，中英文提示都指向“部署失败”，错误码经常是 0x80073CF3，后面跟着“找不到适用的依赖包”。
原因：最常见的有两种。一是解压后只拷贝了 Store 目录，Dependencies 目录漏了，脚本找不到依赖文件；二是机器是 64 位系统，但资源包里同时有 x64 和 ARM64 包，安装脚本无差别遍历，或者你自己把架构选错了。
解决：把整个解压目录原样保留，不要按“看起来有用”来挑选文件。先看目录下有没有架构子目录，再检查 Dependencies 是否完整。如果脚本是批量遍历的，我一般改成先单独装一个依赖包试试，确认当前架构能装上，再放行整个遍历流程。
4.2 商店白屏闪退，问题多数出在 ClipSVC 服务
现象：商店图标存在，双击后窗口出现，但内容区一片空白，十几秒到几十秒后自动退出；有的会重新回到桌面，没有任何错误弹窗。
原因：商店启动时要去 ClipSVC 拿许可状态，这个服务如果被禁用或没有启动，商店就拿不到“允许运行”的凭据。LTSC 系统经常被各种优化脚本处理，服务状态被改动是常事。
解决：先执行Get-Service ClipSVC看状态，如果 StartType 是 Disabled，用上一章的Set-Service命令恢复为自动并启动。然后运行一次wsreset.exe -i重置商店缓存，这是清理商店“头一次打开就崩溃”的常规手段。服务修好后再打开商店，白屏问题基本消失。
4.3 管理员运行却提示“无法安装”：注册方式与执行策略的坑
现象：脚本右键“以管理员身份运行”，窗口一闪而过或者直接提示“无法安装”；部分情况下报“拒绝访问”。
原因：如果资源包脚本用的是-Register参数，它不是通过正常部署流程展开包内容，而是把一个已存在的应用目录注册进系统。这种方式适合从别的机器整体拷贝的包目录，但在 LTSC 这种缺依赖的环境里，-Register不执行依赖校验，失败率反而更高。另外，部分封装镜像把 PowerShell 执行策略固定在 Restricted，脚本开头的Set-ExecutionPolicy被组策略压住，脚本内容根本不会执行。
解决：不看脚本本身，直接在 PowerShell 窗口里逐条执行Add-AppxPackage -Path，绕开执行策略脚本文件这一层。执行策略用Get-ExecutionPolicy -List查看，如果组策略层锁死了，就放弃跑 .ps1，改成手动输入命令逐包安装。
4.4 商店能开却无法下载：系统时间、商店缓存与账户许可
现象：商店能正常浏览主页，点击“获取”后按钮变成转圈状态，持续几分钟后提示“稍后再试”，或者立即报“无法完成购买”。
原因：这一条往往不是单一原因。系统时间偏差会让许可服务校验失败；商店缓存损坏会导致下载队列无法建立；还有一些资源包不含交易许可组件 Microsoft.StorePurchaseApp，商店本体能装，但“获取”按钮依赖的这个组件缺失，下载流程无法继续。
解决：先对时，同步完再试一次；然后无参数运行wsreset.exe清缓存；最后检查资源包里是否包含 StorePurchaseApp 相关包，如果缺，需要另外补齐这个组件包。三条按顺序排查，大多数“能开不能下”都能定位到其中一步。
4.5 旧包装完还是闪退：2019 资源包与较新系统的版本代差
现象：在已经打过大量累积更新的 LTSC 机器上，2019 资源包装完，商店当天能打开，第二天或重启几次后开始闪退；而依赖包的安装过程常常显示“跳过”，因为系统已有更高版本。
原因：资源包里的框架包版本低于系统当前内置版本，部署时按“已存在更高版本”被忽略。但商店主包本身可能是一个较老构建，它与系统新组件之间存在不兼容，闪退就是这种代差的直接表现。
解决：不要在这个版本上反复重装旧资源包。最可靠的做法是：在一台已经自带最新商店的常规系统上，用Get-AppxPackage -Name Microsoft.WindowsStore | Select InstallLocation找到商店实际目录，整体复制出来，再拷贝到 LTSC 机器上用-Register注册。这样拿到的包版本和当前系统组件是同步的。如果只是日常使用而不是做交付，等商店能打开后，在“设置 → 应用更新”里直接拉一次商店更新也能解决大部分问题。
5. 能用不代表装好：验证方法、更新习惯与更进一步的排查技巧
5.1 三条验证命令和一次真实下载
我判断商店有没有装好，从来不看图标是否存在，而是看三个条件：包存在、依赖完整、能触发真实下载。下面三条命令分别验证这三件事：
# 确认商店本体已注册 Get-AppxPackage -Name Microsoft.WindowsStore | Format-List Name, Version, InstallLocation # 查看商店主包的依赖是否解析完整 Get-AppxPackage -Name Microsoft.WindowsStore | Select-Object -ExpandProperty Dependencies | Format-Table Name, PackageFullName # 从命令行打开商店根页面 Start-Process "ms-windows-store:"包存在和依赖完整只是静态检查，是“前半场”。后半场一定要做一次真实下载：在商店里找一个体积很小的免费应用，点获取，观察进度条能否走完，安装完成后能否从开始菜单启动。这一步通过，才说明部署链路、服务、许可、缓存全部正常。
更进一步的习惯是主动触发商店自更新。商店本体是需要跟随系统更新的，打开“设置 → 应用 → 应用更新”，把自动更新打开，再手动点一次“检查更新”。如果商店能找到自身的新版本并安装成功，说明它不仅能用，还能跟上后续版本迭代，这才算真正收尾。
5.2 离线包的边界：单机补漏可以，批量交付该用镜像预置
这个资源包的价值集中在单机环境和测试机：补一台旧机器、给某个临时环境搭出商店入口，它确实是最省事的路径。但如果你要维护几十台同样镜像的电脑，逐台解压执行脚本就太不划算了，而且每台机器系统补丁状态不同，同一份包在不同机器上表现也不一样。批量交付时应该走镜像预置，在系统镜像阶段用 DISM 把商店宿包注入进去，部署出来每台机器基线一致。这是一条更重的路，但重得值得。
另外要记住这个包的边界：它只能做“从无到有”，不适合做“从旧到新”。系统升级后自带商店的，不要再用旧资源包覆盖；商店能运行但版本落后，优先用商店自更新，而不是重装旧包。硬要用旧包覆盖新系统，反而会把当前可用的依赖链打破。
我现在拿到一台 LTSC 机器，第一件事不是急着补商店，而是先看系统版本、服务状态和现有 Appx 基线，再决定用哪个版本的包。这个习惯是翻车翻出来的——有一次依赖顺序没核对，装到一半系统部署服务状态异常，最后只能回滚重做。先看基线再动包，少走很多弯路。希望帮到你。
本文还有配套的精品资源，点击获取
