我们一直在研究 SCCM 的应用程序目录，并发现了一个有趣的现象。我的经理指示我实施目录，以便那些介于“一次性安装”和“整个工作组都需要”之间的软件（需要多少人）应该发布到应用程序目录中。我们的帮助台技术人员可以根据情况使用应用程序目录来部署这些类型的软件，以选择需要的用户。
我们实行账户分离，例如，我们的帮助台明星 Emmet Brickowski 有两个 Active Directory 用户账户。他的常规非特权账户CONTOSO\ebrickowski账户应该用于他所有的正常工作，当 UAC 提示出现时，他拥有一个特权帐户（CONTOSO\ebrickowski-adm），该帐户是所有工作站上 BUILTIN\Administrators 的成员。
当用户 Joe 致电服务台时，Emmet 会远程或亲自前往帮助用户（我们的文化非常重视面对面的客户时间），使用其特权登录应用程序目录CONTOSO\ebrickowski-adm并查看大量软件，他可以用标准化的方法为用户安装这些软件。
但当 Emmet 按下安装按钮时，他得到了以下信息：
现在我无法在客户端日志中找到任何有关所发生事件的信息。AppIntentEval.log、AppDiscovery.log、AppEnforce.log日志中没有任何内容，而ConfigMgrSoftwareCatalog.log用于记录应用程序目录操作的 不存在。
如果我们将应用程序部署到包含常规用户的用户集合，并且他们使用登录 Windows 的相同帐户登录应用程序目录，则之前安装失败的相同应用程序。这使我相信您不能将应用程序目录的单独帐户用作当前 Windows 会话。这有点令人沮丧。
- 有人可以验证您是否需要使用与当前在 Windows 会话中使用的相同帐户来访问应用程序目录吗？
- 如果有的话我应该查看哪些日志以进一步调查？
- 是否有其他或更好的方法来实现我们期望的目标，即使用应用程序目录作为技术人员访问的软件商店？
答案1
这是设计使然，只有登录计算机的用户才能通过应用程序目录安装应用程序。试图通过使用不同的 ID 登录来“伪造”应用程序目录是行不通的。
正确的做法是向所有用户宣传这些程序，或者，由于这可能会变得混乱，让您的 Rockstar 技术人员使用他们的管理员帐户登录计算机，可以亲自登录，也可以使用新的 SCCM RC 远程登录。新版本允许技术人员访问登录屏幕，而旧版本则不允许。
注意：您稍微违背了 MS 试图通过应用程序目录实现的目标，它旨在让用户安装他们需要的应用程序，以某种方式最大限度地减少帮助台的工作，因此只需稍加权限技巧，您就应该能够避免灾难，但我完全明白您为什么要这样做，我只是想提一下这一点，这样您就知道为什么这很痛苦。
答案2
既然有技术人员参与，为什么不让技术人员从 SCCM 控制台向该用户部署所需的应用程序呢？
如果您希望为最终用户提供更具交互性的体验，技术人员可以暂时将最终用户添加到“所有可用应用程序”用户集合中，同时他们访问目录并确定要安装哪些应用程序。然后，一旦最终用户安装了应用程序，您就可以将它们从该集合中移除，并且可能通过其他集合将他们刚刚安装的应用程序部署给他们的用户。