Lab Automation: Working around issues with New-PSDrive and vimDatastore provider

I’ve long suffered issues with random failures of the New-PSDrive command in our lab automation when attempting to mount datastores to either query or upload content.

For example, running this command

New-PSDrive -Location $DatastoreObject -Name DS -PSProvider VimDatastore -Root "\" > $null

Will work fine over and over, but occasionally will result in an error something like this

A parameter cannot be found that matches parameter name 'Location'.

While searching the web for a resolution I saw several other threads where folks were getting slightly different errors, such as this one:

New-PSDrive : Cannot find drive. A drive with the name 'vmstores' does not exist.

The only solution I could find was to close the PowerShell window, open a new one, and try again. That always worked, until eventually that same shell would fail again. Part of the problem was in reproducing the issue as it seems so random. The same PowerShell function run over and over was fine. Until it wasn’t 😞. Recently, I had it happen to me and decided enough was enough. I wasn’t closing that shell until I found a solution!

Digging in, I noticed a pattern. When you run a command like this in a new shell

Get-PSDrive | Select Name,Provider

You get output something like this

However, if you run the same command immediately after a Connect-VIServer, your output will look something like this

Notice how we have automatically created PSDrives of type VimDatastore. As I played around further in my broken shell, I noticed that the auto-created entries were missing!

I’ve always used New-PSDrive when mounting datastores, but it turns out you can also use these auto-mounted ones directly, as long as you know the Datacenter name, as the path will look something like vmstore://datacenter/datastore/folder

But, regardless of which way you prefer, it seems that both methods inherently rely on the presence of the auto-mounted PSDrives.

At first, I thought that since the Connect-VIServer is what seemed to create them, that re-running it would solve the issue. Not that simple I’m afraid, it did nothing for me.

Then I remembered that in a a new shell, Connect-VIServer is not actually the first thing that happens. When you run that command, PowerShell automatically imports the relevant module first. So in my broken shell I tried this:

Remove-Module VMware.VimAutomation.Core -force -confirm:$false
Import-Module VMware.VimAutomation.Core

And voila, my auto-mounted VimDatastore PSDrives were restored, and I was able to successfully run a New-PSDrive command without issue!

So now, anytime I am about to run a New-PSDrive with a provider of vimDatastore in my script, I run the above two lines first. It doesn’t seem to break anything else, and there is no need to run Connect-ViServer again either.

I haven’t encountered the error since but time will tell if that’s just luck or if this is truly a valid workaround. This fix also seems to correct the issues I saw in those parallel threads where users were getting errors to the effect of ‘vmstores’ being missing, or where you are attempting to use the vmstore/vmstores directly rather than using a New-PSDrive. Using the vmstores directly feels like a more elegant method to interact with datastores, so I might refactor my scripts in time – you just need to know (or discover) which vSphere Datacenter the datastore is in.

Hope this helps folks. Its certainly helped my OCD.