Getting starting with Cisco UCS PowerShell Toolkit

Cisco – widely known as a networking infrastructure vendor – entered the blade server market in 2009. Their offering is called Unified Computing System, described by Gartner as a fabric-enabled, enterprise-class platform with good integration of networking, virtualization, management tools and storage. On the 2011 Gartner Magic Quadrant for Blade Servers theyre defined as a visionary vendor, and it will be interesting to see if they can challenge the 3 leaders Dell, IBM and HP.

The Cisco Unified Computing System is quite different from traditional blade systems, in that the server profiles (so called service profiles) is independent from the physical blade servers. An example to describe what this means is that a physical blade server might fail and be replaced, while the server profile keeps unique IDs like MAC addresses, World Wide Names (WWNs) and so on. If using boot from SAN rather than local disk drives, physical interaction is not required to get the system back online if a spare blade server is available.


The UCS core components

  • Blade Chassis – Blade server enclosure
  • Cisco UCS Manager – Embedded into the Fabric Interconnect. Provides management capabilities
  • Cisco UCS fabric interconnect – Provides networking (Ethernet/Fibre Channel) and management for connected blades and chassis
  • Fabric Extenders – Provides connection between the interconnect fabric and the blade enclosures

A photo showing the Cisco Unified Computing System architecture is available here ( In regards of management, all aspects of Cisco UCS can be managed through an XML API. This makes it possible for 3rd parties to offer management solutions, and integration with other products. An example of a 3rd party product is the Cisco UCS Iphone/Ipad application for managing and monitoring the system. Links for more information on the management model and the XML API is available in the resources section in the bottom of this article.


Cisco UCS PowerShell Toolkit

Based on a customer request from an early adaptor, Cisco provided PowerShell support for managing their UCS product through the XMP API. With the Microsoft automation strategy in mind, this was an excellent choice. It will make integration into products like System Center Orchestrator (formerly Opalis) very easy, and the also make the product attractive for enterprises. The PowerShell administration tool is available as a module part of the Cisco UCS PowerShell Toolkit.

A great way to learn using the Cisco UCS PowerShell Toolkit is downloading the Cisco UCS Emulator. This is a virtual machine image which can be imported into VMware Player or VirtualBox. When the VM is up and running you can access both the UCS Manager (http URL is shown when the VM has started) and the XML API. A great feature is that you can import the configuration from a production UCS to simulate administration changes in a lab environment.

Next, you can download the latest versions of both the Cisco UCS PowerShell Toolkit (aka UCSMPowerTool) and the PowerShell Toolkit User Guide from this website.

The installer will by default put the files in %programfiles%CiscoUCSMPowerToolkit:


CiscoUCSPS.dll is the assembly which can be imported as a module in Windows PowerShell 2.0 and later. You can either double-click LaunchUCSPS.bat or invoke StartUCSPS.ps1 from an existing PowerShell session to get started. Alternatively you can use Import-Module from an existing PowerShell session like this:
Import-Module “C:Program Files (x86)CiscoUCSMPowerToolkitCiscoUCSPS.dll”

I would suggest rather than installing to the Program Files folder (which requires administrative privileges), that Cisco generates a module manifest and install the module to the default PowerShell module directory (C:Users<username>DocumentsWindowsPowerShellModules).

When the module is imported we can use Get-Command with the –Module parameter to list all command inside the CiscoUCSPS module:


The current version of the module contains 149 cmdlets, so all commands are not shown in the above screenshot.

The first thing we need to do is connect to an instance of the UCS Manager. If using the Cisco UCS Emulator you can view the management  IP address when the virtual machine has started:


We then use the Connect-UCSM cmdlet to connect to the UCS Manager:


The default credentials for the UCS Emulator is config/config.

Next we can start exploring cmdlets like Get-Blade and Get-Vlan. Note that by default the cmdlets outputs a lot of information for each object, so Ive picked out a few properties to show using Format-Table:


Going further its easy to automate things like adding VLAN and assigning it to a vNIC template:



Although the PowerShell coverage isnt 100% yet, its possible to administer all aspect of the UCS directly through the XML API from PowerShell using the Invoke-XmlCommand cmdlet.



Cisco Unified Computing

A Platform Built for Server Virtualization: Cisco Unified Computing System

Cisco Unified Computing Forums

Automating Cisco UCS Management with Windows PowerShell

PowerScripting Podcast – Josh Heller from Cisco on UCS and PowerShell

Cisco UCS Manager XML API Programmer’s Guide

Cisco UCS Manager API Management Information Model

Cisco Developer Network: Unified Computing

Managing your Cisco UCS from an iPhone or iPad

Adding printer drivers from a print server using Windows PowerShell

Managing printer drivers in a Remote Desktop Services (formerly Terminal Services) environment can be a challenge for administrators. There are many ways to ease this challenge, including third party solutions such as ThinPrint and UniPrint. When “thick” drivers are used on the RDS servers, all printer drivers must be installed locally on every server. Citrix XenApp has a printer driver replication feature which makes it possible to distribute printer drivers from a source server to one or more destination servers in a farm.

There might be situations where none of the mentioned solutions can be used for various reason, i.e. financial costs. A common way to solve this problem is to map all printer connections from a specified print server using administrative credentials during the initial setup of each RDS server. This solves the problem, but it can be time consuming as all printers that uses the same driver is being installed. Even though the driver is already installed on the local computer, it takes some time to process each printer connection.

I recently faced this challenge, as the installation of all printer connections from a few specified print servers took 30-40 minutes using a legacy script. I then wrote an advanced function in PowerShell to make the procedure more effective. This was accomplished by installing a printer connection only for unique printer drivers.
An example: A print server has 500 shared printer objects, while there is only 10 unique printer drivers. It would make more sense to add a printer connection (in order to install the driver) to 10 printer objects rather than 500, given the time consumed by installing a printer connection.

The function is available for download from here.

Sample usage and output:




There is a switch option added to the function called Clean. If this parameter is specified the function will also remove all mapped printer connections for the current user.

The function doesn’tt provide any log options. However, it produces PowerShell objects, so it would be easy to pipe the output to a file.
An example on how to export the output objects to a csv-file:


But what about printer drivers added to the print servers after the function is run on an RDS server? One way to solve this could be adding the PowerShell function to a script-file which is set up as a scheduled task to run i.e. once a day on every RDS server.  If the scheduled task is set up using Group Policy Preferences, it will be automatically created on every new RDS server that is added later on. Beside scheduling the task to run at specified intervals, the print server administrator may also invoke the scheduled task remotely on every RDS server whenever a new print driver is added to a print server. The details on how to do this is previously described in this blog-post.

Since the function might be run several times on the same computer, it also checks if the driver to be installed is already in place on the local computer. This means that after the first run, only printer drivers added to the print server after the first run is actually installed. This makes the script more effective, and depending on the number of shared printer objects on the specified print server, it shouldn'tt run for many seconds.

Coming back to the before mentioned example (~600 printer objects, ~50 unique drivers) where it took 30-40 minutes to install printer drivers from a print server, when using the Add-PrinterDriver PowerShell function the execution ran for 4 minutes. After the first run, subsequent executions ran for  20 seconds.