Fixing a (minor) PowerCLI 6 R1 issue

With PowerCLI 6 R1 a major change was introduced, PowerCLI now has modules !

Such a major change is bound to introduce some minor nuisances, as some PowerCLI users have already discovered. This post will try to tackle some of these nuisances.

pcli-v6-bandaidThe first issue is with the PSConsoleFile, called vim.psc1, which was often used in batch invocations of PowerCLI scripts. Unfortunately this is a breaking change, but it can easily be fixed as this post will show.

The second annoyance has to do with the PowerShell environment variable called $env:PSModulePath. The installation package for PowerCLI 6 R1, sets the module path in the user environment variable, which might cause an issue. Read on.

PSConsoleFile

The PSConsoleFile is used to load PSSnapins and can be passed on the powershell.exe command via the PSConsoleFile parameter.

This was used quite often to run PowerCLI scripts as batch jobs or as scheduled tasks. See for example Alan Renouf‘s excellent post called Running a PowerCLI Scheduled task.

In PowerCLI 6 R1, the PSConsoleFile is used by the PowerCLI initialisation script (Initialize-PowerCLIEnvironment.ps1) to load the PSSnapins and the Modules. But to enable that for that script, the vim.psc1 now contains a PSModules tag, which is afaik, not a supported tag in a PSConsoleFile.

As a result, when you try to start PowerShell with the PowerCLI 6 R1 PSConsoleFile, you will see

pcli-v6-batch-psconsole

PSModulePath

During the installation of PowerCLI 6 R1, the module folder is added to the environment variable called PSModulePath. This will allow for example module autoloading.

Unfortunately the PowerCLI 6 R1 installation program adds the module path to the “user” environment variable and not the machine environment variable.

pcli-v6-modulepath

This is not really a problem when you run your PowerCLI scripts with the same account as the one that you used to install PowerCLI. But for scheduled tasks enterprise environments tend to use a dedicated account, so the problem will pop up in that case.

The Fix

Luckily these annoyances can easily be fixed. In fact you use the following script to automate the fixes.

The script is quite straightforward:

  • Check if we are dealing with PowerCLI 6 R1
  • Correct the PSModulePath
  • Correct the vim.psc1 file

Once the script has done its work, you should now be able to run your batch and scheduled tasks with PowerCLI 6 R1 without any changes.

You can validate that the fix works by running a simple test PowerShell task.

pcli-v6-batch-psconsole-fixed

Enjoy !

9 Comments

    Willian Lanzelotti

    @LucD
    Thanks!!

    Noel

    @LucD

    Hi,

    I tried uninstalling PowerCLI-6.3.0-3737840 and reinstalling again but I have the same problem.

    This is the command i run as administrator:

    C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe -PSConsoleFile “C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1″ ” & “C:\scripts\vcheck_vcenter\vCheck_atvcen8\vCheck-vSphere-master\vCheck.ps1”

    The output is as follows:

    Get-VICredentialStoreItem : The term ‘Get-VICredentialStoreItem’ is not
    recognized as the name of a cmdlet, function, script file, or operable
    program. Check the spelling of the name, or if a path was included, verify
    that the path is correct and try again.
    At C:\scripts\vcheck_vcenter\vCheck_atvcen8\vCheck-vSphere-master\Plugins\00
    Initialize\00 Connection Plugin for vCenter.ps1:53 char:10
    + $Creds = Get-VICredentialStoreItem -Host $VIServer -File C:\credentia …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : ObjectNotFound: (Get-VICredentialStoreItem:Strin
    g) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

    This is how my psmodulepath looks …

    PS C:\Users\Administrator> $env:psmodulepath
    C:\Users\Administrator\Documents\WindowsPowerShell\Modules;
    C:\Program Files\WindowsPowerShell\Modules;
    C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;
    C:\Program Files\Hewlett-Packard\PowerShell\Modules;
    C:\Program Files\EMC\EMC Storage Integrator\;
    C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules;
    C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules\;
    C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules\

    And this vim.psc1 file in C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI

    1.0

    and this is my powershell version

    PS C:\Users\Administrator> $PSVersionTable.PSVersion

    Major Minor Build Revision
    —– —– —– ——–
    5 0 10514 6

    Regards,

    Noel

      LucD

      I suspect the issue is because the PowerCLI do not work with autoload.
      You have to load them explicitly, and the PSSnapin as well. That was one of the reasons I wrote my Enable-PowerCLI function.
      Can you try with the function, just call it in the beginning of your script.

    Dingus McGee

    Can you please post an example of what the vim.psc1 should look like after this script runs? I’ve not been able to have success using the script, but want to manually modify the vim.psc1 to be able to run batch files via scheduled tasks using PowerCLI 6.0 R3. Thanks

      LucD

      Hi, the fix is only valid for PowerCLI 6.0 R1.
      If you have 6.0 R3, the problem is not there anymore.

        Jonas Jakobsen

        Hi Luc

        I just upgraded from 5.8 R1 to first 6.0 R2 and then 6.0 R3 but this problem is haunting me 🙁

        It seems like PSModulePath is correct both for my batch user and for machine. Running Get-Module -ListAvailable shows the modules but autoloading is not working. Running a powershell.exe with the vim.psc1 does not fix this – “Connect-VIServer cmdlet not found”.

        One thing I noted is that running Get-Module -ListAvailable shows no exported commands for the VMware modules but for all other and if I read Microsoft Technet[1] correct this needs to be the case for autoloading to work otherwise get-command won’t show them and this is necessary for autoloading to work.

        Any ideas on what to look for?

        [1] https://technet.microsoft.com/en-us/library/dd878284%28v=vs.85%29.aspx

          Luke

          I am having this same issue with 6.3 R1 as well.
          None of my batch files that were created to run scheduled tasks will run now. When trying to use the Get-PowerCLIVersion test as outlined about, i get the error:
          C:\Users\username_admin>powershell.exe -psc “D:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1” -noprofile -command “Get-PowerCLIVersion”

          Get-PowerCLIVersion : The term ‘Get-PowerCLIVersion’ is not recognized as the
          name of a cmdlet, function, script file, or operable program. Check the
          spelling of the name, or if a path was included, verify that the path is
          correct and try again.
          At line:1 char:1
          + Get-PowerCLIVersion
          + ~~~~~~~~~~~~~~~~~~~
          + CategoryInfo : ObjectNotFound: (Get-PowerCLIVersion:String) [],
          CommandNotFoundException
          + FullyQualifiedErrorId : CommandNotFoundException

          I’ve modified the vim.psc1 console file to include the line

          because it seems that the only snap-ins that are included are VMware.DeployAutomation and VMware.ImageBuilder but even with that change i’m not having any luck, but now get a different error:
          C:\Users\username_admin>powershell.exe -psc “D:\Program Files (x86)\VMware\In
          frastructure\vSphere PowerCLI\vim.psc1” -noprofile -command “Get-PowerCLIVersion”

          Windows PowerShell terminated with the following error:
          There is no Runspace available to run scripts in this thread. You can provide one in the DefaultRunspace property of the System.Management.Automation.Runspaces.Runspace type. The script block you attempted to invoke was: Import-Module VMware.VimAutomation.Cis.Core

            LucD

            This is different in 6.3R1.
            Since 6R2 the $env:psmodulepath was doen correctly during the installation of PowerCLI.
            What you are seeing is most probably caused by the difference in PSSnapin and Modules in PowerCLI.
            I now use the following lines to load the PSSnapin and Modules.

            $loaded = Get-Module -Name VMware* -ErrorAction SilentlyContinue | where{$_.Name -notmatch 'Common$|SDK$'} | Select Name
            Get-Module -Name VMware* -ListAvailable | where{$loaded -notcontains $_.Name} | %{Import-Module -Name $_.Name}

            $loadedSnap = Get-PSSnapin -Name VMware* -ErrorAction SilentlyContinue | where{$_.Name -notmatch 'Core$'} | Select Name
            Get-PSSnapin -Name VMware* -Registered | where{$loadedSnap -notcontains $_.Name} | %{Add-PSSnapin -Name $_.Name}

            Hope that helps.

    Vandrey Trindade

    I had this problem and didn’t find nowhere an answer… So I edited the vim.psc1 myself to remove PSModules… Thanks for the script!

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*

This site uses Akismet to reduce spam. Learn how your comment data is processed.