Issues Executing NetApp PS Toolkit Cmdlets from SRM 4.1

Hello All,

I wrote a script that leverages the NetApp PowerShell Toolkit to mount LUNs that are directly attached to VM Guests that are Protected with SRM. I am executing the script using the Post Power-On execution feature of a SRM Recovery Plan but the script doesn't seem to execute the NetApp PowerShell commandlets. I started off by first loading hte modules at the top of the script and next I attempted loading the module as part of the PowerShell profile for the user that is running SRM.

When I execute the command from the SRM host as the user that the SRM process is run as the script works like a charm but it doesn't seem to work from within SRM.

Has anyone had a similar issue?

Re: Issues Executing NetApp PS Toolkit Cmdlets from SRM 4.1

First thing first, is the script running at all?  Assuming it is but isn't working, you need to isolate where the script is failing.  A quick way to do so is to make all cmdlets stop on error, by adding -EA Stop, and then wrap the whole scriptblock in a try catch.  Try the script attached...  It could be a number of things causing the error.

If it's not running, what cmd did you add into SRM?

Very Nice use of the Toolkit in a DR plan BTW!!!


Re: Issues Executing NetApp PS Toolkit Cmdlets from SRM 4.1

Hi Glenn,

Thanks for the positive comment, I take pride in making elaborate scripts :-)

First thing first, I have verified that the script runs, cause I can execute the script manually from a powershell prompt from the SRM "Recovery Node" Host while logged in as the user that the SRM process is running as. I've gone the extra step to even load the NetApp module in all powershell environments for this user by modifying the powershell $profile and adding "import-module DataOnTAP" unfortunately that still doesn't load the NetApp PS cmdlets when run via the Post PowerOn process.

From the extra logging that I've placed into the script and from the SRM execution logs I believe that the Netapp powershell commandlets aren't loading which causes the meat of the script to not function. I usually rely on logs to troubleshoot, unfortunately I do not see anything in the logs that I produce that show the "Import-Module DataOnTap" command failing. But I will test the "-EA" after the "Import-Module DataONTAP" to see if that produces any useful logs to see if that is what is causing my script to fail.

To answer you other question, I use the following syntax to run the script as a post Power-On recovery step.

   C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe C:\WINDOWS\SRM\script.ps1

Thanks for the suggestion as I'm quite stumped by this.

Re: Issues Executing NetApp PS Toolkit Cmdlets from SRM 4.1

Hey Man,

Let us know if you ever get it working. Nice work!

Re: Issues Executing NetApp PS Toolkit Cmdlets from SRM 4.1

This is just a general poll...

Is anyone using the NetApp PowerShell Toolkit with VMWare SRM to assist in automating the failover/failback procedures?

Re: Issues Executing NetApp PS Toolkit Cmdlets from SRM 4.1

I found something that would help my cause but unfortunately did not solve my problem. I realized that even though I had set the execution policy to unrestricted for the user executing the NetApp PS Toolkit cmdlets, I was still being prompted to load the modules every-time I executed my script (please see the example below).

A colleague had informed me that this isn't normal behavior for an unrestricted execution policy and the error is caused by UAC and the fact that Windows recognized that the ONTAP Toolkit files had been downloaded from the internet.  In order to resolve this discrepancy, I had to uninstall the PS Toolkit and prior to re-installation I had to unblock each of the files I needed to install the toolkit (ie, install.ps1, uninstall.ps1 )

After performing these procedures, when I load the powershell toolkit I'm not prompted to confirm that I want to load the module. Which is a benefit for scripting, but unfortunately this didn't solve my issue. Possible someone else can benefit from the time I've spent troubleshooting this problem. If I do find the solution I'll be sure to post it.