设想：
我在 Azure 中有一个 Windows 2012R2 VM。我已在 Azure 存储帐户中创建了 Azure FileShare。
我需要在我的虚拟机上创建一个映射网络驱动器，以使我的 FileShare 可供以“本地系统”用户身份运行的 Windows 服务使用。
迄今为止：
我已设法使用以下文章为我的 Azure FileShare 创建持久映射网络驱动器。
运行正常，并且确实在操作系统重启后仍然可用。一旦操作系统“完全关闭并重新启动”，映射驱动器确实会显示给所有用户，并且连接正常。
我的问题是，我还有一个 Azure 自动化任务，用于每晚停止我的虚拟机（已释放），以节省成本。这是因为这些特定的虚拟机是开发人员测试机器，仅在白天使用。
当我使用 Stop-AzureRmVm 停止我的 VM 时，当我再次启动 VM 时，我的网络驱动器不再映射到我的 Azure FileShare，因为它甚至不再作为驱动器出现。
我只能假设这是由于 Azure 在操作系统关闭并启动或重新启动时释放了其资源，从而使驱动器保持正常。
有人能给我提供一些关于如何在 Azure VM 关闭电源的情况下生存的建议，或者建议解决此问题的其他方法吗？
答案1
我找到了解决方案...
我发现，通过 Azure 关闭电源，添加到 cmdkey 的凭据已经保留下来，只有映射网络驱动器消失了。
我没有坚持要求我的服务通过映射网络驱动器号连接到 Azure 文件共享，而是更改了代码以通过其 UNC 地址访问文件共享。
\\storageaccount.file.core.windows.net\MyFileShare
将凭据添加到 cmdkey 存储后，我在浏览此 UNC（包括我的服务）时无需重新进行身份验证。
我只需要确保使用 PsExec 以 SYSTEM 用户身份添加了 cmdkey 凭据。
编辑于 2016 年 9 月 5 日 - Jon Hoare
事实上，使用 cmdkey 来保留凭据仍然对我没有帮助，因为我的 LocalSystem 用户仍然无法使用这些凭据，即使我在 LocalSystem 用户的上下文中添加了它们。
我所做的实际上是在本地计算机上创建了一个“影子”本地用户帐户。此用户拥有我的 StorageAccount 的用户名，并且我已将密码设置为我的 StorageAccount 的主访问密钥。
然后将我的 Windows 服务设置为以此本地用户身份运行，现在当它尝试连接到 UNC 并传递其帐户凭据时，它们与 Azure 的要求相匹配并授予身份验证。
我希望这能帮助那些像我一样陷入困境的人。