我还不能评论(在声誉方面)，但创建了一个帐户，只是为了回答@Tech Jerk @spankmaster79(好名字lol)和@NMC问题，他们在回复“我发现了一个解决方案，与psexec类似，但不需要额外的工具，并在重启后幸存。”

解决方案是在登录帐户中浏览到该文件夹，即:

    \\servername\share  

并让它提示登录，并输入您在psexec中用于UNC的相同凭据。之后就开始工作了。在我的例子中，我认为这是因为提供服务的服务器与我要映射到的服务器不属于同一个域。我在想，如果UNC和计划任务都是指IP而不是主机名

    \\123.456.789.012\share 

它可能会完全避免这个问题。

如果我曾经得到足够的代表点在这里，我会把这作为一个回复。

The reason why you are able to access the drive in when you normally run the executable from command prompt is that when u are executing it as normal exe you are running that application in the User account from which you have logged on . And that user has the privileges to access the network. But , when you install the executable as a service , by default if you see in the task manage it runs under 'SYSTEM' account . And you might be knowing that the 'SYSTEM' doesn't have rights to access network resources.

这个问题有两种解决方案。

To map the drive as persistent as already pointed above. There is one more approach that can be followed. If you open the service manager by typing in the 'services.msc'you can go to your service and in the properties of your service there is a logOn tab where you can specify the account as any other account than 'System' you can either start service from your own logged on user account or through 'Network Service'. When you do this .. the service can access any network component and drive even if they are not persistent also. To achieve this programmatically you can look into 'CreateService' function at http://msdn.microsoft.com/en-us/library/ms682450(v=vs.85).aspx and can set the parameter 'lpServiceStartName ' to 'NT AUTHORITY\NetworkService'. This will start your service under 'Network Service' account and then you are done. You can also try by making the service as interactive by specifying SERVICE_INTERACTIVE_PROCESS in the servicetype parameter flag of your CreateService() function but this will be limited only till XP as Vista and 7 donot support this feature.

希望这些解决方案对你有帮助。如果这对你有用，请告诉我。

我还不能评论(在声誉方面)，但创建了一个帐户，只是为了回答@Tech Jerk @spankmaster79(好名字lol)和@NMC问题，他们在回复“我发现了一个解决方案，与psexec类似，但不需要额外的工具，并在重启后幸存。”

解决方案是在登录帐户中浏览到该文件夹，即:

    \\servername\share  

并让它提示登录，并输入您在psexec中用于UNC的相同凭据。之后就开始工作了。在我的例子中，我认为这是因为提供服务的服务器与我要映射到的服务器不属于同一个域。我在想，如果UNC和计划任务都是指IP而不是主机名

    \\123.456.789.012\share 

它可能会完全避免这个问题。

如果我曾经得到足够的代表点在这里，我会把这作为一个回复。

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

例如，你可以使用符号链接。

mklink /D C:\myLink \\127.0.0.1\c$

更好的方法是使用mklink.exe使用符号链接。你可以在文件系统中创建一个任何应用程序都可以使用的链接。见http://en.wikipedia.org/wiki/NTFS_symbolic_link。

您要么需要修改服务，要么将其包装到辅助进程中:除了会话/驱动器访问问题外，持久驱动器映射仅在交互式登录时恢复，而服务通常不会执行。

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

The helper service will need to pass on all appropriate SCM commands (start/stop, etc.) to the real service. If the real service accepts custom SCM commands, remember to pass those on as well (I don't expect a service that considers UNC paths exotic to use such commands, though...) Things may get a bit tricky credential-wise. If the real service runs under a normal user account, you can run the helper service under that account as well, and all should be OK as long as the account has appropriate access to the network share. If the real service will only work when run as LOCALSYSTEM or somesuch, things get more interesting, as it either won't be able to 'see' the network drive at all, or require some credential juggling to get things to work.