The best way is to do a backup on one, install SNMPc on the new computer, then copy over the backup files and do a restore.

If you're changing the IP address of the machine as well, and you were running version 5.1 or earlier of SNMPc, there is a quick way to switch over all the "Polling Agent" attributes to the new machine. There are two ways to resolve this:

• Once you've restored the map, shut down SNMPc, edit the SNMPC.INI file and set the MyAddress value in the [Server] section to the OLD IP ADDRESS. When you re-start SNMPc it will see that the MyAddress value does not match the REAL address and will update all the icons in the map from the old poller address to the new one. This could take some time during the startup.
  
  
• Use the Edit/Find menu to search for all objects of type device. In the displayed window, select all lines (click, shift-click) and use the right-click Properties menu. Select the attributes tab and change the Polling Agent attribute to the new address.
  
  

In both cases you need to manually change the Polling Agent attribute in the "Config/Default Object menu". There are some directory configurations in SNMPc that you may need to change as well. Once you have started SNMPc again and logged in, go to the "Config/Trend Reports" menu, set the directory where the web reports are saved, then go to the "Config/Backup & Restore" menu and set the correct directory here as well.

You don't need to worry about the local polling agent addresses in version 6.0 and up since the loopback address is used.

Lastly, you will need to use the "Config/Discovery Agents" menu, delete the old entry and configure the new entry.

Please note that all the configuration files are not stored in the backup. You will have to manually copy the SNMPC.INI file (this file is already included in the backup in SNMPc 7.0) from the main directory and the NAMES.TXT file from the MIBFILES directory (this is the list of MIBs to compile) along with any other MIBs you have added to SNMPc. You should copy the MIBFILES directory before doing the backup restore so that the MIBs are already in place if SNMPc needs to recompile the MIBs if the database format has changed from one version of SNMPc to another.

SNMPc uses TCP ports 165 through 168 by default to communicate with remote pollers and consoles. You can change the ports it uses by editing the SNMPC.INI file and changing the PORT_XXX entries in the [SNMPcConfig] section.

Make sure you set the same values on both the server and remote computers. If you are using the java console, you will have to allow port 12421 (and 31415 for remote telnet) as well. The SNMP protocol itself uses UDP port 161 for requests to a device and 162 for traps sent from the device to the manager.

The first thing to check is that the polling agent attribute of your nodes is set to the correct address. If you've moved your SNMPc system from one computer to another or changed the address on the computer, SNMPc doesn't always detect this and you may have to manually change the polling agent to the local computer. If you are using 6.0, this shouldn't be an issue for locally polled nodes since it now always uses the loopback address.

If you've migrated to 6 from an earlier version, you could have the same problem. In the older versions, the polling agent attribute had to be set to the local IP address, but in the new version it must be set to the loopback, "localhost".

If the polling agents for your notes are not set to "localhost", you can ether use the Edit/Find command to find all your devices then multiple select and edit them, or you can shut down SNMPc, edit the SNMPC.INI file, and make sure the MyAddress value in the server section is set to your real IP address. When you restart SNMPc, it should convert nodes with the MyAddress polling agent to the new localhost setting.

Another thing that may be causing this is that the map database files may be corrupt. You can edit the SNMPC.INI file (located in your main SNMPc directory) and add the line "MapFix=yes" to the [Server] section. You should also remove the POLLDB.DAT and POLLDB.IDX files (they are a polling cache and will be re-created automatically from the map).

When you re-start SNMPc, it will try to find and fix problems in the map file. It may take a while to start up (minutes), but don't shut it down while it is doing this - it hasn't crashed. You should probably perform a backup before trying this just in case.

There are a few things you can check to see what is causing this problem. The first is to right click on the report in SNMPc and see if you can view the data from in there. This will determine if it is a problem with the saving or the exporting. If you can't load the data from within SNMPc, make sure that the HIST32.EXE process is still running on your computer. This is the program that actually polls, stores, and serves the report data. If it is not running, try restarting SNMPc and see if this program runs. If it shuts down again, or it is running, but no data is being saved then it is most likely that your history data files have become corrupt. The next thing to try is to delete (or rename) the HISTORY.DAT and HISTORY.IDX files in the SNMPc directory and restart SNMPc. SNMPc will create fresh versions of these files and hopefully start saving the data again. The report profiles will still be there as they are saved in a different set of files (GWDB.DAT/IDX). Any web reports that were previously exported will still be there as well.

If you still aren't getting any data in the reports, then the problem is probably due to a node or table in a report that is returning bad information that is confusing the poller. If none of these suggestions help, please let us know and we will probably ask you to send us your files.

You can create manual threshold alarms using trend reports. The steps involved are:

ADDING A REPORT

• select the objects you want to monitor
• go to the SNMPc "Trend Reports" selection tree (printer tab)
• use the "Insert/Trend Report" menu to add a new report
• select one of the include tables from the pulldown, or use the ">>" button to select a different mib table
• select a polling interval. For thresholds that check for an average over 10 minutes, select 10 minute poll interval

EDITING THE INSTANCES:

• use the Instance button to view the table instances for the selected objects
• select one or more instances from the table for which you would like to set threshold alarms
• Press the Add button. The selected instances will be added to the appropriate object subtrees on the left
• if you only want to save/check the selected instances, then you can select the <All Instances> items and press Exclude
• if you want to set the same threshold for all instances then you don't need to add the instances but just continue onto the next step and edit the <All Instances> item

FOR EACH INSTANCE ADDED (still in Instance dialog):

• select the instance in the left tree
• press the Edit button
• select the variable you want to monitor
• enter a threshold expression in the Threshold edit box.This can be a series of comma separated expressions such as "<10,>20"
• press OK at the Edit dialog
• repeat Edit dialog for each other instance
• press OK at the Instances dialog
• press OK at the Trend Report dialog

You will now get threshold alarms for this report. The alarm will be "alarmManualThresholdTrigger". To set custom actions, do the following:

• go to the SNMPc Event Actions selection tree (blue bell tab)
• open the SNMPcNT-thresholdAlarm sub-tree and then the alarmManualThresholdTrigger sub-tree
• to set global actions, right-click the Default filter and use the properties menu. To set actions for a specific node/group, use the right-click Insert Filter menu
• to match specific nodes, use the Match tab
• to set actions, use the Actions tab

There are two ways to do this, either though listening for traps or by proactively polling the device. If your device supports the linkUp/Down standard traps then you can do this. Usually you have to enable this on the router and tell it which IP address to send the traps to. You'll need to add filters to SNMPc if you wish to take actions on these traps. You do this in the Event tab of the SNMPc selection tool window. You can find the linkUp/Down traps under the snmpTraps folder and or the frame relay trap frDLCIStatusChange under the frame-relay folder. For the link traps, you can just add a filter to the down trap and set the actions you want (priority, beep, page, email, etc). In the frame relay trap, there is only one trap and you'll have to check the value of the returned variable to determine if it is a good or bad trap. You'll want to add a new filter for this trap, type in the message you want displayed, and then in the Match tab click on the frCircuitState variable and set the value to "inactive". Now, whenever you get one of these traps when the circuit goes into the inactive state, the incoming trap will match this filter and perform whatever actions you set.

If you can't get the device to send you traps or you want to poll for status, you can monitor the circuits by creating link objects in your SNMPc maps. You can right click on them and bring up the properties. You'll notice that the links have an IP address and SNMP access rights associated with them the same as the nodes do. You can set it up to poll a status var such as ifOperStatus.# to check the link state of an interface (replace the # with the number of the port you want to poll). The OK value should be set to "up". Also check that you have the poll interval for the link object set to a non-zero value. Once you have this done, you will set up filters in the Snmpc-Status-Polling/pollStatusTestFail & pollStatusTestPass events. You can change the default filter if you are only going to be monitoring port status. If you're going to set up polling for multiple variables, you should add a new filter and in the Match tab, set the alarmVariable match filter to "ifOperStatus*" (the * is the wildcard character and will match any port instance).

If you have any questions about these methods please let me know. If you need help on how to configure the filters and how to perform certain actions, please take a look in the SNMPc Getting Started Guide in the "Emailing or Paging the Administrator on an Event".

There are several things that can cause this. If the link is full duplex (communication in both directions at link speed is possible - usually possible with 100mb Ethernet) and you're using the LanHealthMeters, then you can see volumes up to double the expected speed (200%). Also, the numbers for utilization variables are based on the ifSpeed of the port. If you look at the IfEntry (interface) table, you can see what this value is actually set to. With PVCs, it may be listing the link speed and not just the bandwidth available to this connection. We look at the in and out bytes sent on each interface and divide them by the speed of the port and the poll interval. For frame relay, it is actually possible for utilization to exceed the CIR rate for a frame relay port and for you to get utilizations up to 200% or so. If you are getting numbers much larger, then it may be something else so let us know. A detailed description follows:

Frame Relay is optimized for use over higher-speed (such as T1) and very low error-rate data circuits. For example, to reduce the processing load on, and latency through, frame relay networks, the switches do not perform any error correction (other than discarding corrupted frames) nor flow control (other than setting the Forward Explicit Congestion Notification and Backward Explicit Congestion Notification bits in the frame header). If the user equipment does not react fast enough (or at all) to the flow control, then the network discards frames when it gets congested. Whether due to corrupted frames or a congested network, discarded frames must be retransmitted by the user-equipment (which is typically a router).

Port speeds (the speed of the physical data circuit access line from the user to the service provider's frame relay switch and the speed of the switch port) are typically between DS-0 and T1, though there are usually only two choices:

• 56,000 or 64,000 bits/s (whichever is offered)
• T1 (1.544 Mbits/s)

As was stated above, the network does not use conventional window-based flow control (which only lets end-stations transmit a predetermined number of messages before they are acknowledged). Instead, carriers commit to being able to carry a pre-specified data rate (the committed information rate) for each PVC. The CIR (which will usually be up to one-half of, but could be equal to, the speed of the access line) is specified as a bit rate averaged over a 1-second period. Carriers charge more for higher CIRs.

Users can always send data at up to the speed of the access line, and if the carrier's network has extra capacity, then the network will carry these "burst" data (that is, data coming in, in excess of the CIR). Otherwise, the network can discard the burst data. Some carriers offer PVCs with zero CIR (at a cost savings to the user). Users find that these services drop less than 0.01% of traffic and so are often a cost-effective choice.

PROBLEM:

• If you run SNMPc under Windows NT, sometimes Ping discovery and polling does not work.

CAUSE:

• Raw Sockets (ICMP) are not available when you are logged on to Windows NT as a non-Admin user. This is as security feature of Windows NT.

WORKAROUND:

• Please view the following Microsoft web page for a solution to this problem:
  http://support.microsoft.com/support/kb/articles/q195/4/45.asp

PROBLEM:

You can not use an old serial number with a fresh install or new evaluation copy of SNMPc. You can only install the new version as an update. To do this, simply run the new installation and it will automatically detect the existing copy and ask if you want to update it. If you are installing on a new machine, you must first install your original version of the software before updating.

SNMPc's auto-discovery is an heuristic algorithm and will probably not discover all your devices, nor even the same devices when run twice. That said, it should at least find a few. It uses several methods to find IP addresses. It starts with the seeds you give it and polls the routing tables and ARP address caches to find out what the device is talking to. It then does broadcasts and tries to ping ranges of addresses depending on what it's found. You can also always add icons manually to the map using the Insert/Map Object menu. When you insert a device, make sure you enter the IP address in the General tab and set poll interval and get/set community names in the attributes tab. Some devices need to be configured with the managers address for security reasons.

Discovery is configured through the Config/Discovery agents menu item. The main switch to turn it on and off is the "Enable Discovery" checkbox. You can then turn on and off the different methods used. Make sure both the subnet broadcasts and ping scans are checked for optimal results. You can disable polling on this screen by un-checking the boxes in the "Polling Config" section.

The next tab - proto - allows you to set up automatic polling for different services and also to create icons for devices that do not have SNMP to poll with pings.

Seeds are a starting place for discovery. Usually you would supply the addresses of some routers with SNMP since they would know about other routers and devices communicating through them. The comm tab allows you to set the community name used to poll for SNMP information and to set up multiple community names. Finally filters allows you to limit the reach of discovery so it doesn't get out and start discovering devices over the internet. You can also use this if you have multiple polling agents to specify what networks each agent is responsible for. Discovery will try to lay out the devices based on their IP address and subnet mask, placing devices with multiple IP addresses (routers) at the top level.

However, most people will not use the maps that auto-discovery creates. They will let discovery find most of their stuff, add the things that weren't discovered by hand, then rearrange the maps into a more physical representation of their network.

There are three places where this can go wrong. The first is the Air Messenger Pro configuration. You should be able to send test pages using the AMP interface. This must work before you proceed.

Next, the communication between SNMPc and AMP must work. You have to create an SNMPc user with the same name as the user in AMP (this is case sensitive). You must also have AMP configured as the program to use for paging (go to Config/Event options and make sure SNMPc is not set for Notify!Connect). AMP has to be running to send pages - you can not close this program down.

Finally, you have to make sure your event filter is configured properly and the actions are actually getting called. You might want to check the Alarm box in the actions along with the paging group to verify this.

If each of these individual settings are correct when you get the alarm, you should check the log (Reports/Raw Log menu) in AMP to see if it is even trying to send the page or just queuing up the requests. If this is the case, choose the "Air Message Pro - No Q" option in the pager application selector.

If you are running SNMPc 6.0, both SNMPc and AMP must be running the same way, either both as services or both inapplication mode.

In the past, we noticed a problem similar to this on some of our NT servers (you should have events in the system log telling you there was an error starting the SNMP agent service - something like "SnmpSvcGetEnterpriseOID Not Found When SNMP.exe Is Started"). This is actually a bug with one of the service packs corrupting the SNMP agent. If you take a look at the Microsoft knowledge base articles:

• Q192528 (http://support.microsoft.com/support/kb/articles/Q192/5/28.ASP) or
• Q163595 (http://support.microsoft.com/support/kb/articles/Q163/5/95.asp)

One of these should fix your problem. If not, please let us know. There was a bug in an older version of SNMPc that caused similar problems, but it was fixed back in 5.0.9f.

This problem occurs when running SNMPc as a service. When any program is running as a service it does not have access to the mapped network drive letters. Shared drives are only connected for a logged in user.

You need to do these things:

1. You must be using snmpc 6.0.5 or later.
2. In the backup directory name, use a UNC pathname in the format "\\\\computer\\sharename\\path" instead of "n:\\path".
   
3. Use the "Control Panel" Services tool and set the owner of the crserv.exe (SNMPc Server) and hist32.exe (History Agent) services to a real user instead of "local system account". This must be a user that has access to the remote share.

The first thing you should do is download the SYSLOGdaemon from Kiwi (http://www.kiwisyslog.com/info_syslog.htm). They have a freeware version of their tool which will receive SYSLOG messages and based on filters, perform a number of actions, one of which is to send an SNMP trap.

The default trap it sends is not a valid trap from any MIB so you can't set a filter in SNMPc. Also, you can't use the appInfo/Warn/Error traps SNMPc has for use by external programs since Kiwi only allows you to send one string - the SYSLOGmessage string.

You'll have to either create your own MIB with a trap definition, or piggy-back on an existing trap that has one string variable defined. The PATTON.MIB file would be a good one since it already defines a SYSLOG enterprise with a trap called syslogStatusChange. You could use this MIB and send a trap with the following info:

• enterprise 1.3.6.1.4.1.1768.20.7
• trap type 6, trap number 7
• variable OID: 1.3.6.1.4.1.1768.20.7.20.1.3 contains syslog message

You can then create a new filter in the SNMPc syslog\syslogStatusChange event in the event action tree with a message something like "SYSLOG: $'1" and whatever actions you want to take.

If the update installation is complaining that it can't proceed because the SNMPc tasks are still running, it is usually due to the taskbar icon. You should right click on the SNMPc icon and choose exit to shut it down. If that wasn't the only one, you should check the task manager for any of the following and shut them down:

• CRSERV32.EXE
• HIST32.EXE
• DISCAGT.EXE
• SNMPC32.EXE
• ODBCEX.EXE
• TRENDVIEWPRO.EXE
• STARTUPCFG.EXE

With a Microsoft SQL Server database, the SNMPc services can not properly access the database with the "LocalSystem" user account. You must set the SNMPc service owner to a username that has access to the SQL database. For example, use the "Administrator" username. Alternatively you can embed the username into the SNMPc ODBC DSN in the "Config/ODBC Export" dialog.

You don't need to compile in many of the standard RFCs as they are already included in the STANDARD.MIB file. Some of the definitions in those MIBs are even hard coded into SNMPc (DisplayString or SMI for instance) and will generate errors if re-defined in a MIB. Here is a list of what is included in STANDARD.MIB:

• SNMPv1: RFC1155, RFC1212, RFC1213, RFC1215
• SNMPv2: RFC1901-1911
• SNMPv3: RFC3410-3418 (same as 2570-2578)
• RMON: RFC1757
• Host: RFC1514
• Ethernet: RFC1650
• DOCSIS: RFC2669-2670
• Private: CastleRock & Microsoft Lanmanager

There is currently a problem with running SNMPc under Windows Server 2003. SNMPc normally gets its directory configuration information from the WIN.INI file, but Windows 2003 sometimes maps the INI file to the registry. When we try to get the value, it checks the registry rather than the file and can't find the directory where SNMPc is installed. In 7.0 we added an additional registry entry as a backup. What you should do is open up REGEDIT and make sure the "Dir" value is set to the proper SNMPc directory in these two locations:

• HKey Local Machine\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping\win.ini\SNMPc Network manager
• HKey Local Machine\Software\Castle Rock Computing\SNMPc Network Manager

As long as there is a value called "Dir" that is set to the correct path in those two keys, SNMPc should be able to pick it up. The installation is supposed to do it automatically, but it may not have written them due to permissions settings on your computer.

In SNMPc 7.0, we changed the email alert functionality to encode the subject to allow for international characters. Most email clients will parse this correctly. If you client is not, you can edit the SNMPC.INI file and set the "Encoding=" method in the [SNMPcConfig] section to blank. You need to be running version 7.0.1 or above for this fix to work.

There is currently a problem with running SNMPc under Windows Server 2003. SNMPc normally gets its directory configuration information from the WIN.INI file, but Windows 2003 sometimes maps the INI file to the registry. When we try to get the value, it checks the registry rather than the file and can't find the directory where SNMPc is installed. In 7.0 we added an additional registry entry as a backup. What you should do is open up REGEDIT and make sure the "Dir" value is set to the proper SNMPc directory in these two locations:

• HKey Local Machine\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping\win.ini\SNMPc Network manager
• HKey Local Machine\Software\Castle Rock Computing\SNMPc Network Manager

As long as there is a value called "Dir" that is set to the correct path in those two keys, SNMPc should be able to pick it up. The installation is supposed to do it automatically, but it may not have written them due to permissions settings on your computer.

There is probably something wrong with the object counter in their map, but the following should fix it. First, do a backup in case the repair mechanism fails. Next, shut down the SNMPc server and add the line "mapfix=yes" to the [Server] section of SNMPC.INI, then restart the server. It will rebuild the map file updating the object count. Once the server reloads and you can log in, you can remove the mapfix line from the INI file. Note that the limit applies to all map objects: devices, networks, links, subnets, and gotos.