When you run one of these cmdlets with the -RunAsync param, the output is a ClientSideTaskImpl object, as opposed to what most of the others I've seen use which is a TaskImpl object. The output at the command-line is different as well as you can see here:
PS > Get-VM fudgeapp01 | Set-VM -MemoryMB 256 -RunAsync -Confirm:$false Name State % Complete Start Time Finish Time ---- ----- ---------- ---------- ----------- ReconfigVM_Task Running 0 09:31:40 PM
PS > Get-Datacenter my* | Move-Datacenter -Destination (Get-Folder test) -RunAsync Id : IsCancelable : False IsComplete : False Result : Name : MoveIntoFolder_Task Description : Move Entities State : Running PercentComplete : 0 StartTime : 9/14/2008 1:32:06 AM FinishTime : ObjectId :
This does not seem to affect the functionality of the cmdlet, but it may certainly throw someone for a loop if they were trying to correlate the task objects back to the server tasks to update status in a script. Based on examination, it looks like the ClientSideTaskImpl objects don't even include an ID property, so that would make such correlation quite difficult.
Author of the upcoming book: Managing VMware Infrastructure with PowerShell
Co-Host, PowerScripting Podcast (http://powerscripting.net)
Did you ever solve this?
I'm running into something similar, but behavior varies across two different hosts. Host A is running PowerShell 2.0 w/ PowerCLI 4.0 U1 Build 208462 on Windows XP.
Host B is running PowerShell 2.0 w/ PowerCLI 4.1 U1 Build 266648 on Windows 2008 SP2.
On Host A, I make an asynchronous call to Set-VM and get back a valid Task object. The same script on Host B results in a ClientSideTaskImpl object which is not very useful.
I'm thinking this must be a change between the 4.0 and 4.1 versions of PowerCLI?
In both cases I am talking to a vCenter 4.1 server.