scheduled tasks + credentials not passed to script

[RobMokkink]

I opened another thread, because if accidentaly set the other thread to solved.

I am still having issues with scheduled tasks and credentials. I created a new lab (on my laptop) to test the issue.

But still i am having issues, i keep on getting this error:

Connect-VIServer : C:\WINDOWS\system32\windowspowershell\v1.0\%APPDATA%\VMware\

credstore

When i installed the previous version everything works oke. When i hard code the username and password in the script, it works oke

Who has the answer to my problem, i can't seem to find the problem.

.

[CITITECHS]

As stated in the last thread. Am also having the same issue. Am replying so that I get alerts when post are made to this thread.

[RobMokkink]

Thanks CITITECHS for the update. I will not close this thread until the problem is resolved.

As a workaround i create a encrypted password file the same way i use it in my updatelocalusers script to login as root to the individual esx hosts.

[RobMokkink]

I have done some extra error handling %APPDATA%, the users profile folder is not loaded during a scheduled taks:

write-ouput $env:appdata

[pxu]

I too am seeing the exact same problem after upgrading to 1.5.

[RobMokkink]

Okay, i got it working using the following few lines:

#FIX FOR TOOLKIT 1.5

$USER = $env:username

$APPPATH = "C:\Documents and Settings\" + $USER + "\Application Data"

#SET THE APPDATA ENVIRONMENT WHEN NEEDED

if ($env:appdata -eq $null -or $env:appdata -eq 0)

{

$env:appdata = $APPPATH

}

Can other people please test also? So i know this is a proper fix.

[CITITECHS]

Rob - The Fix worked for me thanks ...

If you get a chance please share your debugging methods as how you determined that was needed.

Thanks

[RobMokkink]

CITITECHS good to hear it works oke.

You can debug powershell script quite easily when running as a scheduled task, add the following after the C:\Windows\system32\windowspowershell\v1.0\powershell.exe <pathtoscript\<scriptname>.ps1 2>&1 >> C:\debug.txt

I also ran the scheduled task when i was logged in as the service account , tip from LucD.

You redirect standarderror is redirected to standardout which you log into a file.

[LucD]

Your fix works for me on XP and W2K3.

Well done Rob.

[RobMokkink]

Hi Luc,

Thanks for testing and helping me fix the problem.

[pxu]

Thank you Rob, that worked. I also tried logging in with my functional account and set a AppData environment variable to the proper folder and that worked also, probably not recommended.

[RobMokkink]

pxu,

the powershell $env:appdata is the equivalent of the commandprompt %APPDATA%, it is always set when you are logged in, but it is empty when running a scheduled task.

You can see the value when you do $env:appdata in powershell. So you don't need to set in when you are logged on.

[roity57]

I ended up just using:

$USER=$env:username

$env:appdata = "C:\Documents and Settings\" + $USER + "\Application Data"

Works a treat! Thanks for the fix.

[RobMokkink]

Oke the problem is fixed. I will set the thread to answered.

Thank you all for testing.

[mabrown]

Awesome! Thanks for the fix Rob!!

[vmdavinci]

It's also works for me! Thanks

[jonmusker]

Really brilliant tip - thanks.

The scripts suggested in this thread to fix the problem make assumptions about the location of the user-profile that may not always be correct. My testing shows a slightly more elegant and rather more robust fix is this one-liner (although in cases of shell-folder redirection this could still fail)

if (! (Test-Path [string]$env:APPDATA) ) {$env:APPDATA = $env:USERPROFILE + "\Application Data"}  

Even better - if you add that line to the file

C:\Windows\System32\WindowsPowershell\v1.0\profile.ps1

then it will apply universally to all scripts on that computer.

(why do it this way? First, the location of the user profile varies by operating system; in Vista/Win7/Server2008 it isn't c:\documents and settings but rather c:\users. Next, the subfolder within the profiles folder isn't guaranteed to match the username for various reasons. Next, by using Test-Path I can account for a blank APPDATA variable but also an APPDATA variable that points to a non-existent location )

[LucD]

Afaik, this is not needed anymore since PowerCLI v4.

[alanrenouf]

Luc,

FYI, I just had this issue with PowerCLI v4

The fix worked fine, thanks Rob.

Alan[http://virtu-al.net]

[RobMokkink]

Thanks Alan.

I still haven't started testing the new powercli.

Carter promised at Vmworld that this issue would be fixed in the new version.