映射要由服务使用的networking驱动器

假设某些Windows服务使用希望映射networking驱动器的代码,并且不使用UNCpath。 服务启动时,如何使驱动器映射可用于服务的会话? 作为服务用户login并创build持久映射不会在实际服务的上下文中build立映射。

您需要修改该服务,或者将其包装在帮助程序中:除了会话/驱动器访问问题,持久性驱动器映射只能在交互式login中恢复,而这些服务通常不会执行。

辅助进程的方法可以非常简单:只需创build一个映射驱动器并启动“真实”服务的新服务。 唯一不是完全无关紧要的事情是:

  • 帮助服务将需要将所有适当的SCM命令(启动/停止等)传递给实际的服务。 如果真正的服务接受自定义的SCM命令,记得也要传递这些(我不认为一个服务,认为UNCpath异国情调使用这样的命令,虽然…)

  • 事情可能会有点棘手凭证。 如果真实的服务运行在一个普通的用户帐户下,那么你也可以在该帐户下运行助手服务,只要该帐户具有适当的networking共享访问权限,所有应该都可以。 如果真正的服务只能以LOCALSYSTEM或者其他方式运行,那么事情就会变得更加有趣,因为它根本无法“看到”networking驱动器,或者需要一些凭证来扭转局面。

使用这个需要您自担风险。 (我已经在XP和Server 2008 x64 R2上testing过了)

对于这个黑客,你将需要Mark Russinovich的SysinternalsSuite :

第一步:打开提升的cmd.exe提示符(以pipe理员身份运行)

第二步:使用PSExec.exe再次提升到根目录:导航到包含SysinternalsSuite的文件夹,然后执行以下命令: psexec -i -s cmd.exe您现在位于nt authority\system的提示符内,您可以通过打字whoami-i是需要的,因为驱动器映射需要与用户交互

第三步: net use z: \\servername\sharedfolder /persistent:yes以下命令创build永久映射的驱动器作为SYSTEM帐户net use z: \\servername\sharedfolder /persistent:yes

就这么简单!

警告 :只能从SYSTEM帐户中删除此映射,方法与创build该映射的方式相同。 如果需要删除它,请执行步骤1和2,但将步骤3中的命令更改为net use z: /delete

:新创build的映射驱动器现在将显示给该系统的所有用户,但他们将看到它显示为“Disconnected Network Drive(Z :)”。 不要让这个名字欺骗你。 它可能声称是断开连接,但它将为大家工作。 这就是你可以告诉这个黑客不被M $支持。

我发现了一个类似于psexec的解决scheme,但是没有额外的工具,并在重新启动后仍然存在

只需添加一个sheduled任务,在“run as”字段中插入“system”,并用简单的命令将任务指向一个batch file

 net use z: \servername\sharedfolder /persistent:yes 

然后select“在系统启动时运行”(或类似的,我没有英文版本),你就完成了。

更好的方法是使用mklink.exe的符号链接。 您可以在文件系统中创build任何应用程序都可以使用的链接。 请参阅http://en.wikipedia.org/wiki/NTFS_symbolic_link

你可以使用'net use'命令:

 var p = System.Diagnostics.Process.Start("net.exe", "use K: \\\\Server\\path"); var isCompleted = p.WaitForExit(5000); 

如果在服务中不起作用,请尝试Winapi和PInvoke WNetAddConnection2

编辑:显然我误解了你 – 你不能改变服务的源代码,对不对? 在这种情况下,我会按照mdb的build议,但有一点麻烦:创build您自己的服务(让我们称之为映射服务)映射驱动器,并将此映射服务添加到第一个(实际工作)服务的依赖项。 这样,在映射服务开始之前,工作服务不会启动(并映射驱动器)。

这里有一个很好的答案: https : //superuser.com/a/651015/299678

也就是说,您可以使用符号链接,例如

 mklink /DC:\myLink \\127.0.0.1\c$ 

ForcePush,

:新创build的映射驱动器现在将显示给该系统的所有用户,但他们将看到它显示为“Disconnected Network Drive(Z :)”。 不要让这个名字欺骗你。 它可能声称是断开连接,但它将为大家工作。 这就是你可以告诉这个黑客不被M $支持…

这一切都取决于共享权限。 如果您拥有共享权限中的所有人,则此映射的驱动器将可由其他用户访问。 但是,如果只有一些特定用户在批处理脚本中使用了其凭据,并且此批处理脚本已添加到启动脚本中,则只有系统帐户才能访问该共享,甚至不能访问pipe理员。 因此,如果您使用例如计划的ntbackuo作业,则系统帐户必须在“运行方式”中使用。 如果您的服务的“login为:本地系统帐户”它应该工作。

我做了什么 ,我没有在启动脚本中映射任何驱动器号,只是使用net use \\\server\share ...并在我的预定作业中使用了UNCpath。 添加一个login脚本(或者只是将一个batch file添加到启动文件夹)映射到与一些驱动器号相同的共享: net use Z: \\\...具有相同的凭据。 现在login的用户可以看到并访问映射的驱动器。 有2个连接到相同的份额。 在这种情况下,用户不会看到烦人的“断开的networking驱动器…”。 但是,如果您确实需要通过驱动器号访问该共享,而不是UNC,请将该共享映射到不同的驱动器号,例如对于System的Y和对用户的Z。

find了将Windows服务访问权授予networking驱动器的方法。

以Windows Server 2012和NFS Disk为例:

第1步:写一个batch file挂载。

写一个batch file,例如:C:\ mount_nfs.bat

 echo %time% >> c:\mount_nfs_log.txt net use Z: \\{your ip}\{netdisk folder}\ >> C:\mount_nfs_log.txt 2>&1 

步骤2:将磁盘挂载为NT AUTHORITY / SYSTEM。

打开“任务计划程序”,创build一个新任务:

  1. 在“系统启动”中以“SYSTEM”身份运行。
  2. 创build操作:运行“C:\ mount_nfs.bat”。

经过这两个简单的步骤,我的Windows ActiveMQ服务在“本地系统”特权下运行,无需login即可完美运行。

当你正常运行可执行文件的命令提示符时,你能够访问驱动器的原因是,当你正常执行exe文件时,你正在从你login的用户帐户中运行该应用程序。 该用户有权访问networking。 但是,当您将可执行文件作为服务安装时,默认情况下,如果您在任务pipe理器中看到它,则以“SYSTEM”帐户运行。 你可能知道'SYSTEM'没有访问networking资源的权限。

这个问题可以有两个解决scheme。

  1. 如上所述,将驱动器映射为持久性。

  2. 还有一种方法可以遵循。 如果您通过input“services.msc”打开服务pipe理器,您可以访问您的服务并在服务的属性中有一个login选项卡,您可以在其中指定帐户作为除“系统”之外的任何其他帐户从您自己的login用户帐户或通过“networking服务”启动服务。 当你这样做的时候,服务可以访问任何networking组件,即使它们也不是永久的。 要以编程方式实现此目的,可以查看http://msdn.microsoft.com/zh-cn/library/ms682450(v=vs.85).aspx中的 “CreateService”函数,并可将参数“lpServiceStartName”设置为“NT AUTHORITY \networking服务”。 这将在“networking服务”帐户下启动您的服务,然后完成。

  3. 你也可以尝试通过在你的CreateService()函数的Servicetype参数标志中指定SERVICE_INTERACTIVE_PROCESS来交互服务,但是这只会被限制到XP,因为Vista和7不支持这个特性。

希望解决scheme可以帮助你。让我知道这是否适合你。

你不能改变服务在“系统”下运行的用户,或者find一个偷偷摸摸的方式来运行你的映射为系统。

有趣的是,这是可以通过使用“at”命令,只需将您的驱动器映射到未来一分钟,它将在系统帐户下运行,使驱动器可见您的服务。

我发现了一个非常酷的方式来获得UNC在代码项目的Windows服务工作的凭据。

见阿德里安·海斯的post: http : //www.codeproject.com/Articles/43091/Connect-to-a-UNC-Path-with-Credentials

他的解决scheme是一种享受。

我还不能评论(在声誉上),但创build一个帐户只是为了回答@Tech Jerk @ spankmaster79(好名字哈哈)和@NMC问题,他们报告在回复“我find了一个类似的解决schemepsexec,但没有额外的工具,并幸存重启。“ @Larry发了post。

解决这个问题的方法是从login帐户中浏览该文件夹,即:

  \\servername\share 

并让它提示login,然后在psexec中input用于UNC的相同凭据。 之后开始工作。 在我的情况下,我认为这是因为具有该服务的服务器不是我映射到的服务器所在域的成员。 我想如果UNC和计划的任务都提到IP而不是主机名

  \\123.456.789.012\share 

它可以完全避免这个问题。

如果我在这里获得了足够的代表点,我会将其添加为答复。