HPe MSA2040 Password Recovery / Factory Reset

I recently needed to reset the password on an HPe MSA2040 SAN to which I had physical access. It turns out this information was more difficult to find than I had presumed.

The often recommended action is to contact HPe who will send a engineer on-site to reset the MSA password/settings. Don’t hesitate to do that if you have an active support contract. However, here are the instructions for doing it yourself, without a call to support:

  1. Connect to the MSA CLI interface over the USB serial port using putty, minicom or your preferred serial terminal emulator (see HPe documentation).
  2. Hit enter to display to the MSA welcome banner and login prompt
  3. Proceed to login with username restoredefaults and the serial number of the MSA module as the password
  4. The controller will reboot to factory settings, albeit retaining the network (IP) configuration
  5. Once the controller has rebooted, you can login with HPe default username manage and password !manage

Credit to the commentator on these pages whom provided the key information about the “secret” username and password combo to trigger the reset:

Regular Change Windows

I am a proponent of change management (CM). I value the function, even if I sometimes despise the bureaucracy found in typical implementations.

At $work, we follow fairly well established CM process. It’s not perfect and it has bureaucratic elements but it’s well understood and mostly respected. Regular thinking about process improvement has led to critique of the individual elements of the process. Deadlines. Approvals. Communication plans. Success criteria. Change windows.

Let’s talk about change windows. We have a “regular” change window that happens once a month on a particular weekend. This was an IT decision. We decided on a particular schedule and called it the “regular” change window and asked everyone to schedule their changes within that window unless they had justification and approval from management for doing otherwise. The problem is, by the numbers, it is hardly our “regular” change window.

The Numbers

In 2014, just over 89% of our changes were performed outside of the “regular” change window. The trend for 2015 remain nearly identical.

Those numbers mean that we’re (re)negotiating change windows with stakeholders 9 out of 10 times. We’re creating justifications and requiring “off-cycle” approvals 9 out of 10 times. Talk about overhead!

The key to this process failure and resulting overhead is that we haven’t tied change windows to the actual business. We didn’t engage stakeholders to determine when is a good time to make changes for the business. However, in our complex environment doing so isn’t straight forward. We have a multitude of different clients, stakeholders and services. Boundaries often overlap.

Reducing the Friction

We can consider focusing in on major services, identifying stakeholders and establishing regular change windows on a per-service basis. This probably makes sense for the major services but what about the smaller, less visible services? What about services with a single stakeholder? How do we document each change window? How do we enforce changes to a particular service within that service’s specific change window? I don’t know…. but my short-term recommendation is to simply ditch the idea of regular change windows unless we can do them right. Why are we bothering with rubber stamp approvals for scheduling on 90% of changes when we’re going to talk about schedule in CAB anyways? What are we gaining from this?