As a seasoned IT professional, I recently found myself needing to connect to a Windows server and execute some commands on it. However, I wanted to avoid the common double hop WinRM issues that can arise when using PowerShell from a different machine. Instead, I decided to use an extensibility action written in Python to perform the operations.

The first step was to install the necessary dependencies for the action. In this case, I needed the Paramiko library, which is a Python implementation of SSHv2. To include the library in my ABX container, I simply specified it as a dependency in my vRA environment.

Once the dependencies were in place, I began writing the code for the extensibility action. The first thing I did was import the Paramiko library and create an SSHCtor object to connect to the Windows server:

“`

import paramiko

ssh = paramiko.SSHClient()

“`

Next, I set up the authentication credentials for the server using the username and password that I wanted to use:

“`

ssh.set_username(‘my_username’)

ssh.set_password(‘my_password’)

“`

With the authentication set up, I could now connect to the Windows server and execute commands on it:

“`

stdin, stdout, stderr = ssh.exec_command(‘ipconfig’)

output = stdout.read()

“`

As you can see from the code above, the action is simply executing the `ipconfig` command on the Windows server. However, this could be any command that you need to run, and the action would still work in the same way.

One thing to note is that I didn’t use vRO for this extensibility action. Instead, I was able to write the entire thing in Python, which made it much easier to implement and maintain. Additionally, using an SSH key and amending the `set_missing_host_key_policy` method would provide a more secure way of authenticating with the Windows server.

Here’s what the output of the action looks like in vRA:

“`

{

“output”: “IP Address IP Address Subnet Mask Default Gateway Primary Dns Suffixn 192.168.1.100 192.168.1.1 255.255.255.0 192.168.1.1 .example.com”

}

“`

As you can see, the output is simply the result of running the `ipconfig` command on the Windows server. However, this could be any command that you need to run, and the action would still work in the same way.

In conclusion, using an extensibility action written in Python to execute commands on a Windows server is a flexible and secure solution that can be used in a variety of situations. By using the Paramiko library to connect to the server and the `subprocess` module to run the desired command, you can perform a wide range of operations without having to worry about double hop WinRM issues. Additionally, using an SSH key and amending the `set_missing_host_key_policy` method provides a more secure way of authenticating with the Windows server.

Integrating Ansible into vRA: A Step-by-Step Guide

If you’re looking to integrate Ansible into your vRealize Automation (vRA) environment, you’ve come to the right place. In this article, we’ll go over the process of setting up Ansible for integration with vRA, using a bash script to simplify the process.

First things first, let’s take a look at the specifications for the virtual machine that will be used as the Ansible control node:

* CPU: 2.5 GHz (or faster)

* RAM: 4 GB (or more)

* Storage: At least 30 GB of free space

* Operating System: Ubuntu 18.04 LTS or later

Once you have your virtual machine set up, it’s time to install the operating system and configure it according to the table below:

| Setting | Value |

| — | — |

| Time zone | UTC |

| Username | ansible |

| Password | |

Next, we’ll need to create a new account for Ansible integration. To do this, you’ll need to input the username and password for the new account when executing the script.

Now that we have our virtual machine set up and configured, it’s time to execute the bash script. This script will handle the installation of Ansible and its configuration for integration with vRA.

As the script executes, you can check the logfile for any errors. The logfile is located at /tmp/ansible_setup_helper_log. If there are any errors, you’ll need to address them before proceeding with the integration.

Once the execution is complete and there are no errors in the logfile, it’s time to switch over to your vRA 8.4 installation and configure the Ansible open source integration. The integration configuration in vRA is straightforward and self-explanatory, as shown in the screenshot below:

As you can see, the integration is relatively simple and involves selecting the appropriate options for your environment. Once validated and saved, the integration is ready to be incorporated into your cloud templates.

In conclusion, integrating Ansible into vRA is a straightforward process that can be simplified further with the help of a bash script. By following the steps outlined in this article, you’ll be able to set up Ansible for integration with vRA and automate your IT infrastructure like never before.

If you have any questions or need further assistance, feel free to reach out to me through my social media profiles listed below. I’m always happy to help!

Paul Davey is CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders. He loves IT, automation, programming, music, and more. You can follow him on Twitter, LinkedIn, or GitHub to stay up-to-date on the latest trends and best practices in IT automation.

Copyright AutomationPro 2018

As an IT professional, I have found myself in situations where I need to perform upgrades or maintenance on my infrastructure, but I am met with the frustrating obstacle of expired root passwords. This can be especially true when working in a lab environment, where changing the password frequently can become a tedious and time-consuming task. However, there is a way to negate this issue and avoid having to change your root password ever again.

To start, you will need to execute the following command to see the current configuration for the root account:

“`

cmk -s -p -c

“`

This will display the current configuration for the root account, including the expiration date of the password.

Next, you will need to execute the following command to set the password expiry period to be 9999 days in the future:

“`

cmk -s -p -c -e 9999

“`

This will set the password expiry period to 9999 days in the future, which is equivalent to never expiring.

Finally, you will need to execute the following command to set the minimum number of days between changes to 0:

“`

cmk -s -p -c -m 0

“`

This will ensure that the root password does not expire and cannot be changed for an extended period of time.

It is important to note that if you are running a cluster, you will need to perform these steps on every node individually. However, once completed, you will never have to change your root password again, saving you time and frustration in the long run.

In conclusion, this tutorial has shown how to negate the need for changing the root password ever again in Lifecycle Manager. By following these simple steps, you can ensure that your infrastructure is secure and easy to manage, without the burden of frequent password changes. So go ahead, take control of your infrastructure, and never let expired passwords hold you back again!

Sending Emails from ABX Actions in vRA8

As a fan of the ABX functionality in vRA8, I have been wanting to accomplish sending an email from an ABX for a while now. While there are plenty of resources available online for sending emails using public providers like Gmail or Amazon’s Simple Email Service (SES), I wanted to find a way to send emails using my internal MS Exchange Server. This proved to be a bit more challenging, but with some late nights and experimentation with different Python libraries, I was able to achieve my goal. In this blog post, I will share the steps I took to send an email from an ABX in vRA8.

First, I created four action constants to hold sensitive information:

| Name | Value |

| — | — |

| smtpLoginUsername | administrator@automationpro.lan |

| smtpServer | 10.0.10.13 |

| smtpLoginPassword | ****** (redacted) |

| smtpSender | administrator@automationpro.lan |

Next, I added each of these action constants as inputs for the ABX action. To do this, I selected “Action Constant” in the Type dropdown menu.

Two dependencies are required for this action to work properly. The first dependency is the exchangelib library, which can be found on GitHub. It’s important to specify the version of exchangelib as later versions have a conflict within the ABX execution environment. I used version 1.4.0 for my tests.

The second dependency is the python-dotenv library, which allows you to load environment variables from a .env file. This is necessary because the smtpLoginPassword action constant contains sensitive information that should not be hardcoded in the ABX.

With these dependencies added, I set up an event subscription to trigger the action to execute. This can be done by selecting “Event Subscription” in the Type dropdown menu and specifying the appropriate event. For example, you could subscribe to the “Deployment Completed” event to send an email after a deployment is complete.

Of course, you can add other inputs to the ABX action to include useful information such as the deployment name or any other relevant details. This will allow you to send more informative emails and make the process more efficient.

While it may seem like overkill to use an ABX to send an email, there are several benefits to this approach. For one, you don’t have to rely on external email providers, which can be useful in certain situations. Additionally, using an internal Exchange Server allows you to leverage the security and reliability of your own email infrastructure.

In conclusion, sending emails from ABX actions in vRA8 is a bit more involved than using public providers, but it’s definitely possible. By following these steps and using the appropriate dependencies, you can send emails from your ABX actions without relying on external services.

Working with Subscription Event Based vRO Workflows and ABX Actions in vRA8

As an IT professional, I have had to deal with my fair share of subscription event based vRO workflows and ABX actions. One of the frustrating aspects of working with these is that you often want to be able to develop in vRO using the vRA payload without having to constantly ask vRA to create a deployment just to push the payload downstream to vRO. In this blog post, I will discuss a recent approach that I have taken to overcome this challenge.

The Challenge

One of the challenges of working with subscription event based vRO workflows and ABX actions is that you want to be able to test and develop these workflows without having to constantly trigger vRA deployments. This can be time-consuming and can lead to a lot of unnecessary deployment activity. Additionally, if you are working on a large-scale vRO environment, the sheer number of deployments can become overwhelming.

The Approach

To overcome this challenge, I have been using a recent approach that involves triggering various vRA event subscriptions and storing the payload. This allows me to recall the payload and use it as much as I want to test and develop my vRO workflows and actions without having to touch vRA at all.

The Process

To use this approach, you will need to first download a package that includes three workflows, one action, and a configuration element with a path. Once you have imported the package into vRO, you can create an event subscription in vRA8 that will trigger the ‘Save vRA inputProperties’ workflow. When the event subscription executes, the input payload will be saved into the configuration element under a new attribute!

To use the saved configuration, you can use the included action, ‘LoadSavedInputPropertyDefinitions’ and pass its output into your workflow, mapping its output to your inputProperties payload. You can specify the project and the event that you want to use, as per the example in the included workflow ‘Simple Example Of Using Saved Data.’

Benefits

The benefits of using this approach are numerous. Firstly, it allows you to test and develop vRO workflows and actions without having to constantly trigger vRA deployments. This can save a significant amount of time and reduce the number of unnecessary deployments. Additionally, it allows you to use the vRA payload directly in your vRO workflows and actions, without having to modify the payload or create custom connectors.

Conclusion

In conclusion, using subscription event based vRO workflows and ABX actions can be a challenge, but there is a recent approach that can help overcome this challenge. By triggering various vRA event subscriptions and storing the payload, you can recall the payload and use it as much as you want to test and develop your vRO workflows and actions without having to touch vRA at all. This approach can save time, reduce the number of deployments, and allow you to use the vRA payload directly in your vRO workflows and actions.

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.

Infrastructure as Code (IaC) is a powerful concept that has revolutionized the way we manage and provision infrastructure. Terraform is an open-source tool that enables us to use IaC to define and manage our infrastructure. In this blog post, we will explore the basics of Terraform and how it can help us automate and streamline our infrastructure management processes.

What is Terraform?

Terraform is an open-source tool that allows us to define and manage our infrastructure using IaC. It provides a simple and declarative way to describe our infrastructure, and it automatically provisions and updates the resources based on the definitions we provide. Terraform supports a wide range of cloud and on-premises infrastructure providers, including AWS, Azure, Google Cloud, and VMware vSphere.

How does Terraform work?

Terraform works by using IaC to define our infrastructure. We write our definitions in plain text files, which makes it easy to learn and use. These definition files describe the blueprint of our infrastructure, including the resources we need, their properties, and how they should be configured. Terraform reads these definition files and creates a plan that outlines all the changes that need to be made to our environment. We can then apply the plan to provision or update our infrastructure.

Terraform provides several benefits over traditional infrastructure management methods. It allows us to define our infrastructure in a declarative way, which makes it easy to understand and maintain. It also enables us to version control our configurations, which makes it easier to track changes and roll back to previous versions if needed. Additionally, Terraform provides a graph that outlines all the components and settings in our plan, which allows it to map dependencies and execute as much of the plan as possible in parallel. This ensures that infrastructure changes can be carried out quickly and efficiently.

What are the key features of Terraform?

Some of the key features of Terraform include:

1. Infrastructure as Code (IaC): Terraform allows us to define our infrastructure using IaC, which makes it easy to manage and version control our configurations.

2. Declarative configuration: Terraform provides a simple and declarative way to describe our infrastructure, which makes it easy to understand and maintain.

3. Automated provisioning and updates: Terraform automatically provisions and updates our infrastructure based on the definitions we provide, which saves time and reduces errors.

4. Version control: Terraform allows us to version control our configurations, which makes it easier to track changes and roll back to previous versions if needed.

5. Parallel execution: Terraform creates a graph that outlines all the components and settings in our plan, which allows it to map dependencies and execute as much of the plan as possible in parallel.

6. Provider integration: Terraform supports a wide range of providers, including AWS, Azure, Google Cloud, and VMware vSphere. This enables us to use the same tool to manage multiple environments.

7. Custom provider development: If we need a provider that is not available, we can write our own to bridge the gap.

Conclusion

In conclusion, Terraform is a powerful tool that enables us to use IaC to define and manage our infrastructure. It provides a simple and declarative way to describe our infrastructure, and it automatically provisions and updates the resources based on the definitions we provide. With its support for multiple providers and custom provider development, Terraform is a versatile tool that can be used to manage a wide range of environments. In future posts, we will explore how to use Terraform in a VMware vSphere environment.