Do you really need the logs from the virtual NSM imported to the new NSM?
How many days worth of alerts are you keeping on the Virtual NSM?
Are all of your NSM's running the same software version?
How many sensors are attached to each of your NSM's?
You can use the Alert Archival feature to export them from your virtual NSM, but I wouldn't try importing them into your new NSM as it could cause you issues.
The alert data from the virtual NSM would not match to your sensors and policies after being imported and would probably result in DB corruption.
You should contact McAfee Support before you go any further with this to see if they would recommend it or even support you if it went badly.
Thanks for your support.
No NSMs are not running the same version, the New NSM v 126.96.36.199 and VM NSM image v 188.8.131.52.
I have read in McAfee links the below, and you can see that in the attached link page 210,211.
• You can restore alerts only if the major versions of the backed up Manager and the present Manager match. For example, a backup from Manager 184.108.40.206 can be restored on a Manager version 220.127.116.11 or 18.104.22.168. A backup from Manager 22.214.171.124 cannot be restored on 126.96.36.199.
• You cannot restore alerts of a later version of the Manager on an earlier version of the Manager. For example, you cannot back up alerts from Manager version 188.8.131.52 and restore it on Manager version 184.108.40.206.
The alert logs are for 7 months.
The virtual NSM handling 2 sensors while old NSM is a physical appliance and handle 12 sensors. the New NSM is also a physical appliance.
I don't think the documentation covers your scenario because you are importing alerts from 2 separate NSM's.
I don't know how the Sensor / NSM assigns the alert ID's etc., but you could potentially end up with alerts being over written.
I would just move the sensors to the new NSM and keep the old Virtual NSM until the 7 months is up and the DB has completely purged.
I have tried the same scenario in my virtual lab environment, but by restoring the Configuration Table since I don't have any Alert logs.
First I restore the configuration of the old NSM then I had restored the configuration of the VM NSM. The policies were all over written.
Doesn't McAfee have any tool to do Database migration? what if someone has different policies on different NSMs and wants to migrate ALL Tables for example?
Thank you Peter,
1 of 1 people found this helpful
I don't believe there is such thing as a dB migration on NSP, especially if you have two different NSM versions from start to end.
Even if you are on the same build, I'm not sure a policy (IPS, Fw, ignore rules) export/import would work - as they may just be overwritten during import, not 'joined' to the existing policies - but I have never tried this so would need some testing to confirm.
For the IPS alerts, alert archival export/import may present issues as Peter says, if the alerts being imported have or 'will have' the same uuid. You could always check the uuids and if they are really different give it a go on a test NSM to check you get all the alerts at the end.
I'm thinking that I way of workaround this is via a SIEM, where you could create a dbconnect task to your old (and upgraded) NSM, and pull the IPS alerts into a 'SIEM source' via the db connection. At the same time, you could create another dbconnect on the SIEM for the 'new' NSM to import the alerts into a different SIEM source.
This would allow you to have all the IPS alerts into two different source tables on the SIEM that you could use for historical analysis and correlation. You would need the iv_alert and iv_alert_uri_info tables imported if you want both IPS alert and L7 data.
I know I'm not answering your question , sorry, but hopefully this helps you getting some ideas to workaround this and have some actionable data sets at the end.
Thanks for your support.
I have opened a ticket with McAfee to see if they have another way or a work around to do the migration.
I will update you as soon as they get back to me.
You can always export the sensor configuration, and archive the alerts on the virtual NSM, then import the archivals to the "shared" NSM. And import the sensor config files to "shared" NSM.
Here is the update of the above discussion.
I have tested this in Lab and the logs are not getting over-written. All the logs will be added using data archival feature:
You will find data archival under Manager >>> Maintenance >> Data Archiving >>IPS>> Restore Archives.