企业官网建设流程全解析

简介：面向 Windows 10 LTSC 长期服务频道用户，这份 67.23MB 的 7z 压缩包是一套经过整理的 Microsoft Store 离线恢复方案。LTSC 版本默认移除了商店及相关 UWP 依赖，导致便笺、计算器这类基础应用无法安装。包内共 16 个文件，以 appx 和 appxbundle 安装包为主体，涵盖商店应用本体、购买与账户组件、Xbox 身份验证、.NET Native 框架、Visual C++ 运行库以及桌面应用安装器；辅以 xml 配置、cmd 自动脚本和 md 说明文档，既可一键运行，也能手动逐步注册。安装脚本会自动完成依赖注册、商店部署等步骤，说明文档则给出了常见报错处理与组件安装顺序，方便不同水平的用户快速落地。尤其对需要使用 Store 下载工具、媒体应用或游戏的企业用户和个人爱好者来说，免去了逐个匹配组件版本的繁琐流程。目前已有 1552 人学习下载，适合希望在保持 LTSC 精简稳定特性的同时，按需扩展应用生态的场景。

1. LTSC 补商店：一个 7z 压缩包背后的系统缺口逻辑

一台 LTSC 2019 的办公终端，系统干净到连磁贴都没有，用着确实清爽。可等你要装一个重要软件时才发现，应用分发全走商店通道，系统里却连商店图标都不存在。LTSC-Add-MicrosoftStore-2019 这个 7z 工具包，解决的正是这个让运维人员头疼的缺口：离线状态下把商店本体、运行库依赖、身份组件和许可证服务一并补回系统。它不像普通安装包那样“双击完事”，而是要按依赖顺序手动注册，但稳定性和可控性远比从消费版镜像里扒拉文件要强。适合系统封装、终端运维、批量镜像部署场景的从业者，也是我在处理这类“缺组件”故障时反复验证过的方案。

2. 商店为什么会在 LTSC 上消失：先看清缺失的部件是什么

2.1 长服务通道的精简逻辑与商店消失的真正原因

LTSC 这个版本的设计初衷是“长期服务，不推功能更新”，所以系统层面把大量与商店绑定的组件直接移除了。普通消费版系统里，商店不是一个独立应用，它牵涉到 AppX 部署服务（AppXSVC）、许可证服务、后台智能传输服务以及一连串 UWP 运行时框架。这些组件在 LTSC 上都处于缺失或停用状态，于是你就算拿到一个 .AppxBundle 安装包，双击也会直接报“无法在你的电脑上运行”。

更关键的是，商店类应用走的是 AppX 部署协议，不是传统的 MSI 或 EXE，它要求系统预先具备一整套“框架依赖树”。LTSC 把这些依赖树砍了，商店就变成无根之木。我见过有人走捷径，从同一版本的消费版系统里把C:\Program Files\WindowsApps目录整个复制过来，结果商店图标是出来了，点开只有灰屏，因为目录复制不会重建注册表关系，也不会在部署服务里注册包引用关系。

LTSC 2019 的系统版本对应关系，和后来 2021 或更晚版本完全不同。工具包名称里的 2019，标的就是这一代商店框架所匹配的组件集合。用其他版本组件强行装配，最常见的结果是商店能装上但下载全挂，或者商店本体一启动就退出。

2.2 解包看内容：从文件清单反推安装流程

这个 7z 包解压后，里面是一堆命名“非人类”的包文件。文件名带着产品名、版本号、架构和哈希码，初看像乱码，但分工非常明确。一个完整的 LTSC 商店补充包，通常包含这几类核心组件：

从文件后缀能看出一些门道：.AppxBundle是包含 x86、x64 和 ARM 多架构的“全家桶”，安装器会自动匹配当前架构；.Appx则是单架构包，通常用于运行库这类轻量组件。好处在于，这些包一旦安装成功，系统就会把它们完整体纳入 AppX 部署服务的管辖，卸载和更新都有标准路径可走。

2.3 两种安装方式：Register 与 Add-AppxPackage 怎么选

把商店包弄进系统，实际操作中常见两种命令路径。第一种是展开注册法：把包解压后，用Add-AppxPackage -Register AppxManifest.xml来注册。这种方式适合开发者调试未签名应用，但对商店这类带完整签名链的包反而不友好，它要求开启开发者模式，还会把包引用绑定到解压目录，目录一动就失联。

第二种是直接安装法：用Add-AppxPackage指向 .AppxBundle 原始文件，让部署服务自己处理签名、依赖和框架关系。我在批量部署时基本只认这条路径，原因是 Register 方式在关闭开发者模式的域环境里会被策略拦死，而 Add-AppxPackage 的包“落地”后文件会拷贝进系统托管目录，不会因为原始文件夹被移动而变成死链。

# 用 Add-AppxPackage 安装商店包，依赖包放在同一目录下 Add-AppxPackage -Path "D:\store\Microsoft.WindowsStore_2019.AppxBundle" -DependencyPath "D:\store\Dependencies\*"

这里-Path是主体包路径，-DependencyPath支持通配符，依赖包只要都在指定文件夹里，一条命令就会自动按依赖约束装配起来。实际执行时，我更习惯先手动装运行库，再装商店包，虽然部署服务也会做依赖检查，但一步步来更容易定位是哪一家掉链子。

2.4 安装作用域：装给哪个账户，差别很大

LTSC 设备往往是多人共用或“终端机模式”，所以商店包安装作用域这个问题，碰过几次坑才意识到它有多重要。默认情况下，Add-AppxPackage 安装的包只注册到当前用户；而 LTSC 上很多应用是按机器维度部署的，希望每个账户登录后都能看到商店入口。

如果只装了当前用户作用域，切换账户后商店图标又消失，排查起来极其迷惑。处理办法是用带-AllUsers的查询确认包的实际归属：

# 查看某个商店包是装给了当前用户还是所有用户 Get-AppxPackage -Name Microsoft.WindowsStore | Select-Object Name, PackageUserInformation, InstallLocation

PackageUserInformation字段会显示包所属的用户 SID，如果是 “S-1-5-18” 这类系统账户，说明包是机器级的，所有用户共用；如果显示当前用户名，就说明它只对当前账户注册。LTSC 批量部署时，通常需要以管理员身份安装且使用带-AllUsers的移除参数去清理旧包，否则很容易留下“这个用户有商店，那个用户没商店”的怪象。

3. 把商店装回去：从预检到验证的四段操作

3.1 动手前先看系统底子：版本、残留包、执行策略

拿到 7z 包后别急着解压执行，先确认这台 LTSC 的版本底细。直接按 Win+R 输入 winver 最直观，看版本号是否落在 17763 这个区间。命令行里也可以用 .NET 方法读出版本信息：

# 读取当前系统主版本号，用于确认是否为 LTSC 2019 [System.Environment]::OSVersion.Version

输出结果里，Build 如果对应 17763，就和这个资源包的定位匹配。接下来检查系统里有没有历史残留的商店相关包，避免新包和旧包在发布者签名上打架：

# 搜出所有商店相关包，确认是否已有旧版本占位 Get-AppxPackage -AllUsers | Where-Object { $_.Name -like "*WindowsStore*" } | Format-List Name, PackageFullName, Status

这一步查询返回空，是最理想的“白纸”状态。如果返回有包，先记录版本号，看是否低于工具包内版本。版本过低或状态损坏，都建议先卸载干净再走安装，否则容易在中途撞上签名冲突。还需要顺手确认 PowerShell 执行策略有没有被锁死：

# 查看当前执行策略，Restricted 时需要临时放开 Get-ExecutionPolicy

如果策略是 Restricted，不必修改系统级设置，用-Scope Process只对当前窗口放开即可，不会影响后续环境的策略审计。

3.2 执行安装：依赖顺序决定成败

一个完整商店包的标准装配顺序，我总结成一句话：先框架，再运行库，再身份组件，最后商店本体。这个顺序不是脚本写死了，而是商店包的依赖签名里就写明了对框架的最低版本要求，先装框架相当于先打好地基。

下面的安装脚本适合放在解压目录下直接运行，没有现成脚本时手动保存也很方便：

# 安装依赖包：先遍历 Dependencies 目录，把运行库和框架包逐个装上 $deps = Get-ChildItem -Path "$PSScriptRoot\Dependencies" -Include *.Appx,*.AppxBundle -File foreach ($dep in $deps) { Write-Host "Installing dependency: $($dep.FullName)" Add-AppxPackage -Path $dep.FullName -ErrorAction Stop } # 再安装商店主体包：搜索当前目录下的 Store AppxBundle $main = Get-ChildItem -Path "$PSScriptRoot" -Filter "*Store*.AppxBundle" -File foreach ($pkg in $main) { Write-Host "Installing Store: $($pkg.FullName)" Add-AppxPackage -Path $pkg.FullName }

-ErrorAction Stop在这里是关键参数，它让依赖包安装失败时立即终止整个流程。有段时间我用的是 Continue，结果依赖包坏了一个，后面还继续硬装，最后商店图标出来了但里面全空白，排查时浪费了大量时间。错误越是提前暴露，越容易定位。

工具包若自带 Install.ps1 脚本，建议先打开看一眼里面的安装顺序，确认它是不是先装依赖再装主体。很多网上流传的脚本只做了“暴力循环安装”，顺序没控制，遇到包版本不一致时就翻车。

3.3 安装日志查错：不要靠肉眼猜

安装过程如果抛错，第一步就是把这个 AppX 的部署日志拉出来看。系统里其实有详细的安装记录，命令行直接查：

# 输出 AppX 部署相关的错误日志，按时间倒序 Get-AppxLog -All | Where-Object { $_.Message -like "*error*" } | Select-Object -First 10

Get-AppxLog 是 Windows 10 后才有的模块，它能把部署服务的日志整理成可读条目。排错时我一般先看错误的Message字段里有没有依赖名称或版本号，比如 “Framework package not found” 是依赖缺失，“0x80073D19” 是签名冲突。这几类直接和错误代码表格对上，不用在事件查看器里层层翻。

依赖的问题，优先检查框架版本号和架构。LTSC 2019 上商店包要求 VCLibs 是 14.0 系列，如果装成了 13.0 或 15.0，安装器一样报错。查看已装框架包版本可以用：

Get-AppxPackage -Name "*VCLibs*" | Select-Object Name, Version, Status

返回的版本号要和工具包内包文件名里的版本号对照，有一处对不上，就先把系统里的旧版本卸载，再装正确版本。

3.4 安装完成后真正的验证路径：不只是看图标

商店图标出现在开始菜单，只说明包注册成功，不代表商店能正常可用。我把它拆成三步验证，每一步对应一个常见故障面。

第一步验证包的完整性：

Get-AppxPackage -Name Microsoft.WindowsStore | Format-List PackageFullName, Status, InstallLocation

Status字段是 OK，说明部署服务认可这个包；显示 NeedsRemediation 说明包虽然注册了但状态不健康，常见于之前有用过不完整复制方案的系统。

第二步确认部署服务本身在运行：

Get-Service AppXSVC | Select-Object Name, Status, StartType

这步很关键，因为 LTSC 上 AppXSVC 常被优化软件顺手关掉。服务状态是 Stopped，商店就算包是好的也起不来，手动启动即可。

第三步打开商店实际执行一次搜索并进入应用详情页。这一步能过滤掉大量网络链路问题：搜索能出结果，代表商店后端通信正常；点下载能进入队列，代表 BITS 通道活着。如果卡在转圈，问题就不在包，而在第 4 章要讲的网络与代理参数。

4. 按需深挖：商店装好后哪些参数值得调整

4.1 签名冲突的处理：发布者不同导致装不上

LTSC 终端上经常有企业自研的 UWP 内部应用，这些应用和商店包在发布者签名上不一致时，直接安装商店就会撞上 0x80073D19。这个错误背后的逻辑是：系统不允许存在“包名称相同但发布者不同”的两个已注册条目。商店包名称是固定的，如果有人之前装了一个名称冲突但发布者不同的占位包，后面真商店就永远装不进去。

处理办法是先清理冲突包，再走安装流程：

# 按通配符查出所有商店相关包，强制移除 Get-AppxPackage -AllUsers *WindowsStore* | Remove-AppxPackage -AllUsers

-AllUsers参数在这个场景下不能省。只移除当前用户的包，不会动系统账户下的占位条目，之后安装还是报同样的错误。清理完之后重启系统，再重新执行商店安装，签名冲突才能绕过去。

4.2 依赖包的安装顺序：能少走一半弯路

框架包的装配顺序，经验法则和编译期依赖一致：运行时先于运行库，运行库先于应用。具体到 LTSC 商店场景，是 .NET Native Framework 和 VCLibs 先装，再装身份提供者，最后装商店主体。这个顺序一旦打乱，可能出现界面正常但下载环节异常的情况，反直觉且极难查。

我习惯把依赖包按顺序写死到一个数组里，保证脚本可重复执行而不出错：

# 按依赖顺序依次安装框架、运行库、身份层、商店主体 $packages = @( "Microsoft.NET.Native.Framework.Appx", "Microsoft.VCLibs.140.00.Appx", "Microsoft.XboxIdentityProvider.AppxBundle", "Microsoft.WindowsStore.AppxBundle" ) foreach ($pkgName in $packages) { $file = Get-ChildItem "D:\store" -Filter "*$pkgName*" -File | Select-Object -First 1 if ($file) { Add-AppxPackage -Path $file.FullName } }

这段脚本里Select-Object -First 1是防止目录里同时存在多个版本的同一包，强制取第一个，避免脚本盲目循环装出版本冲突。实际使用时要依据资源包里的文件名调整通配规则，但顺序控制的思路是通用的。

4.3 服务级参数与修改建议

商店补好后，相关的几个服务参数最好按固定标准设置，避免后续自动更新或下载时被服务状态卡住。

这几个服务里，BITS 最容易被安全软件或优化工具关掉。查看当前状态可以用：

Get-Service BITS, AppXSVC, LicenseManager | Select-Object Name, Status, StartType

如果发现 BITS 的 StartType 是 Disabled，就用管理员权限改回来，而不是只临时启动一下，否则重启后下载又会卡住。

4.4 系统更新与商店更新：要拆开管

LTSC 用户普遍会关闭系统更新，但关掉系统更新经常让商店也无法下载应用，原因是商店的下载通道复用了系统更新进程。处理这个问题，并不是简单把系统更新打开，而是要在更新服务配置上“拆开管”：保留 BITS，保留 Windows Update 服务的停止状态但不要禁用其启动类型，或者直接把更新服务设为手动而只禁用在重启时执行安装。

组策略里要确认“关闭应用商店应用程序”这个策略没有启用，否则你再怎么装商店包，双击也一样闪退。很多单位的域策略默认会把商店作为“娱乐应用”关掉，这是 LTSC 商店异常第三大常见原因，优先级仅次于依赖缺失和网络代理。

5. 常见问题与避坑记录：四处容易翻车的现场

5.1 安装时报 0x80073CF9

现象：PowerShell 执行 Add-AppxPackage 时，命令返回错误 0x80073CF9，提示内容是“应用安装失败，因为找不到所需框架包”。

原因：依赖包没装全，或者依赖包的版本不满足商店包清单里的要求。第一次给 LTSC 装商店时，我拿到包后只装了 VCLibs，漏掉了 .NET Native Framework，安装商店包时对方直接拒绝执行。商店包把依赖约束写在签名清单里，不满足就是不让装。

解决：把资源包 Dependencies 目录下的所有包按 3.2 节脚本先完整装一遍，再装商店主体。如果已经全装过，重点看日志里提到的是哪个“Framework”缺失，再到目录里搜对应文件名，把它单独安装一次。安装完重新执行商店包安装，这个错误消失的几率极高。

5.2 商店能开但下载进度条一直转圈

现象：商店应用可以正常浏览，但点击下载安装时，进度一直停在 0%，转圈十几分钟也没有动静。

原因：最初遇到过这个问题时，我先怀疑商店包版本问题，换了几个版本依旧卡。后来查到 BITS 服务的启动类型被系统优化工具改成 Disabled，商店的下载通道根本没有工作进程在跑。还有一种情况是局域网代理设置不对，商店进程不会自动使用系统代理，下载请求直接卡死在连接层。

解决：确认 BITS 服务并把它设为自动：

Set-Service -Name BITS -StartupType Automatic Start-Service BITS

网络代理方面，在系统设置里检查“代理”选项，如果启用了手动代理且代理服务器地址填了内网地址，先临时关掉代理，再重启商店应用验证。大部分转圈都在这一步解决。

5.3 登录商店账户时灰屏

现象：商店能打开，搜索、页面浏览都正常，但点击右上角账户登录，界面变成灰色，转圈一阵后回到空白页，无法弹出登录框。

原因：登录功能依赖账户身份组件和许可证服务。这套组件在 LTSC 上默认处于“冷启动”状态，需要服务被触发时才会工作。如果 LicenseManager 服务的启动类型被改成了 Disabled，登录功能就会直接失效。另一个容易被忽视的因素是系统隐私设置里的“账户信息”权限，如果关闭，商店无法读取当前用户上下文，登录窗口就渲染不出来。

解决：打开服务管理器，找到 LicenseManager，确认启动类型为“手动（触发启动）”，不是禁用。然后在系统设置里把“隐私 → 账户信息”的访问权限设为“允许应用访问账户信息”。改完重启商店应用，再次尝试登录。这两步之后，灰屏问题基本会消失。

5.4 商店本身正常，但商店装出的应用闪退

现象：商店部署成功，从商店里安装了一个第三方 UWP 应用，应用图标存在，但双击后立刻闪退，事件日志显示某个框架模块加载失败。

原因：LTSC 基础镜像没有完整携带 UWP 通用组件，商店包装好的框架只是商店自用版本，第三方应用引用的是另一个版本的 UI 框架或运行库，版本错位时启动即崩溃。

解决：在商店里搜索该应用，查看是否有可用更新，新版本通常会适配旧框架。没有更新的话，去该应用对应发行方下载“框架依赖包”补充安装。定位具体缺哪个框架，用事件查看器看错误模块名称，再对应补装相应运行库。这一块没有统一命令，得按模块来。我处理过的多数案例是补装对应版本 VCLibs 后解决，但也有个别应用需要额外补装 .NET Native Framework。

5.5 卸载商店后，系统里残留灰色条目

现象：执行 Remove-AppxPackage 移除了商店包，开始菜单图标也消失，但“应用程序和功能”设置页里还留着一个灰色、无法点选的应用条目，非常影响后续干净的重新安装。

原因：卸载动作只清除了当前用户作用域的注册信息，系统账户或另一账户下的包引用没有清理干净，或者注册表的卸载键里残留了包元数据。

解决：先强制清理所有用户的包引用：

Get-AppxPackage -AllUsers *WindowsStore* | Remove-AppxPackage -AllUsers

重启后再检查设置页里残留是否消失。若还在，则需要进入注册表编辑器，在HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall分支下，查找包含商店包标识的条目并删除。操作注册表前先导出备份，这是最稳妥的后悔药。

6. 装完商店之后，顺手把离线 Appx 部署也学起来

商店补好只是第一步，真正的效率在批量部署时才能体现。LTSC 终端往往需要反复安装相同应用，而每个应用都要登录商店、点下载、等进度，效率太低。商店提供了一套内置的导出机制，可以把已安装的应用连带依赖包整体导出，再到其他机器上离线安装，整个过程不需要目标机器出网。

在一台已经安装好目标应用的样板上，执行：

# 将目标应用的所有包和依赖导出到共享目录 Get-AppxPackage -Name "*TargetApp*" -AllUsers | Export-AppxPackage -Path "\\srv\common\storecache\"

Export-AppxPackage会识别目标包的所有依赖关系，并将主包和依赖包都输出到指定目录。输出后能看到，目录里不只有应用主体包，还额外生成了 Dependencies 子目录，里面是运行库和框架包。这些文件本身就能直接为下一台机器提供安装源。

到新机器上的安装命令是：

# 从导出目录安装目标应用，依赖由导出工具自动排好 Add-AppxPackage -Path "\\srv\common\storecache\TargetApp.AppxBundle" -DependencyPath "\\srv\common\storecache\Dependencies"

这里-Path可以直接指共享路径，不需要把文件先复制到本地，省去大量拷贝时间。如果目标应用已经存在但版本旧，需要覆盖安装，则要加上-ForceApplicationShutdown参数先结束正在运行的旧版本进程，否则会报进程占用错误。

批量部署时我的固定动作是：先在样板机部署商店，再在第二台验证离线包安装全链路通过，然后才把导出目录加入批量分发任务。这一套流程走顺后，LTSC 的软件分发就不再依赖商店的在线状态。

自从有次批量部署时因为漏装依赖包，导致十几台机器同一时间商店白屏之后，我每次装完 LTSC 商店都强制走一遍“预检 - 依赖安装 - 服务验证”三步，把 0x80073xxx 这类错误从源头挡住。希望这份拆解能帮你在 LTSC 设备上少走几段弯路。

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