我们在Windows 7 / Server 2008 R2域环境中。 我们有一个.NET应用程序，其中包含许多用于不同UI和其他function的内部库。 我们使用最新版本号为每个“版本”创build一个目录的共享部署它。 有时候，有些部门需要根据自己的具体需求对应用程序进行一些调整，在下一个版本之前，他们需要紧急更改。 我们可以通过给他们一些自定义的DLL文件来做到这一点。 我试图devise出让我们的客户端机器自动检查并复制这些“自定义”文件的最可靠和有效的方式。 我想以最有效率，最可靠，集中pipe理的方式来完成这个任务，并且在客户端开销最less。 最好在我们有自定义文件部署的时候，我们希望所有的客户端在把它们放在共享上之后的24小时内复制它们。 他们将进入当前的networking版本目录的子文件夹，名为“自定义”或类似的东西。 我们目前没有SCCM，所以我正在看下面的选项：
batch filelogin脚本的用户将检查networking目录并抄下（覆盖）本地文件使用robocopy或xcopy。 这将要求用户注销并重新打开，所以可能会延迟获取任何自定义文件。 用户将有一个简单的，可靠的方式来触发它，这将是一个加号。
计划任务通过组策略首选项configuration，以检查任何自定义文件可能每天几次的networking目录。 这可能比用户login脚本更快得到文件，但我没有使用GPP计划任务项目的经验。 安装和维护是否可靠和简单？ 同样，这个任务将运行批处理脚本来检查networking上的文件，并使用/ xo选项启动robocopy。 如果我们将任何文件放在自定义目录中，我们将假定它们是需要的，不pipe版本是什么。 简单地检查文件date应该是有效的，所以一旦它们到位，它们就不会被一遍又一遍地复制。
计划任务与上述相同，但基于事件日志条目进行触发。 这可靠吗？ 我从来没有尝试过。 find一个表示应用程序刚刚启动（或closures）的事件触发器，然后立即复制这些文件，这样用户工作中断的可能性就会降低。
我知道还有一个用于pipe理/复制文件的组策略首选项。 我认为在这种情况下pipe理将会是太多工作，因为在多个版本的应用程序中，一次可能存在多个文件。
我还考虑过一个Powershell脚本，它可以做比较实际的DLL文件版本等有趣的事情，但是这可能需要更多的资源开销（运行速度较慢），而且确实做得比需要的多。
任何其他的想法可能是最好的？ 最简单的答案（用户login脚本）真的是最好的吗？
我结束了select＃1，一个用户login脚本，这一直工作可靠一段时间了。 我会在这里发布整个脚本，但是它充满了内部应用程序的细节，这使得它在大多数情况下是无用的。 最有趣的细节是我们使用wmic来获取本地安装的应用程序的内部版本号，并使用它来在我们的部署服务器上引用正确的版本目录。 此代码设置名为Version的variables以匹配从wmic.exe返回的值
set "myfile=c:\\progra~2\\%AppFolder%\\AppName.exe" for /f "tokens=*" %%f in ('wmic datafile where "name='%myfile%'" get version /value ^| findstr "="') do set "%%f"