When the NHS required a complete IT solution, it turned to Family Health Systems to help – and it turned to Network Instruments
As part of England's National Health System (NHS), Family Health Systems (FHS) is a non-profit group committed to providing the country's health organisations with the IT solutions they need to improve patient care and maximise resources. With its headquarters in Exeter, Devon, the FHS has offices located throughout England and offers a complete IT solution for the NHS, wherever the location. For the past 15 years, it has supported, maintained and developed the Exeter System, software that provides fundamental operational support to all of England's health authorities.
FHS is committed to offering fast response times to network problems. In order to continue to provide quick response, comprehensive network monitoring became increasingly important. All FHS support calls are received and managed by its Helpdesk in Exeter and are then directed to the appropriate support service in the field.
Monitoring the network was fragmented at best, so FHS had to expand its overall strategy of monitoring network traffic. "We were using a number of products that highlighted bits and pieces of what was happening," says Andy Dawson, network communications engineer for FHS. "But we didn't have a coherent package that would give us all of the information."
The FHS network consists of several Ethernet LANs located at its headquarters in Exeter and at each of its four branch offices. These LANs are connected via an FDDI ring. It also utilises about 40 NT servers, 12 NetWare servers and 20 Unix boxes. With about 250 users throughout the country, there are a number of problems that can and do occur on a regular basis. "We wanted something that was integrated, that could do a good overall general analysis and that would allow us to look at all segments equally," Dawson says.
FHS ran across Distributed Observer from Network Instruments on the Internet. Realising that it might be something that could enhance the network, Dawson downloaded an evaluation copy and was immediately impressed. "For starters, Observer had packet capture and analysis information that we found useful," he says. "It is really important to see what the actual traffic is doing, and Observer allowed us to do that."
After discovering Observer, Dawson found Distributed Observer, a product that works in a client/server environment and enables FHS to actually monitor all of its remote branch locations throughout the country.
With Distributed Observer, companies stay informed with real-time LAN traffic information and ongoing trend data that helps them quickly pinpoint problems or anticipate potential problems before they lead to disaster ( all from a single PC at one location using a convenient Windows interface.
By providing remote protocol analysis and complete network monitoring from a central location, Distributed Observer lets companies be in many places at one time, monitoring multiple LANs and even multiple sites. They can view each LAN more clearly and see all network traffic in real time.
The Distributed Observer console and the Probe both function in a "client/server" relationship. The Distributed Observer console acts as the server: it is installed on a PC running Microsoft Windows 95/98/NT. The Probes are installed on each segment of the network being monitored ( one per segment - and act as clients to the Distributed Observer console.
The Distributed Observer console's function is to collect and decode packets and/or real-time LAN traffic data from the Probe clients. Any Windows 95/98/NT PC on the network can host a Probe. The Probe runs in the background (or as a service under NT), collecting network information and sending it to the Distributed Observer console while the user continues to work as usual. Probes communicate with the Distributed Observer console using Microsoft Winsock and the TCP/IP protocol. The Distributed Observer console can monitor up to 252 Probes at one time. Probes can be located on any network ( local or remote, Ethernet, Token Ring or FDDI ( and are connected to the Distributed Observer console via IP. NT servers, IP routers or WAN connections can serve as bridges between the Distributed Observer console and its Probes, and these can be run unattended for collecting long term trending information.
Currently FHS has seven Probes installed and is able to keep on top of its entire network. According to Dawson, Distributed Observer gives them the remote features needed to monitor their network at a reasonable price. "It is now our principal network analysis tool and we use it on a regular basis," he says. "It is helping us in a number of areas because of the many functions it performs."
One of the Distributed Observer features that FHS uses most is Bandwidth Utilisation. "This allows us to see at anytime exactly how much of the available bandwidth is being used on the network," Dawson explains. "We can pinpoint a possible surge on the network, what is causing it, and get the users to stop whatever they are doing at that particular time and continue that task when there isn't so much bandwidth being used."
When bandwidth isn't the problem, Distributed Observer discovers what the actual problem might be. It may be a configuration error, several applications running concurrently or a broadcast storm. "With Distributed Observer, we have the ability to identify the type of problem we are dealing with and correct it quickly."
The product also helps them in the reverse. For example, it may not be a network problem, but the server may be down. "Distributed Observer points us in the right direction, and we can immediately improve the situation."
Distributed Observer has made an already healthy network even better. It also helps FHS plan for the future as new technology appears on the horizon. "We use it to monitor the network, and thus are keeping ahead of the game," Dawson says. "Network problems can creep up rather quickly if you don't keep on top of things. We know that our network is healthy because of Distributed Observer."
Compiled by Craig Hinton
(c) Network Instruments 1999