It is my understanding that Windows services now run in a substantially different environment from login sessions, especially on Vista® where they (for instance) no longer have any direct access to the console.

It is therefore entirely possible – would not surprise me in the slightest – if “drive letter mapping” did not exist at all. Services are now intentionally placed “more than an arm's length away from” the world of interactive users and from anything that those users might be able to control or influence. (After all these years, Microsoft finally got the message!)

There are many reasons to prefer UNCs. A UNC-path is self describing, whereas a path that uses a “mapped drive letter” is dependent on something that it neither specifies nor controls:   that the drive-letter is not only mapped, but mapped “correctly.” (Whatever that means.)

Finally, pay very careful attention to the user-id under which the service runs. It should be (in my opinion) a dedicated user-id, chosen for the purpose, which does not allow direct logins but which can only be used by a service. Naturally, that user must have the right to have (read-only) access to the appropriate UNC share.

(Again for “hacker prevention” reasons, that service-userid should not have read/write access to that share: what it does not require, it should not have, nor be able (by any means whatsoever) to get.

Thanks for the help. this is most likely the reason I am having this problem. I have the service set up to run as the user with read/write access to the share/drive.

I also understand that the UNC path has it's merits. My problem is that we use a lot of different automated jobs here, and the IT/Server people occassionall move things around. If I use drive letters in the code then I don't have to change every script running on a given server every time a share is moved to a new machine or changed. I just need to change the mapped drive. I suppose I will just need to mark down this special case and make sure someone remembers it next time the server changes. thanks

For example, the per-user environment variables aren't set. I assume the same is true of drive mappings for that user.

You might have luck executing a "NET USE" from your script prior to accessing the drive letter, but that's really no different from using the UNC path directly.

There may be an invocation which allows services to see this sort of setting - perhaps someone else could chime in if so.

Actually, unless nothing else has been specified, the service will run as the system user, and the system user does not even have the permissions to access network resources, be they mapped or unmapped.

The solution is usually to run the service as another user than the default.

I've faced a similar issue. The above posters are probably right in that the mapped drive doesn't exist. In fact, even if you have a mapped drive in your default profile, you are currently logged in as that user, starting the service as that user, and have the service configured to run as that user, it still won't work. One solution I've used is to create a scheduled task like so:

at 17:40 /interactive net use L: \\servername\sharename /u:mydomain\my
+user
[download]

You can also add a check for this in your Perl code:

unless { -d 'L:\' } { write_to_log_and_die(); }
[download]