ICT Management > Strategy & Planning
Networks > Getting A Network

Upgrading your network – pleasures and pitfalls

By Lasa Information Systems Team

Over a few days in February 2007, Lasa‘s network was given a thorough overhaul. Apart from the network being down over a weekend, the system was alive and well for a normal Monday morning’s work. This is the story of how it came about and what went on behind the scenes...

Lesson 1 – start early and give yourself more time than you think you’ll need

In early 2006, Lasa decided that it would tender for network support. Our support contract was running out in December and, having had the same company for a number of years, decided that it would be good to test the market. In addition, we realised that as some of the network hardware was reaching the end of its life, there were issues which needed resolving and new technologies out there which we could take advantage of, it would be advantageous to combine all this into one tender. We knew that it would take time to carry out all the stages we needed to go through and even starting in the summer meant that we only just made it in time…

Lesson 2 – assess and inventory

The first thing that was done was an assessment of the current situation both with regard to equipment, services and support. We came up with a number of issues:

• The firewall was no longer supported by the manufacturer
• Our main server was out of warranty and running Windows Server 2000 and coming to the end of its life
• Email was mounting up in Exchange Server and an archiving solution may be required
• Servers were not in the most accessible place and subject to heat build-up
• ADSL was crucial to the organisation and redundancy would be welcome
• Back up routines and software were overcomplicated
• Outlook Web Access and remote access could be easier and more secure
• Updates needed to be more consistent
• Disaster recovery needed addressing
• Remote support would be useful

Lesson 3 – get more than one quote, meet the tenderers and interview your short listed contractors

From this an Invitation to Tender was written, using the Knowledgebase article Working with an IT support company to draw up requirements, and sent out to a number of suitable tenderers in late September. All the tenderers visited our offices, asked questions and discussed possible solutions. Because the approaches in certain cases were very different it was extremely useful to be able to talk through the pros and cons of a particular solution. Tenders were received and a comparison done which short listed two companies who offered what we considered to be the best service and value for money. Also we liked them!

Lesson 4 – check ‘em out

Having selected the company who we believed were the best fit for the contract, we asked 3 referees some pertinent questions about how satisfied they were with the service provided, responsiveness and so on. They all came back very positive.

Lesson 5 – know exactly when your previous contract runs out!

By the start of December the decision had been taken and the contract signed. An email from our existing provider asked whether we would be re-signing the contract as it had run out on the 1^st December! Although we’d envisaged the new contract starting in January the new contractor were happy to start it early. Lesson learnt.

Lesson 6 – plan your installation

Having settled into the new support regime, we started looking at the upgrade and when it might best be done. We had no immediate deadlines apart from the usual funding issues which meant that it would be best if it was done by the end of March for tax year purposes. We also planned around our dedicated engineer’s skiing holiday… There was some cabling and electrics to be done as we were moving the server room so that required a cabling contractor to come along (obviously) prior to the main install.

Lesson 7 – purchase software well in advance

We were buying most of the software through the CTX donation service and they provided everything we needed promptly. But it’s wise to allow some time in case of delays – you don’t want your carefully laid plan being wrecked because a disc or licence key hasn’t turned up.

Lesson 8 – know how big your server cabinet is going to be

We decided that the new server would be rack-mounted and therefore we needed a rack cabinet. Because the existing ‘traditional’ server which runs our accounts software would be retained, along with commissioning a redundant rack server as a terminal server for remote access we needed a large cabinet to contain everything. We didn’t anticipate that it wouldn’t go in the lift or get through the office door in one piece. Luckily it (just) made it through the front door of the building and we were able to dismantle it and take it up the stairs and in the lift in sections.

Lesson 9 – communicate; let the staff know what’s happening

Installing the software on the new servers took a few days to do and we then planned a weekend for the data migration, joining the PCs to the new domain, upgrading some PCs, installation of the firewall, router and so on. A few days beforehand, staff were informed as to what would happen and how it would affect them. As we were setting up a new domain all passwords would be changed to a default – staff were informed of this on the morning of the changeover using ye olde fashioned paper which gave them the temporary password and instructions of what to do – and who to call for help.

Lesson 10 – set up a secondary mail server

If you haven’t already got one, it’s a good idea to have this in place so that any mail received while the mail server is offline will be stored. It will then be released once the server is back up again – see the Knowledgebase article Secondary Mail Servers for more information.

Lesson 11 – identify mission-critical applications and be prepared

Lasa’s database was developed by a one-person company and needed migrating to the new server including the open-source Firebird SQL back-end. We ensured that there wouldn’t be any significant impact, but, as the database is mission critical and links to our accounts system, it was vital that it was up and running again on the Monday morning. Similarly the maintenance company for our Sun Accounts finance package were also contacted.  We also were migrating data so we needed to make sure we had an up-to-date back-up in case something went wrong.

Lesson 12 – order new IP addresses weeks before you need them

Having ordered a box which would provide secure access to files on the server and the terminal server, we discovered that we didn’t have enough static IP addresses. Our ISP could arrange this but it could take some time. Luckily the remote access wasn’t something that we’d promised to have up and running on “go live” day so were able to set this up once the address range had been allocated. Also, you can’t use the first or last IP address of a range so buy at least two more IP addresses than you need!

Lesson 13 – ensure your technician can be on site for the first day after an upgrade

No matter how much you do to mitigate problems there will always be something – shortcuts to documents not working any longer, network printers not installed and so on. Although Lasa has two staff with ICT responsibility, we knew that it would be quicker and easier for our support company to handle the problems. Interestingly, you’ll still find issues months later when, for example, someone tries to run a mail merge from your database which was mapped to a drive letter that no longer exists…

Lesson 14 – document it

Our support company logged all the work that was being done and also documented new passwords, internal and external IP addresses, license keys and so on. We brought all of this information together so we knew we could lay our hands on it quickly.

In conclusion

Whilst you can never expect everything in a complex upgrade to go smoothly, with proper planning, good management and everyone knowing what their responsibilities are you can mitigate a lot of the risks.