VMware Cloud Community
Trammell
Contributor
Contributor
Jump to solution

PowerCli Scheduled Task completed (0x0) Not connecting to VIcenter

Have spent a day trying different ways to get this working. I have no issues configuring a schedule task with other powershell scripts in the past few years but for some reason this one is escaping me. Here are the things I have configured\setup.

1. 2012r2 with PowerCli 10.

2. AD account has UPN & SPN configured.

3. Policy configured to allow account "log on as batch" as well as administrators group. (Has permissions to vcenter)

4. Can execute script via powershell, ISE as the service account and works fine.

5. Task set to run with or without user logged on and highest privilege.

6. Tried credentials in script (readable) & credential store (prefer the store method)

7. [Program/Script] C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

8. [Arguments] -PSConsoleFile "C:\Scripts\PowerCli\exportedconsole.psc1" -ExecutionPolicy unrestricted -NoLogo -NonInteractive -file "C:\Scripts\PowerCli\Get-VMinfo-da1w.ps1" (have tried with and without the blue bolded.

##############################################################################################

Get-Module -Name VMware* -ListAvailable | Import-Module

##############################################################################################

$vserver ="VCENTER"

$Logpath="C:\Scripts\PowerCli\reports"

$Date=(Get-Date).ToShortDateString()

$StartTime=(Get-Date).ToShortTimeString()

##############################################################################################

#New-VICredentialStoreItem -Host VCENTER.DOMAIN.local -File "c:\scripts\powercli\VCENTER-credendtials.xml" -User VCENTER@DOMAIN.local -Password ***************

Get-VICredentialStoreItem -File C:\Scripts\PowerCli\VCENTER-credendtials.xml | %{Connect-VIServer -Server $_.host -User $_.User -Password $_.Password}

##############################################################################################

$StringToWrite = "$vserver - $Date - $StartTime - starting script" | Out-File -FilePath $logpath\Get-VMinfo.log -Append

##############################################################################################

$outputfile = "C:\Scripts\PowerCli\Reports\" + $vserver +" " + $((Get-Date).ToString('MM-dd-yy')) + ".csv"

$allvminfo = @()

$vms = Get-Vm

After this it goes into the foreach loop which is ignored since it cannot connect and then mails me an empty .CSV file (so I know it isn't connecting)

Would really like to get this figured out. Thank You

1 Solution

Accepted Solutions
LucD
Leadership
Leadership
Jump to solution

The System32 folder is confusing.

On a system that has 32- and 64 bit support, the 64-bit system apps are under System32, the 32-bit ones are under SysWOW64.

The primary reason for that is that many applications had system32 hard-coded.
See  Why do 64-bit DLLs go to System32 and 32-bit DLLs to SysWoW64 on 64-bit Windows? for a more detailed explanation.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

View solution in original post

15 Replies
LucD
Leadership
Leadership
Jump to solution

Did you already try adding a transcript to the script (Start-Transcript and Stop-Transcript)?

That might give some extra clues what happens.

Also try adding a -Verbose switch to the cmdlets.

And if you are on PowerCLI 10, I don't think you still need the -PSConsoleFile parameter.

That was used to load the PSSnapin in older versions.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
Trammell
Contributor
Contributor
Jump to solution

Never used Transcript before (self taught with some help), will remember that one. So it would appear that the get-module -name vmware* | Import-module does not work.

**********************

Transcript started, output file is c:\scripts\transcript.log

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\PowerCli\Get-VMinfo-da1w.ps1:11 char:1

+ Get-VICredentialStoreItem -File C:\Scripts\PowerCli\DA1W-credendtials ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

Which PowerShell version are you using (check $PSVersionTable)?

Since PS v5 there is the something called module auto-loading, meaning that modules do not need to be loaded explicitly anymore, provided they are in the correct folders.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
Trammell
Contributor
Contributor
Jump to solution

Name                           Value                                                                                                                                                                                               

----                           -----                                                                                                                                                                                               

PSVersion                      5.1.14393.2068                                                                                                                                                                                      

PSEdition                      Desktop                                                                                                                                                                                             

PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                                                                                                                                                                             

BuildVersion                   10.0.14393.2068                                                                                                                                                                                     

CLRVersion                     4.0.30319.42000                                                                                                                                                                                     

WSManStackVersion              3.0                                                                                                                                                                                                 

PSRemotingProtocolVersion      2.3                                                                                                                                                                                                 

SerializationVersion           1.1.0.1

I used "Install-Module -Name VMware.PowerCLI" to install, so I would assume it is in the correct location?

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

Yes, that is a good PS version, and yes, the modules should be in the correct locations.

To check under which Scope the modules are installed, execute the following

Get-Module -Name VMware* -ListAvailable

and check which Directory is listed at the top of the output.

Next item to check, do you run the scheduled task with the same account as the one with which you tested the script from the ISE?

If they are not, the modules need to be installed under the Scope AllUsers.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
Trammell
Contributor
Contributor
Jump to solution

I am logged on the server with the service account in question.

ISE Command: Get-Module -Name VMware* -ListAvailable

PS C:\Windows\system32> Get-Module -Name vmware* -ListAvailable

    Directory: C:\Program Files\WindowsPowerShell\Modules

ModuleType Version    Name                                ExportedCommands                                                                                                                                                       

---------- -------    ----                                ----------------                                                                      Script     6.5.2.7... VMware.DeployAutomation             {Add-DeployRule, Add-ProxyServer, Add-ScriptBundle, Copy-DeployRule...}                

Script     6.5.2.7... VMware.ImageBuilder                 {Add-EsxSoftwareDepot, Add-EsxSoftwarePackage, Compare-EsxImageProfile, Export-EsxImageProfile...}                                                                       

Manifest   10.0.0.... VMware.PowerCLI                                                                                                            

Script     10.0.0.... VMware.VimAutomation.Cis.Core       {Connect-CisServer, Disconnect-CisServer, Get-CisService}                              

Script     10.0.0.... VMware.VimAutomation.Cloud          {Add-CIDatastore, Connect-CIServer, Disconnect-CIServer, Get-Catalog...}               

Script     10.0.0.... VMware.VimAutomation.Common                                                                                                

Script     10.0.0.... VMware.VimAutomation.Core           {Add-PassthroughDevice, Add-VirtualSwitchPhysicalNetworkAdapter, Add-VMHost, Add-VMHostNtpServer...}                                                                     

Script     6.5.4.7... VMware.VimAutomation.HA             Get-DrmInfo                                                                            

Script     7.1.0.7... VMware.VimAutomation.HorizonView    {Connect-HVServer, Disconnect-HVServer}                                                

Script     10.0.0.... VMware.VimAutomation.License        Get-LicenseDataManager                                                                 

Script     10.0.0.... VMware.VimAutomation.Nsxt           {Connect-NsxtServer, Disconnect-NsxtServer, Get-NsxtService}                           

Script     10.0.0.... VMware.VimAutomation.PCloud         {Connect-PIServer, Disconnect-PIServer, Get-PIComputeInstance, Get-PIDatacenter}       

Script     10.0.0.... VMware.VimAutomation.Sdk            {Get-PSVersion, Get-InstallPath}                                                       

Script     10.0.0.... VMware.VimAutomation.Srm            {Connect-SrmServer, Disconnect-SrmServer}                                              

Script     10.0.0.... VMware.VimAutomation.Storage        {Add-KeyManagementServer, Copy-VDisk, Export-SpbmStoragePolicy, Get-KeyManagementServer...}                                                                              

Script     1.2.0.0    VMware.VimAutomation.StorageUtility Update-VmfsDatastore                                                                   

Script     10.0.0.... VMware.VimAutomation.Vds            {Add-VDSwitchPhysicalNetworkAdapter, Add-VDSwitchVMHost, Export-VDPortGroup, Export-VDSwitch...}                                                                         

Script     10.0.0.... VMware.VimAutomation.Vmc            {Connect-Vmc, Disconnect-Vmc, Get-VmcService, Connect-VmcServer...}                    Script     10.0.0.... VMware.VimAutomation.vROps          {Connect-OMServer, Disconnect-OMServer, Get-OMAlert, Get-OMAlertDefinition...}         

Script     6.5.1.7... VMware.VumAutomation                {Add-EntityBaseline, Copy-Patch, Get-Baseline, Get-Compliance...}

Yes, the task is configured to run as the same account which is in the VICrendentialStore.

[additional info]

PS C:\Users\sa1-vcenter-svc> import-module vmware.powercli

          Welcome to VMware PowerCLI!

Log in to a vCenter Server or ESX host:              Connect-VIServer

To find out what commands are available, type:       Get-VICommand

To show searchable help for all PowerCLI commands:   Get-PowerCLIHelp

Once you've connected, display all virtual machines: Get-VM

If you need more help, visit the PowerCLI community: Get-PowerCLICommunity

       Copyright (C) VMware, Inc. All rights reserved.

PS C:\Users\sa1-vcenter-svc> (get-module vmware.powercli).path

C:\Program Files\WindowsPowerShell\Modules\vmware.powercli\10.0.0.7895300\vmware.powercli.psd1

PS C:\Windows\system32> $env:PSModulePath

C:\Users\sa1-vcenter-svc\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

That all looks ok.

If you just do get-module -name vmware* in the scheduled script, do you see the modules listed in the transcript file?


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
Trammell
Contributor
Contributor
Jump to solution

Changed beginning of script:

Start-Transcript -Path c:\scripts\transcript.log -Force

Get-Module -Name VMware*   (removed -ListAvailable | Import-Module)

**********************

Windows PowerShell transcript start

Start time: 20180328112159

Username: DOMAIN\sa1-vcenter-svc

RunAs User: DOMAIN\sa1-vcenter-svc

Machine: SERVER (Microsoft Windows NT 10.0.14393.0)

Host Application: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy unrestricted -NoLogo -NonInteractive -file C:\Scripts\PowerCli\Get-VMinfo-da1w.ps1

Process ID: 3876

PSVersion: 5.1.14393.2068

PSEdition: Desktop

PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.14393.2068

BuildVersion: 10.0.14393.2068

CLRVersion: 4.0.30319.42000

WSManStackVersion: 3.0

PSRemotingProtocolVersion: 2.3

SerializationVersion: 1.1.0.1

**********************

Transcript started, output file is c:\scripts\transcript.log

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\PowerCli\Get-VMinfo-da1w.ps1:12 char:1

+ Get-VICredentialStoreItem -File C:\Scripts\PowerCli\DA1W-credendtials ...

It's as though it is completely not reading that.

Reply
0 Kudos
Trammell
Contributor
Contributor
Jump to solution

Powershell modules in scheduled task - Stack Overflow

Changed Program in Task Scheduler to the system32 versus the syswow64.

Transcript log is filling up and it appears to be running. So loading the PowerCli via the gallery is 32bit and while it may work while using the gui. The task scheduler doesn't work with x64 powershell and PowerCli modules.

Working as intended?

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

No, but that seems to be a PowerSHell issue.
On which OS is the scheduled task running?


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

That seems to be indeed the issue, you installed the PowerCLI modules from a 64-bit PowerShell session.

And the scheduled task runs the 32-bit PowerShell version.

Start powershell as C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, not the 32-bit version.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
Trammell
Contributor
Contributor
Jump to solution

The original post, I mentioned the server os being 2012r2, the program field in the task scheduler was syswow64\powershell and the arguments. So then your saying when I ran the Install-Module -Name VMware.PowerCLI (it was within a x86 powershell window)?

I sincerely appreciate you helping me diagnose the solution to this.

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

From the listing of the PowerCLI modules, you see that they are installed in the 64-bit folder (C:\Program Files\WindowsPowerShell\Modules)

In you scheduled task (bullet 7), you call the 32-bit version of PowerShell.

Leave the modules where they are, just call the 64-bit PowerShell version (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
Trammell
Contributor
Contributor
Jump to solution

By switching task scheduler to use the powershell located in system32 folder. The scheduled task ran successfully, even though the modules are located under the x64 program files directory. I've got no idea how that makes sense.

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

The System32 folder is confusing.

On a system that has 32- and 64 bit support, the 64-bit system apps are under System32, the 32-bit ones are under SysWOW64.

The primary reason for that is that many applications had system32 hard-coded.
See  Why do 64-bit DLLs go to System32 and 32-bit DLLs to SysWoW64 on 64-bit Windows? for a more detailed explanation.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference