Desktop Migration

As part of another contract, we were asked to help out on a desktop migration that was beginning to lag behind.

We had to have a look at what was happening with the migration project. It appeared there were technical issues with some parts and we needed to recommend a course of action.

The migration was to replace old desktops, and for newer ones to have new images delivered remotely. It seemed sound, but there were problems with a large number of desktops not accepting the new images. There was no reason why to desktops with the same model number and same firmware version would behave differently.

We began by looking at a selection of desktops, comparing models and firmware versions. No trend emerged from that respect. We took a failing desktop from its location and brought it into the support area. Strangely the upgrade worked. It must be the network. The switch was checked and there were no port problems. We returned the desktop to its original position and the upgrade worked.

It was starting to defy all reasoning. It it isn’t the network, then it has to be something to do with the workstation. We thoroughly checked the firmware, board revisions, and every aspect. There was nothing untoward.

We decided to build a service which will check the firmware of the desktop. The vendor provided the software and we began the checks. The result was a huge data set, which we needed to trim down. After examining the data, we started to spot a trend. In the majority of the failing desktops with some of the firmware settings. We copied the settings from a good desktop to a failing one, and the upgrade went fine.

But this still left us with the strange situation of the desktop that upgraded when it was moved. That came in one of the settings from the firmware log. On the laptop in question, we noticed that the battery backup switch was set to ‘off’. On the ones which were working, the battery was ‘on’, and the problem settings were all off. It meant that when the problem desktop was switched off and moved (all desktop were kept on 24/7) the firmware settings were put back to default, allowing the upgrade.

Armed with this evidence, we got the desktop rollout team to add a physical check to switch on the battery backup, and to a hard reset on the firmware settings. From that point, the deployment of the new images went ahead as planned.

Our experience has taught us o start with the obvious things, even if they had already been tried, whittling down the possibilities until the problem is uncovered.

reporting back to all levels of management, even when there is nothing, or bad news, to report keeps everyone informed as to progress.

Talking to teams, and trying suggestions, even off the wall ideas, is a butter way of resolving issues, rather than arguing.

Having a good team and one you can rely upon is crucial. We’re used to working with virtual teams, which in our opinion is more flexible than trying to get a big team rolling.