企业官网建设流程全解析

简介：这份资源面向使用 Windows 10 Enterprise LTSC 版本的用户，尤其是遇到 wsappx 进程 CPU 占用过高、输入法缺少候选提示框等困扰的运维与桌面使用者。它通过补齐应用商店相关组件，让精简版系统也能正常安装和使用 Microsoft Store，从而缓解上述异常。压缩包共 16 个文件，以 appx 与 appxbundle 安装包为主，辅以 xml 清单、cmd 脚本和 md 说明，整体约 68.16MB，解压后以管理员身份运行 Add-Store.cmd 即可完成部署。资源还提示可通过 WSReset.exe 重置商店缓存，便于处理安装后的残留问题。目前已有 2178 人学习下载，适合希望在不重装系统的前提下恢复商店功能、排查 wsappx 高占用与输入法提示异常的用户参考，脚本与组件清单完整，便于按需部署和后续维护。

1. Windows 10 Enterprise LTSC 增加应用商店：一条被低估的补全路径

装完 Windows 10 Enterprise LTSC 的人，十有八九会先愣一下：开始菜单里干干净净，没有 Microsoft Store，没有 Cortana，没有那些花里胡哨的 UWP 预装件。这正是 LTSC 的卖点——长期服务通道，只推安全补丁，不塞功能更新，系统干净得像刚擦过的玻璃。但问题也来了：越来越多的工具、驱动面板、甚至某些硬件厂商的配套软件，只发 Store 版本，官网连 exe 都不给了。这时候你面对的不是「要不要装商店」，而是「不装商店，这个软件我就用不了」。

LTSC 增加应用商店这件事，本质上是给一个被官方刻意裁剪过的系统，把 UWP 运行时的入口补回来。它不改变 LTSC 的更新通道，不引入功能更新，只是把 Store 这个壳和它依赖的框架装回去。适合谁？适合那些既要 LTSC 的稳定和长周期，又偶尔需要从 Store 拿一两个独占应用的人——比如 HEVC 视频扩展、Windows Terminal 预览版、某些品牌的音频控制面板。不适合谁？如果你追求的是「绝对零改动」，那这篇文章的操作你一条都别做。

我自己的主力开发机就是 LTSC 2021，三年下来只重装过一次，中间为了一个只发 Store 的截图工具折腾过一轮。下面把这条路完整走一遍，包括哪些包必须装、顺序错了会怎样、以及为什么有人装完商店打不开。

2. 先搞清楚 LTSC 缺的到底是什么：Store 不是单个 exe

2.1 应用商店在 Windows 里是一组包，不是一坨安装文件

很多人以为 Microsoft Store 就是一个Store.exe，把它拷进去就能跑。实际上在 Windows 10 的现代应用体系里，Store 是一组 Appx 包的集合，彼此有依赖关系。核心的几个是：

• Microsoft.WindowsStore：商店前台界面本身
• Microsoft.StorePurchaseApp：购买和许可证校验
• Microsoft.DesktopAppInstaller：负责安装 winget 和 App Installer
• Microsoft.VCLibs.140.00和Microsoft.VCLibs.140.00.UWPDesktop：UWP 的 C++ 运行时
• Microsoft.NET.Native.Framework和Microsoft.NET.Native.Runtime：UWP 的 .NET 运行时
• Microsoft.UI.Xaml：新版商店界面依赖的 XAML 框架

这些包缺一个，商店要么装不上，要么装上了点开闪退。LTSC 之所以没有商店，不是删了某个文件，而是整个 Appx 包集合在镜像阶段就被移除了。所以「增加应用商店」的准确说法是：把这组包按正确顺序重新部署回去。

2.2 为什么不能直接下个 Store 安装包双击

网上流传过一些「Store 独立安装包」，下载下来是个.appx或.appxbundle，双击后系统弹窗说「此应用无法在你的电脑上运行」或者「需要新应用打开此 ms-windows-store」。原因有两个：一是缺少依赖框架，二是 LTSC 默认没有注册 Appx 部署所需的许可证服务上下文。

正确的做法是用 PowerShell 的Add-AppxPackage命令，按依赖顺序逐个部署。顺序错了，比如先装 Store 再装 VCLibs，Store 会注册失败，报0x80073CF3或0x80073D02。我踩过的坑是：以为依赖会自动拉取，结果卡在Microsoft.VCLibs上，商店图标出来了但点开就消失。

2.3 需要准备哪些包，从哪来

最稳妥的来源不是第三方网站，而是微软官方的 Appx 包分发渠道。常见做法是从一台已经装好商店的同版本 Windows 10 机器上，用Get-AppxPackage导出包路径，再拷贝出来。或者用winget的离线包机制，但 LTSC 默认没有 winget，所以这条路先不走。

我一般会准备一个文件夹，放以下包（版本号以你系统对应的 1809/21H2 为准，不要跨版本混用）：

注意：包版本必须和系统内部版本号匹配。LTSC 2021 是 19044，LTSC 2019 是 17763。拿 19044 的包往 17763 上装，大概率报0x80073CFD。

3. 用 PowerShell 按依赖顺序部署：每一步都能回滚

3.1 开启旁加载和开发者模式

LTSC 默认策略可能禁止旁加载 Appx 包。先确认注册表项：

# 查看当前旁加载策略，1 表示允许，0 表示禁止 Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" -Name AllowAllTrustedApps -ErrorAction SilentlyContinue

如果返回空或者值为 0，需要手动打开：

# 开启旁加载（允许安装受信任的 Appx 包） New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" -Force | Out-Null Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" -Name AllowAllTrustedApps -Value 1 -Type DWord

逻辑说明：AllowAllTrustedApps控制是否允许安装未经过商店签名的 Appx 包。LTSC 出于安全默认关闭，打开后系统才认Add-AppxPackage的部署请求。参数上，-Force确保路径不存在时自动创建，-Type DWord明确写入 32 位整数，避免写成字符串导致策略不生效。

3.2 按顺序部署依赖框架

把准备好的包放在C:\StorePackages下，然后按顺序执行：

# 定义包目录 $pkgPath = "C:\StorePackages" # 第一步：部署 VCLibs 运行时（两个都要） Add-AppxPackage -Path "$pkgPath\Microsoft.VCLibs.140.00_14.0.30704.0_x64__8wekyb3d8bbwe.Appx" Add-AppxPackage -Path "$pkgPath\Microsoft.VCLibs.140.00.UWPDesktop_14.0.30704.0_x64__8wekyb3d8bbwe.Appx" # 第二步：部署 .NET Native 框架和运行时 Add-AppxPackage -Path "$pkgPath\Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe.Appx" Add-AppxPackage -Path "$pkgPath\Microsoft.NET.Native.Runtime.2.2_2.2.28604.0_x64__8wekyb3d8bbwe.Appx" # 第三步：部署 UI.Xaml Add-AppxPackage -Path "$pkgPath\Microsoft.UI.Xaml.2.8_8.2306.22001.0_x64__8wekyb3d8bbwe.Appx" # 第四步：部署商店和购买应用 Add-AppxPackage -Path "$pkgPath\Microsoft.WindowsStore_22210.1401.2.0_neutral_~_8wekyb3d8bbwe.AppxBundle" Add-AppxPackage -Path "$pkgPath\Microsoft.StorePurchaseApp_22210.1401.1.0_neutral_~_8wekyb3d8bbwe.AppxBundle" # 第五步：部署 App Installer（可选，但强烈建议） Add-AppxPackage -Path "$pkgPath\Microsoft.DesktopAppInstaller_2023.1101.10.0_neutral_~_8wekyb3d8bbwe.AppxBundle"

逻辑说明：Add-AppxPackage是部署 Appx 包的核心命令，它会校验包签名、解压到WindowsApps目录、注册到当前用户。依赖框架必须先于上层应用部署，因为 Store 在注册时会检查Microsoft.VCLibs和Microsoft.UI.Xaml是否已存在。参数上，-Path指向本地包文件，如果是.AppxBundle格式，系统会自动选择适合当前架构的子包。

执行完每一步后，可以用Get-AppxPackage确认是否注册成功：

# 检查商店是否已注册 Get-AppxPackage -Name Microsoft.WindowsStore # 检查所有依赖框架 Get-AppxPackage -Name Microsoft.VCLibs* | Select-Object Name, Version, Status

如果Status显示Ok，说明注册成功。如果显示Modified或Tampered，说明包签名或版本有问题，需要换包重试。

3.3 部署后商店打不开的排查顺序

装完包不等于商店能用。我遇到过三种典型情况：

第一种，商店图标出现，点击后窗口一闪而过。这通常是Microsoft.UI.Xaml版本不匹配，或者Microsoft.NET.Native.Runtime没注册上。解决方法是重新部署这两个包，然后重启AppXSVC服务：

# 重启 Appx 部署服务 Restart-Service -Name AppXSVC -Force

第二种，商店能打开但一直转圈，提示「无法加载页面」。这多半是网络策略或代理设置导致 Store 的 CDN 请求被拦。LTSC 默认没有配置 Store 的网络白名单，需要确认系统代理没有把*.microsoft.com和*.windowsupdate.com拦掉。

第三种，商店能打开但搜索不到任何应用，或者提示「此应用在你的设备上不可用」。这是许可证服务上下文缺失，需要重新注册StorePurchaseApp，并确认系统区域和语言设置与商店区域一致。

提示：每次部署失败后，不要反复执行同一条命令。先用Get-AppxLastError查看最近一次部署的错误码，再针对性处理。

4. 避坑：LTSC 加商店最容易翻车的五个地方

4.1 现象：部署时报 0x80073CF3，提示「包依赖项不满足」

原因：依赖框架的版本低于 Store 要求的最低版本。比如 Store 22210 要求Microsoft.VCLibs至少 14.0.30704.0，你装的是 14.0.30035.0，就会报这个错。

解决：用Get-AppxPackage -Name Microsoft.VCLibs*查看已装版本，去同版本 Windows 10 机器上导出对应版本的包，重新部署。不要试图用-ForceUpdateFromAnyVersion参数强推，那个参数只对同包不同版本有效，跨大版本会直接失败。

4.2 现象：商店装好了，但开始菜单里搜不到

原因：LTSC 的开始菜单缓存没有刷新，或者 Appx 包注册到了当前用户但没注册到所有用户。

解决：先确认Get-AppxPackage -Name Microsoft.WindowsStore返回的PackageUserInformation包含当前用户。如果没有，用Add-AppxPackage -Register重新注册：

# 从安装目录重新注册商店 Get-AppxPackage -Name Microsoft.WindowsStore | ForEach-Object { Add-AppxPackage -Register "$($_.InstallLocation)\AppxManifest.xml" -DisableDevelopmentMode }

-DisableDevelopmentMode表示以正式模式注册，避免开发模式下的调试标记影响商店运行。

4.3 现象：装完商店后，系统更新开始推送功能更新

原因：Store 的某些组件会触发Windows Update的 UUP 更新通道，导致 LTSC 的更新策略被绕过。

解决：部署完商店后，立刻检查组策略或注册表，确认DeferFeatureUpdates仍然生效：

# 确认功能更新延迟策略 Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -Name DeferFeatureUpdates -ErrorAction SilentlyContinue

如果返回空，需要手动写回。LTSC 的更新通道由ProductType和BranchReadinessLevel控制，Store 本身不会改这些值，但某些 Store 应用的安装脚本会。我一般会在部署完商店后，把WindowsUpdate策略导出备份一次，方便对比。

4.4 现象：商店能打开，但下载应用时提示 0x80D05001

原因：LTSC 默认没有启用Delivery Optimization服务，而 Store 下载依赖这个服务做分块传输。

解决：确认DoSvc服务状态：

# 查看 Delivery Optimization 服务 Get-Service -Name DoSvc | Select-Object Name, Status, StartType

如果Status是Stopped，启动它并设为自动：

Set-Service -Name DoSvc -StartupType Automatic Start-Service -Name DoSvc

这个服务在 LTSC 里默认是手动触发，Store 下载时会尝试启动，但有时触发失败。手动设为自动可以避免这个问题。

4.5 现象：部署完所有包后，系统变得不稳定，某些原生功能异常

原因：Microsoft.UI.Xaml的版本和系统自带的 XAML 框架冲突，或者Microsoft.NET.Native.Framework覆盖了系统原有的 .NET 运行时。

解决：这种情况没有后悔药，只能按部署的逆序逐个移除包，定位是哪个包引起的：

# 按逆序移除，每次移除后重启资源管理器测试 Remove-AppxPackage -Package Microsoft.WindowsStore_22210.1401.2.0_x64__8wekyb3d8bbwe Remove-AppxPackage -Package Microsoft.UI.Xaml.2.8_8.2306.22001.0_x64__8wekyb3d8bbwe

移除后如果系统恢复正常，说明冲突包就是刚移除的那个。换一个更低版本或者跳过这个包，只装 Store 必需的最小集合。

5. 进阶：用 winget 替代商店，或者把商店做成可回滚的部署脚本

5.1 为什么我后来更推荐 winget 而不是完整商店

完整商店部署的包太多，依赖链太长，每次系统打补丁后都有可能被重置。我现在的做法是：只部署Microsoft.DesktopAppInstaller，拿到winget命令，然后用 winget 装应用。winget 的包源是微软维护的社区仓库，大部分常用工具都有，而且不依赖 Store 前台。

部署 App Installer 的最小命令：

# 只装 App Installer，不装商店前台 Add-AppxPackage -Path "C:\StorePackages\Microsoft.DesktopAppInstaller_2023.1101.10.0_neutral_~_8wekyb3d8bbwe.AppxBundle" # 验证 winget 是否可用 winget --version

如果winget --version返回版本号，说明部署成功。之后用winget install装软件，完全绕开商店界面。这个方案的好处是：包少、依赖少、系统更新后不容易被重置。坏处是：某些只发 Store 独占的应用（比如某些硬件厂商的驱动面板）还是得走完整商店。

5.2 把部署过程写成一个可重复执行的脚本

手动敲命令容易漏步骤，我一般会写一个 PowerShell 脚本，带错误处理和日志：

# deploy-store.ps1 # 用法：以管理员身份运行，确保 C:\StorePackages 下包齐全 $ErrorActionPreference = "Stop" $logFile = "C:\StorePackages\deploy.log" $pkgPath = "C:\StorePackages" function Write-Log { param([string]$Message) $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss" "$timestamp - $Message" | Out-File -FilePath $logFile -Append } # 按依赖顺序定义包列表 $packages = @( "Microsoft.VCLibs.140.00_14.0.30704.0_x64__8wekyb3d8bbwe.Appx", "Microsoft.VCLibs.140.00.UWPDesktop_14.0.30704.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", "Microsoft.UI.Xaml.2.8_8.2306.22001.0_x64__8wekyb3d8bbwe.Appx", "Microsoft.WindowsStore_22210.1401.2.0_neutral_~_8wekyb3d8bbwe.AppxBundle", "Microsoft.StorePurchaseApp_22210.1401.1.0_neutral_~_8wekyb3d8bbwe.AppxBundle" ) foreach ($pkg in $packages) { $fullPath = Join-Path $pkgPath $pkg if (-not (Test-Path $fullPath)) { Write-Log "缺失包：$pkg，跳过" continue } try { Add-AppxPackage -Path $fullPath -ErrorAction Stop Write-Log "部署成功：$pkg" } catch { Write-Log "部署失败：$pkg，错误：$($_.Exception.Message)" # 失败后不中断，继续尝试后续包，最后统一排查 } } Write-Log "部署流程结束"

逻辑说明：脚本用$ErrorActionPreference = "Stop"让Add-AppxPackage的异常能被try/catch捕获，避免中途静默失败。Write-Log函数把每一步的结果写到日志文件，方便事后对比。包列表按依赖顺序排列，缺失的包跳过而不是中断，这样即使某个可选包没有，核心商店也能装完。

参数上，-ErrorAction Stop是关键，不加的话Add-AppxPackage失败只会写错误流，不会抛异常，catch块永远不触发。日志文件放在包目录下，部署完直接看deploy.log就知道哪一步出了问题。

5.3 验证商店是否真正可用，而不是只看图标

装完商店后，我一般会做三个验证：

第一，打开商店，搜索一个免费应用（比如Windows Terminal），点安装，看是否能正常下载和启动。这一步验证的是商店前台、购买服务和 Delivery Optimization 是否都正常。

第二，用winget install装一个命令行工具，验证 App Installer 是否独立于商店前台工作。

第三，重启系统，再次打开商店，确认不是「一次性可用」。有些包在重启后会因为注册表上下文丢失而失效，重启后还能用才算真正部署成功。

如果三步都通过，这套 LTSC 加商店的方案就算落地了。我自己的机器上，这套流程跑了三年，中间经历过两次系统累积更新，商店没有掉过。唯一一次翻车是某次更新后Microsoft.UI.Xaml被重置，重新部署一次就恢复了。

希望帮到你。

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