Creating a Cisco UCS Profile using PowerTool

Creating a Cisco UCS Profile using PowerTool

This post is going to walk through creating a powershell function to create a Service Profile on a Cisco UCS domain. Later posts in this series will look at how to assign it to a server, configure shared storage on a NetApp filer, and configure the zoning on Fiber Channel switches – essentially all the work we’d need to do to automate the creation of a physical server.

There are a few ways to create Service Profiles on a Cisco UCS domain, but if you’re looking for consistency, best practice and the possibility to automate then you’ll need to use templates – not just a Service Profile template, but templates within the Service Profile template – for vNICs, vHBAs and for any other policies. I have assumed that templates have been set up and are being used.

We are going to be using Cisco UCS PowerTool for this, so ensure you’ve got this installed on your system. You can get it from , but you’ll need a login.

The File

Open up your favourite IDE or text editor (personally I use Notepad++) and create a new file. Save it with a filename and a location of your choice. My file is going to be called “automate.ps1” and I keep everything in a “scripts” folder in the root of a hard drive. Powershell has a verb system, so the cmdlets are prepended (for example) with “New”, “Get” and “Set”. I’m going to use the verb “Automate” to make our functions stand out from anything else that might exist on your system, but you might wish to use your company name or something else.

Below is a sample function definition for “Automate-NewUCSProfile”.

The first line declares the function and the curly brackets open its contents. The “Param()” line will be expanded so we can pass parameters into the function, and the main body of code will reside in the curly brackets are the “Process {” section. We then close off every open curly bracket “{” with the opposite curly bracket “}”.

If you’d like to learn more about Powershell functions, your search engine of choice will direct you.


When we connect to a UCS domain we can be given a handle to it. PowerTool will support connections to multiple UCS domains, though I believe the default is one and it needs to be reconfigured through the Set-UcsPowerToolConfiguration cmdlet (see it and the Connect-UCS cmdlet help for more information). If we are connecting to one UCS domain then we won’t need to use the handle when using other cmdlets, however I believe it is good practice to do so, so I will.

To connect we use:

When running the above connect cmdlet (and after entering correct credentials for the target UCS domain) we are given something similar to below (which is a platform emulator output running on VMware Workstation 9):

So, if we want to connect without this information being printed to the screen then we’ll need to accept the handle being returned from the cmdlet, as below:

Credential can be prompted for by using the “(Get-Credential)” input above, or it can be provided ahead of time, by putting the output of “Get-Credential” into a variable.

To disconnect, we use the cmdlet

So building our function it will start to look as below. We are passing in the name of the UCS domain and the credentials to connect to it.

One thing to note here is that if a Credential is not provided, then the person running the script is prompted to provide one.

Creating a Service Profile from a template

One line of code is required to create a Service Profile based upon a template, and it takes the following parameters:

– ServiceProfile is the name of the template upon which to base the new profile
– NewName is the name of the new profile.

It returns a object to represent the service profiles that it creates. An example:

Note this this leaves the new profile bound to the template. We can change this later.

We should do some sanity checking though – I’m sure you are aware of the two types of templates – “initial” and “updating” (if not, Cisco have a useful page on Service Profiles). These are represented in PowerShell by being a Service Profile object, but with a type of either “initial-template” or “updating-template”. A Service Profile object that is actually a Service Profile has a type of “instance”. So let’s make sure that a profile with this name exists:

This code is retrieving all service profiles of the name “template-name”. It then runs a check on them to see if they have type set to “instance”, and if so, the object is returned.

If $template is equal to $null (i.e. $template -eq $null) then no template could be found. Putting our code together, outside of our function, it would look like:

Optional: Unbinding from the Service Profile template

If you wish to unbind from the template, the line is simple:

Though we could pipe the $service_profile variable to it, as per:

The “| out-null” just ensures that nothing is printed on the screen as it is being run.

Assembling our Function

From the above we need to know some things:

– The name of the UCS domain to connect to.
– The credentials to connect with.
– The name of the Service Profile we want to create.
– The name of the Template we are going to bind to.

So when we put the code from above into the function, and configure our parameters, this is what it should look like:

Organisations and checking Profile existence

We’ve got one last check that we should make – that the service profile doesn’t already exist. This is slightly more complicated due to Organisations – service profile names are unique within each organisation. This is represented in service profile objects by distinguished names which are formed of two parts, the location and the service profile name. Running the code:

will show us the format:

As we can see, we have two service profiles with the name “test”, one in the “root” organisation, and one in the “Finance” organisation. Let’s get the details about the organisations:

So when we create our profile we must make a choice about where we create it – by default it will be in the root organisation. Our code will have to take a string that allows callers to provide an organisation (but have a default of “root”). We will then search for the service profile within that organisation:

It looks simple, but there is a catch – it will still match against any service profiles in sub-organisations. We need to add the “-LimitScope” parameter in order to only match within our desired target organisation. If $existing_profile is equal to $null, then we can continue.

So our function will now look like:

Note: Organisation names are not unique throughout the Domain and it is the Dn that will determine uniqueness. This is something that we’ll deal with next.

One Final Step

To make everything simple, we should do all our checks to see if any stage of this will fail at the start of code. For the sake of separation we’ll create a new function for this:

There are a few differences to our original function – we are passing in the connection handle to the UCS Domain, so we don’t have to deal with any Connect-Ucs/Disconnect-Ucs and credentials. We are then going to run some checks and return whether we can go ahead with creating the service profile.

Let’s go through the code:

– We first get all the Organisations that have the name we supply.
– If there are no Organisations then we output this to the user and ensure we will return failure.
– We see if there is more than one Organisation with the name.
– If there is one Organisation then we check to see if there is a service profile with the same name in it.

– We check to see if the service profile template exists.
– We return the result.

This is where we are handling that we could have multiple Organisations could have the same name. If more than one is found, then we will fail and tell the person running our function to supply the Dn if they wish to continue.

When we alter our original function to use this one to do checks, and put everything together, it looks as per the below:

And that’s it :). We now have some code that will create a UCS Service Profile from a template in a given organisation and will pass the obvious sanity checks.

We can now create (or at least attempt to) a service profile by doing the following:

Next time, we’re going to get the HBA WWPNs and associate the service profile with a server.