Back to top

Windows Service using mapped network drive

Windows Service using mapped network drive

Today I ran in to a situation, a small hump in the highway that is my life at the moment, moving my entire development environment to Mac, running Windows on Parallels for my .NET development (as I eagerly await vNext and the hopeful transition for me to doing it all (?!) on the Mac.

The situation is that when running Parallels, your home directory on the Windows machine is actually a mapped network drive (in my case, to v:) back to \psfhome, and when installing a Windows Service for a program that sits on that mapped drive (for me it was under the Documents\Visual Studio 2013\Projects\etc location), it will fail with the following error:

The system cannot find the path specified

The issue is that a Windows Service runs by default under the local SYSTEM account, which doesn’t “know” that network drive, as network drives do not exist across login contexts, so you need to get a drive mapped for it before the service will run. Even running as your own account won’t work, as the service will actually run under a separate login context to your own “current” login.

Microsoft actually tell us that you shouldn’t access local or network resources through mapped drive letters. The reasons for this, as per their page, are:

  • Drive mappings exist across logon contexts, so if an application is running in the context of the LocalService account, then any other service running in that context may have access to the mapped drive.
  • If the service provides explicit credentials to a net use command, those credentials might be inadvertently shared outside of the service boundaries. Instead, the service should use client impersonation to impersonate the user.
  • Multiple services running in the same context may interfere with each other. If both services perform an explicit net use and provide the same credentials at the same time, one service will fail with an “already connected” error.

This is kind of my disclaimer - if you still feel that you must have this mapped drive in order for your service to work (for example, I think it’s kind of unavoidable in my situation, when your whole home directory is running as a mapped drive), then proceed, but with caution that it may be a slippery slope. So far so good for me.

The solution is sneaky and simple… using a scheduled task to set up a persistent mapped drive for the SYSTEM user:

  1. Create a batch file that creates the network drive: 
     net use v: \servernamesharedfolder /persistent:yes

    e.g.

     net use v: \psfHome /persistent:yes
  2. Save the batch file (e.g. “map-home.bat”) somewhere.
  3. Create a new Scheduled Task which runs that file as a Once Off for any time, and change the user to run it as to “SYSTEM”.
  4. Save the new task and either wait for it to run or right-click on it and click “Run” to run it immediately.
  5. Now you should be able to start the service.
  6. What this process has done is set up a persistent network drive mapping for the SYSTEM user.

I would not recommend using this to allow access to mapped network drives for access during the general running of the service (based on Microsoft’s reasonings above). However in this case of having a network drive mapped for your home directory (e.g. in my case when running Parallels), it seems like a safe and viable solution, and I don’t expect any program to ever utilise this V: drive for anything BUT the home directory that Parallels has set up for me.

Hope it helps!