一个办公室六十台电脑人手一台要求周一上班前把新的业务客户端装好、桌面图标摆正、旧版本清掉。你要是打算一台台远程桌面进去双击安装包那就得做好周末泡在公司的准备。这种场景下域环境里最省事、也最容易被低估的一招就是把安装包挂到组策略上让机器开机自己装、让用户自己按需装。这篇就围绕组策略应用里的软件分配和软件发布这两条路径把原理、操作、包改造、排错链路和后续维护讲透适合已经有一台域控制器、手里有 MSI 包、但对为什么用户看不到图标为什么开机装到一半失败这类问题还没搞明白的运维同行。1. 从装软件这件小事说起组策略软件部署到底解决什么1.1 一台机器三分钟六十台机器一整天手工装软件的账很好算。假设一个 MSI 包从共享目录双击到装完需要三分钟六十台机器就是三个小时纯操作时间这还没算上你远程连接失败、用户把屏幕锁了、机器正在跑别的任务、装完还要手动清旧版本的时间。真实项目里这个数字通常会翻两到三倍。更麻烦的是不一致A 机器装的是 3.1B 机器装的是 3.0C 机器上残留了上一版的服务进程出问题时你连环境是否一致这个前提都无法确认。组策略的软件安装扩展Software Installation解决的就是这件事把 MSI 包和它的部署策略绑定在一条 GPO 上客户端在开机或登录时自动拉取、自动安装装完的结果是受策略管理的——包括后续的版本升级、卸载、修复都可以从同一个入口批量操作不需要再碰客户端。它的核心价值不在省了三次双击而在于状态可收敛、结果可追溯。这套机制依赖三个前提缺一个都跑不起来客户端必须是域成员或者至少能读到域的 SYSVOL 和 AD 里的策略信息安装包必须是 Windows Installer 能识别的格式分发源必须是一条长期稳定可读的 UNC 路径。第三点是最容易被忽略的后面会单独说。1.2 分配与发布两个词两条完全不同的路径中文界面里把 Assign 翻译成已分配把 Publish 翻译成已发布这两个词看起来差不多实际差别大得像送货上门和把货摆在货架上自取。**分配Assign**是强制性的策略生效后软件会被自动安装用户没有拒绝的权利。用在计算机配置下它在开机阶段、用户登录之前就以系统身份装好了这台机器上的所有用户都能用用在用户配置下它在这个用户登录时安装或者更准确地说是在用户第一次触发这个程序的通告入口快捷方式、文件关联时才真正落盘。**发布Publish**是软性的软件被登记到活动目录里用户打开程序和功能里的从网络安装程序能看到这个程序出现在可选列表里想装就点一下不想装就永远不装。它只存在于用户配置下因为发布依赖的是用户去查询有哪些程序可用这个动作机器账号不会去查询。一句话记住区别分配是我给你装上发布是我告诉你这有个软件要不要随你。1.3 什么时候不该用组策略装软件得说清楚边界不然容易把工具用错地方。组策略软件部署的几个明显短板只认 MSI。纯粹的 EXE 安装包要么重新打包成 MSI要么走 ZAP 这种降级方案只能发布、不能分配、不能提权。触发时机很死。只有开机和登录两个窗口改完策略想立刻生效基本只能重启或注销重登gpupdate /force对安装动作本身不生效。没有回执。装成功了没有统一报表装失败了要去每台机器翻日志。规模上了几百台这种无反馈的体验非常难受。不适合高频变更。包一换就得动 GPO风险评估、变更记录、回滚都要走流程。如果你的终端规模超过三五百台或者需要按用户按需自助安装、需要详细的部署成功率报表那组策略适合做保底的基础软件更复杂的部分交给专业的终端管理平台去做更合理。但对绝大多数几十到一两百台规模、需求相对固定的场景组策略的投入产出比依然是最高的——它不需要额外授权域控上就能配完。2. 分配与发布的机制差异从AD到客户端的完整链路2.1 分配型的两副面孔开机安装与登录安装同样是已分配放在计算机配置和用户配置下行为完全不同这一点值得单独拎出来讲。计算机配置下的分配客户端开机组策略引擎Winlogon 阶段的策略处理拿到 Software Installation 扩展的数据发现有一个包被分配给了这台机器于是调用 Windows Installer 服务以本地系统账号的身份静默安装。安装发生在欢迎界面之前所以用户登录进来时图标已经就位。因为是系统身份它有完整的本地管理员权限可以写注册表 HKLM、可以注册服务、可以装驱动级的组件。这个模式的坑也很典型开机阶段网络栈还没完全就绪如果分发目录在另一台服务器上可能包还没拉到就超时了。所以我一般会同时开启计算机启动和登录时总是等待网络这条策略牺牲几秒开机时间换稳定性。用户配置下的分配用户登录后策略处理到用户侧的分配项。默认情况下MSI 不会立刻完整安装而是做通告advertise——把快捷方式、开始菜单项、文件关联这些入口注册上真正的文件字节在用户第一次点这些东西的时候才拉下来。这是 Windows Installer 的按需安装特性好处是登录快坏处是第一次点击会有几秒到几十秒的等待用户会以为程序卡了。如果你希望用户一登录就装全可以在部署属性里勾上登录时安装此应用程序代价是登录时间变长。这个取舍我通常按包的大小来定50MB 以内直接登录时装超过 200MB 就用按需模式。2.2 发布型为什么只活在用户配置里发布型的实现机制和分配完全不同。当你在用户配置下选择已发布时客户端在策略处理阶段做的事情是把这个包的信息名称、版本、发布者、UNC 路径登记到活动目录的相应位置让它在用户的可用程序列表里出现。真正的安装动作要等用户主动选择才发生而且是以用户身份执行的。这就解释了两件事。第一为什么发布型不能放在计算机配置下。计算机账号没有我去挑一个软件装这种交互语义发布依赖的是一个用户可查询的目录机器账号查询了也没人看。第二为什么发布型装不了需要提权的软件。以用户身份安装意味着受 UAC 和用户权利分配的限制写 HKLM、注册系统服务这类动作要么被拦要么弹提权框在受控环境下弹框本身就违反静默原则。所以发布型适合什么适合那些按用户安装、不需要提权的工具输入法、PDF 阅读器、截图工具、行业里的小型查询客户端。凡是需要装服务、写系统目录的老老实实用分配。2.3 一张表看清三种部署类型部署方式可用位置安装触发执行身份用户可否拒绝是否需要提权已分配计算机计算机配置开机阶段本地系统不能系统身份无需额外提权已分配用户用户配置登录时或首次点击入口用户不能视包而定可能需要已发布仅用户配置用户在列表中主动选择用户可以不装也行不能提权高级含转换文件两者皆可同上同上同上同上这张表建议打印出来贴工位。我见过太多明明配了却装不上的问题根因就是把发布型放在了计算机配置下根本不会显示或者把需要装服务的包做成了发布用户点了没反应因为提权被拦。3. 动手前的三件准备MSI包、共享路径、权限3.1 MSI、MST、ZAP安装包格式怎么选组策略软件安装真正原生支持的只有MSI。这是硬性约束因为整套机制依赖 Windows Installer 提供的静默安装接口、产品代码ProductCode管理、自我修复能力和卸载入口。你给不了 MSI就走不通完整流程。现实中有三种补救MST 转换文件MSI 自带的定制化机制。厂商给的原始 MSI 通常带安装向导需要输入序列号、选择安装路径、去掉不需要的组件。这些选择可以被固化成一个 .mst 文件在部署时附加到 MSI 上。这是最规范的做法后面第 6 节会详细讲。重新打包成 MSI用打包工具把 EXE 安装过程录制成 MSI。优点是统一缺点是录制出来的包质量参差不齐尤其是涉及驱动、COM 组件、自定义服务的安装程序重打包后很容易出现缺文件、注册表写入不全的问题。我个人的经验是能用厂商 MSI 就绝不重打包。ZAP 文件一个纯文本的伪应用描述指向一个 EXE 和它的静默参数。系统把它当作可发布的程序登记但只支持发布不支持分配也不做提权。它是一个应急方案用在厂商死活不给 MSI、又确实需要让用户自助安装的场景。ZAP 的字段很少一个可用的样子是这样[Application] FriendlyName 业务查询客户端 SetupCommand \\fileserver\deploy\query\setup.exe /silent DisplayVersion 3.2.1 Publisher 内部研发有个细节要注意SetupCommand里的路径必须写成 UNC 形式不能用映射盘而且它不会帮你做版本管理用户装完之后你在控制台里看不到任何状态。3.2 软件分发目录的共享权限与NTFS权限分发目录的权限是所有部署失败问题里排名第一的根因而且它有个很讨厌的特性配置阶段完全不报错只有客户端装的时候才失败。所以这一步值得花十分钟认真做对。目录本身我习惯放在文件服务器的一个独立卷上比如D:\SoftwareDeploy共享名用deploy最终路径是\\fileserver\deploy\。权限分两层两层都要给权限层对象权限说明共享权限Domain Computers读取计算机分配型必须机器账号要能读共享权限Domain Users读取用户分配型和发布型必须NTFS 权限Domain Computers读取和执行只给读不要给写NTFS 权限Domain Users读取和执行用户登录安装时需要NTFS 权限域管理员组完全控制维护用几个实操上的心得千万不要给Everyone 完全控制。虽然省事但这意味着任何一个被入侵的终端都能往分发目录里塞文件等于给自己埋了一颗雷。只读就够。不要用映射盘符作为包路径。GPO 里填的路径必须是 UNC因为开机安装阶段根本没有用户登录映射盘不存在。不要用带空格和中文的文件名。老版本系统上中文路径导致的找不到包我踩过不止一次改个名就好了排查时间却花了两个小时。命名规范统一用英文小写加下划线。不要用会下线的机器做源。有人图方便把包放在某台临时测试机上三个月后这台机器重装系统所有客户端后续的安装、修复、卸载全线报错。分发源要放在长期稳定的文件服务器上。3.3 OU、安全组与WMI筛选器的提前规划GPO 是要挂到某个容器上的挂之前先想清楚这批软件要覆盖哪些对象。常见的划分方式有三种实际用起来经常组合按 OU 划分财务部一个 OU、技术部一个 OU各自挂对应 GPO。优点是直观缺点是 OU 结构往往跟着组织架构走组织一调整 OU 就变GPO 跟着迁移很烦。按安全组划分GPO 挂在上级 OU用安全筛选Security Filtering只对某个组生效。优点是和组织架构解耦缺点是每加一台机器都要记得往组里加人容易漏。按 WMI 筛选器划分用来区分操作系统版本、笔记本和台式机、是否安装过某个前置组件。比如只给 Windows 11 的机器推新客户端SELECT * FROM Win32_OperatingSystem WHERE Version LIKE 10.0.2%注意 WMI 筛选器是在策略处理时实评估的会拖慢开机策略处理时间所以别写太复杂的查询也别叠好几层。安全筛选这里有个新手常犯的错误只给安全组加了权限忘了保留读取和应用组策略的授权。正确做法是移除默认的 Authenticated Users 之后把你指定的组加进来并确认它同时具备读取和应用组策略两项权限缺一个GPO都不会对目标生效而且在客户端上表现为策略根本没被应用很容易误判成软件包的问题。4. 分配型部署的完整操作从新建GPO到客户端装好4.1 计算机配置与用户配置的选择逻辑打开组策略管理控制台新建一条 GPO 命名规范一点比如SW-Deploy-业务客户端-3.2.1这样半年后你自己还能看懂。然后右键编辑路径在左侧树里是计算机配置 → 策略 → 软件设置 → 软件安装用户配置 → 策略 → 软件设置 → 软件安装选哪个按上一节的判断标准来需要提权、需要装服务、需要全员可用、包比较大的走计算机配置按用户授权、每人一套配置、不需要提权的走用户配置。这里顺带回答一个高频疑问本地组策略编辑器里根本没有软件安装这个节点。这不是你的系统坏了也不是家庭版缺功能而是软件安装扩展本身就依赖活动目录——它要把包信息登记到 AD 里、要从 AD 里读策略脱离域的本地策略没有这套基础设施所以本地策略编辑器里就不会出现这个节点。想练手的话必须搭一个最简单的域环境哪怕是一台域控加一台虚拟客户端。另外域成员机器上组策略能否打开这件事本身也不重要客户端只要正常处理策略就行了不需要本地有编辑器。4.2 新建软件安装包并选中已分配在软件安装节点上右键 → 新建 → 程序包弹出的文件选择框要求你填 UNC 路径。这一步有个硬性规则必须用 UNC 路径不能用本地路径也不建议用映射盘。填\\fileserver\deploy\client\client_3.2.1.msi回车之后系统会去读这个 MSI 的元数据把产品名、版本、发布者填进列表。如果这一步就报无法打开包或者路径验证失败八成是当前这台管理机的账号对共享没有读权限或者路径打错了。先在资源管理器地址栏里粘贴一次同样的路径能打开再继续。紧接着弹出部署软件对话框两个选项已发布和已分配。这里选已分配。选中之后如果你在用户配置下操作还会弹出在登录时安装此应用程序的复选框前面说过按包的大小决定勾不勾。4.3 部署属性里的几个关键开关包加进列表之后右键 → 属性有几个标签页值得逐个看一遍。部署Deployment标签可以看到当前类型能改分配/发布部署选项里有几个开关自动安装此应用程序如果它已被安装则重新安装用于强制刷新场景。如果此应用程序已安装则不要安装用于保护用户自己装的版本。在登录时安装此应用程序前面提过。升级Upgrades标签做版本迭代时的核心第 8 节详述。修改Modifications标签挂 MST 转换文件的地方顺序敏感先加的先生效。高级Advanced标签几个容易被忽略但很关键的选项选项含义建议忽略语言不校验 MSI 的语言与系统语言是否一致多语言环境下勾上避免语言不匹配失败使 32 位 X86 应用程序可用于 Win64 机器64 位系统上按 32 位模式安装老的办公插件类包建议勾上当此应用程序超出管理范围时将其卸载包从 GPO 移除后自动卸载默认是勾上的删除包前务必确认不在添加或删除程序中显示此程序包隐藏卸载入口防止用户自行卸载基础客户端时勾上最后那条超出管理范围时卸载是很多人第一次踩的坑想临时把某个包从 GPO 里移掉结果第二天一上班全公司的客户端软件被集体卸载了。要避免先在高级标签里取消勾选等确认好了再删包。配完之后把 GPO 链接到目标 OU调整好安全筛选客户端重启一次。这里再强调一遍gpupdate /force不会触发软件安装因为安装动作绑定在开机和登录这两个特定时机上强制刷新策略只能让策略数据更新不会重跑安装引擎。想要立即生效重启计算机分配或注销重登用户分配。5. 发布型部署的实操与用户看不到软件的排查5.1 发布型部署的设置步骤发布型的配置步骤和分配型很像只有一处不同在部署软件对话框里选已发布。而且必须在用户配置 → 软件设置 → 软件安装下操作计算机配置下根本没有已发布这个选项。发布型通常配合两个设置使用。一是在高级标签里勾上不在添加或删除程序中显示此程序包——发布型的初衷就是让用户自己挑如果还想控制用户不能卸载那发布这个动作本身就没意义了这种情况应该直接用分配。二是考虑是否需要类别标签给程序分组程序多了之后按办公工具业务系统辅助工具分类能让用户找起来快一点。5.2 客户端界面在哪里找到已发布的程序用户侧的入口在控制面板 → 程序和功能 → 左侧的从网络安装程序部分系统上叫安装程序或从网络安装程序。点进去之后能看到已发布的可选程序列表选中 → 安装 → 确认系统会去 UNC 路径拉包并静默安装。在新版系统上这个入口的位置有变化有些版本需要经由程序和功能左侧链接进入有些精简过的镜像里入口被隐藏。测试阶段我一般直接告诉用户打开控制面板切换成大图标视图找程序和功能左侧那一列有个蓝色的链接比描述菜单路径管用。安装完成后程序不会自动出现在所有程序列表里除非包自身创建了快捷方式这一点要提前和用户说明不然他们会以为没装上。5.3 看不到、装不上、点了没反应发布型的失败率比分配型高因为它涉及用户交互环节变量更多。按下面这个顺序排查基本能在十分钟内定位确认 GPO 生效了没有。在客户端上跑gpresult /r /scope:user看用户配置里有没有你要的那条 GPO。没有的话先解决安全筛选、OU 链接、WMI 筛选器的问题别急着查包。确认用户对分发目录有读权限。发布型是用户身份去读包的所以 Domain Users 的读权限必须有。用这个用户的账号在资源管理器里直接打开那条 UNC 路径试试弹权限拒绝就是这个问题。确认从网络安装程序入口是否可用。有些系统因为策略或组件精简这个入口是空的或者根本不存在。确认这个包本身能不能以用户身份装。做法很简单用这个用户的账号在资源管理器里双击 UNC 路径下的 MSI看看会不会弹提权框或者报没有足够权限。会弹框说明这个包不适合发布改用分配。第 4 步是我最常用的一个降维测试——把 GPO 这一层剥掉直接验证包和权限能省掉大量来回猜测的时间。6. 安装包改造转换文件、静默参数与顽固兼容问题6.1 用MST把安装路径和序列号固化下来厂商给的 MSI 大多会弹向导而组策略部署的整个链路是无人值守的向导弹出来就等于卡死。解决办法是先把向导的选项固化成一个 MST。有两种做法一是用微软官方的转换文件编辑器Orca 这类工具打开 MSI 的 Property 表把SERIALNUMBER、INSTALLDIR、AGREETOLICENSE这类属性直接写死然后另存为 MST。二是在测试机上手动跑一遍带/r参数记录模式的安装命令msiexec /i client.msi SERIALNUMBERXXXX-XXXX /qb /l*v C:\temp\record.log不过更实用的路径是先用向导装一遍把生成的 MST 从临时目录捡出来有些包会用msiexec /a做管理安装点生成一个带定制选项的 MST再挂到 GPO 的修改标签里。挂 MST 时注意文件的存放位置——MST 必须和 MSI 放在同一个共享目录下并且保持相对位置不变。有人把 MST 放在管理员自己的机器上路径写成本地盘结果客户端当然找不到报错信息又很含糊。还有个顺序问题如果挂了多个 MST安装引擎会按列表顺序依次应用后面的覆盖前面的。所以定制项冲突时把优先级高的放后面。挂完之后一定要在测试机上完整验证一遍重点看安装目录是不是按你指定的路径落的、序列号有没有写进去、不需要的组件有没有被跳过。6.2 EXE包怎么办ZAP与自解压MSI不是所有场景都有 MSI。遇到 EXE我按下面的优先级处理首选是问厂商要 MSI 版本或者管理安装点。很多软件的安装介质里其实带了一个msi目录或者支持/extract参数解开提取 MSI只是文档里没写。花十分钟翻一翻安装包目录结构经常有惊喜。其次是用自解压包装把 EXE 和静默参数包成一个 MSI 外壳让它调用内部的 EXE。这种做法能走通分配流程但它有个致命的副作用——卸载信息是外壳的真正的程序卸载机制不归 Windows Installer 管后续想用策略卸载就会变成删了图标程序还在。所以凡是这么包出来的我都在文档里注明只能装不能卸。最后才是ZAP只走发布、只针对用户、不涉及提权适用面很窄。6.3 依赖、重启与安装顺序有两个运行时依赖需要提前处理。前置组件依赖比如某个客户端必须先装 .NET 运行库或者某个 C 运行库。做法是单独建一条 GPO 装依赖链接到同一个 OU并用 WMI 筛选器限定尚未安装该组件的机器也可以把依赖作为第二个包按顺序排在同一个 GPO 里。要注意组策略不保证同一个 GPO 里多个包的严格安装顺序所以更稳妥的是分两条 GPO一条装依赖、一条装主程序并且分两次重启窗口推。重启抑制有些 MSI 装完要求重启。策略部署场景下你不可能让用户看着重启提示所以要在包里尽可能抑制重启很多 MSI 支持REBOOTReallySuppress这类属性通过 MST 写进去把重启统一交给维护窗口。如果实在抑制不了至少要让它在后台排队不要弹窗打断用户——弹窗被用户点掉之后安装状态会停留在一个很尴尬的中间态。7. 排查链路日志、错误码与慢速链接7.1 三处日志的查看顺序软件安装失败日志一定在三个地方之一按下面顺序看别乱翻第一处事件查看器 → Windows 日志 → 应用程序来源筛选Application Management。这是软件安装扩展的专属日志源装成功、装失败、卸载、修复都会在这里留记录。我最常遇到的两条是 ID 108无法应用软件安装设置的更改多半是路径不可达或权限不足和 ID 102安装过程未能完成前者几乎全是共享权限或路径写错后者要看具体的 MSI 错误码。第二处应用程序和服务日志 → Microsoft → Windows → GroupPolicy → Operational。这里记录的是每个客户端扩展的处理情况能看到软件安装扩展有没有被触发、处理花了多久。如果这里压根没有软件安装扩展的记录说明策略没到这台机器上问题不在包而在 GPO 的适用范围。第三处Windows Installer 自己的详细日志。这个默认不开需要手动触发一次带日志的安装来对比msiexec /i \\fileserver\deploy\client\client_3.2.1.msi /qb /l*v C:\temp\msi_install.log用管理员账号跑一遍这条命令看日志末尾的Return value 3附近通常能直接定位到是哪个动作失败。这个办法的价值在于把 GPO 因素彻底排除。如果手动跑也是同样报错那问题 100% 在包本身不用再去折腾策略了。7.2 错误码对照表MSI 的错误码是排查的主要线索下面这些是我实际碰到频率最高的错误码含义常见原因与处置1619无法打开安装包UNC 路径写错、文件被删、共享权限不足1601无法访问 Windows Installer 服务客户端 Installer 服务被禁用或损坏检查服务状态1603安装过程中发生致命错误最泛化的错误必须配合详细日志定位常见于磁盘空间、权限、前置依赖缺失1612安装源不可用分发服务器离线、网络中断、源文件被移动1625被系统策略阻止软件限制策略或 AppLocker 拦截了安装程序1622打开安装日志失败日志目录不存在或无写权限改成已存在的目录即可1603 这个码要单独说一句它本身不提供任何有用信息只是安装过程出错了的兜底码。看到它别浪费时间搜1603 解决方法直接去抓详细日志看Return value 3前面那几行是哪个 Action 失败的。7.3 慢速链接与始终等待网络组策略有个慢速链接检测机制默认阈值是 500 Kbps。当客户端判断自己处在慢速连接上时会跳过一部分扩展的处理软件安装就是被跳过的那一类。这个机制设计的初衷是保护远程办公场景下的登录体验但在实际环境里经常误判——尤其是无线网络、链路聚合或者跨网段访问的情况下。如果你的软件在总部能装、在分部装不上先去查这条策略的阈值设置再确认是不是触发跳过了。同时在域控或本地策略里开启计算机配置 → 管理模板 → 系统 → 登录 → 计算机启动和登录时总是等待网络。这条策略的作用是让客户端在开机阶段等网络完全就绪再处理策略对于计算机分配型的软件安装几乎是必需的。代价是开机慢几秒换来的是部署成功率从七成提到九成以上这个交换非常划算。验证结果时gpresult /h C:\temp\result.html生成的报告比命令行输出更直观可以看到每条 GPO 的胜出情况、哪些扩展被处理、哪些被跳过。RSoP 那个老工具在较新的系统上支持得不好我基本已经不用了。8. 升级、卸载与生命周期维护8.1 用升级标签做版本迭代软件装上去只是开始后续的版本升级才是长期工作。组策略提供了原生的升级机制新建一个包含新版 MSI 的包然后打开新版包的属性 → 升级标签 → 添加在列表里选中旧版包并选择升级方式。几个关键选项必须升级Mandatory upgrade会让旧版必须被替换客户端在新策略生效时自动执行升级卸载现有程序然后安装升级程序则先用旧版的产品代码执行卸载再装新版适合两者不能共存的场景。如果不勾必须用户可能长期停留在旧版本上。这里有个实用的前提条件新旧两个 MSI 最好共享同一个升级代码UpgradeCode厂商在打包时通常会保证同一个产品线的升级代码一致。如果升级代码变了Windows Installer 就认为这是两个完全不同的产品升级标签也关联不上只能走卸载旧的、分配新的这条路。8.2 卸载的两种颗粒度卸载包有两种做法区别很大。第一种是把包从 GPO 里删掉。右键包 → 所有任务 → 删除会弹出两个选项立即从用户和计算机中卸载软件策略下次处理时也就是下次开机或登录执行静默卸载。允许用户继续使用软件但阻止新的安装已经装的保留没装的不会再有。这个选项适合软件要停用但不想影响正在用的人的场景。第二种是改高级标签里的超出管理范围时卸载。这个开关决定了删包这个动作是否连带卸载。前面反复提醒过默认是勾上的所以删包前务必先确认好这个状态。顺带提一个真实碰过的坑如果包已经被卸载了但客户端上还残留文件往往是因为原来的安装不是通过 MSI 完成的比如用户自己手工装的 EXE 版本。Windows Installer 只能卸载它自己装的东西这种情况就得靠额外的清理脚本或登录脚本来兜底。8.3 自我修复机制与源的长期可用性Windows Installer 有个自我修复的特性当用户点击一个通告型程序的快捷方式、而系统发现关键文件缺失或注册表项被破坏时会自动回到原始安装源重新拉取文件。这是好事也意味着分发目录必须永久可用。我踩过最惨的一次坑就是这个早期把包放在一台测试虚拟机上半年后这台机器退役接下来的三个月里陆续有人报点图标提示找不到安装源一查全是自我修复失败。修复方式是重新指一条可用的源但在找到原因之前用户那边感受到的就是程序坏了。所以分发目录的几个长期要求放在有备份的文件服务器上不要随意改动目录结构和文件名改了就等于断源包文件不要删旧版本包留着能省很多事服务器要有基本的监控磁盘满了或者共享断了要及时发现。8.4 一点关于规模和后续演进的实话组策略软件部署的上限我自己摸索出来的经验值是两三百台。再往上问题不在技术能不能跑通而在于你无法知道有多少台机器装成功了。没有报表、没有失败重试、没有按时间的部署单所有的验证都靠抽查和翻日志这在规模化场景下是不可接受的。所以我的实际做法是分两层基础和通用的强制性软件办公套件、运行库、安全客户端、内部业务客户端继续用组策略推因为它稳定、零成本、覆盖可靠需要按时按需、需要自助安装、需要详细回执的场景交给更专业的终端管理工具。两者的边界不是非此即彼而是各自干自己擅长的那一段。另外提醒一句关于测试的纪律任何包第一次上线一定先在一条测试 GPO 上、挂到一台虚拟机所在的测试 OU 上跑通整个流程包括安装、验证、卸载三个环节都走一遍。跳过卸载验证是个常见疏忽等哪天需要紧急下线某个软件时才发现卸载报错那时候的处境会比现在难看很多。