Azure File Map Drive LocalSystem not persisting


  • Hi

    I have a number of 3rd party services on my Virtual machines (Windows Server 2012, based on the standard Azure image) running as local system that needs to access a shared file location, and I'm aiming to replace this with Azure File, now that's it's GA. We don't own the services code and can't get them rewritten to work with the Azure API
    I've tried a few tricks but the drive mapping isn't persisting for LocalSystem. What I'm having most success with (i.e works about 70% of the time) is a scheduledTask that runs on startup, but despite being configured to run 3 times if it fails, often does not. 

    I've followed the instructions in the blog post below, but although I can see the cmdkey has registed the credentials in the local system account, it makes no difference to the net use command.

    Anyone got any ideas? Thanks


    net use w: /delete
    net use w: <a href="file://\\\worksite">\\<myservicename>\worksite /u:<my servicename> <storage key> /persistent:yes

    $TaskName = "Map Azure Drive"
    $Tasktrigger = New-ScheduledTaskTrigger -AtStartup -RandomDelay (New-TimeSpan -Seconds 30)
    # The Task Action command argument
    $TaskArg = "" #"-WindowStyle Hidden -NonInteractive -Executionpolicy unrestricted -file $TaskScript"
    $TaskCommand = "C:\Packages\mapAzureDrive.bat"
    $TaskAction = New-ScheduledTaskAction -Execute "$TaskCommand" #-Argument "$TaskArg"
    $TaskSettings = New-ScheduledTaskSettingsSet –AllowStartIfOnBatteries –DontStopIfGoingOnBatteries  -ExecutionTimeLimit (New-TimeSpan -Minutes 5) -RestartCount 3 #actually the restart count doesn't apply, have to set it manually in the Gui
    Register-ScheduledTask -Action $TaskAction -Trigger $Tasktrigger -TaskName "$TaskName" -Settings $TaskSettings -User "System" -RunLevel Highest

    Wednesday, October 21, 2015 10:13 AM

All replies

  • Hi,
    Thanks for posting here.

    We are looking into this and will revert to you at the earliest.

    Girish Prajwal

    Wednesday, October 21, 2015 7:29 PM
  • Hi Richard,

    I had a windows service that needed to access an Azure File Share. The service ran under the LOCAL SYSTEM account, and I tried what you're trying, and it wouldn't mount the drive and retain the credentials.

    If you go back and look at that article again, there's a spot where it mentions "context". It doesn't really make a big deal out of it, but it IS a big deal. Each context has its own set of credentials and file shares. For example, I tried the following three cases with my windows service and found they each required their own mount and their own credentials:

    o User account with regular privileges.

    o User account with administrative privileges.

    o User account running as a windows service.

    For me, the question was how do I set the credentials for a user account running as a windows service?

    I ended up adding code to the service to mount the share programmatically (using the code included in the article) when the service started up. Then I found it didn't matter if I set up the credentials and mount beforehand. Since you don't have the code, this isn't something you can do. (Could you write a small exe that does this and call it before starting the service?)

    I could never get the LOCAL SYSTEM to store the credentials because I couldn't figure out how to log in as LOCAL SYSTEM.

    What I didn't try was running the windows service under the user account, and setting up the credentials for the user account running admin privileges. It makes sense (now that I think of it) that a windows service probably runs with admin privileges. So rather than run those services under LOCAL SYSTEM, could you try setting up a user with admin privileges and running the service under that user. Then you can try logging into the VM with Remote Desktop, open a command window with admin privileges, and save the credentials and mount the drive, and THEN see if your service works?

    Good luck,


    Wednesday, October 21, 2015 10:30 PM
  • Thanks The scheduled task is running as local system, and I'm using SysInternals (never leave home without it) PSExec to verify the drive is mapped for the local system context. It reconnects most of the time, so the principle works, but this occasional failure is not meeting my SLA :-) (the error I get in Task scheduler is 0x2, not been able to get a more helpful message) I'm deliberately avoiding setting up a separate service account as this adds a password maintainance overhead, and in domain environments running as local system helps with keboros pass though authentication for this service. I'm also running the service on multiple servers in non domain environments, so local accounts is a further overhead I could do without. Thanks
    Thursday, October 22, 2015 11:17 AM
  • I encounter the same issue, while using Azure file share and try to access it with windows service. Here is how I am able to resolve it (thought i am still looking for to access azure file share using Windows Service Local Service or Local System account) 

    I created a local user on that VM

    I store credentials using cmdkey through power shall 

    I run the service to run as that user instead using Local System/Service Account

    If anyone still know how can i use Local Service account for it, please DO let me know

    Wednesday, March 8, 2017 8:53 AM