Tag Archives: Powershell

Running Docker inside of VCSA 6.7

During this years VMware {code} Hackathon at VMworld Vegas I submitted a team project which ran PowerShell within the vSphere Client.  To achieve this I had to create a Docker container running PowerShell Core.  During development I ran the container on an Ubuntu Linux server.  For my final submission at the Hackathon I wanted to minimise the dependency to run a separate Linux VM.  So I created a process to install and run Docker directly on VCSA 6.7.

The process to install and run Docker within VCSA 6.7 is surprisingly very simple.  As a reference I used a blog post from William Lam but with a small modification to correctly load the Bridge module in VCSA 6.7 (as opposed to VCSA 6.5 in William’s post).

I thought I would share the steps I used below for others to experiment with.

Step 1.
SSH to the VCSA VM and enter the Shell

Install the docker package

tdnf -y install docker

Step 2.
Load the kernel module to start the Docker client. (This step needs to be re-run if the VCSA is rebooted)

modprobe bridge --ignore-install

If successful no information should be returned.

You can check if the module is installed by running the following

lsmod | grep bridge

[email protected] [ ~ ]# lsmod | grep bridge
bridge                118784  0
stp                    16384  1 bridge
llc                    16384  2 stp,bridge

Step 3.
Enable and start the Docker Client
systemctl enable docker

systemctl start docker

 

Making the Bridge module load after a reboot (Optonal)

As with William’s process to install and run Docker Step 2 needs to be re-run each time the VCSA is rebooted.  The solution to make the Bridge module automatically load after a reboot happens to be exactly the same.  I’ve included the specific commands to simplify the process.

Step 1.
Make a backup of the file we are going to modify.

cp /etc/modprobe.d/modprobe.conf /etc/modprobe.d/modprobe.conf.bak

Step 2.
Comment out the line that disables the Bridge module from loading

sed -i "s/install bridge/# install bridge/g" /etc/modprobe.d/modprobe.conf

Step 3.
Create a new config file to load the Bridge module

touch /etc/modules-load.d/bridge.conf

Step 4.
Specify the name of the Bridge module to load at reboot

echo bridge >> /etc/modules-load.d/bridge.conf

That’s all we need to do to start running containers on VCSA 6.7.  Excluding the steps to have the Bridge module persist after a reboot and it’s even simpler.

 

Running a Docker container

If you want to test your first container on VCSA you can try my Docker image I build for the Hackathon.  The steps are very simple and listed out below.

Step 1.
Download the two required files from my GitHub repo

curl -O https://raw.githubusercontent.com/originaluko/vSphere_PowerCLI/master/Dockerfile

curl -O https://raw.githubusercontent.com/originaluko/vSphere_PowerCLI/master/supervisord.conf

Step 2.
Build the Image

docker build -t vsphere-powercli .

Step 3.
Start the container with this image

docker run -d -p 4200:4200 --name vsphere-powercli vsphere-powercli

You can check if the docker container is running with the below command.

docker stats

You can check if the port has been mapped correctly by running

docker port vsphere-powercli

Step 4.
Open a web browser and test if you can connect directly to the container through the browser and login to the PowerShell prompt.

https://{my_vcsa}:4200

Accept any certificate warning and login with the default credentials of powercli / password

I hope that was all fairly straight forward  to understand.  It’s actually all very simple to achieve under VCSA 6.7.  As in William’s post, none of this is supported by VMware, so user beware.  Though I have been playing with Docker inside of VCSA 6.7 for quite a few months now with no noticeable issues.

If you want to see my full VMworld Hackathon project you can check it out over in my GitHub repo

VMware {code} Hackathon – VMworld Vegas 2018

It was a tough decision.  Hit up the Cohesity party and watch Snoop Dogg perform or participate in the VMware Code Hackathon.  No, the decision was easy, I was always going to take part in the Hackathon.  I had regretted not taking part last year and I was super keen for this year’s hackathon, I wasn’t going to miss it.  I think it’s safe to assume I chose wisely.  With my team, Team vMafia, coming away with the winning project and an impromptu segment on Virtually Speaking!

Left to right: Anthony Spiteri, Matt Allllford, Mark Ukotic, and Tim Carman

This year’s Hackathon broke from the format from previous years.  Whereas in previous year you showed up, attempted to form a team and an idea, then execute all within a handful of hours.  This year the Hackathon chose to leverage HackerEarth and give participates three weeks to create a team and build out a hackathon idea.  Without a doubt this was the single biggest improvement to the format of this years event.  Leading to some great projects being built.

Rewind a month, In the week leading up the Hackathon I started thinking about an idea I could submit.  Struggling to think of something I started playing a bit of buzzword bingo.  PowerShell and PowerCLI were big passions of mine.  Docker was an area I wanted to explore more into and I had wanted to learn more about what the vSphere SDK could do.  At that point an idea just naturally presented itself.  Could you run a PowerShell console with PowerCLI modules inside the new HTML5 vSphere Client?

At this point I didn’t know I had a good idea, let alone just an idea.  I ran it past some friends within a local Aussie Slack group I’m part of.  It went down extremely well but I still had my doubts.  So I did what anyone would do and went to ‘other’ friends who also thought it was a great idea.  So OK I thought, I have an idea.

Having recently quit my job I was able to focus 100% of my attention to the project.  Great for me and the Hackathon, I guess bad for everyone else with jobs 😛  I formed a team and without any persuasion a number of the Aussie Slack team jumped on-board including Anthony Spiteri, Matt Alffford, and Tim Carman.  We were going to need a lot of help so I reached out to a few friends for assistance.

First up was my ex-manager John Imison for some assistance around Docker.  Installing Docker and running a container is one thing.  But building a container image was something new.  John provided some great advice and ideas around building the docker image.  Actually far too many for a Proof of Concept hackathon idea that I could implement in a practical timeframe.  If this project continues to develop past hackathon expect to see some more of his ideas integrated in.

Next I hit up my Developer brother-in-law Simon Mackinnon.  After spending a couple days crying in front of my computer attempting to build and configure my vSphere SDK environment.  I went to Simon for help in decipher the vSphere Plugins.  Simon helped put us on the right track with finding the easiest solution to embed a console into the vSphere Client.

After a solid week of learning Docker and the vSphere SDK it was time to actually build something and put it all together.  Believe it or not this was actually the easiest part of the whole project.  Once I knew how to build a Docker image it was just a matter of customising it for my purpose.  The same went for the vSphere Plugin.  Take a sample plugin and modify it for purpose.

The night of the Hackathon at VMworld was fairly cruisey for Team vMafia 2.0.  Our project was built.  We performed some final testing to prove it all worked.  We gave some of the judges a walk-through of what we built.  I should point out that the night was extremely well run.  Previous years had some controversy around the event.  None of that existed this year.  Two rounds of hot food was served with lots of drinks and candy lollies to be had.  With WiFi and Internet stable and strong.  The event was pushed back from an original start time of 6:30 to 7:30.  This was due to some of the judges holding training sessions / presentations on some of the hackathon themes.  At 10 PM all the teams were given two minutes to present their ideas and projects in front of a projector.  A completed project was not a requirement to present.  The judges had a number of criteria they were working off for judging, such as how well you kept to your 2 minutes and how well you conveyed your idea.

Team vMafia were one of the last to present.  I was certainly not confident as there was some great ideas before us.  I spoke for our team.  I’m not sure how long I presented for but it was definitely less than the 2 minutes.  During the entire presentation i had Anthony Spiteri whispering in my hear, ‘hurry up, don’t waste time, go go go’.  Distracting, yes, but he did keep me on point.  The judges then left the room to vote.  They came back pretty quickly with it being a unanimous decision that Team vMafia had the winning idea of an integrated PowerShell console inside the H5 vSphere Client.  It was not until they called our name that I thought, ‘Hey, maybe we do have a good idea’.

Screen of vSphere PowerCLI being used within the vSphere Client

The night didn’t quite end there for Team vMafia.  After the event we passed by Eye Candy in Mandalay Bay where we ran into the Virtually Speaking guys, Pete Flecha and Glenn Sizemore.  While Anthony denies it , I think this was his master plan for us to bump into them.  We had some great conversations with the guys and they were super excited for our Hackathon project and win that they invited us onto the podcast the following day.

The episode of Virtually Speaking with Team vMafia can be found here.   While I find it hard to listen to myself I’m assured that the segment was really good and funny.  Our segment also managed to make the cut in the same episode as Micheal Dell and Pat Gelsinger which I have to say is pretty cool.  I huge thank you to Pete and Glenn for allow us to come into the show!

Finally I can’t end without linking to the actually project.  During the development I used my own private repos but have now moved it over to my GitHub page.  The project has the very original name of vSphere PowerCLI.  As far a disclaimers go the project is free to download and use at will.  I’m not really holding any restriction on it.  It was always just a Proof of Concept idea I had.  The instructions are hopefully fairly easy to follow.  Most people have been taking a snapshot of their VCSA and using the option to run Docker on their VCSA.  If the support is there I’ll be considering developing the project past hackathon idea.

Thanks for everyone’s support and kind words and let me know if you’d like to see the project developed further.

 

Getting Started With Ansible And PowerCLI

Continuing on my journey of learning Ansible with a twist of VMware (see my previous post on Getting started with Ansible and VMware).  I’ve started to play around with PowerShell Core and PowerCLI in Ansible.  What I’ve found is that you can do a lot of interesting things with PowerCLI in Ansible, removing the need for a Windows jumphost.

Now I think the magic here is really just using PowerShell Core with Ansible.  However, I wanted to tackle this once again from the VMware admin view point.  So I’m focusing on using Ansible to leverage PowerCLI to connect to vCenter server and to perform some PowerShell / PowerCLI actions, all running from the local Ansible host.

As with my previous post, this is not really an Ansible 101 guide.  Rather the goal here is to show you, the reader, what’s possible with PowerShell Core and PowerCLI using Ansible.  Getting you thinking about how you might leverage this in your environment.

So let’s lay the framework of what we’ll cover below.  I’m going to assume Ansible has already been installed.  I’ll go through the steps to install PowerShell Core onto the Ansible host.  Then install the VMware PowerCLI modules and run some basic Cmdlets.  Finally I’ll cover the more interesting Ansible integration part.

In my lab I’m using Ubuntu.  So everything I’m going to do will be based on this distro.  So let’s get started.

Installing PowerShell

Install PowerShell Core with the following command.  Depending on your Linux distro and version you may have to set an updated MS repo.

sudo apt-get install -y powershell

Next sudo into PowerShell.  We use sudo because the next few commands we run in PowerShell will need elevated privileges.

sudo pwsh

Install the VMware PowerCLI modules with the first command below.  Then change your PowerCLI settings to ignore self signed certificates.  If you have signed certs you can skip this step but most of us probably don’t.

PS /home/mukotic/> Install-Module vmware.powercli

PS /home/mukotic/> Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Scope AllUsers

At this point you can exit out of the PowerShell prompt and come back in without using sudo, or just keep going as is, the choice is yours.  We can now make our first connection to our VCSA host and if successful run a few basic PowerCLI Cmdlets like Get-VMHost.

PS /home/mukotic/> Connect-VIServer {vcsa_server}

PS /home/mukotic/> Get-VMHost

Creating the PowerShell Script

Assuming all is successful up to this point we can now turn the above commands into a PowerShell script called vcsa_test.ps1.  It’s not ideal but for the sake of demonstration purposes I put the username and password details into the script.  I like to pipe the vCenter connection to Out-Null to avoid any stdout data polluting my output results.

Connect-VIServer -Server vc01.ukoticland.local -User {vcsa_user} -Password {vcsa_pass} | Out-Null
$result = Get-VMHost | Select-Object -ExcludeProperty ExtensionData | ConvertTo-Json -Depth 1
$result | Out-File -FilePath vmhost.json

Creating the Ansible Playbook

We can now create an Ansible Playbook that will call our PowerShell script.  Exit out of the PowerShell prompt and using vi, nano, or another editor create a file called vcsa_test.yml and enter the below.  The only real important line is the one with ‘command’.  Remember that spacing is important in the yaml file.

---
- hosts: localhost

  tasks:
    - name: Run PowerShell Core script
      command: pwsh /home/mukotic/vcsa_test.ps1
      ignore_errors: yes
      changed_when: false
      register: powershell_output

Now try running the Ansible Playbook we just created and check if it runs.

ansible-playbook vcsa_test.yml

Again if all successful the results should look something similar to below.

PLAY [localhost] ****************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************
ok: [10.10.10.10]

TASK [Run PowerShell Core script] ********************************************************************************************************************************
ok: [10.10.10.10]

PLAY RECAP *******************************************************************************************************************************************************
10.10.10.10 : ok=2 changed=0 unreachable=0 failed=0

Finally we check if our ouput file created correctly.

cat vmhost.json

[
{
“State”: 0,
“ConnectionState”: 0,
“PowerState”: 1,
“VMSwapfileDatastoreId”: null,



“DatastoreIdList”: “Datastore-datastore-780 Datastore-datastore-529 Datastore-datastore-530”
}
]

What we covered above are just some of the fundamentals to running a PowerShell Core script on an Ansible host.  There are still a lot of improvements that can be made.  The most obvious is we can move our username and password details out of the main PowerShell script.  We could also take the json output and pass it into the Ansible Playbook to read the values for later use in our plays.  But most importantly we can now start to make advanced configuration changes in vSphere where Ansible modules don’t exist.

References

Installing PowerShell Core on Linux -- MS

5 Getting Started PowerShell Core Tips

Now that PowerShell Core 6 has gone GA, it’s a great time to start learning this new version.  So I thought I would put together 5 quick tips and tricks that I’ve used to make using PowerShell Core a little easier for myself while making the transition from Windows PowerShell.

While the intention of this post is not to go into the differences between Windows PowerShell and PowerShell Core.  Despite the slightly mixed or vague messaging we getting from Microsoft on the future of PowerShell.  I think it’s safe to say that PowerShell Core is not a replacement or upgrade for Windows PowerShell but it is the future of PowerShell.  As soon as more and more Modules start supporting PowerShell Core the argument to switch over will become easier.

So while people continue to argue if they should make the switch to PowerShell Core or not here are 5 tips and tricks I have used with PowerShell Core in the meantime.  It’s also worth noting that all of these tips are Windows specific.

Tip 1. Modify your default profile.

I wrote a post on this a little while back on how to modify your default profile in Windows PowerShell here.  I recommend taking a look at it and bring a bit of yourself to PowerShell.  Much of what I discuss in the post is still valid for PowerShell Core.  The only different really is your profile path in PowerShell Core.

You can easily locate your profile in PowerShell Core by typing $Profile at the command profile.  Unless you’ve already modified it, there’s a good chance that the location path doesn’t actually exist on your PC.

In Windows 10 the path is C:\Users\{username}\Documents\PowerShell\Microsoft.PowerShell_profile.ps1.  If it doesn’t exist go ahead and create the folder PowerShell in your Documents folder.  Then create a file called profile.ps1 and modify to your hearts content.  All the steps are laid out in my previous post I mentioned on modifying your Windows PowerShell profile. Without any specific Core modifications I took my already modified profile.ps1 profile from Windows PowerShell and copied it to this location.

Original PowerShell Core console on the left with my modified profile.ps1 profile on the right.

Tip 2. Modify VS Code to use PowerShell Core Integrated Terminal

While I still do like to use the Windows PowerShell ISE with ISE Steroids from time to time.  I’ve for the most part switched to VS Code for most of my day to day use.  If you haven’t yet made the switch I highly recommend downloading it and giving it try.  It’s fast, stable, and uses relatively little memory compared to the PowerShell ISE.

Currently as of VS Code 1.22 you can’t run multiple different Integrated Terminals.  But there’s still a few things we can do here.  We can change our default Integrated Terminal to PowerShell Core.

Open VS Code and navigate to File / Settings.  On the left you have your Default Settings and on the Right you have your User Settings to overwrite the Default Settings.

Enter in the following between the two { }

// PowerShell Core
“terminal.integrated.shell.windows”: “C:\\Program Files\\PowerShell\\6.0.0\\pwsh.exe”,

Now when you open up an Integrated Terminal it should default to PowerShell Core (pwsh.exe)

You can download VS Code from https://code.visualstudio.com/

Tip 3. Modify Console Window properties

This one kind of carries on from Tip 1.  More visual customisations on how a terminal session looks and is very much personal preference.  Right click on the top left and pull up the terminal properties.  I drop the Font size down to a non standard size of 13 which fixes what I feel is an overly elongated terminal.  Increase the Layout windows size to 130 x 40 and hard code a different background colour.  Finally I increase the Command History buffer size.

Tip 4. Use Chocolatey to Install and Upgrade PowerShell Core.

Chocolatey is a Windows Package Manager similar to apt-get or yum in the Linux world.  What I love about Chocolatey is that it handles installing and configuring all dependencies you require when installing an application.

Installing Chocolatey is as simple as running a few commands on one line in PowerShell.  Installing / Upgrading Powershell Core is just has simple once Chocolatey is installed.

The below command will install Chocolatey from a Powershell prompt.

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString(‘https://chocolatey.org/install.ps1’))

This next command will install PowerShell Core and any dependencies it needs.  Replace install with upgrade if you have a previous version of PowerShell Core installed.

choco install powershell-core -y

You can download Chocolatey from their website at https://chocolatey.org/  and instructions to install PowerShell Core can be found at https://chocolatey.org/packages/powershell-core

Tip 5. Find some modules

PowerShell Core by default uses a different module path to load modules. Meaning that all your Windows PowerShell modules won’t just import and run. This doesn’t mean that they won’t work. PowerShell Core has been designed to be has backwards compatible as possible. While modules like Active Directory won’t work correctly many still do.

By installing the WindowsPSModulePath module from the PowerShell Gallery, you can use Windows PowerShell modules by appending the Windows PowerShell PSModulePath to your PowerShell Core PSModulePath.

First, install the WindowsPSModulePath module from the PowerShell Gallery

Install-Module WindowsPSModulePath -Force

Then run the Add-WindowsPSModulePath cmdlet to add the Windows PowerShell PSModulePath to PowerShell Core:

Add-WindowsPSModulePath

This will now allow you to now start using all your current Windows PowerShell modules in Core (in your current session).  This is not a guarantee that they will work though.  So test thoroughly.

If you’re after specifically supported PowerShell Core modules you can search for the tag PSEdition_Core in the PowerShell Gallery.

 

I hope some of the above quick tips help you get started with PowerShell Core and make the transition a little easier.

HaveIBeenPwned PowerShell Module

If you haven’t heard of Have I Been Pwned, firstly what are you doing?  It’s a site created by fellow Aussie Troy Hunt.  Troy aggregates data breaches as they become public into a searchable database. One of the primary goals of Have I Been Pwned is to raise security awareness around data breaches to the public.

As a bit of a learning exercise to myself, I created a PowerShell Module that leverages the haveibeenpwned.com APIs.  The module contains five Functions, Get-PwnedAccount, Get-PwnedBreach, Get-PwnedDataClass, Get-PwnedPassword, and Get-PwnedPasteAccount. I like to think of the HaveIBeenPwned PowerShell Module as an Enabler. By itself it does nothing more than what the haveibeenpwned.com site does. But by leveraging the Power of PowerShell and returning the results in object format the data can be easily manipulated for many other purposes.

Installing and using the Module and Functions is very simple. Ideally you will be running PowerShell 5 or above which will allow you to easily download and install from the PowerShellGallery. If you’re not on PowerShell 5 I’d highly recommend you download the WMF 5.1 (Windows Management Framework) which includes PowerShell 5.

Installing the module is simply a matter of typing the following.

PS F:\Code> Install-Module -Name HaveIBeenPwned

Once installed you can view all the Functions available with the following command.

PS F:\Code> Get-Command -Module haveibeenpwned 

CommandType     Name                                               Version    Source                                                                               
-----------     ----                                               -------    ------                                                                               
Function        Get-PwnedAccount                                   1.1        HaveIBeenPwned                                                                       
Function        Get-PwnedBreach                                    1.1        HaveIBeenPwned                                                                       
Function        Get-PwnedDataClass                                 1.1        HaveIBeenPwned                                                                       
Function        Get-PwnedPassword                                  1.1        HaveIBeenPwned                                                                       
Function        Get-PwnedPasteAccount                              1.1        HaveIBeenPwned      

The two main Functions are Get-PwnedAccount and Get-PwnedPassword.

The first, Get-PwnedAccount, will enumerate if an account, based off an email address, has been found in the Have I Been Pwned list of data breaches.

PS F:\Code> Get-PwnedAccount -EmailAddress [email protected]

In the above example all breaches are listed where the account used [email protected] as the email address. Which is huge by the way.

The second and slightly more controversial, Get-PwnedPassword, will take a password and confirm if it has been identified in a data breach.  Get-PwnedPassword will accept a password in three different formats.  Plain text, Secure String, and SHA1 hash.

PS F:\Code> Get-PwnedPassword -SHA1 AB87D24BDC7452E55738DEB5F868E1F16DEA5ACE

In the above example a SHA1 hash was generated offline using Quick Hash GUI.  Get-PwnedPassword will then send that Password or SHA1 hash in the body of a HTTPS request to Have I Been Pwned.  Now, obviously, what can been see as the controversial part off this is not only do you have to trust Have I Been Pwned but also this PowerShell Function.

All Functions come with Help and Examples which can be view using Get-Help.  For example.

PS F:\Code> Get-Help Get-PwnedPassword -Examples

The Module and all Functions can be found in the PowerShellGallery for download.  The Module can also been found in my public GitHub Project https://github.com/originaluko/haveibeenpwned.  All code can been view and sanity checked and is free to consume.

 

Lastly, I thought I might show how you can go one step further from simply enumerating an individual account. Many organisation’s IT departments create and manage accounts for their staff. They also provide security awareness training in protecting online accounts. An organisation could take a CSV list of their staff’s email addresses, import that list into PowerShell, and run it against the Get-PwnedAccount Function and identify if any of their staff have been involved in a data breach.

In the below example I import a small CSV file I have created with a list of email addresses. Then using half a dozen lines of code I iterate through the CSV list of email addresses and identify all the accounts that have been involved in a data breach. Using this information I can pro-actively notify staff to review these accounts.

$emails = Import-Csv F:\email_list.csv
foreach ($email in $emails) {
    $email = $email.accounts
    $results = Get-PwnedAccount -EmailAddress $email
    if ($results.status -ne 'Good') {
        foreach ($result in $results) { 
            $breach = $result.title
            Write-Output "Email address $email has been found in a $breach breach"
        }
    }
    Start-Sleep -Milliseconds 1500
}

And sample output after running the above code.

Email address [email protected] has been found in a Yahoo breach
Email address [email protected] has been found in a Youku breach
Email address [email protected] has been found in a Zomato breach
Email address [email protected] has been found in a 000webhost breach
Email address [email protected] has been found in a 17 breach
Email address [email protected] has been found in a Adobe breach
Email address [email protected] has been found in a Bell (2017 breach) breach

Download Links
PowerShellGallery: https://www.powershellgallery.com/packages/HaveIBeenPwned/
GitHub: https://github.com/originaluko/haveibeenpwned

Could not establish trust relationship for the SSL/TLS Secure Channel – Invoke-WebRequest

I’ve recently been playing around with VMware’s REST APIs in VCSA 6.5 using PowerShell. I’ve been using a lot of Invoke-WebRequest and Invoke-RestMethod to do my work. Chris Wahl has a great primer on how to get started here.

One issue that I ran into very quickly working again my VCSA was a certificate trust relationship error. I’ve run into this error numerous times in the past.

PS F:\Code> Invoke-WebRequest -Uri https://10.0.0.201/rest/com/vmware/cis/session -Method Post -Headers $head
Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
At line:1 char:1
+ Invoke-WebRequest -Uri https://10.0.0.201/rest/com/vmware/cis/session ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

The first time I ran into this error I was stumped for while finding a solution. Ultimately it comes down to using Self-Signed Certificates in vCenter, as most of us do.  In general using Invoke-WebRequest or Invoke-RestMethod against a server using a Self-Signed Certificate will cause this error, it’s not just related to vCenter.

The solution is quite simple.  I found a snippet of code some time back that I keep on hand in this situation.  It basically ignores certificate validate in PowerShell allowing you to make a connection with Invoke-WebRequest.  All you have to do it paste this code into your PowerShell session before you run Invoke-WebRequest against a server with a Self-Signed Certificate.

if (-not ([System.Management.Automation.PSTypeName]'ServerCertificateValidationCallback').Type)
{
$certCallback = @"
    using System;
    using System.Net;
    using System.Net.Security;
    using System.Security.Cryptography.X509Certificates;
    public class ServerCertificateValidationCallback
    {
        public static void Ignore()
        {
            if(ServicePointManager.ServerCertificateValidationCallback ==null)
            {
                ServicePointManager.ServerCertificateValidationCallback += 
                    delegate
                    (
                        Object obj, 
                        X509Certificate certificate, 
                        X509Chain chain, 
                        SslPolicyErrors errors
                    )
                    {
                        return true;
                    };
            }
        }
    }
"@
    Add-Type $certCallback
 }
[ServerCertificateValidationCallback]::Ignore()

Once you run the code you will be able to now successfully make a connection.

I’ve seen some simple one liner solutions for Self-Signed Certificates but none of them seemed to work for me.  Whereas the above snippet of code has always worked.  Obviously bypassing certificate validate is not something you want to run on a global scale in PowerShell but this code works great for your current session only.

If there is a simpler way to bypass certificate validation I’d love to hear it.

Store Multiple Pure Storage Connections In A PowerShell Array

I’ve recently been playing around with the Pure Storage PowerShell modules. I’ve found the Pure cmdlets to be quite extensive and easy to use. Quite a nice change from PowerShell Cmdlets of other traditional storage vendors. One thing, though, that I found a little annoying was that I had to store a connection for a Pure Array into a PowerShell object and constantly reference that object in each cmdlet I ran. Not a big deal normally but where I ran into an issue was wanting to connect to multiple Pure Arrays at the same time and being able to run and iterate against them all at the same time. I quickly came to realise that the cmdlets themselves are designed to run against one Pure Array at a time.

Initially I thought I could store multiple connections to a variable using the += operator. But this lead to the following error.

C:\Code>   $arrays = New-PfaArray -EndPoint purearray1 -ApiToken 'b2342442-ebb2-5673-a452-c443f562cb7' -IgnoreCertificateError

C:\Code>   $arrays += New-PfaArray -EndPoint purearray2 -ApiToken '6523ff23-32ac-2890-9843-2e4e9543672' -IgnoreCertificateError
Method invocation failed because [PurePowerShell.PureArray] does not contain a method named 'op_Addition'.
At line:1 char:1
+ $array += New-PfaArray -EndPoint purearray2 -A ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (op_Addition:String) [], RuntimeException
+ FullyQualifiedErrorId : MethodNotFound

A quick inspection of the data type of the variable created using GetType shows that it is a System.Object and not an Array. By default creating a connection to a Pure Array using New-PfaArray and storing that to a variable will cast it as an object.

C:\Code>   $arrays.GetType()

IsPublic IsSerial Name                                     BaseType          
-------- -------- ----                                     --------    
True     False    PureArray                                System.Object

This is easily fixed by setting the data type for our variable to [array] when we create it.

[array]$arrays = New-PfaArray -EndPoint purearray1 -ApiToken 'b2342442-ebb2-5673-a452-c443f562cb7' -IgnoreCertificateError
[array]$arrays += New-PfaArray -EndPoint purearray2 -ApiToken '6523ff23-32ac-2890-9843-2e4e9543672' -IgnoreCertificateError

Now when we check the data type we see it’s System.Array.

C:\Code>   $arrays.GetType()

IsPublic IsSerial Name                                     BaseType      
-------- -------- ----                                     --------       
True     True     Object[]                                 System.Array    

Checking the variable again we can see we have two records.

C:\Code>   $arrays

Disposed : False
EndPoint :
UserName :
ApiVersion : 1.7
Role : StorageAdmin
ApiToken : b2342442-ebb2-5673-a452-c443f562cb7

Disposed : False
EndPoint :
UserName :
ApiVersion : 1.7
Role : StorageAdmin
ApiToken : 6523ff23-32ac-2890-9843-2e4e9543672

Using this new variable with a Pure Storage Cmdlet is just a matter of specify the line in the array representing the Pure Storage Array we want using square brackets.

C:\Code>   Get-PfaArrayId -Array $arrays[0]

version revision             array_name           id                                  
------- --------             ----------           --  
4.8.10 201705102013+977fb3c  purearray1           b2342442-ebb2-5673-a452-c443f562cb7b

Where this array we created really becomes handy is when using it with foreach loops. We can now rap our Cmdlets in a foreach loop and iterate through all our Pure Storage Arrays.

C:\Code>   $results = foreach ($array in $arrays) {
Get-PfaArrayId -array $array
}

C:\Code>   $results | ft

version revision             array_name           id                                  
------- --------             ----------           --    
4.8.10 201705102013+977fb3c  purearray2           6523ff23-32ac-2890-9843-2e4e9543672
4.8.10 201705102013+977fb3c  purearray1           b2342442-ebb2-5673-a452-c443f562cb7

This is just a simple example but now we can start enumerating across all our Pure Storage arrays and easily start manipulating objects returned.

I really like the Pure Storage PowerShell modules but I really hope that a future update allows for easier working with multiple Pure Arrays. Hopefully allowing their Cmdlets to work against multiple arrays at the same time.

Cisco UCS PowerTool Suite – Part 3

In Part 3 of this series I cover a great cmdlet that’s really useful when first learning UCS PowerTool.  It’s called ConvertTo-UCSCmdlet and what it does is translate actions in the Java GUI into PowerTool commands.

If you haven’t yet checked out the previous posts in this series I recommend you do below.
Cisco UCS PowerTool Suite – Part 1
Cisco UCS PowerTool Suite – Part 2
Cisco UCS PowerTool Suite – Part 3

ConvertTo-UCSCmdlet monitors the java log file that the UCSM Java GUI creates when it’s run.  When it sees a Change Event it outputs the equivalent PowerTool command to the PowerShell console.  Using the Cmdlet is quite straight forward.  First log into the Java GUI of UCSM.

Next head over to your PowerShell / PowerTool CLI and run ConvertTo-UcsCmdlet.  You can run this cmdlet without needing to be connected to UCSM in PowerTool.

PowerTool C:\> ConvertTo-UcsCmdlet

You should see something similar to below.  ConvertTo-UcsCmdlet is now monitoring the log file of the UCSM Java GUI session you opened up and will capture any Change Events.  Leave the cmdlet running in the background.

Back in the Java GUI make a simple change.  In the below example we add a new VLAN.

We create a new VLAN ID 13 and give it a name of 13 and click OK.  If you can see your PowerTool session running in the background you will see the equivalent PowerTool command appear below the monitored log file.

Usually what you get back is a little more than you need to make a change in PowerTool.  For example ConvertTo-UcsCmdlet also provides you with all the default parameters when creating a VLAN using Add-UcsVlan.  While you could omit some of these parameters when normally working in PowerTool there’s no real harm in having them all in.

It’s also worth noting that ConvertTo-UcsCmdlet will only capture Change Events.  It will not capture basic navigation inside the UCSM GUI.

I have found this to be a great cmdlet in learning UCS PowerTool.  Especially when I don’t know how to do an equivalent command from the GUI inside PowerTool.

Cisco UCS PowerTool Suite – Part 2

In Part 1 of this series I covered the fundamentals of Cisco UCS PowerTool and how to make your first connection.  In Part 2 I expand on this and now show some of the basic commands you can use against UCSM when first learning to script with PowerTool.  With 4500+ commands, over 2300 just in the Cisco.UCSManager module alone it’s impossible to cover them all.  The intention here is not to show you them all but rather give you an idea of what’s out there and possible.

Cisco UCS PowerTool Suite – Part 1
Cisco UCS PowerTool Suite – Part 2
Cisco UCS PowerTool Suite – Part 3

In the below examples we will be working with the Cisco.UCSManager module.  We’re going to assume you’ve already made your connection to UCSM.  If you’re not sure how, checkout Part 1 of this series.

Now with our connection made one of the first commands we can try is Get-UCSChassis. This simply returns a list of all our UCS chassis’ in UCSM.

PowerTool C:\> Get-UcsChassis

AckProgressIndicator  : ack-not-in-progress
AdminState            : acknowledged
AssignedToDn          :
Association           : none
Availability          : available
ConfigState           : ok
ConnPath              : {A, B}
ConnStatus            : {A, B}
Discovery             : complete
DiscoveryStatus       : A,B
FabricEpDn            : fabric/server/chassis-6
Id                    : 6
LcTs                  : 1970-01-01T00:00:00.000
LicGP                 : 0
LicState              : license-ok
ManagingInst          : A
MfgTime               : not-applicable
Model                 : UCSC-C3X60-BASE

Above is a small extract of the output that comes back to us in list format.  This can be a little difficult to read if we have a few chassis’. We can clean this up a little by piping it to Format-Table and selecting our own columns.

PowerTool C:\> Get-UcsChassis | Format-Table RN, Id, Model, Availability, AdminState, Serial, ConfigState

Rn        Id Model           Availability AdminState   Serial ConfigState
--        -- -----           ------------ ----------   ------ -----------
chassis-3  3 UCSB-5108-AC2   unavailable  acknowledged CH29   ok
chassis-4  4 UCSC-C3X60-BASE available    acknowledged CH30   ok
chassis-5  5 N20-C6508       unavailable  acknowledged CH31   ok
chassis-6  6 UCSC-C3X60-BASE available    acknowledged CH32   ok

This now looks a little cleaner and provides us with information more relevant to what we might be after.

Next we can check what blades we have with Get-UCSBlade.  As with the previous command we can pipe it to Format-Table and select more meaningful columns.

PowerTool C:\> Get-UcsBlade | Format-Table DN, Model, NumofCPUs, NumofCores, TotalMemory

Dn                    Model            NumOfCpus NumOfCores TotalMemory
--                    -----            --------- ---------- -----------
sys/chassis-3/blade-1 UCSB-EX-M4-1             2         10       49152
sys/chassis-3/blade-3 UCSB-EX-M4-1             2         10       49152
sys/chassis-3/blade-7 UCSB-EX-M4-1             4         20       49152
sys/chassis-4/blade-1 UCSC-C3X60-SVRNB         2          8       49152
sys/chassis-4/blade-2 UCSC-C3X60-SVRNB         2          8       49152
sys/chassis-5/blade-4 UCSB-B200-M4             2          8       49152
sys/chassis-5/blade-5 UCSB-B420-M4             4         16       49152
sys/chassis-6/blade-1 UCSC-C3K-M4SRB           2          8       49152

If we have rack servers added into UCSM we can list them as well with Get-UcsRackUnit.  Or alternatively we can use Get-UcsServer to list both Blade and Rack servers in the one output display.

PowerTool C:\> Get-UcsServer | Format-Table AdminState, Model, operState, Serial, RN

AdminState Model            OperState    Serial Rn
---------- -----            ---------    ------ --
in-service UCSB-EX-M4-1     unassociated SRV72  blade-1
in-service UCSB-EX-M4-1     unassociated SRV73  blade-3
in-service UCSB-EX-M4-1     unassociated SRV75  blade-7
in-service UCSC-C3X60-SVRNB unassociated SRV76  blade-1
in-service UCSC-C3X60-SVRNB unassociated SRV77  blade-2
in-service UCSC-C220-M4S    unassociated RK32   rack-unit-1
in-service UCSC-C240-M4S    unassociated RK33   rack-unit-2
in-service UCSC-C220-M4S    unassociated RK34   rack-unit-3
in-service UCSC-C220-M4L    unassociated RK35   rack-unit-4
in-service UCSC-C220-M4L    unassociated RK36   rack-unit-5
in-service UCSC-C240-M4SX   unassociated RK37   rack-unit-6

Working with Orgs is very simple too with Get-UCSOrg.  In the below example I have just one root Org with is returned.

PowerTool C:\> Get-UcsOrg


Descr        :
Level        : root
Name         : root
PermAccess   : yes
Sacl         :
Ucs          : UCSPE-10-0-30-79
Dn           : org-root
Rn           : org-root
Status       :
XtraProperty : {}

Creating a new Org is just a matter of changing the ‘Get’ Verb to ‘Add’ using Add-UcsOrg

PowerTool C:\> Add-UcsOrg -Name Ukoticland


Descr        :
Level        : 1
Name         : Ukoticland
PermAccess   : no
Sacl         :
Ucs          : UCSPE-10-0-30-79
Dn           : org-root/org-Ukoticland
Rn           : org-Ukoticland
Status       : created
XtraProperty : {}

And you guessed it, we can remove an Org with the Remove Verb using Remove-UcsOrg

PowerTool C:\> Remove-UcsOrg -Org Ukoticland

Remove-UcsOrg
Are you sure you want to remove UCSPE-10-0-30-79:org-root/org-Ukoticland?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): Y


Descr        :
Level        : 1
Name         : Ukoticland
PermAccess   : yes
Sacl         :
Ucs          : UCSPE-10-0-30-79
Dn           : org-root/org-Ukoticland
Rn           : org-Ukoticland
Status       : deleted
XtraProperty : {}

Working with Service Profiles is extremely easy as well.  Get-UcsServiceProfile will display all service profiles. In the below example I have two.

PowerTool C:\> Get-UcsServiceProfile | Format-Table Name

Name
----
Production
Test

Creating an initial Service Profile is as simple as Add-UcsServiceProfile

PowerTool C:\> Add-UcsServiceProfile -Name MyFirstSP

And removing a Service Profile as simple as Remove-UcsServiceProfile

PowerTool C:\> Remove-UcsServiceProfile -ServiceProfile MyFirstSP
Are you sure you want to remove UCSPE-10-0-30-79:org-root/ls-MyFirstSP?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

...
Dn                       : org-root/ls-MyFirstSP
Rn                       : ls-MyFirstSP
Status                   : deleted
XtraProperty             : {}

PowerTool has the ability to perform a number of different backups using Backup-Ucs.

The most complete form is full-state. Full state creates a binary file with a snapshot of the entire system. This type of backup can then be used to perform a full system restore to the Fabric Interconnect

PowerTool C:\> Backup-Ucs -Type full-state -PathPattern 'C:\cisco\ucspe-backup.tar.gz'

The second type of backup is config-logical which backs up information like service profiles, VLANs, VSANs, pools, and policies and is saved as an XML.

PowerTool C:\> Backup-Ucs -Type config-logical -PathPattern 'c:\cisco\ucspe-config-logical.xml'

The third is config-system. This includes all system configuration settings such as usernames, roles, and locales. This is also in XML format.

PowerTool C:\> Backup-Ucs -Type config-system -PathPattern 'c:\cisco\ucspe-config-all.xml'

The last is config-all. This is a combination of config-logical and config-system and once again saved as an XML.

PowerTool C:\> Backup-Ucs -Type config-all -PathPattern 'c:\cisco\ucspe-config-all.xml'

None of the XML backups are suitable for full system restores and do not contain passwords of accounts.

Finally, XML backups can be imported back in with Import-UcsBackup.

PowerTool C:\> Import-UcsBackup -LiteralPath 'C:\cisco\ucspe-config-all.xml' -Merge

This brings us to the end of the primer on UCS PowerTool cmdlets. Everything that we covered above was just a very small taste of what’s possible with Cisco UCS PowerTool. As mentioned in the beginning the intention was to get you thinking about what’s possible. There’s a wealth of information that can be retrieved from UCS with PowerTool. It’s not really a question of what I can retrieve but how I can retrieve it.

References
Cisco UCS PowerTool Suite
Cisco UCS PowerTool Suite Communities Page

Cisco UCS PowerTool Suite – Part 1

I thought I would created a short blog series on a very underrated collection of PowerShell modules from Cisco called the Cisco UCS PowerTool Suite.  The UCS PowerTool Suite was released back in early 2013 and has been steadily growing and maturing since.   The current release of the PowerTool Suite, as of this blog post, is 2.2.1 which contains 5 modules and over 4500 Cmdlets!   Yes that’s right, over 4500 Cmdlets, crazy huh.

PowerTool brings PowerShell and all its goodness to Cisco UCS and allows you to script and automated your UCS management is a very powerful way.  PowerTool can connect to Cisco UCS Manager, UCS Central and UCS IMC (namely C-Series and E-Series).  PowerTool isn’t doing anything special behind the scenes.  It connects via the standard XML APIs that the Java GUI uses to connect to things like UCS Manager, as well as respecting and working with the Management Information Tree (MIT) that UCS is built on.

In Part 1 of this series I run through the basics of installing UCS PowerTool and connecting to your first UCS Manager.

Before you install the UCS PowerTool Suite you need to meet a few requirements.  PowerTool is not currently compatible with PowerShell Core so at present you will need a Windows box running the following.

  • Windows PowerShell 3.0 or higher
  • .NET Framework Version 4.5 or higher
  • PowerShell 4.0 and higher for the DSC module resources

Once you met these requirements you can download the latest version of UCS PowerTool from Cisco.  Then proceed to install from the MSI file.  The installation wizard is straight forward and will copy the modules to your C:\Program Files (x86)\WindowsPowerShell\Modules folder along with three shortcuts to your desktop.  Each shortcut, Cisco IMC PowerTool, Cisco UCS Central PowerTool, and Cisco UCS Manager PowerTool, runs a small startup script that basically loads their respective module.

We don’t need to actually use these shortcuts if we choose not to.  We can just run PowerShell as we normally would and import the modules as needed.  If we’re running Windows Server, though,  these module will actually auto load for us.

Below is what we see when we use the shortcut, Cisco UCS Manager PowerTool.

Below we will delve into connecting to our first UCS Manager, but first let’s run through a few of the basics.  First we run Get-Module -ListAvailable.  This will show us all the modules available on our system.  Below we can see the five Cisco modules we just installed.

PowerTool C:\> Get-Module -ListAvailable

    Directory: C:\Program Files (x86)\WindowsPowerShell\Modules


ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Binary     2.2.1.8    Cisco.IMC                           {FnResetImcPowerProfile, FnTestImcLd...
Binary     2.2.1.8    Cisco.UCS.Core                      {Add-UcsHardwareProfile, Get-UcsPowe...
Manifest   2.2.1.8    Cisco.UCS.DesiredStateConfiguration {Get-UcsConnection, Get-ImcConnection}
Binary     2.2.1.8    Cisco.UCSCentral                    {Connect-UcsCentral, Disconnect-UcsC...
Binary     2.2.1.8    Cisco.UCSManager                    {Connect-Ucs, Disconnect-Ucs, Start-...
Script     1.0.1      Microsoft.PowerShell.Operation.V... {Get-OperationValidation, Invoke-Ope...
Binary     1.0.0.1    PackageManagement                   {Find-Package, Get-Package, Get-Pack...
Binary     1.0.0.0    PackageManagement                   {Find-Package, Get-Package, Get-Pack...
Script     3.4.0      Pester                              {Describe, Context, It, Should...}
Script     1.0.0.1    PowerShellGet                       {Install-Module, Find-Module, Save-M...


PowerTool C:\>

Next we run Get-Command -Module Cisco.UcsManager.  This displays all the Cmdlets inside this module, all 4500+ of them!  Once you’ve memorised them all we can move on… just kidding 🙂

PowerTool C:\> Get-Command -Module Cisco.UcsManager
...
Cmdlet          Set-UcsWwnInitiator                                2.2.1.8    Cisco.UCSManager
Cmdlet          Set-UcsWwnPool                                     2.2.1.8    Cisco.UCSManager
Cmdlet          Start-UcsGuiSession                                2.2.1.8    Cisco.UCSManager
Cmdlet          Start-UcsKvmSession                                2.2.1.8    Cisco.UCSManager
Cmdlet          Start-UcsServer                                    2.2.1.8    Cisco.UCSManager
Cmdlet          Start-UcsTransaction                               2.2.1.8    Cisco.UCSManager
Cmdlet          Stop-UcsServer                                     2.2.1.8    Cisco.UCSManager
Cmdlet          Sync-UcsManagedObject                              2.2.1.8    Cisco.UCSManager
Cmdlet          Undo-UcsTransaction                                2.2.1.8    Cisco.UCSManager
Cmdlet          Update-UcsCatalogue                                2.2.1.8    Cisco.UCSManager
Cmdlet          Update-UcsFirmware                                 2.2.1.8    Cisco.UCSManager
Cmdlet          Watch-Ucs                                          2.2.1.8    Cisco.UCSManager

PowerTool C:\>

To connect to our UCSM we use the Cmdlet Connect-Ucs. To find out how to do this we can use Get-Help to find example syntax.

PowerTool C:\> get-help connect-ucs

NAME
    Connect-Ucs

SYNOPSIS
    Connects to a UCS


SYNTAX
    Connect-Ucs [-Name] <string[]> [-Credential] <PSCredential> [-Port <ushort>] [-NoSsl]
    [-NotDefault] [-Proxy <WebProxy>] [<CommonParameters>]

    Connect-Ucs -LiteralPath <string> -Key <SecureString> [-NotDefault] [-Proxy <WebProxy>]
    [<CommonParameters>]

    Connect-Ucs -Path <string> -Key <SecureString> [-NotDefault] [-Proxy <WebProxy>]
    [<CommonParameters>]


DESCRIPTION
    Connects to a UCS. The cmdlet starts a new session using the specified parameters. One can
    have more than one connections to a server. PowerTool Supports working with multiple default
    servers. This can be enabled by setting SupportMultipleDefaultUcs using
    Set-UcsPowerToolConfiguration.

We’re now ready to make our first connection.  In the below example we connect using the Cmdlet Connect-Ucs and save the connection to the variable $handle1.  This gives us the flexibility to connect to multiple UCSM devices at the same time and run commands against them.  Something which I’ll cover more on in a future post.

PowerTool C:\> $handle1 = Connect-Ucs -Name 10.1.1.1

Running the command gives a credential request dialog box. Enter in the same credentials you normally would when connecting to your UCSM.

If we run Get-UcsPSSession we can display our current session details.  Here you can see that we’re connected to UCS UCSPE-10-1-1-11

PowerTool C:\> Get-UcsPSSession

NumPendingConfigs : 0
Ucs : UCSPE-10-1-1-11
Cookie : 1494751391/e26549b0-557a-4ba7-83a8-c1ae36468ebb
Domains : org-root
LastUpdateTime : 14-May-17 6:43:14 PM
Name : 10.0.30.77
NoSsl : False
NumWatchers : 0
Port : 443
Priv : {aaa, admin, ext-lan-config, ext-lan-policy...}
PromptOnCompleteTransaction : False
Proxy : 
RefreshPeriod : 600
SessionId : 
TransactionInProgress : False
Uri : https://10.1.1.11
UserName : ucspe
Version : 3.1(2b)
VirtualIpv4Address : 10.1.1.11
WatchThreadStatus : None

Here’s where things get a little interesting.  We can export this session to an XML file, using Export-UcsPSSession, and with a secure key we can connect to our UCS in the future without providing credential details.

In the below example we export our current session to an XML file called ucspe.xml and type in a secure key.  Next using ConvertTo-SecureString we can export the key we used to a file called ucspe.key which we can use to decrypt our password in the XML file.

PowerTool C:\> Export-UcsPSSession -LiteralPath C:\cisco\ucspe.xml
cmdlet Export-UcsPSSession at command pipeline position 1
Supply values for the following parameters:
Key: ********

PowerTool C:\> ConvertTo-SecureString -String "Password" -AsPlainText -Force | ConvertFrom-SecureString | Out-File ucspe2.key

Now we can use our key file and our XML file to connect to our UCSM without being prompted for credentials.

PowerTool C:\> $key = ConvertTo-SecureString (Get-Content C:\cisco\ucspe.key)

PowerTool C:\> $handle1 = connect-ucs -Key $key -LiteralPath C:\cisco\ucspe.xml

The key file should, of course, be treated as highly sensitive.  Steps should be taken to protect unauthorized people accessing and reading this file.  I find a good way to protect it is by locking down permissions on the file and folder where the XML and key file are stored.  In my case only myself and the Scheduled Task account that requires it can access the file.

Last we should know how to cleanly disconnect from our UCSM session.  This simply requires the use of Disconnect-Ucs.  In the below example we also reference our session in the variable $handle1 which is good practice if we are connecting to multiple UCSM devices.

PowerTool C:\> Disconnect-Ucs -Ucs $handle1

In Part 1 of this series I cover the minimum requirements you need on your system before install PowerTool.  I then go through the fundamental basics of making your first connection to a UCS Manager. Then taking it one step further and showing how we can future connect without providing credentials. Finally I show how to disconnect from the UCSM. In Part 2 of this series I will run through the basics of querying information from UCSM via some of the 4500+ Cmdlets.

Cisco UCS PowerTool Suite – Part 1
Cisco UCS PowerTool Suite – Part 2
Cisco UCS PowerTool Suite – Part 3

References
Cisco UCS PowerTool Suite
Cisco UCS PowerTool Suite Communities Page