Blade Watch

For the second time, I had a conversation with a colleague. They had just moved from one vendors server to another. The specifications, the underlying kit was more or less the same, a few Xeon or AMD processors, an array controller and a network card.

Janet had been given this new vendors software and been told fix it. “Make it work with our build”. The following interview happened over the phone and had no specific structure or guidance. To avoid any statements or emotional discussions I have removed the references to the vendors, but the content, the underlying message remains the same.

So what do you and what are you up to?

I work in the Windows design team, we provide the ongoing hardware validation and integration services. It sounds more complicated than it is. We validate the servers against the existing enterprise build. This includes establishing what drivers and components are needed, what components we will need to include in the next release of the build so that the engineers can deploy the new operating system to that model of server.

At the moment we are working on adapting the build for the new servers we are buying which are from a different vendor, it can be quite frustrating and surprisingly time consuming.

You say time frustrating or consuming why?

Every build version has to be approved by the different sponsors and include the necessary hot fixes, driver packs which also have to be backward compliant with the older systems that are still supported under that build. This becomes even more so when you change server vendors as we need to validate what is required, what is extra and what we can get away without installing. The fewer bits we install, the less we have to manage and update with each release or update to the build, the does the network card driver work with the network card management software issue.

So name two features of the vendors software/drivers web site that cause you pain

First one would be the web sites can often be a bit high maintenance, designed from a driver publishing format, not a server or end user viewpoint. A perfect example (I will seem a bit emotional, but anyway), if I want the driver for a network card in server three, I might have to go through different parts of the web site, I might have to register, I might need to even know the serial number/derivative or get the list of every possible component for that series of server.

Second would be the differences between how the drivers, management software and firmware all interact. The main vendors we deal with all seem to have different ways of doing things which is fine, but this simply adds to the overhead, the learning experience.

I will continue by saying thirdly (which you never asked for) the complexity in the difference between what is needed to make the server operational, what is core to systems management and what is a nice to have. There does not seem to be a matrix in terms of core that is needed to make it boot, necessary like the server agents, and nice to have like online diagnostics.

We need to make the drivers easier to upgrade in terms of a software pack, remove the end user from individual component and management updates, the more separate bits there are to manage, the higher our costs, the more we remove from the build, simply saying “it is not core or supported by our build”.

Can you give me an example?
My favourite example was the guy that upgraded the drivers on his server as part of testing only to find that he could not use the management server because the driver was not supported with that management pack, the result being that he could not easily change the network card speed using the software, and had to access it using the device manager. That caused us endless calls and comments.

Do you have a preferred vendor?
Yes but I wonder how much of that is because we are used to, how much is because we got told from now you buy these servers. Interestingly though I wonder how much of our views are because no one vendor has sat us a team down and translated features and concepts. By that I mean, no one has said you are used to so and so, this is how it works with us.

Related posts:

1. Choosing your next server – some tips Check out this article talking about how to choose the...
2. Interviewing a server guy (part 2 of phased approach) So we left Mike wanting to upgrade all the servers...
3. Writing about my obsession with firmware/drivers Writing about my obsession with firmware and drivers.  The reason...
4. What do we expect from a ’server engineer?’ Chris emailed me this an agent had phoned him asking...
5. Interviewing a support guy – what concerns and challenges do you have? This interview happened earlier on in the week in a...

Related posts brought to you by Yet Another Related Posts Plugin.