Create a Persistent Network Drive on an Azure VM to survive "Azure Stopped (Deallocated)" PowerOff

Question

Scenario:

I have a Windows 2012R2 VM in Azure. I have created an Azure FileShare in my Azure Storage Account.

I need to create a Mapped Network Drive on my VM which makes my FileShare available to a Windows Service that is running as the "Local System" User.

So far:

I have managed to use the following article to create a Persistent Mapped Network Drive to my Azure FileShare.

https://blogs.msdn.microsoft.com/windowsazurestorage/2014/05/26/persisting-connections-to-microsoft-azure-files/

This works ok, and does indeed survive OS restarts. As soon as the OS has "Cleanly shutdown and started again", the Mapped Drive does indeed appear for all Users and connects fine.

My issue is, that I also have an Azure Automation Task to Stop my VMs (Deallocated) every night, to save on costs. This is due to these particular VM's being developer test machines which are only used during the day.

When I Stop my VM's using Stop-AzureRmVm, when I start the VM again, my Network Drive is no longer mapped to my Azure FileShare, as in it does not even appear as a drive anymore.

I can only assume it is due to having its resources deallocated by Azure as an OS shutdown and start or restart, keeps the drive ok.

Can anyone give me any suggestions for surviving an Azure VM Power Off scenario, or suggest another way of tackling this issue?

Answer 1

I have found a solution...

I found that the credentials added to cmdkey had been persisted, through the Azure Power Off, and it was only the Mapped Network Drive that was disappearing.

Instead of insisting on my Service to connect to the Azure FileShare by a Mapped Network Drive Letter, I have changed the code to access the fileshare by its UNC address instead.

\\storageaccount.file.core.windows.net\MyFileShare

With the credentials added to the cmdkey store, I am never asked to reauthenticate when browsing this UNC, including my Service.

I just had to make sure that the cmdkey credentials were added using PsExec as the SYSTEM user.

Edited 09/05/2016 - Jon Hoare

Infact using cmdkey to persist the Credentials still didn't help me as my LocalSystem user was still unable to use these credentials, even though I added them in the context of the LocalSystem user.

What I have done is actually created a "Shadow" LocalUser account on my local machine. This user has the username of my StorageAccount and I have set the password to be the Primary AccessKey for my StorageAccount.

My Windows Service is then set to run as this Local User, and now when it tries to connect to the UNC, and it passes through its account credentials, they match what Azure requires and authentication is granted.

I hope this helps someone else who is stuck like I have been.