In order to enable NCCM for a node it needs to be modeled within NetYCE. This can both be as a regular node, as a CMDB node. We need to have access to its login credentials through its domain. If you then add the node to a node group, and that node to a polling group it will automatically be picked up by our NCCM.
A node group is meant to group nodes together. A polling group is specifically for NCCM, meant to set how often its nodes should be polled. This can be once a week, once a month, or for critical systems, once a week. Once you couple your node to a polling group, it will be automatically scheduled for an NCCM poll.
Our NCCM is being run by a daemon that wakes up every five minutes to check if any nodes need to be polled. It then takes these nodes, and pulls their configurations. This can happen through ftp, scp, sftp and tftp, depending on the vendor. We would recommend avoiding tftp, since it has no security measures and can be very slow and unreliable.
These configurations are then saved into our system. When we do this, we check if there any differences compared to the most recent saved configs that we have recorded, filtering of course any timestamps or other lines that are always different. We detect, so if any change has been made you can follow this up automatically with compliance if you so desire.
Aside from polling groups, you can also use syslog in order to detect changes from your configurations and respond to them on the fly. This is especially useful for nodes that change irregularly, and not often. This might be a bit overkill when you're dealing with big cores whose configuration changes really frequently.
Overall we made this process to be as automatic as possible. When your syslog settings and NetYCE models are correct, all changes in your configurations are detected automatically, stored, and processed, allowing you to keep a better eye on your network, increasing your control over it.
You can read more in the WIKI article on NCCM.