场景：
我在Azure中有一个Windows 2012R2虚拟机。 我在Azure存储帐户中创build了一个Azure FileShare。
我需要在我的虚拟机上创build映射networking驱动器，使我的文件共享可以作为“本地系统”用户运行的Windows服务。
至今：
我已经设法使用下面的文章创build一个持久映射networking驱动器到我的Azure文件共享。
https://blogs.msdn.microsoft.com/windowsazurestorage/2014/05/26/persisting-connections-to-microsoft-azure-files/
这工作正常，并确实幸存OS重新启动。 一旦操作系统“干净地closures并再次启动”，映射驱动器确实出现在所有用户和连接正常。
我的问题是，我也有一个Azure自动化任务来停止我的虚拟机（释放）每晚，以节省成本。 这是由于这些特定的VM是开发人员testing机器，这些机器仅在白天使用。
当我使用Stop-AzureRmVm停止虚拟机时，当我再次启动虚拟机时，networking驱动器不再映射到Azure FileShare，因为它甚至不再显示为驱动器。
我只能假设这是由于Azure将其资源解除分配作为操作系统closures和启动或重新启动，保持驱动器正常。
任何人都可以给我任何build议幸存的Azure虚拟机关机的情况下，或build议解决这个问题的另一种方式？
我find了一个解决scheme…
我发现添加到cmdkey的证书已经通过Azure Power Off持续存在，只有映射的networking驱动器正在消失。
而不是坚持我的服务通过映射networking驱动器号连接到Azure文件共享，我改变了代码访问文件共享的UNC地址。
\\storageaccount.file.core.windows.net\MyFileShare
凭借添加到cmdkey存储的凭据，我从来没有要求浏览此UNC时重新进行身份validation，包括我的服务。
我只需确保使用PsExec作为SYSTEM用户添加了cmdkey凭据。
编辑09/05/2016 – Jon Hoare
事实上，使用cmdkey来保存证书仍然没有帮助我，因为我的LocalSystem用户仍然无法使用这些证书，即使我将它们添加到LocalSystem用户的上下文中。
我所做的实际上是在本地机器上创build了一个“Shadow”LocalUser帐户。 此用户具有我的StorageAccount的用户名，我已将密码设置为我的StorageAccount的主AccessKey。
然后，将我的Windows服务设置为以本地用户身份运行，现在，当它尝试连接到UNC并通过其帐户凭据时，它们将匹配Azure所要求的身份validation并授予身份validation。
我希望这能帮助像我一样被卡住的其他人。