"In the blue corner weighing in at 300mbps is the network with 20 technical knockouts!"

"In the red corner coming in at 2 services and 4 processes is the software with 14 and 0!"

 The first thing that we must do is understand the environment that we are working in. If you are more of a trainer than a techie then that is OK. We are going to take a 3000 foot view of all of this for the most part. For those of you that get excited when you have to read hex then we will try to keep you interested as well.

  Step one entails getting a baseline of the traffic that passes their network. This is done with a network analyzer which is a software application that captures the data streams that travel across the line from one computer or device to another. There are several well known analyzers that range in capability as well as price. For this article we will focus on Omnipeek by Wild Packets (www.wildpackets.com) and Wireshark (www.wireshark.com). Omnipeek is quite expensive at ~2500.00 but is extremely versatile and has an exceptionally friendly user interface.  Wireshark is free but requires you to be more familiar with datagram analysis in order to use it effectively. We currently use Wireshark due to it's pricing structure.

It is important to note that these applications require you to be on site and must be deployed on the same physical segment of the target computer. Wild Packets does make a remote data analysis tool, called Packet Grabber, which allows for remote administration, data collection and delivery.

 

 Once a baseline is completed then you can begin to collect other network flows which hopefully include an example of the problem at hand. It is important to collect as much data as possible which should always include data from an affected client and the server. The process for performing this action is beyond the scope of this article so I will not go into it at this time.

 With this information we can get an understanding of how the network behaves, who (or what) is using the most bandwidth, and what problems the firm may be facing with their network. This is where the proverbial rubber meets the road. If the issue is identified as being caused by the network then we have proof to provide to the firms IT person. If the issue is with the application then we can provide the same to LexisNexis Tech Support which will most likely result in a Webstar and land on a QC desk.

  So what happens if neither the network nor the application prove to be problematic? Well, we are now able to remove the network from being suspect and focus our attention in other arenas of troubleshooting. Having this data available for Tech Support will go a long way in presenting them with a full picture of your user environment as well as help you to be fully prepared to work through your customers situation prior to making your call into support where you will more than likely end up running an analyzer anyway.

  I once worked with a customer that complained of slow response to lexis.com. It had been working without issue for several years and one day users began to flood his help desk with complaints. After walking through the usual troubleshooting I was at a loss. He agreed to allow me to place a remote network sniffer on one of the troubled machines and we collected several trace files for review. We found that one of his users was serving .mp3 files out to the Internet which slowed all of the traffic on his LAN. This manifested itself in the lexis.com traffic as other sites did not require the same throughput and seemed unaffected. once we shut the offender down the results were immediate.

 Another example of real world results stems from a Juris customer that complained of intermittent application lockups at the workstation. Once again I pulled out my go to tool and ran Packet Grabber on his server to see if there was a network issue (all attempts to produce the problem failed and troubleshooting revealed nothing out of the ordinary). I found that there were excessive SMB command rejected messages within the flow of his data. This impacted Juris in that it, like TM, relied on the SMB protocol to pass data to and from the server. The SMB errors were coming from an unknown IP address, however. After a little research the admin called me back to say that he had an antiquated network scanner that was flooding his network with the SMB errors which affected the Juris applications ability to perform it's data transfer effectively. Once the scanner was removed, the Juris issues cleared up. We certainly would never have found this without the aid of a network analyzer.

 So what do these examples have to do with TM? I'm glad that you asked. All of these applications rely on the network to pass their valuable payload to the intended targets. If the delivery mechanism is somehow compromised then we see these odd and sporadic behaviors.

 It should come as no surprise (shameless plug)  that AlliancePCG is fully qualified to perform an analysis for your end users. We have the knowledge and experience to make this process smooth and painless and will be there for you from the time the software is deployed to your user through the conversations with technical support.