Info

AMS for Windows is designed to take full advantage of wide area networks (WANs). Due to its client-server design many users can be supported over relatively slow phone lines running the AMS for Windows application (see AMS for Windows Configuration Guide for specifics). Obviously, there are many other applications run in a normal insurance agency that are not necessarily client-server, including some of AMS' companion products. In order to get the very best performance and use of a WAN and AMS software it is important to understand how the environment works and how best to tune it for your particular configuration. The information presented here is somewhat technical due to the nature of WANs and the various types of software found on Insurance Agent's systems. AMS recommends working with an AMS Preferred Vendor on these issues. First, let's review the required components of an AMS for Windows network. There is a database server running Microsoft Windows NT Server that was purchased from AMS, a number client (workstation) computers, and the network itself (wiring and hubs/switches). In addition, there will be at least one laser printer and a modem that allows AMS to dial in and provide troubleshooting. When a remote office is added to the network some sort of routing hardware is added along with the proper phone circuit and equipment (usually a DSU/CSU). The remote office usually has all of the hardware that the main office has, except the database server - there is only one database server for the entire business no matter how many sites are involved. This means that there must be workstations and the proper networking (wiring and hubs/switches) at the remote site and usually a laser printer too. The client part of the AMS for Windows software is loaded on each workstation no matter if it is at the main location or at a remote site. This software is loaded and runs exactly the same in either place. This means that when AMS for Windows is running, only data is sent from the database server to the workstation - either on the local network or over the WAN. In fact, the database server actually logically determines which data is needed rather than sending all of it and making the workstation sort it out. This is the efficiency that the client-server architecture provides. The same is not true of other applications you may be running. Applications like AMS Rating and AMS PS/4 are more traditional in nature and cannot be run over a WAN the same as AMS for Windows does. This is also true for many other applications common to insurance agencies, like company specific communication or rating programs. Many times these programs load on a local server and are all run from one location. That is, rather than copy the application to the local hard disk of each workstation, the application is run directly from the server. This means that when the application is run the program files are copied over the network from the hard disk of the server to the memory of the workstation. Often these programs can be very large. WANs like those set up to support AMS for Windows do not generally have enough "bandwidth" (speed) to allow a user at the remote site to run a program on a server at the host site in this manner. If this is attempted, the program is copied from the local server, across the network to the WAN and eventually to the workstation at the remote site. The WAN (phone line) part of the network becomes a huge bottleneck and performance is unacceptable. Fortunately, there are a number of ways to configure the remote site so that these issues can be overcome. Before specifics are discussed, it is important to understand what performance can be expected at remote sites. To be honest, we have become spoiled with the speed of the servers and workstations used in a network today. At the main site, where phone lines are not an issue, many activities happen instantaneously. At the remote site however, there will always be a slight lag (no matter what technology is being used) due to the speed of the phone line part of the network. This difference between the main site and remote site will vary depending on the the specific configuration, but it should be expected. You will find that while the performance is a bit different, both main and remote site performance is quite acceptable and much better and cost effective that many of the possible alternatives. In a smaller remote office (say, less than 4-5 users) it is probably more cost effective to load these more traditional applications on each workstation. This means, for example, that the AMS Rating diskettes must be loaded at the main site normally, then sent from the main site to the remote office and installed on each workstation in the office. The same would be true for any rate change diskettes. While a bit more diskette handling and installing is required for the remote site, this will provide the best performance for this type of software at the remote site. If the remote office is a bit larger, or very large, it is important to have some type of server at that site. The server would only be used to hold these traditional software applications and their data - the AMS for Windows data would still be written to the database server at the main site. Either Microsoft Windows NT Server or Novell NetWare type servers would work in this instance since either can function as a "file" server. In many cases the agency will already have an older server that can be used for this purpose. If not, there may be other applications that can also take advantage of a server of this type such as EMail or company wide scheduling. There is even a case in using AMS for Windows where a server at the remote site is required - AMS for Windows Imaging. If you are planning on using Imaging there must be a place to store images at each site. Your AMS Preferred Vendor may be able to help you with these possibilities. Suffice it to say, there are many good reasons to configure the remote site with its own file type server. By having the server at the remote site the problem of programs running over the WAN is avoided. It is also easier to deploy printers and other network devices. As with the previous example the software loaded at the main site would have to be sent to the remote site to be loaded there also, but in this case, only loaded once. With an understanding of the network that must be set up, and how important it is to properly load the applications that are not client-server based, there are some additional steps that can be taken to improve performance at the remote site. When AMS for Windows is installed, or sometimes while running, it accesses specific files. These files are generally loaded either from your database server, or from a file server you have set up at the main office. This is not your actual data from the database, but shared and program files. There are two directories of files affected. First, there is a directory of programs that are used to load the proper software to each workstation. As mentioned above, AMS for Windows loads all of its programs on each workstation. Therefore, AFWPGM directory (where these programs are located) is only accessed when programs are loaded to each workstation. This usually happens when you first load the software, or when there are updates. AMS for Windows expects this directory to be available and checks each time the program is started. This way, if any files were accidentally deleted, programs updated, or a new workstation was added to the network, it would be easy to add/update the software. The other important directory is called the "shared area". The AFWSHARE directory has a number of important files that are accessed by AMS for Windows on a regular basis. These files include a company-wide information file (AGENCIES.INI) and all of the word processing and spreadsheet templates that are used to generate form letters and reports between AMS for Windows and Microsoft Office. While the two directories (AFWPGM and AFWSHARE) are always set up at the main site, they can also be set up at the remote site to improve performance. There is some additional work required to maintain this configuration, but it is usually a good idea since it will improve performance. This document also discusses the need to "redo" this process when any new versions of AMS for Windows are released. Once your network is set up properly, and all the programs are loaded in the appropriate places, you should have a system that runs smoothly with good performance. If there are still issues that need to be resolved, AMS Technical Services (for those note yet "live"), or AMS Technical Support can help. Before you call however, please consider the following questions:General Questions What seems slow?AMS for Windows, some functions within AMS for Windows or some other application(s)? Are things always slow or do things slow down periodically? Is just the remote site slow or is the main site also slow? Has performance always been a problem/issue or is the problem new? How many users are at the remote site(s)? How many remote sites do you have? Who installed your WAN? (Name of Preferred Vendor or consultant)