You mention Add-PSSnapin, are you sure you installed PowerCLI 6.5.1, and not 6.5R1?
They are not the same, the former only has modules, so Add-PSSnapin should return an error.
You could also check by doing a Get-PSSnapin -Registered, this should not return anything for 6.5.1.
I assume you installed the PowerCLI modules under E:\vROPS\Modules?
In that case, did you update the $env:PSModulePath variable to include that folder?
Not 100% sure if that would matter in your setup though.
For further debugging it would be important to know under which account your PowerShell script is executed.
Perhaps active a transcript log at the beginning of your script, and perhaps add the Verbose switch on the cmdlets.
wow thanks for getting back to me so quickly.
Yes I am sure I installed it correctly as my script works with PowerCLI 6.5.1 and earlier versions (The code checks if it should use modules or load snapins depending on the version of PowerCLI)
When I execute it in PowerShell, PowerShell ISE or a windows Scheduled task with PowerCLI 6.5.1 everything works just fine (This is all on the same server where the portal runs, all methods are executing the same script). Its only when its executed via C# and ASP.net on a box with PowerCLI 6.5.1 that it does not work.
Yes I have the modules under E:\vROPS\Modules, I thought it was a permission issue but it also throws the same error when the module is installed to the default path. Yes I also checked $env:PSModulePath and everything is correct.
Regarding permissions: The script is exeucted by IIS, the application pool is running as a domain user in the local Administrators
Its the same user account which runs the script for scheduled tasks and works just fine.
The issue really appears to be in C# and ASP.net calling the PowerCLI cmdlets when using C# PowerShell.Create();
Just curious, did you already try the Import-Module with the full path of the module?
Like (the path of course needs to be adapted to where you installed the module).
Import-Module -Name "C:\Program Files\WindowsPowerShell\Modules\VMware.VimAutomation.Core"
Yes I did also try to hardcode it:
Import-Module -Name "E:\vROPS\Modules\VMware.VimAutomation.Core\22.214.171.12474329\VMware.VimAutomation.Core"
I spent a while on this issue and it's really strange / specific to the asp.net / C# execution method when using import-module instead of Add-PSSnapin.
I should also mention that I have this issue on my server (IIS) and my workstation (VS 2012)
Another additional bit of info:
The same script which performs all the data collection from vRops and vCenter then exports the data into several worksheets using module Export-Excel without any issues.
And you did suppress all Warnings before loading the module?
There is this CEIP message when you load the Core module.
But then again, it would require running the Set-PowerCLIConfiguration cmdlet before importing the module (chicken & egg).
Unless you can do this, with the correct account, interactively beforehand.
Just guessing btw
Yes I did try, I ran PowerShell as the service account using "Run as different user" and set:
Can you see anything wrong based on the lines below?
Set-PowerCLIConfiguration -Scope AllUsers -ParticipateInCEIP $false -InvalidCertificateAction Ignore -ErrorAction SilentlyContinue -WarningAction SilentlyContinue -InformationAction SilentlyContinue -DisplayDeprecationWarnings $false
Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false -InvalidCertificateAction Ignore -ErrorAction SilentlyContinue -WarningAction SilentlyContinue -InformationAction SilentlyContinue -DisplayDeprecationWarnings $false
Not sure if it's related since I don't do C, but at some point in PowerShell (~4.0) we had to start using the full assembly name [System.Management.Automation.PowerShell]::Create() instead of just PowerShell::Create().
Thanks for the info, I will check it out but the actual script launches from c#/ASP.net just fine and 90% of the functionality works... its just that it fails to load the vmware core module which I need for the vCenter events as vRops doesnt expose it with the suite-api
It looks like you are targeting VMware.VimAutomation.Core directly. Do your results change (for the better) when targeting VMware.PowerCLI? The only downside is it loads all PowerCLI modules, but it's dependable.
As for your PowerCLI configuration that looks fine. Please note that the
'-ErrorAction', 'WarningAction' and 'InformationAction' are not needed. This only affects your interaction with the Set-PowerCLIConfiguration cmdlet while you're doing the settings (i.e. do you want to see if an error happened while setting the setting). These are part of the 'free' cmdlets you get when you add [CmdletBinding()] to the top of a script (as VMware does).
Remove redundant question
Add link to Don Jones Toolmaking (3 part series on youtube)