Configuring a PowerShell workflow in vRO and then having it as a blueprint in vRA

[emcclure]

Hello,

I'm currently running vRO/vRA 7.3.1.  I've created a blueprint in vRA which has been nice, but I'd like to do more with it.  I have some PowerShell scripts that I'd like to setup as a workflow in vRO and then have them as a blueprint somehow in vRA (if possible) so anybody on my team or in the company if needed could just click and run a script.  I have created a PowerShell machine (2k12 R2) that has PowerShell 5.1 on it.  I've run the New-VICredentialStoreItem on there for a particular vCenter to test with.  Below is the code I'm using for the script:

$creds = Get-VICredentialStoreItem -File C:\vicredentials.xml

Connect-VIServer -Server $creds.Host -User $creds.User -Password $creds.Password

$log = Read-Host "Enter log name i.e. VRM.txt"

$GetVM = Get-VM -location VRM | sort Name

$GuestCredential = Get-Credential #Provide Guest OS credentials

$obj = foreach ($vm in $GetVM)

{

   $string = "query user /server:$vm"

   Invoke-VMScript -vm $vm -ScriptText $string -ScriptType Powershell -GuestCredential $GuestCredential | Format-List | Out-File $log -append

Basically I'd like to setup a workflow somehow to just list the particular vCenter this would apply to, then ask the user for the name of the log file they want and then have it pass that into the script.  They would also pass the credentials for the machines (a service account, or maybe that's in the workflow, but hidden somehow).  The script would run and somehow (I'm not sure if this is possible in vRO/vRA) the file is created and the user can access it somehow after vRA has completed it..  Perhaps I create a share they can get to that the script puts it there.  I tried looking around on google for this, but whatever I tried really didn't work, so I'm stuck.  I'm not sure if this is possible or not, but since this is the simplest script I have I want to try it first before moving onto ones that require more input from the user.  Any help is appreciated.

Thanks

[daphnissov]

If you have the Enterprise license, you could just use a software component to use those PowerShell scripts in. There are multiple ways to do this, but avoiding using PS hosts and individual scripts is usually ideal.

[NuggetGTR]

So Software Components are fine to install application and run scripts at deployment time, but if your refering to something people can execute a script as a seperate catalog item? then yes this is possible.

It would just be a simple XaaS Blueprint but while powershell host would work(I use them for a number of things), I would not use Powershell host for this. because you are just executing a script in a guest, you can achieve this with "run script in guest" using native vRO capability as well as the vCenter plugin etc. This would be faster, more efficient and less error prone. As for a file, this could be done a number of ways. vRA cant handle mimetypes so would have to email or log it out to a central location. Its very doable and I have seen many enterprises have XaaS blueprints to generate reports and email them etc.

[emcclure]

Yes ideally I'd like someone to execute it as a separate catalog item if it's possible.  I know some of the scripts I have ask for more than what I attached so I'm guessing it'd be on a case by case basis, and maybe not.  So if not using the PowerShell host is the best thing, then I just need to do what exactly?  Where do I store the scripts?  Am I putting them in vRO somehow and creating a blueprint.  I'm new to this so any advice/steps to try/follow would be great.

Thanks.

[daphnissov]

It really depends on what these scripts do and when you want them run. As mentioned, if they're scripts that solely need to run at the time a new machine is built and deployed, then this is ideally a job for software components (provided you own vRA Enterprise). If these are scripts you just want to run as either XaaS or day2, then that wouldn't be a job for software components. There are multiple ways to skin this cat, but without more details on what you have and how they need to run, it's difficult to provide specific advice.

[emcclure]

So I have the script that was in the original post to just get RDP session info and save it to a log file.  I have others that export an OVF to a location that can be specified by the user or hard coded in the script, I have an import OVF script, ones to clone VM's, one to update VMware tools, one to run Windows update.  I may add more as I go, but these are the main ones I'm working with.

The scripts are designed to use stored credentials, which is why I was hoping I could use the PowerShell machine and store the creds on there.  I figure that way the script would have access to whatever and only certain people would access those scripts, so a regular user wouldn't have the access.  I could create it for a regular user though, but somehow use their credentials when logged into the system.

Scripts like the import/export scripts require a lot of input.  What datacenter, datastore, host, etc.  Those I'd want to be based on users as some can only see a certain datacenter inside of vCenter and I'd only want the script to access that.  If you need more info please let me know and I can provide the script info if needed.

Thanks.

[emcclure]

Anybody have any updates?  Ideas?  I was really hoping to have a place to start on this.

[daphnissov]

You might want to consider breaking these up depending on their purpose. Some might be better suited as software components if they are to execute on the deployed machine or relate exclusively to it. Others might be XaaS that you want to execute independently, and those you could use your PS host or turn them into vRO workflows using the guest script manager package that Christoph wrote. Some others still, especially those that have an existing vRO plug-in (like vCenter) I'd probably re-write as native JS and turn into workflows. So there's probably not a good "one size fits all" approach here but is going to come down to your requirements.

[emcclure]

Hmm I can't get to that link at all.  Tried 2 different machines and 3 different browsers, all give me the fun 404 error.