There was a requirement in one of the projects to create multiple (approx. 60) datastores using a PowerCLI script. We wrote a PowerCLI script to perform this operation on multiple LUNs presented to all ESXi hosts in the cluster.
Just replace the vCenter_Server_IP_Address/FQDN, Path of File Containing Datastore Names, NAA Ids, ESXi Host, Cluster Name and Sleep Interval after each Datastore creation operation with the details of your environment. BOOM!!
We were working on a requirement last week to pull a report of all vRealize Automation Managed Machines using PowervRA Module version 3.7.0 which supports vRealize Automation 7.6. While generating the report using a PowerShell script we noticed that the output was only showing the name of the Machine owner instead of the ID.
Then we started digging into the function Get-vRAResource of PowervRA Module and we noticed that the method which is used by function Get-vRAResource in PowervRA Module is /catalog-service/api/consumer/resourceViews
vRealize Automation API Method used by function Get-vRAResource in PowervRA
After checking the vRealize Automation Catalog Service API 7.6 documentation we realized that this method was deprecated in vRealize Automation 7.5 version and this method is similar to /catalog-service/api/consumer/resources method.
Method /api/consumer/resourceViews has been deprecated since version 7.5
We used our Good Old API building Platform Postman to do a side by side comparison of vRA API methods /catalog-service/api/consumer/resourceViews and /catalog-service/api/consumer/resources. If you’ll look at the output of both the methods closely, you’ll notice that the resourceViews methods returns only the Name of the Owner where as the resources methods returns an Array which includes the values of tenantName, ref, type & value out of which ref is the Machine Owner’s ID.
Side-by-Side Comparison of API Methods /api/consumer/resourceViews and /api/consumer/resources using Postman
Armed with all that information we prepared our script to pull resource Information of all vRA Managed Machines using PowervRA function Get-vRAResource and then we used the vRealize Automation API method /catalog-service/api/consumer/resources/{ResourceID} to get the Machine Owner’s ID of each Resource to generate our vRA Managed VMs report with Owner’s ID.
We received a request to export the details of vRealize Automation Network Profile’s IP Ranges. We wrote a PowerShell script which uses PowervRA (3.6.0) module to extract the details of Network Ranges for each Network Profile.
There was a requirement in one of the projects to perform an unattended shutdown of multiple Virtual Machines during a planned Maintenance Window. We wrote a PowerCLI script to perform shutdown operation on multiple VMs with a delay of 20 seconds between each shutdown.
foreach ($VM in $VMs) { Get-VM $VM | Select Name, PowerState | Ft -AutoSize -Wrap } Disconnect-VIServer -Confirm:$false
Note: Virtual Machines are shutdown gracefully and requires VMware Tools to installed on machine.
Just replace the vCenter_Server_IP_Address/FQDN, Path of File Containing VMs Name and Sleep Interval after each shutdown operation with the details of your environment. BOOM!!
We received a requirement to export the details of vRealize Automation Business Groups, to be more specific to extract the Business Group Ids, which is a very time consuming task if you have a large number of Business Groups in your environment. I wrote a PowerShell script which uses PowervRA (3.6.0) module to extract the details of Business Groups.
In order to execute PowerShell scripts from vRealize Orchestrator, we need to configure a PowerShell host as an endpoint for your vRealize Orchestrator. vRealize Orchestrator which comes embedded with vRealize Automation appliance already has PowerShell Plug-in installed and has all the required workflows available under Library > PowerShell.
Adding PowerShell host to vRealize Orchestrator:
Pre-requisites:
vRealize Orchestrator with PowerShell Plug-in
Windows Host – 2 vCPUs & 4 GB RAM, PowerShell PSVersion 5.X, Windows Server 2012 or later (Domain-joined)
Certificate for Windows Host (if you are using Custom certificates)
Active Directory User Account – Service Account which should be part of Administrators and Remote Management Users groups on Windows Host.
Configuration Steps:
Enable PowerShell Remoting on Windows Host by running the command Enable-PSRemoting command. The Enable-PSRemoting cmdlet configures the computer to receive PowerShell remote commands that are sent by using the WS-Management technology. PowerShell remoting is enabled by default on Windows Server 2012. You can use Enable-PSRemoting to enable PowerShell remoting on other supported versions of Windows and to re-enable remoting on Windows Server 2012 if it becomes disabled. This command has to be run only once on the Windows PowerShell Host. Increase the amount of memory each PowerShell session is allowed to consume for executing the scripts by running the below command:
winrm set winrm/config/winrs @{MaxMemoryPerShellMB=”2048″}
Import the Custom Certificate generated by your Certificate Authority to your Windows PowerShell Host. In this example, we are generating a Self-signed certificate (Using a Self-signed certificate is not recommended for the Production environment). Self-Signed certificate can be generated using the below command:
Copy this newly generated Self-signed certificate to Console Root > Certificates > Trusted Root Certification Authorities > Certificates. Note down the thumbprint of the certificate from the Certificate details:
Create a WinRM HTTPS Listener by running the below mentioned command:
Replace PWShellHost_FQDN with the FQDN of your PowerShell Host and replace Certificate_Thumbprint with the thumbprint of the Self-signed certificate generated in the previous step.
Run the following command to enable Kerberos authentication for WinRM service:
winrm set winrm/config/service/auth @{Kerberos=”true”}
If you need to delete the WinRM HTTPS Listener for some reason, run the below command:
Create an Inbound Windows Firewall Rule on Windows PowerShell Host by running the below command:
New-NetFirewallRule –Direction Inbound –Action Allow –DisplayName “Windows Remote Management [HTTPS-In]” –Description “Inbound rule for Windows Remote Management via WS-Management. [TCP 5986]” –Program “System” –Profile Domain,Private –Protocol TCP –LocalPort “5986” –RemotePort Any
Firewall Rule Details:
Name: Windows Remote Management (HTTPS-In) Description: Inbound rule for Windows Remote Management via WS-Management. [TCP 5986] Program: System Local IP address: Any Remote IP address: Any Direction: Inbound Profile: Domain, Private Protocol: TCP Local port: 5986 Remote port: Any
We need to configure vRealize Orchestrator to use Kerberos Authentication. Edit the krb5.conf configuration file on your vRealize Orchestrator server located at path /usr/java/jre-vmware/lib/security/ to specify the domain name and domain controller name. If the file does not already exist, create a new file and paste the contents after modifying as per your requirement in the file:
Set the permissions of the file krb5.conf to chmod 7777.
Run vRealize Orchestrator workflow Import a certificate from URL located under Library > Configuration > SSL Trust Manager > Import a certificate from URL to import the certificate of the PowerShell Host to vRealize Orchestrator: There will be couple of warnings thrown at you, just accept all the warnings and verify the Certificate Validity and accept to Import the certificate.
Once the Certificate has been imported successfully, you’ll be able to see the certificate under the CA Keystore:
Next step is to run the vRO workflow Add a PowerShell Host located under Library > PowerShell > Configuration > Add a PowerShell host workflow to add the Windows PowerShell Host to vRO.
Enter PowerShell Host FQDN under Host, Any reference name under Name and Port should be 5986 for HTTPS connection: Select WinRM under PowerShell remote host type, HTTPS under Transport protocol, set Accept all certificates to Yes and Authentication type should be Kerberos. Enter the credentials of Active Directory Service Account which is part of the Administrators and Remote Management Users groups on Windows PowerShell host and select Session mode as Shared Session. Under Advanced Settings select Shell Code Page as UTF8. Once Workflow has ran successfully, you’ll be able to see the newly configured PowerShell host under PowerShell plugin in Inventory tab of vRealize Orchestrator.
Now comes the part we have been waiting for, we can now execute any PowerShell script hosted on this newly configured Windows PowerShell Host. To execute a PowerShell Script we will run the vRealize Orchestrator workflow Invoke an external script located under Library > PowerShell > Invoke an external script. Select your newly configured Windows PowerShell host under the Host. Enter the path of the PowerShell script which is hosted on the Windows PowerShell Host and enter any arguments under Arguments section. Voila! You are now all set to run all your favorite PowerShell scripts using vRealize Orchestrator.