VMware Cloud Community
SueUva
Contributor
Contributor
Jump to solution

Invoke-vmscript file not found on Windows Guest

Using invoke-vmscript on a newly deployed windows guest and often (not always) it errors out with "File c:\Users\TEMP\AppData|Local|Temp\powerclivmware59 was not found".  The number at then end of the file name varies.  Is there a way to prevent this error?

Tags (1)
Reply
0 Kudos
1 Solution

Accepted Solutions
LucD
Leadership
Leadership
Jump to solution

I'm afraid not, that's internal to the cmdlet.

I have the impression sometimes it has to do with the user's profile not being completely created yet.

An autologon in the OSCustomizationSpec, when you deploy the vM, for the account avoids the error.

I also sometimes use a Try-Catch, where I intercept the error, and then just try the call again.

Not elegant, but it seems to work.

You could have a look in the VM's vmware.log to check if there any further indications of the cause of the error.


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

View solution in original post

Reply
0 Kudos
3 Replies
LucD
Leadership
Leadership
Jump to solution

I experienced similar.
Did the guest credential you used on the Invoke-VMScript already logged on to the guest OS before using the cmdlet?
I assume the guest username is not TEMP?


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

Reply
0 Kudos
SueUva
Contributor
Contributor
Jump to solution

No as the vm was just created from a template in the same script.  I had also tried using administrator.  Both fail about 1 out of every 3 times.  Is there a way to specify a different location for the file?

Reply
0 Kudos
LucD
Leadership
Leadership
Jump to solution

I'm afraid not, that's internal to the cmdlet.

I have the impression sometimes it has to do with the user's profile not being completely created yet.

An autologon in the OSCustomizationSpec, when you deploy the vM, for the account avoids the error.

I also sometimes use a Try-Catch, where I intercept the error, and then just try the call again.

Not elegant, but it seems to work.

You could have a look in the VM's vmware.log to check if there any further indications of the cause of the error.


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

Reply
0 Kudos