Configuring SCOM to Monitor Dell Storage Solutions

  • Article

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

I was asked by a customer recently to configure SCOM to monitor Dell EMC SANs. The request seemed easy enough, until I got to doing it and realized that the documentation is, well, less than stellar. As such, this will be a quick post as to how we managed to get this working. I’m not 100% sure that every step listed in here is needed, but this is what we did to accomplish that task.

First, the instructions. The best documentation we were able to find was not off of Dell’s site, sadly. It was here on systemcenter.wiki. Even that, however, appears to be a bit out of date. Dell’s instructions said the following:

  1. Install the ESI Service
  2. Configure the ESI service connection.
  3. Publish the connection.
  4. Import the Management Packs.

The “how” was missing from their documentation, and their online video that was supposed to show us how only showed us what it looked like once done. I’m sure there’s some better documentation out there, or at least I’d like to hope there is, but I was unable to find it and as such I’m publishing this article.

Installing the ESI Service

First we needed to find that. This too wasn’t easy. There was no ESI service download from Dell’s site. We did find it eventually, as it’s included in the ESI PowerShellSetup files that they made available for download. That was mentioned in the description of the download. There were several versions available, but for what it’s worth, we did not get the latest version to work and had to settle on 5.1.0.3. This may have been due to a few reasons. I suspect in retrospect that this is because the ESI service may be dependent on the Unisphere CLI component; however, the installer did not call this out as a dependency and let us proceed without it. Also, I will note that one of the big problems we had is that we installed the PowerShell patch that they provided. This did not uninstall, making rollbacks impossible. I would advise against this without a snapshot in advance and understanding of what this patch is doing and if you need it.

On to the steps.

  • Download the files. As mentioned before, we only got 5.1.0.3 working. These are the files as they are named on the Dell portal. We needed the ESI.5.1.0.3PowerShell.Setup, ESI.5.1.0.3.GUI.Setup, UnisphereCLI-Win32-x86-en_US-3.0.0.1.16-1, and the ESI.SCOM.ManagementPacks.5.1.0.3.Setup. 
    image

    I would note that we never got 5.2.0.9 working. There’s no GUI for it, which we needed, but there could have been other factors there, so I don’t want to say it won’t work. I will state that the GUI MMC kept crashing every time we launched it in this configuration.

  • We installed all of these from an administrative command prompt to get around UAC issues. The first piece we installed was the UnisphereCLI file. This is supposedly only needed for certain adaptors, but since we were using a Unity adaptor, this was a requirement. This may not be necessary depending on our SAN’s adaptor, though I’m not convinced that this isn’t a component for ESI as well.

  • Next, we installed the 5.1.0.3 PowerShell setup and then the GUI setup. I’ll note one other issue we had (though it was with 5.2.0.9), was that the AD publishing piece kept crashing on a Server 2016 build during install, as such, we decided to use the options to publish locally for this piece. Everything else was default.

  • Last, we ran the management packs. This is a typical MP extraction. We will need to import them later.

Configuring the ESI Service Connection

Once everything is installed and working, you should be able to successfully launch the EMC Storage Integrator MMC icon created during the install. What we need to do here is tell the ESI service to talk to the SAN devices that you want to monitor. This part is fairly straight forward, though you will need to have some sort of storage credentials to talk to this, so someone from your storage team may need to be involved.

  • Launch the EMC Storage Integrator.
  • Right click on “Storage Systems” and choose “Add Storage System”.
    image
  • Choose your adaptor type, and fill out the appropriate information (note that each type may have a different set of info, this screenshot is for Unity only). Definitely test the connection before clicking add.
    image
  • Repeat until all connections are added.

Publish the Connections to ESI

At this point, we need to publish this information. We chose the local host during setup, so effectively that means this info is stored locally. Active directory is an option, though as I mentioned earlier, this kept crashing during install. This could have been our lab, a bug in their software, or who knows. We didn’t spend a lot of time figuring that out as a local connection was acceptable. This too is done from the EMC Storage Integrator.

  • Right click on the EMC Storage Integrator MMC icon (from within the MMC) and choose the option to Publish Connection.image
  • This box appears:
    image
  • You’ll need to change the Publish to Target option to the ESI Service. Strangely enough, this would crash if we added any value in the “Target Host field,” so we left it blank. We kept the default installs during the various setup routines, so if you configured custom ports, no SSL, etc., you’ll need to change that accordingly.
  • Next step, is to click “Refresh”. That will display your targets in the left pane. They did not automatically appear here. Select the appropriate targets and click “Add”.
  • After that’s done, the Publish button will no longer be gray and you can click “Publish”.

Import the Management Packs

At this point, we are in the home stretch… or so we thought at least. We went ahead and imported the 5.1.0.3 management packs that we extracted earlier. The ESI service discovered as expected. Nothing else did. So now more digging. The problem is that the next discovery is disabled by default. That isn’t bad practice per se, but it would be nice if there had been any documentation on this, as you’ll need to do this in order to actually get good data into SCOM.

  • From the Authoring workspace, expand “Management Pack Objects,” and select “Object Discoveries”.
  • Do a find for “EMC SI Service Discovery”.
    image
  • You can see that this is disabled by default. I’m not exactly sure why this is targeted at Windows Computer and not the ESI Service that was already discovered, but I didn’t have access to the people that wrote this. Go ahead and perform an override. You can likely override just for the object that hosts the service, though we did all objects of the class. It’s worth noting that you do need to specify the machine name in the override settings (or at least we did).
  • This appears:
    image
  • It’s worth noting that there are lots of options here that can be overridden. We did the Enabled and ESI Service Host options, though if you have customizations, proxy, ports, accounts, etc., that should be included here. I would note that I don’t think this is being configured with SCOM run as accounts, so I’m not certain how secure it would be to put a username and password in this field.

That did it. A short time later, all of our storage pools were showing up in SCOM and monitoring was working.