Recently, I have been helping a customer replace their self-signed Management Agent certificate in vRA7.6 with a new self-signed one (old one is expiring). To be clear, this is the Management Agent certificate on the Iaas servers. VMware provides documentation on how to replace the certificate, but here are a few hints on the process.

Firstly, obtain the Management Agent identifier on each of the Iaas nodes where you will be replacing the certificate. You can do this by opening the Management AgentVMware.IaaS.Management.Agent.exe.config file. Make a note of the . The last part is what you will need for the -nd parameter when following the VMware documentation.

Next, obtain the SSL thumbprint needed for the -tp parameter. You can find this in the same file (Management AgentVMware.IaaS.Management.Agent.exe.config).

To execute the command, make sure you run it in an elevated command prompt. Remember that everything you enter is case sensitive. If the machine name is ABC101, entering abc101 will not work!

Before we dive into the process, let me provide some context. vRA7.6 provides a feature called Management Agent, which allows you to manage and automate your vCenter environments. The Management Agent certificate is used to establish trust between the Management Agent and the vCenter server. When the certificate expires, it needs to be replaced with a new one to maintain this trust.

Now, let’s get started with the process of replacing the self-signed Management Agent certificate in vRA7.6.

Step 1: Obtain the Management Agent Identifier

Open the Management AgentVMware.IaaS.Management.Agent.exe.config file and look for the tag. The identifier is located within this tag, and it looks something like this:

Note down the entire identifier, as you will need it for the -nd parameter later.

Step 2: Obtain the SSL Thumbprint

Open the same file (Management AgentVMware.IaaS.Management.Agent.exe.config) and look for the tag. The SSL thumbprint is located within this tag, and it looks something like this:

Note down the entire thumbprint, as you will need it for the -tp parameter later.

Step 3: Execute the Command

Make sure you run the command in an elevated command prompt. The command to replace the self-signed Management Agent certificate is as follows:

vmware-vipr-iaas-management-agent -nd -tp

Replace with the identifier you noted earlier, and replace with the thumbprint you noted earlier.

For example, if your Management Agent identifier is “abcdefg-hijkl-mnopqrst” and your SSL thumbprint is “xxxxxx-xxxx-xxxxx-xxxxx”, the command would look like this:

vmware-vipr-iaas-management-agent -nd abcdefg-hijkl-mnopqrst -tp xxxxx-xxxx-xxxxx-xxxxx

After running the command, the new certificate will be installed on the Iaas servers, and the Management Agent will use this new certificate to establish trust with the vCenter server.

Conclusion

In this blog post, we have covered the process of replacing a self-signed Management Agent certificate in vRA7.6. We have obtained the Management Agent identifier and SSL thumbprint from the configuration file and executed the command to replace the certificate. Remember that everything is case sensitive, so make sure you enter the identifiers and thumbprints correctly.

If you are working with vRA7.6 and need to replace a self-signed Management Agent certificate, I hope this post has been helpful. Happy automating!

As a software developer, I have been asked many times about my coding habits and styles. In this post, I would like to share some of my thoughts on how to code effectively and efficiently in vRO (vRealize Automation).

First and foremost, keep it simple. Coding is a continuous learning process, and you should always strive to simplify your code whenever possible. Don’t get emotionally attached to the code you’ve just written; go back and simplify it, make it easier to read, and consume. The biggest benefit you can give to yourself and your peers is to make your code easy to consume and reusable.

When developing code, think about writing code that solves a generic problem, not just the exact issue at hand. This approach will make your code more versatile and reusable in different contexts. Imagine working on projects with hundreds of commits per month, without any code comments. The code should explain itself; why is this done? Why is it so backwards?

To avoid such issues, comment your code, please! Fill your debug console with row after row of output showing the various objects and properties being managed by your code. This will make it easier to debug when something goes wrong.

Use source control to store your code and batch up your work into small pieces, committing often. This simplifies bug fixing later on, makes it easier to review code changes, and tracks where you are and what you’re working on. Treat source control with respect and use it properly; it will reward you well.

Now, let’s look at an example of creating twenty example vm objects to test a method. Instead of constructing each object individually, we can create an array of twenty vmObjects using a function call. This approach is not only more readable but also reusable and adaptable to different use cases.

In addition to the above practices, consider reading release notes to see what changes have been introduced that may streamline your code. Embracing new syntax and abilities can make your life easier. Don’t be afraid to ask for help from peers or relevant communities. No one has seen it all! Asking for help can lead to problem-solving together, learning something new, or helping someone else learn. There is no negative in asking for help.

In conclusion, coding in vRO (vRealize Automation) or any other language should be about keeping it simple, reusable, and adaptable to different contexts. Remember to comment your code, use source control, and embrace new functionality and practices that streamline your workflow. Don’t be afraid to ask for help when needed, and always stay up to date with the latest releases and features.

As I settled back into work after the holiday break, I was greeted with a familiar yet frustrating issue in my home lab: vRA8 was not behaving as expected. After some investigation, I discovered that the root cause of the problem was a full /var/log directory, consuming 100% of the available space on the volume.

At first, I thought that simply removing some of the older log files would resolve the issue. And indeed, after cleanly shutting down and rebooting, the problem was temporarily resolved. However, I knew that this was not a sustainable solution, as I needed to keep the logs for troubleshooting and auditing purposes.

To prevent this issue from happening again in the future, I decided to investigate enlarging the volume. After some research, I found an article by Paul Davey, CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders. The article outlined a step-by-step approach to expanding the /var/log directory and resolving the issue.

According to the article, the first step was to identify the current size of the /var/log directory using the command “du -sh /var/log”. This command provides a summary of the disk usage for the specified directory. In my case, the output showed that the /var/log directory was consuming 100% of the available space on the volume.

The next step was to create a new partition for the /var/log directory using the command “sudo df -h /var/log”. This command provides a summary of the disk usage for the specified directory and also shows the percentage of the total disk usage. In my case, the output showed that the /var/log directory was consuming 100% of the available space on the volume, which confirmed my initial diagnosis.

Once I had identified the current size of the /var/log directory and confirmed that it was full, I could proceed with enlarging the volume. The article recommended using the “resize2fs” command to expand the partition. However, when I ran this command, I received an error message indicating that the partition was not mounted.

To resolve this issue, I needed to unmount the partition before attempting to resize it. I did this by running the command “sudo umount /var/log”. Once the partition was unmounted, I could proceed with resizing it using the “resize2fs” command.

After running the command, I received a confirmation message indicating that the partition had been successfully resized. To verify that the /var/log directory had been expanded, I ran the command “du -sh /var/log” again. This time, the output showed that the /var/log directory was no longer full and had freed up some space on the volume.

In conclusion, this experience taught me the importance of regularly monitoring and maintaining my home lab environment to prevent issues such as this from occurring. Additionally, I learned a valuable lesson about the importance of keeping track of disk usage and enlarging partitions as needed to ensure that the system remains healthy and functional.

Overall, this experience reinforced the importance of proactive maintenance and monitoring in maintaining a healthy and functional home lab environment. By following the steps outlined in the article and taking preventative measures, I was able to resolve the issue and ensure that my home lab continued to function optimally.

VMware vRealize Suite Lifecycle Manager 8.6: Outbound Notifications – A Game Changer!

The latest release of VMware vRealize Suite Lifecycle Manager (8.6) has introduced a new feature that promises to revolutionize the way we receive updates and notifications from the platform. Say goodbye to the days of manually checking for updates and hello to a more streamlined and automated process with Outbound Notifications!

Configuring Outbound Notifications is easy and straightforward. You can choose from three methods to receive notifications: Microsoft Teams, Slack, or email. If you opt for email, you’ll need to provide the following details:

1. SMTP server address

2. SMTP server port

3. SMTP username and password (if using a secured SMTP server)

4. Your Lifecycle Manager appliance will need access to the internet (through a configured proxy server is ok)

Once you have entered all the details, ensure you send a test email message to confirm that everything is working as expected. Don’t forget to hit save!

Configuring SMTP Server Settings

To configure your SMTP server settings, head into the Settings page of the Lifecycle Manager appliance and select the “SMTP” option from the left-hand menu. Enter the required details, such as the SMTP server address, port, username, and password.

Configuring Outbound Notifications

To configure outbound notifications, head back into the Settings page and select the “Outbound Notifications” option. Choose your desired frequency (daily is a good starting point for testing) and enter your recipients list. Select the notification triggers you want to receive, such as product updates, license health updates, or all notifications. Hit save, and you’re done!

Example Email Received

Here’s an example of what you might receive in your inbox:

Subject: vRealize Suite Lifecycle Manager Update Notification

Dear [Your Name],

This is a test email notification from VMware vRealize Suite Lifecycle Manager 8.6. You have selected to receive notifications via email for the following triggers:

* Product Updates

* License Health Updates

Please note that this is just a test email and you will only receive actual notifications if there are updates or changes to your vRealize Suite products.

—

As great as this new feature is, there are a few bits missing from the roadmap that would make it even more powerful. For instance, it would be fantastic if product update notifications could go to our operational teams and license health updates could go to our licensing team. However, this is a great step in the right direction, and we can expect even greater benefits in the future.

In conclusion, VMware vRealize Suite Lifecycle Manager 8.6’s Outbound Notifications feature is a game changer for automation and IT professionals who want to stay on top of their product updates and notifications without having to manually check the platform. With its ease of use and flexibility, this feature promises to revolutionize the way we work with vRealize Suite products.

—

Paul Davey is CIO at Sonar, Automation Practice Lead at Xtravirt, and a guitarist in The Waders. He loves IT, automation, programming, and music.

I recently had some fun and games with vRA 8.2’s extensibility capabilities, particularly with PowerShell support for vRA actions. I wanted to see what I could break, so I tried to obtain the ‘userName’ of the requester from the metadata section using PowerShell. However, no matter what I did, the metadata always remained empty.

I then discovered that using the Flow type of action can be quite handy. This allows me to chain multiple actions together and pass output from one action to another by updating values. What I didn’t realize at first was that I could also add new properties to the payload with a value, use it in the next action, and then remove it so that there is no ‘secret data’ left over on the deployed resource properties.

Here is an example of a simple PowerShell action I wrote:

The $payload that is injected into the function contains all the information and properties as of the time of the subscribed event. I create a new object, copy all of the payload to it. I then pass the new payload, stored as $outputs to the Add-Member PowerShell function. I add a new property called ‘Testing’ and set a value on it of ‘Michael.’ Finally, I return the $outputs, sending this object as an output that will be used as the payload into the next action in the flow.

In the second action, I again take the $payload and make a new object and copy all of its properties and values. To prove that the previous action’s output contains the new ‘Testing’ property, I write out the value to the console [log]. Finally, I remove the property from my $outputs object and return it.

When the blueprint is requested following the action executions, you can clearly see our new property ‘Testing’ printed out to the screen. However, when we look at the properties of the deployed resource once deployment is complete, the property is not shown.

This demonstrates how we can add new properties to the payload and use them in subsequent actions without leaving any ‘secret data’ behind on the deployed resource properties. Additionally, this shows how we can chain multiple actions together using the Flow type of action and pass output from one action to another by updating values.

I hope that someone out there can tell me what I have done wrong! Please let me know if you have any answers on a postcard.

—

VMware vRA8 Cheat Sheet

Welcome to the VMware vRA8 cheat sheet! This document is designed to provide a quick reference guide for common tasks and questions related to vRA8. It will evolve over time to cover more topics and become a single source for all things you forget, common questions with answers, and anything else that might be useful.

vRA8 FQDN Links

—————-

To access the vRA8 Control Center, use the following link in your chosen web browser:

https:///vco-controlcenter

To access the vRA8 Automation UI API Documentation, use the following link:

https:///automation-ui/api-docs/

Note: Replace with your vRA8 FQDN.

Day 2 Actions for vSphere

—————————

If you’re looking for a simple Day 2 action example for vSphere, check out the following link:

How to create a Cloud Assembly resource action to vMotion a virtual machine (vmware.com)

Critical Vulnerabilities in Apache Log4j

—————————————–

Recently, critical vulnerabilities in Apache Log4j were publicly disclosed, which impact VMware products. To learn more and what to do about it, follow this link:

Cloud Assembly Resource Flags for Requests (vmware.com)

Cloud Assembly Expression Syntax (vmware.com)

Quick Tips and Shortcuts

————————-

Here are some quick tips and shortcuts to help you work more efficiently with vRA8:

* Select multiple lines and then hold down the Ctrl key and press K followed by C to comment them out.

* To uncomment, hold down the Ctrl key and press K followed by U.

* Select multiple lines and then press the Tab key to indent them.

* To remove the indent, select the lines and then press the Shift key and the Tab key simultaneously.

That’s it for now! We hope you find this cheat sheet helpful in your vRA8 journey. Stay tuned for more updates and additions as we continue to evolve this document over time.

—

Paul Davey, CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders, loves IT, automation, programming, music, and is the copyright owner of AutomationPro 2018.

Integrating Puppet Enterprise with vRA 8.3: A Step-by-Step Guide

If you’re looking to integrate Puppet Enterprise with VMware vRealize Automation (vRA) 8.3, you might have encountered some obstacles in the process. In this blog post, we’ll walk you through the necessary steps to configure the integration between Puppet Enterprise and vRA 8.3. Note that these instructions are based on a freshly installed Linux VM for the Puppet primary server install, so make sure to follow them in order before installing Puppet Enterprise.

Step 1: Update CentOS

Before we begin, ensure that your CentOS is up to date by running the following command:

sudo dnf -y update

Step 2: Install Utilities

Next, install the required utilities by running the following commands:

sudo dnf -y install wget curl vim nano open-vm-tools bash-completion

Step 3: Set Hostname

Ensure that your hostname is set correctly by running the following command:

sudo hostnamectl set-hostname hostname_fqdn_format

Step 4: Create User for Integration

Create a user for the integration between Puppet and vRA by running the following commands:

sudo adduser account_name

Set password for the account by running:

sudo passwd account_name

Add the user to the wheel group by running:

sudo usermod -aG wheel account_name

Step 5: Disable Firewall

Disable the firewall by running:

sudo systemctl stop firewalld

sudo systemctl disable firewalld

Step 6: Create File in /etc/sudoers.d/ Directory

Create a file in the /etc/sudoers.d/ directory with the following contents:

account_name ALL=(root) NOPASSWD:/opt/puppetlabs/bin/puppet node purge *

account_name ALL=(root) NOPASSWD:! /opt/puppetlabs/bin/puppet node purge *[[:blank:]]]*

account_name ALL=(root) NOPASSWD:/opt/puppetlabs/bin/puppet config print *

account_name ALL=(root) NOPASSWD:! /opt/puppetlabs/bin/puppet config print *[[:blank:]]]*

account_name ALL=(root) NOPASSWD:/opt/puppetlabs/bin/facter -p puppetversion

account_name ALL=(root) NOPASSWD:/opt/puppetlabs/bin/facter -p pe_server_version

account_name ALL=(root) NOPASSWD:/opt/puppetlabs/bin/puppet agent -t

account_name ALL=(root) NOPASSWD:/bin/kill -HUP *

account_name ALL=(root) NOPASSWD:! /bin/kill -HUP *[[:blank:]]]*

account_name ALL=(root) NOPASSWD:/etc/puppetlabs/puppet/ssl/ca/ca_crl.pem

Step 7: Download Puppet Enterprise

Download the latest version of Puppet Enterprise from the Puppet website by running:

sudo curl -JLO ‘https://pm.puppet.com/cgi-bin/download.cgi?dist=el&rel=8&arch=x86_64&ver=latest’

Step 8: Install Puppet Enterprise

Extract the installer files by running:

sudo tar -xf *puppet-enterprise*.tar.gz

Install Puppet Enterprise by running:

cd ./puppet-enterprise*/

sudo ./puppet-enterprise-installer

Step 9: Set Console Password

Set the console password for your Puppet infrastructure by running:

sudo puppet infrastructure console_password

Step 10: Execute the Puppet Agent (twice)

Execute the Puppet agent twice to complete the integration by running:

puppet agent -t

puppet agent -t

At this point, you are now able to configure the integration in vRA. Specify the account to use as the one you configured above as account_name and make sure to tick the ‘Use Sudo commands for this user‘ tickbox.

We hope these instructions have helped you integrate Puppet Enterprise with vRA 8.3 successfully!

Creating an ABX Action to Raise a Jira Ticket on Deployment Failure

As a CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders, I love automation and the power it has to streamline processes and improve efficiency. Recently, I challenged myself to create an ABX action that would raise a Jira ticket when a deployment fails. Here’s how I did it and what I learned along the way.

First, I needed to install the atlassian-python-api library, which is required for interacting with Jira. Once I had installed the library, I created three action constants: one for the Jira URL, one for a Jira user account, and finally, an encrypted one for the Jira account password.

Next, I added new inputs for each of these action constants, so that the user can enter the necessary information to raise a Jira ticket. I also set up the action to be triggered on one event subscriptions, specifically Deployment completed. To ensure that the action is only triggered when a deployment fails, I used a Condition filter to check if the deployment status is “failed”.

With all of the pieces in place, I tested the action and was thrilled to see that it worked as expected! When a deployment fails, the Jira ticket is raised automatically, saving time and effort for my team.

This use case shows the potential for further integration between Jira and vRA8. By automating the process of raising a Jira ticket when a deployment fails, we can improve our incident management processes and ensure that issues are addressed quickly and efficiently.

In conclusion, creating an ABX action to raise a Jira ticket on deployment failure was a fun and educational challenge. It demonstrates the power of integration between Jira and vRA8, and highlights the potential for further automation in our IT processes. As a CIO, Automation Practice Lead, and guitarist, I will continue to explore new ways to leverage automation and improve efficiency in my teams.

Here is a 500-word blog post based on the information provided:

—

Building a New Centos7 Template with Packer and Code Stream

In this post, we will detail a simple Code Stream pipeline that builds a new Centos7 template using Packer. We will also cover how to configure Packer to create templates for your lab environment.

To begin, we will make a few assumptions:

* You have a basic understanding of Packer and Code Stream.

* You have the necessary tools installed on your system, including Docker and Git.

* You have a GitHub repository containing the Packer build definition and kickstart file for the Centos7 build.

To get started, we will need to download Packer and create a new pipeline in Code Stream. We can do this by following these steps:

1. Open Code Stream and click on the “New Pipeline” button.

2. Give your pipeline a name and select “Docker” as the runtime.

3. Click on the “Inputs” tab and add three input parameters: GIT_REPOSITORY_PATH, PACKER_FILE, and PACKER_URI. These inputs will be used to configure Packer and obtain the necessary files for the build process.

4. Click on the “Configure Workspace” button and select the Docker radio option for the Auto inject parameters parameter. This will ensure that the input parameters we configure are injected into our Docker container when our pipeline executes.

5. Save your pipeline configuration.

Next, we will need to provide default values for our input parameters. To do this, we can add three variables to obfuscate the values that our pipeline will use:

1. SECRETYour projectssh_password (the password that will be used to SSH into your Centos7 VM)

2. SECRETYour projectvcenter_password (the password for your adminstrator@vsphere.local account)

3. SECRETYour projectGithub Access Token (the access token generated on Github)

We can add these variables by clicking the “New Variable” button in the Configuration section and adding the details below:

Type: Project Name

Value: Your projectssh_password

Type: Project Name

Value: Your projectvcenter_password

Type: Project Name

Value: Your projectGithub Access Token

Once we have configured our pipeline and variables, we can move on to the next stage. We will create a new stage for each task, grouping related tasks together to achieve our end goal of building a new Centos7 template.

The main purpose of this task is to download and unzip Packer using a new variable. We will add some bash code to download Packer using a new variable. This task is very straightforward.

Next, we will create a new stage for the Packer validate switch. This stage will carry out our instructions and ultimately generate our new VM template. Before this, we will carry out a find and replace function to insert the root password into the Centos7 kickstart file. We will also download and add a package into our Docker container, xorriso. This package allows Packer to create our kickstart ISO file on the fly.

You should now be in a position to execute your pipeline and build your first template. Congratulations! In future posts, I will look to improve on this process.

Footnote: Image attribution on this post: Design vector created by macrovector. Tags: automation, build, cloud, code, codestream, hashicorp, icosa, packer, vra8, paul_davey. CIO at Sonar, Automation Practice Lead at Xtravirt and guitarist in The Waders. Loves IT, automation, programming, music. Copyright AutomationPro 2018.

Grouping Custom Properties in Cloud Templates

When working with cloud templates, it is common to have a large number of custom properties that need to be set. These properties can be grouped logically into categories to make them easier to manage and maintain. In this article, we will explore the benefits of grouping custom properties and how to do it in your cloud templates.

Benefits of Grouping Custom Properties

—————————————

Grouping custom properties has several benefits, including:

### Easier Maintenance

When custom properties are grouped logically, it is easier to maintain and update them. You can make changes to one property without affecting the others.

### Improved Readability

Grouping custom properties makes it easier to understand the configuration of your cloud templates. It helps to reduce complexity and improve readability.

### Better Organization

Grouping custom properties allows you to organize your configuration in a more logical and structured way. This can help to reduce confusion and errors.

### Extensibility

When custom properties are grouped logically, it is easier to extract values for use in extensibility actions. Your custom properties are provided as objects within an array, which is simple to iterate through from vRO or an ABX action.

Grouping Custom Properties in YAML

————————————-

To group custom properties in your cloud templates, you can use nested objects. For example, you can create a resource object with nested properties, and then group your custom properties within those nested properties. Here is an example of how to group custom properties in a cloud template YAML file:

“`

formatVersion: 1

inputs:

businessUnit:

type: string

title: Business unit

vmNotesEntry:

type: string

title: VM Notes entry

resources:

Cloud_vSphere_Machine:

type: Cloud.vSphere.Machine

allocatePerInstance: true

properties:

cmdbProperties:

– deploymentName: ${env.deploymentName}

deploymentDate: ${env.requestedAt}

requestor: ${env.requestedBy}

businessUnit: ${input.businessUnit}

deploymentProperties:

– vmNotesEntry: ‘${input.vmNotesEntry}’

operatingSystemType: ‘linux’

image: ubuntu

cpuCount: 1

totalMemoryMB: 8192

storage:

constraints:

– tag: storage.profile:gold

networks:

– network: ${resource.Cloud_vSphere_Network.id}

assignment: static

“`

In this example, we have created two groups of custom properties: `cmdbProperties` and `deploymentProperties`. The `cmdbProperties` group contains properties that are used to populate a CMDB, while the `deploymentProperties` group contains properties that are used to configure the deployment.

Conclusion

———-

Grouping custom properties in your cloud templates can help to improve maintenance, readability, and organization. By using nested objects to group your custom properties, you can make it easier to extract values for use in extensibility actions. Standards should not be understated. So go and give your YAML code a spring clean and de-clutter! You will feel much better for it afterwards.