Invoke-Command to Newly Created Virtual Machines

[L2_L3]

Hi Everybody,

I have been attempting @ getting something to function courtesy of some powershell cmdlets/powercli.  I want to invoke-command and call to an exe/msi when a new virtual machine is created (to install applicable 3rd party storage application in this case).  Have a workflow that clones the virtual machine, and then invokes a powershell command.  Pretty straight forward here.  My concern comes with the names of the virtual appliances will always change.  Would anyone know of a variable I can pass to query this newly created virtual machine during deployment.  Any input would be greatly appreciated.

[jpsider]

When you clone the template, do you give it a name? You should be able to reference that when you want to execute the command. Do you have some scripts we can review?

[LucD]

Without the name of the VM it will be difficult to do this from the outside.

There are a number of options:

• wait for the VmPoweredOnEvent event, from there you can get the VM name. If you have many VMs starting, you should have a way to check if the PowerShell script was already invoked or not. A witness file or a registry entry could serve.
• You can include the PowerShell script in the Run Once list. See for example Execute a Powershell self-elevating script after a VMware template deployment
• You can set a GuestInfo variable via the VMware Tools. Test the variable, and depending on the content run the script or not. See for example How to extract host information from within a VM?

Do you deploy the VMs with a RunAsync task ?

If yes, you can use the Task object to find the name of the VM

[L2_L3]

Guys, really appreciate the responses.  Luc I will look though that information below.

Basically I am using vRealize Automation, but could use orchestrator, but want the invoke-command to be courtesy of Powershell (for obvious reasons).  My workflow, has a number of inputs in which are passed to the createVM schema element.  Once this is completed it is sysprepped and then I run another element vim3Wait DNS which waits for DNS to register and report back.  This allows time for workload to be up.  Once this is completed, I wanted to invoke-powershell script.

So yes I pass the VM a name during my workflow run, this is a "Input"   The input name within is simply "name" and then I have a binding in which hands it off to the cloneVM schema element so the name is passed to the VM and the template name is not used.  So basically by the time the PS script is ready to be invoked, the VM is up running, with DNS/VMWare tools humming away.

Will keep looking at your gents suggestions and report back, once again thanks for your replies thus far.

[L2_L3]

Hi Luc,

"wait for the VmPoweredOnEvent event, from there you can get the VM name. If you have many VMs starting, you should have a way to check if the PowerShell script was already invoked or not. A witness file or a registry entry could serve."

This looks like the most suitable idea for what I am trying to achieve, when you state get the VM name, what variable should I pass in my PS script to capture this newly created VM.

For simplicity sake, lets say I use.

Invoke-Command -ScriptBlock {start-process "C:\Script\applicationinstall.exe" -ComputerName "Get-VM" -ArgumentList @(Insert Arguments) what value for Get-VM should I pass there?

[LucD]

Simplified it looks like this

• Use Get-VIEvent to retrieve events. Extract the VmPoweredOnEvent events (where{$_ -is [VMware.Vim.VmPoweredOnEvent]})
• In the events, you should find the VMname via "Get-View -Id $event.VM -Property Name | Select -ExpandProperty Name", provided $event contains one of the events mentioned above

Stays the point how you are going to distinguish the VMs that already had your script executed.

Easiest would be to create a witness file in the filesystem (C:\witness.dummy) and in your script test if the file is there (Test-Path). At the end of the script you create the witness file

[adamwiso]

Hi Luc:

We are looking at doing something very similar, can you comment on the RunAsync task, this is foreign to me?  Is that a task within orchestrator or the native vCenter customization wizard?

[LucD]

No, RunAsync is a switch that is present on a number of PowerCLI cmdlets. See also about_RunAsync.

If the switch is selected ($true), then the cmdlet will launch the underlying API method in the background, and the cmdlet will return immediately.

Your script will continue while the background task is still running.

When the RunAsync switch is used, the cmdlet will return a Task object.

Via the Task object and the Get-Task cmdlet, you can follow the status and result of the background task.