Are you saying it takes over an hour for a single sensor?
Are you deploying to multiple sensors at once or just one at a time?
Are all of your sensors NS series? What model / software versions?
What version of NSM are you running?
Have you tuned your database recently?
I have been told that when you update a policy it has to individually update the policy for every interface on the sensor, so if you have inactive interfaces apply a Null policy to them and it will speed things up deploying policy changes and SigSets.
Yes, at times it takes an hour or more for a single sensor to update.
I am deploying to 2 sensors usually, and sometimes NTBA appliance also.
Sensors are NS series. Software versions are:
- NSM: 220.127.116.11
- Sensors: 18.104.22.168
- NTBA Appliance: 22.214.171.124
Not sure about tuning database. Never heard of that.
We do have policies applied to every interface, which I can fix and see if it helps today. Looks like the best I can do is place these interfaces in Default Detection for IPS polices. I was able to remove from all other policies though. Each NS appliance has 19 active interfaces (9 segments being monitored plus one flow collector).
I am attempting to deploy changes to a single sensor right now......let's see how long it takes.
Is this only a problem since moving to v 8.3.x?
Database tuning is in the Admin guide under the maintenance section, McAfee support recommend running it at least once a month to optimize your database. Tuning the DB is normally one of their first steps in troubleshooting any policy related issues.
I only have one 8.3 NSM set up in my test zone and haven't looked at it much yet, I thought there was a null policy by default but I don't see one now, maybe this has changed with the newer release.
I will run the tune! This has been slowly getting worse and worse over the last 1-1/2 years since we deployed the sensors. I don't think sensor version has had a whole lot to do with it.
Quite possibly, this tune will help. I have had tickets with McAfee on other issues related to the sensor and they never had me tune. So thanks for the tip!
 System has not been tuned since 3/2015....a year. I am hopeful that will really help. I am waiting on some changes to deploy, then I'll tune!
The Null policy on my NSM's only contains a small number of attacks and they are all disabled. I think this may have been provided by McAfee support at some point in the past as I can't recreate it.
Hope your DB tuning is successful, it can be troublesome if your DB is very large.
Regular tuning and pruning is good regardless of if that's the root cause of the slow updates. Is this a virtual server, or a standalone server / appliance? Does the hardware meet the minimum requirements of 16GB RAM, and a server-class CPU? If the manager is virtual, make sure you have more than one CPU core assigned to the VM.
If any of the above doesn't solve the issue, call the support team for assistance as an hour is too long for an update.
We have 16GB of RAM, 2 sockets and 4 cores per socket. Plenty of physical resources for the VM. After the database has been tuned it's still taking an hour to deploy changes.... :/
I was told by someone offline that this could be because I have a large number of attack definitions enabled on policies, which are applied to a large number of interfaces. Granted, this has never really changed. When we first deployed the sensors, changes only took a few minutes. We might have increased the number of attack definitions in policies though.
That hardware should be enough. Open a SR with the support team and let's figure out why this is taking so long.
Will do. Thanks.