EMC Unity REST API and PowerShell

Earlier this month at EMC World the new Unity storage array was unveiled. There are some cool new features with this product and the architecture is a bit different from the VNX. I like to experiment in my home lab and especially with PowerShell and REST APIs. So when I heard a Unity VSA would be available including the EMC Unity REST API. I was waiting for the EMC World release so I could get my hands on it.

I downloaded the EMC Unity VSA and set it up the first day of EMC World, then started some initial testing with the Unity REST API and PowerShell. I quickly found some distinct differences in the API when compared to the Isilon and XtremIO API’s. The first difference is the authentication mechanism which took some time to figure out. I found some quirks with the PowerShell Invoke-RestMethod and Invoke-WebRequest cmdlets. These cmdlets did not provide enough control over the web requests so I had to resort to creating my own with the .NET framework.

The EMC Unity REST API uses basic authentication via a request header, but also uses login session cookies. While trying to get this working I found I needed to use the .NET class System.Net.HttpWebRequest object for greater control. The two problems I had with the PowerShell cmdlets was the inability to control auto redirect and use request cookies. The use of request cookies is required to maintain session after initial login. The data required to create one of the cookies was returned in a response after an auto redirect so this had to be turned off to capture the information successfully.

The two cookies which have to be captured during the login process are MOD_AUTH_CAS_S and mod_sec_emc which are then used in all subsequent requests to the API. There are also a couple of additional cookies which are passed back and forth during the authentication process. I created a couple of functions to complete the login process, one of which is a recursive function which handles the auto redirects and collects the required login session cookies into global variables. The complete code is more than makes sense to show in this post, but the below example shows the main elements of building the request. This code is called recursively and collects the required session information to be passed in subsequent requests.

Once the login process is complete and the required session cookies are collected data requests to the EMC Unity REST API can be issued. The below code is an example of issuing a request for system information.

The above code also includes the header EMC_CSRF_TOKEN which is actually only required when doing a POST or DELETE. Another thing to notice in the code above is the use of the fields query string. The desired object properties to be returned must be specified using this method. The output is below.

The EMC Unity REST API was a bit of a challenge to get started and took some time with fiddler to figure out. I will say though for the initial release, the API documentation was pretty good. Unity does seem pretty cool, easy to use, and it’s awesome to have the Unity VSA for experimentation. I will try to get some more comprehensive example code on GitHub soon.



EMC Isilon Platform API and PowerShell Part II

In my last post I talked about the Isilon REST based platform API. I have been experimenting more with the Isilon API and PowerShell. I thought I would share the progress so far.

I decided to create a PowerShell module to leverage the functionality exposed by the Isilon platform API. The module provides some advanced functions, script cmdlets if you prefer, to provide API access. Right now I have some ‘get’ cmdlets and a lot of work to do before I have full coverage of the API. Maybe I can catch up by the time there is full coverage of the Isilon functionality in the platform APIJ

The module uses basic authentication at this time as I am still working on other authentication options. The first step in using the module is to download it and place it in your modules directory. Then load the module and create a password file for logging on to the Isilon cluster. The New-PasswordFile command creates an encrypted file containing the supplied password. This file is used to supply authentication automatically. The file can only be used by the user who was logged on when the file was created.

Once this is complete the following code will load a console with the cmdlets and setup authentication.

This code uses the password file we created earlier. Once it is executed we see the available Isilon cmdlets and we have a console to execute Isilon commands and scripts. I put this code into a script to launch an Isilon management console.

Now that we have a console with the commands loaded we can use them to get information from the Isilon system. Here is an example of a command to return all Isilon groups.

Here we can see all groups are returned with all properties. We also see the results are returned as PowerShell objects. This gives us all of the PowerShell goodness when working with the Isilon platform API. The next example uses PowerShell to display just the information we want in an easier to read format.

The following example shows how we can query the groups, filter by type and control the display format. This example retrieves all users with the domain type of BUILTIN and displays the name and provider in a results table.

The cmdlets will also allow using the pipeline. Although, I do not have pipline functionality in all cmdlets yet. The user, group and provider cmdlets do. The following example shows a listing of all Isilon ADS BUILTIN groups and the members of each group.

Hopefully someone finds this interesting and I will try to provide more useful examples as I add functionality to the module. Here are the download links for the module and the console launch script. You will need to modify the console launch script(Start-IsilonPlatform.ps1) for your environment.


This module is a work in progress so use at your own risk. I hope to provide more functionality soon and I hope to see EMC add more coverage to the API. I would really like to see more around cluster configuration and performance statistics. I think this is great functionality provided by EMC, more please!

Feedback on the module is welcome.



Using the Isilon 7.0 ReST API with PowerShell

EMC recently released Isilon 7.0 “Mavericks” version of the OneFS operating system. This release has many great new features, which you can read all about here and here. One of these great new Isilon features is the ReST API, which allows programmatic access to the platform. If you are not familiar with ReST, it stands for Representational State Transfer. This is a lightweight, platform independent and stateless method of programming web services.

PowerShell allows an easy method to access the Isilon ReST API. Working with ReST is a new for me, but I thought it might be useful for some to follow along while I am learning. Also, if anyone has tips for me on this process I welcome the knowledge.

The Isilon ReST API is not enabled by default. To enable the functionality it requires changing options on the HTTP settings page in the protocols section, see below.


The HTTP interface can use active directory authentication, but in this post I will use basic authentication and show examples of reading data from the cluster. I hope to show more advanced examples as I learn.

PowerShell v3 has some great built-in functionality for working with ReST API’s. The Invoke-RestMethod cmdlet is exactly the functionality required to leverage the Isilon ReST API. The first challenges when working with the API will be related to authentication and certificates. The Isilon cluster will use a self-signed certificate by default. This results in a certificate error when connecting via HTTPS and can be seen when connecting to the Isilon cluster via a browser. The following code will allow a work around to the problem by ignoring the error.

In a production environment the correct way to handle this would be to install a certificate issued by a trusted certificate authority. The next step is to setup a proper HTTP header for basic authentication.

Once this is complete all we have to do is build the proper URL and issue the request. The code below will retrieve and display the SMB and NFS settings of the cluster.

The output from the above examples is shown below. As you can see this gives a quick concise view of the protocol settings.

While this is only a simple example of retrieving data from the cluster, the possibilities are endless. When considering where we are in the transformation to cloud and automation. This type of enabling technology will be the foundation of great things to come.

Stay tuned…