"Unable to apply changes. Please try again" message (version 3.1(3)S33)

[e.jastak]

I recently installed a IDS 4210 and upgraded the software from the included CD (version 3.0(5)S17), all the way up to version 3.1(3)S33.

For some reason, every time I try to "Apply changes" via the web interface (IDSM) I get the "unable to apply changes. Please try again message".

I have reinstalled my sensor from the recovery CD three time now to make sure that I applied all the service packs and signature updates properly, and with the correct permissions. I don't see anything in the event logs that indicates what the problem might be.

This is becoming a problem because everytime I exit or reboot the sensor I lose most of my changes (but not all!?!). Has anyone else had problems with this? Any advice would be appreciated.

Thanks!

Eric

[jbohla]

I could not find any useful tip on this except for this URL http://www.cisco.com/en/US/products/sw/secursw/ps2113/prod_release_note09186a00800d9dda.html

[marcabal]

The error you are seeing ocurrs when one of the IDS daemons is not responding after the configuration change.

Occasionally this is because of an incorrect configuration.

There is a diagnostics report that can be run from within IDM.

Once you've seen this error, then go and run the diagnostics report.

In the diagnostic report you should see the output for the "idsvers" command.

Each daemon should be responding. If there is a timeout then you will need to determine which daemon was not responding.

You will likely need to contact the TAC, and supply them with the diagnostic output file.

[e.jastak]

Thanks for the tip. I actually looked through the release notes and couldn't find anything useful. However, the problem seemed to go away after I made a modification to the "daemons" file related to another problem I was having (a service startup error).

After I removed the "nr.smid" entry from the "usr\nr\etc\daemons" file the problem went away. Not sure why that is, but I'll take it. :-)

Thanks,

Eric

[marcabal]

nr.smid doesn't exist on the sensor; it is a Unix Director only daemon.

Postofficed is responsible for starting up daemons and restarting them when you reconfigure the sensor.

What was happening is that when you apply the changes, IDM sends a message to postoffice telling it that a reconfiguration has taken place.

Postoffice checks the latest daemons file for the list of daemons that should be running.

Postoffice then sends a reconfigure message to each daemon that is running.

And starts any daemon that isn't running.

Postoffice then waits for a response from each daemon to determine if the reconfiguration was successful.

If all of the daemons respond then IDM gets a success message from postoffice; if even one dameon (in this case nr.smid because it doesn't exist) does not respond then you get the error you were receiving.

[e.jastak]

Yea, that makes sense. I just don't know how the nr.smid service got placed into that config file. I never made any custom changes, nor did I ever configure the sensor with the Director or CSPM managers. I guess this is something to look out for in future IDM configurations.

Thanks for the detailed explanation!

- Eric