Adding new Windows NIC devices to enVision
I have been struggling with adding new windows nic devices to my ES appliance and decided to log a case with RSA support. My XML file is correct, and if you inject the events via syslog, it adds the device correctly. The problem is that the real-time events come in via the Windows NIC service, not via syslog.
RSA support have advised me that ESI only creates the XML file, and "additional work" is required to actually get an additional Windows NIC device added to the system (similar to using SFTP, SNMP) but this is outside the scope of support. I was advised to engage RSA professional services as they know how to do it, which is really quite annoying as we dont have buckets of money to throw at PS when we were sold an appliance that was "easy to use" etc..
I have used Cisco MARS, and been using Symantec SIM for years, and still cannot get enVision to capture/report on the same devices as the Symantec.
So what "additional work" do i need to do to get additional windows NIC devices into the system ??
BTW, I have run the extractor tool and added the eventlog strings to the system already. If I add the XML to the existing Windows NIC XML file it all works, but I dont want to do this...
>>tried that.. i dont even get a new "unknown" device with multi checked. I have SQL as well and I think it works as RSA support SQL out of the box..
Which specific Windows Event log is your new set of events coming from. Is it the Application Log or somewhere else?
If it's the Application log, you will have a very hard time getting the multi-device to pick it up because there is a very generic "catch-all" Application Message ID in the winevent_nic.xml file. It may be worth commenting out that particular Message ID and then restarting services to see if that helps. I think the message ID for that one is simply "Application" (should be near the bottome of the XML... I'd tell you exactly what/where it is but I'm not anywhere I can access enVision at the moment).
I think we need more clarity on what your are trying to do. I assume that you want some messages from the Application Event log to go to a new device that you have created? Matt is correct that there is a catch all, but that may only be in Content 1.0. I think the catch all may be gone in 2.0.
So, in your scenario, you have a Windows (NIC) device that has already been discovered and when you set it to multi-device it will not discover your new device type that you have defined? or are you doing it the other way where you discover your device and it comes in as unknown, you set the device type to your application and then set it to Windows NIC...when you do that it then discovers the Windows(NIC) device and all of your messages end up going there?
Did you ever solve this issue? There is a hotfix in newer 4.0 patches that provides multi-device ordering, so that you can have two device types for a certain IP, and control which one gets chedked first. Its ECE-314 I think.
Our company was the one to push for this as PS had told us to implement our customizations in a certain way, which led to us requiring this functionality.
Our scenario is that we have custom unix (solaris) messages (that parse to both unix and our custom xml) coming from the unix systems. We wanted to separate out our customized messages from the behemoth solaris XML (at the time 15MB!) and now we can do this.
The ordering is set via a pi.ini setting and then (I think) the order priority is IP, device type name, Instance value (inside device_list table). We choose a device type name starting with aaa to assure that it would always be alphabetically first. Its display name is irrelevant in the process.
Here are the release notes:
The flag must be set in etc\pi.ini to turn on this feature .
When this configuration parameter set, the device load order is changed to Device IP Address, Instance, and DeviceType which can be used to specify the order of the parsing for multi-device events. If alphabetical devicetype ordering is not sufficient, the Instance value can be modified by manually editing the device_list table using ISQL
Description: When collecting events from a configured multi-device event source, it is not possible to specify the order of parser processing when determining the events type. This can cause the event to be assigned to the wrong device type.
This fix does not support maintaining the desired sort order during device re-configuration or device discovery without a collector service restart.