CastleRock SNMPc FAQs

The best way to move SNMPc from one computer to another is to do a backup on one, install SNMPc on the new computer, then copy over the backup files and do a restore. You will need to stop the old server and enter the license number on the new server before you will be allowed to restore the backup (the eval does not allow backup restores).

Note that all the necessary files are not stored in the backup. You also need to copy the entire MIBFILES directory from the old computer to the new one except for the STANDARD.MIB and BASIC.MEN files. This directory also contains NAMES.TXT (this is the list of MIBs to compile) along with any other MIBs you have added to SNMPc. If you are upgrading in the process, you should *NOT COPY* over the STANDARD.MIB and BASIC.MEN files. These files on the new computer may contain information updated in the new version. You should copy the MIBFILES directory before doing the backup restore so that the MIBs are already in place when SNMPc needs to recompile the MIBs if the database format has changed from one version of SNMPc to another. If all the MIBs are not in place, you may be missing custom event filters and MIB tables.

If you have added any icons, you should copy them and any changes to the AUTOICO.TXT file from the BITMAPS directory as well.

If you are running SNMPc OnLine as well, first get the SNMPc Enterprise platform running correctly. When it is working, stop the SNMPc services and install the new version of OnLine over the new SNMPc install. Reboot after the install and verify that OnLine is working and that it is saving data. If this is working, go to the old OnLine web interface, go to the Config page, type in a directory name in the Backup/Restore section, then click the backup button. Copy the SNMPCONLINE.BKP and ATR_*.BKP files from this old system to the new OnLine install, then go to the OnLine Config page on the new server, type in the directory where you copied the files, and click restore.

Note that if you were running the old version with an external SQL server, and want to continue using that server, entering the SQL server credentials during install will point the new install at the same database and all your data will still be in place. Just make sure both versions are not running at the same time.

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.

If you are using SNMPc OnLine or the ODBC export and are having problems getting trend report data from a remote poller, make sure you have TCP port 167 open from the SNMPc server to the remote poller. These programs use a different mechanism to get the data than the console View Report command, and need to make a direct connection back to the poller.

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.

There could be problems with either the map or log databases which could cause problems like this. There are repair mechanisms, but before trying them, do a backup just in case. When the backup is complete, stop the SNMPc services and run the LOGFIX.EXE program in the SNMPc directory. While that is running, you can delete the POLLDB.DAT and POLLDB.IDX files (they are a polling cache and will be re-created automatically from the map). Also edit the SNMPC.INI file (located in your main SNMPc directory) and add the line "MapFix=yes" to the [Server] section. When the LOGFIX is complete, re-start the SNMPc services. When the server starts, it will rebuild the map file. It may take a little extra time for the server to start up while it does this, but by the time you can log in, the repair is finished and you can remove the mapfix line from the INI file. If the problem persists, zip up the files from the backup (you can leave out the HISTORY.* files which are usually large) and send them to us. Let us know which node(s) are having problems.

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 the console. 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 run HISTFIX.EXE from a DOS command prompt. This will scan and repair any problems found in the trend database. Note that it can take some time to perform this scan depending on the size of the database. If the HISTORY.DAT file is 2GB, that is a problem as well so let me know if this is the case. If it's still not working, 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.

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".

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 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 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 subtree and then the alarmManualThresholdTrigger subtree
• 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

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 pages for possible solutions to this problem:

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 bandwith 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 prespecified 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.

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, RFC 1157, RFC1212, RFC1213, RFC1215
• SNMPv2: RFC1901-1911
• SNMPv3: RFC3410-3418 (same as 2570-2578)
• RMON: RFC1757
• Host: RFC1514
• IF-MIB: RFC2233
• Ethernet: RFC3635
• DOCSIS: RFC2669-2670
• Private: CastleRock & Microsoft Lanmanager

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 unchecking 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 autodiscovery creates. They will let discovery find most of thier stuff, add the things that wern't discovered by hand, then rearrange the maps into a more phyiscal 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 appliction selector.

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

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.

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.

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:

• CRSERV.EXE
• HIST32.EXE
• DISCAGT.EXE
• BKSERV.EXE
• SNMPC32.EXE
• ODBCEX.EXE
• JDBAPICLI.EXE
• TRENDVIEWPRO.EXE
• STARTUPCFG.EXE

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 article Q192528(//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 usually happens when you upgrade and move to a computer at the same time. When you update your software, it will usually need recompile the MIB database. If the MIBs on your new computer don't include the MIB sources that your filters or custom tables are derived from, then they will be deleted. The best thing to do is to copy over the entire MIBFILES directory from the old computer to the new one. This will ensure that all the MIBs are available and that the NAMES.TXT file (the ordered list of MIBs to compile) is the same as well. After copying this directory, copy over all the *.DAT and *.IDX files. When you start the v6 system, it will recomipile the MIBs, but it should be able to import all the event filters and custom MIB objects back in now that it can find them.

First check that the MSSQL$SNMPCONLINE service is running. If it is not, start the service and try connecting again. If the service is running, then this error is almost always a permissions problem. If you are running Apache, bring up the Windows serice manager and change the Apace2 service to run under the Administrator account. If you are runing IIS, you will need to bring up the IIS console and edit the SNMPcOnLine virtual directory properties. Go to the Directory Security tab, edit the anonymous user properties, and enter the Administrator user and password. If you are running Windows 2003 with IIS6, you will also need to add the version of PHP we install as a valid web service. Find the "Web Service Extensions" in the IIS tree, right click on it, and select "Add a new Web service extension". Set the name to PHP4 and in the required files section, enter "c:\program files\snmpc network manager\snmpconline\php\php.exe" with whatever path you have installed SNMPc OnLine in, then check the "Set Extension status to Allowed" box.

If you are running Windows XP and haven't set a password for the Administrator user, IIS won't allow the account access to the web pages. You will need to configure the Administrator user to have a password, but you shouldn't need to change anything in the IIS configuration since it handles the accout passwords automatically. The exception is IIS6 where you will have to enter the new password.

There is probably something wrong with the object counter in your 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.

This is a problem InstallSheild has with installs that were aborted or updates to installs built with older verisons. There are also reports that this can happen on Windows 2003 even on a fresh install. There are two solutions we've found that you can try to get around this. The first is to go to the Add/Remove Programs function in the control panel, click on Add New Programs, install from a CD or Floppy, and select the drive where the CD is located. If that doesn't work, the next thing to do is to delete the \Program Files\Common Files, then try to run the setup again. If you don't want to delete this directory, you can just rename it, then copy everything that was in there before to the new Common Files directory the SNMPc installation creates.

There is a bug in SNMPc versions 7.0.15, 7.0.16, and 7.0.17 that affects how events are associated with map icons.

This bug is related to the "Reassign" field in the Event Filter Actions tab. There are two related issues:

• When clearing the "Reassign" field in an Event Filter, it is instead set to "Root Subnet". Thereafter all events for the filter are sent to the root subnet icon.
• If you updated an earlier version to one of the above versions, your Event Filter database may have been corrupted. Some the of "Reassign" fields are set to random device or subnet icons. The result is that events appear to be missing, events go to the wrong icons, and subnets have a status color while underlying icons do not.

There is no workaround for this issue. You must install the 7.0.18 update. This update fixes the issue and will clear all Reassign fields in all filters.

They apologize for any inconvenience caused by this issue.

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.

The daylight savings time change is transparent to us. As long as your Windows system is updated, the time change will be handled correctly. See: http://support.microsoft.com/kb/931836/

The status of the trouble ticket doesn't have any effect on your ability to post to it. New posts to a ticket will flag it for our attention. We use the "Closed" status to indicate that we are not waiting on more information from the customer.

In newer versions of JAVA, all TCP communication is locked down by default. You need to edit the "java.policy" file on the web client machine to allow TCP connections to be made. Add the lines:

• permission java.net.SocketPermission "*:12421", "connect";
• permission java.net.SocketPermission "*:31415", "connect";

Note that on 64 bit versions of Windows, there are two copies of the java.policy file - one for the 32 bit Program Files (x86) version and one in the 64 bit Program Files directory - for the different versions of IE. There can also be multiple versions of Java installed. Search your disk for all the java.policy files on your disk and change them all.

Also note that since these files are in the Program Files directory, if you are running on a version of Windows with UAC, you need to edit the file with admistrator access otherwise your changes will just be saved in a VirtualStore copy.

As a side effect, adding these settings also allow you to serve the java applet from a different web server and type in the SNMPc server's address. If you don't want to allow this, change the * to the IP address of the SNMPc computer and/or loopback address.

There was a change made in 7.2.4 in regards to scaling the icons. In older versions, it showed the full size icon to a certain zoom level, then nothing. The icons in the newer version contain 16x16 and 24x24 images, and these are what are used for intermediate zoom levels. If the icon does not contain these images, it is not displayed at those zoom levels. Adding a 16 and 24 pixel image to your icon file will get it to show up all the time. We've posted a program on the "Contributed Software" section of the helpdesk (CRC266705) which adds additional size images to all the icons in the bitmaps directory. The precompiled version included with the source code in there is built with a newer version of MS Visual Studio and may require updated library files. You can download them from: http://www.microsoft.com/downloads/details.aspx?familyid=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en

The [Strings] and [Instances] section allows you to map status polling variable instances onto longer ones that would normally not fit in the status variable buffer. Entries in the Strings section will be translated as string instances, while entries in the Instances section will remain numeric. For example, if the INI file contained the following entries:

• [Strings]
  www="World Wide Web Publishing Service"
• [Instances]
  snmp=0.0.0.0.161

You could set the status variable attribute to svSvcOperatingState."www" to monitor the web server service on a windows computer, or udpLocalPort."snmp" to confirm that the SNMP agent was running and listening on the SNMP UDP port. These requests would be mapped to:

• svSvcOperatingState."World Wide Web Publishing Service"
• udpLocalPort.0.0.0.0.161

when sent to the device. Note that the variable name plus the instance must still be less than 1024 characters in total. Also, the total length of all instances defined in each section must be less than 16K.

There are two main causes for this error. The first is if you've restored an older backup into the SNMPc console. If this is done, new MIBs, particularly the SNMPc OnLine MIB, might no longer be compiled into the MIB database. To fix this, go to the Config->MIB Database menu in the SNMPc console, check to see that the MIBs (CRATR.MIB for CRATR-MIB tables) are in the compile list, and add them if they is not, then click the compile button. When the compile is complete, restart all the SNMPc services to make sure it is using the new MIB database and see if the error persists.

The other cause is if you've configured SNMPc OnLine to run with an existing SQL server. Each report type is saved in a different database, and whatever user you are using for SNMPc OnLine's SQL access needs to have permission to create new databases.

If neither of these describes your situation, there is a tracing mechanism in the OnLine export server which can tell us what is going on. Stop the OnLine export service, edit the \Windows\PHP.INI file, add the line "SNMPc.debug=1" to the top of the [SNMPc] section, then start the export service again. It will log progress to a file called DBEX_LOG.TXT in the main SNMPc directory. Let it run for a minute or two until you see the error message again, then send the log file to Castle Rock tech support.

This is a security "feature" of Windows. Windows doesn't allow us to launch telnet from the system directory. As part of our install, we copy the TELNET.EXE from the Windows\System32 directory to the SNMPc directory, but if you didn't already have telnet installed when you install SNMPc, the file won't be there to be copied. Just manually copy the TELNET.EXE program to the SNMPc directory and it will work fine.

SNMPc does not support TLS/SSL for its SMTP messages, but there are solutions that will allow you to do this. STunnel is an application you can use to create a SSL tunnel to your email server through local mapped ports.

Here are instructions on how to use stunnel with the Google SMTP servers as an example:

1. Install the Windows version of this application, run "stunnel.exe -install" to install it as a service.
2. Edit the stunnel.conf file and add the following (the default conf file already has this section commented out):
   • [gmail-smtp]
   • client = yes
   • accept = 127.0.0.1:25
   • connect = smtp.gmail.com:465
3. Run "net start stunnel" to start the service. In the future it will start automatically during Windows startup.

The stunnel service will listen on TCP port 25 on the loopback address, and send all connections through an SSL tunnel to smtp.gmail.com on port 465.

Go to the Config->Event Options menu in SNMPc and enter "127.0.0.1" as the SMTP server address. You will need to specify a from address, and if necessary, an authentication password to login to the SMTP server.

There is another option just for Google mail, but it requires access to your DNS server. Set the SNMPc SMTP server address to "aspmx.l.google.com", then add the SFP record "v=spf1 ip4:123.45.67.89 include:_spf.google.com ~all" for your domain to allow emails from the SNMPc computer though the Google mail servers. For detailed information on how to do this, and what to put in your SFP record, see:
http://support.google.com/a/bin/answer.py?hl=en&answer=176600

SNMPc does not show notice, information, and debug messages by default. We chose do to this since many devices will flood the manager with informational messages. This is only the default setting though, and you can configure SNMPc to display these.

If you look in the snmpcSyslogEvent alarm in the event action tree, you can see alert, critical, emergency, error, and warning messages have specific filters, but the Default filter which is catching the info and notice messages is configured not to log them.

Add additional filters to catch these messages and log them. To see notice messages for example, right click on the snmpcSyslogEvent alarm and choose to insert a new filter. Set the name to "Syslog-Notice", leave the message set to "Syslog: $'8 [$'2 - $'4]", switch to the match tab, select snmpcSyslogSeverity in the variable list, select "notice" from the variable value pulldown, switch to the action tab, check the "Log" action, and set the priority (color) you want for the notice messages.