July 31, 2007: 8:14 pm: Antivirus

I have been updating installs to r8.1 of eTrust.  I updated it on my Mac OSX Powerbook.  It works just fine on the laptop itself.  One downside is that they have no pest patrol for OSX yet.  So even if you are licensed for ITM you only get antivirus when you install it on your Mac.  But better safe than sorry.  I also have not had success yet getting a Mac client to go into the organization tree in the admin console.  That is a headache if you have a number of Macs and a desire to run antivirus on them.

Something r8.1 did fix for me.  I had very weird alerts coming from one site.  Alerts for every cookie etc.  Very annoying and it forced me to temporarily disable email alerts.   Updating the server acting as the Alert Manager for that site group of clients to r8.1 fixed it though.

TwitterFacebookLinkedInInstapaperPocketApp.netGoogle+Share
June 28, 2007: 9:15 am: Antivirus

So I am testing a few things. As I originally had things configured three IT groups saw all the alerts for the clients in the three locations. This is because they all report back to one eTrust Server. The annoying thing was that they saw each other’s alerts. The human nature reaction is of course to read NONE of them. That brings us to making each site’s clients send to another Alert Manager. This was not hard for me since we also use CA Brightstor. So the servers that run tape backup and email alerts to only their local group could also forward alerts for eTrust. I changed the IP, setup the distribution list to email on each of those alert manager instances. What do we get? Nothing.

This morning it occured to me why. Both of those servers had THEIR alerting policy settings within eTrust Policy Manger set to forward to the main eTrust server. In essence relay after relay. The result is nothing gets through. So here is what you do.

  1. Make a new Branch for EACH of your Alert Manager servers
  2. Make a new Common/Alert Forwarding Policy object for each of those branches. make sure you check at least these two boxes: Local Alert Manger; Forward to client name: and put the server’s own IP address here.
  3. Now make your clients forward to that server’s IP. On your clients do not check Local Alert Manager. Event Log and Forward are what I recommend. With the forward being the IP of the Alert Manger you just setup.

One issue to be aware of. I think if you are not forwarding alerts to the main eTrust server then the data is not making it into the summary charts on the dashboard nor into the reports. I will watch it for a week and see if I am correct.

TwitterFacebookLinkedInInstapaperPocketApp.netGoogle+Share
May 11, 2007: 3:53 pm: Antivirus

If you use eTrust you may be confused by the ways to discover your agents. There are several types of discovery. One of which only works on r8.

  • Free Election This is directed broadcast discovery on the subnet local to the admin server. r6,7,7.1 and 8 clients are discoverable. If you followed the previous advice on cisco configuration then likely you are blocking directed broadcasts.
  • Biased Election: This is like the free election above but if the IP address specified in the network subnet settings is responding it will be the winner of the election and act as your proxy. Again blocking directed broadcasts can be a problem.
  • Specified Election Use this if you have an always reachable and on host on a remote subnet. r6,7,7.1 and 8 clients are discoverable. This is a proxy type of method where the remote host does a broadcast based discovey on its subnet. But it is not a directed broadcast.
  • Sweep Scan This does a tcp based sweep of a network range looking for agents responding on the eTrust application port. Only r8 agents are discoverable. This puts more of a load on the ITM server so I recommend you use specified election when possible.

I also recommend setting the phone home policy if you are using r8 ITM. This tells the clients to report back to your admin server without waiting to be discovered.

TwitterFacebookLinkedInInstapaperPocketApp.netGoogle+Share