我们有一个共享的Windows服务器上的文件夹，以提供访问重要的应用程序。 当应用程序正在更新时，我们（DBA）更改共享上的权限以拒绝对其进行的所有访问，然后断开共享上打开的任何文件。 在完成应用程序更新（对同一个文件使用不同的共享）之后，我们重新启用对共享的访问。
我们修改共享的方式是使用MSpipe理控制台远程连接到服务器。 显然，这个function需要pipe理员在服务器上访问，或者至less需要基础设施团队想要拿走的某种级别的权限。
问题是，如何处理应用程序更新的DBA禁用和启用访问权限在服务器上尽可能less的权限？
一种可能性，虽然它需要编程，但是可以编写一个系统服务（因此具有所有必需的特权，并设置为手动启动），并赋予特定组启动和停止该服务的权限（这很简单，参见如何将服务的启动/停止/重新启动权限授予非域成员服务器上的任意用户或组？可以使用Service Security Editor或Process Hacker来编辑ACL）。
用户根本不需要任何特权：服务将在启动时执行所需的断开/共享更改，并在停止时恢复到正常configuration。 当您的应用程序必须更新时，执行此操作的用户只需在更新之前启动服务，然后再停止。 顺便说一下，这种解决scheme被某些软件所使用，例如，让每个人都可以更新它（例如，参见Mozilla维护服务 ）。
您可以将共享权限设置为Active Directory组，然后让基础架构团队为您授予该组的授权。 当您需要拒绝访问时，只需编辑组成员资格。 完成后，还原组成员资格。
此解决scheme不需要任何pipe理访问权限，并且比每次编辑共享权限要快得多。
你可以：
D:\additionalFolder\yourfolder ，为DBA团队分享additionalFolder ，和您的文件yourfolder作为当前的份额。 我们正在考虑的选项是让计划任务执行活动，然后使用某种事件触发计划任务运行。 这个解决scheme的问题是，我们不知道发送一个事件的方式，可以导致触发器没有给予比他们需要更广泛的权限触发。