我们有很多运行Windows Embedded Standard 7的瘦客户机和一个SCCM 2012 R2服务器来pipe理它们。 瘦客户机启用了写入filter（FBWF），因此机器更改不会持久。 在极less数情况下，我们必须更新它们，我们只需通过SCCM进行部署，它会自动closures写入filter并重新提交更改。 以下是应该发生的事情： SCCM客户通知用户并进行30分钟的倒计时，以保存他们的工作并下车。 瘦客户机然后重新启动并禁用写入filter。 login屏幕显示一个挂锁，并注意到该单元正在服务，并且不会允许正常（非pipe理员）用户login，而SCCM正在做这件事情。 当SCCM完成后，它将重新启用写入filter，重新启动，然后用户可以再次login。 我遇到的问题是我们使用感应卡读卡器login系统。 员工不input密码。 他们只是挖掘他们的徽章。 这个系统很好，但运行它的软件打破了Windows Embedded的写入filter自动化。 这是实际发生的事情： 在重新启动写入filter之前，SCCM客户端通常会提供15分钟的通知。 重新启动时，会显示正常的login画面。 用户可以login系统并在SCCM安装软件时使用它。 而且由于用户会话处于活动状态，因此在重新启动写入筛选器之前，再次发出30分钟通知。 在这种情况下，它不仅增加了额外的30分钟的部署时间，而且还使普通用户在瘦客户机上保持30-60分钟的无保护时间，写入filter重新打开。 这个问题源于Windows Embedded 7使用与常规Windows 7不同的凭据提供程序（又名GINA），但SSO产品必须replaceWindows凭据提供程序才能正常工作。 我已经联系了这个供应商，但他们只是说这是一个已知的问题，没有修复或解决方法。 所以这是我的问题： 我怎样才能以另一种方式模拟所需的行为？ 我知道有一个组策略设置，您可以拒绝本地login到特定的用户组。 我以为我可以在安装前后翻转相应的registry设置，但我愿意接受其他的想法。 如果必须，我不在脚本安装之上。 我很stream利的脚本，PowerShell，VBScript等，我只是想知道如果有人有任何明智的想法如何解决这个问题。 更新： 我忽略了提及这些设备正在医院环境中用于工作人员对病人进行图表。 它们必须一天24小时提供，所以我们不能限制login时间或configuration维护窗口。 我们通过提前通知轮class主pipe来pipe理停机时间，但是超过一个小时的任何事情都会成为合法合规问题，并且需要执行官方停机时间程序。
所以这听起来像一个简单的问题，但在互联网上search我一直无法findSCCM客户端中的不同操作实际执行的列表。 在我的机器上，它被称为configurationpipe理器，我具体谈论的行动选项卡。 有人有每个行动的清单，他们做什么？ 我会发现在一个地方有一个参考，我可以指出一些技术人员也很有帮助。
它不时发生。 我更新了一个包，需要更新分发点。 我们有多个DP，通常一切都很好，但是每隔一段时间，我们的主DP就无法更新软件包。 内容状态日志从来没有说太多关于失败。 我没有后端服务器访问pipe理点，或DP，我只是SCCMpipe理员。 我可以检查SCCM中的任何日志，运行报告以及所有内容，但是我不知道在哪里查找。 在过去，我已经尝试在问题包中设置“Disconnect Users from Distribution Point”（分配点的用户断开连接）设置，这两个子设置都设置为0，但这对我们来说并不适用。 这个问题似乎在一段时间后自行消失，但有时需要几天的时间。 对于大多数（真的是所有的，但可能有一两个我忽略），我们设置客户端“从分发点运行程序”当部署该程序，不知道这是否有什么关系，或根原因是。 更新 我在报告中发现了更多信息，特别All Status Messages for a Specific Package at a Specific Site查询中All Status Messages for a Specific Package at a Specific Site的All Status Messages for a Specific Package at a Specific Site 。 使用我的软件包ID进行查询，DP更新再次失败后，我看到了一个突出的条目： 分发pipe理器无法处理程序包“configuration更新”（程序包ID = SOM00013）。 可能的原因 ：分发pipe理器无权访问软件包源目录或分发点。 解决scheme：validation分发pipe理器是否可以访问软件包源目录/分发点。 可能的原因 ：软件包源目录包含具有长文件名的文件，并且path的总长度超过操作系统支持的最大长度。 […]
我们注意到，我们的软件更新自动部署规则无法自动下载并应用本月的Microsoft补丁程序，尽pipe它们在目录中正确列出。 自动部署规则列出其最新的错误代码为0X87D20417和最后错误说明为“自动部署规则下载失败”。 手动重新运行规则会重现此错误。 删除并重新创build自动部署规则也会重现相同的错误。 查看SMS_RULE_ENGINE日志显示以下错误： Error Milestone 004 6/19/2013 3:42:21 PM SCCM.ad.example.com SMS_RULE_ENGINE 8706 Content download failed. Message: Failed to download one or more content files. Source: SMS Rule Engine. Error Milestone 004 6/19/2013 3:42:07 PM SCCM.ad.example.com SMS_RULE_ENGINE 8706 Content download failed. Message: Failed to download one or more content files. Source: SMS Rule Engine. […]
我是一所高中的IT技术人员，大约有1600名学生，250名员工和800多台客户端计算机，主要运行Windows 7.我们的团队由三名成员组成。 我的老板似乎满足于一个运行良好的networking，而且这个networking不一定是一个高效的维护良好的networking，易于运行和维护。 我在IT职业生涯中还处于早期阶段，所以我不能快速掌握所有可用的不同端点pipe理解决scheme。 我正在寻找更好的方式来pipe理客户（部署软件，跟踪更改，库存等）。我喜欢SCCM 2012的function，但案例研究似乎是针对大型多站点基础架构而不是单个中型站点。 SCCM适合中型单一场所还是针对大型企业？ 我如何确定像SCCM这样的端点pipe理解决scheme是否适合我们的组织？ 编辑：感谢所有的帮助，我会看看SCE和SCCM，并得到一些提案，以采取我的老板/副主席