Hmm... The rule Jiri gave might help in some instances, but not others. Shows off some weaknesses in the NCM engine I believe unless there is a way to fix it that is escaping me. First I'm going to proselytize a bit on writing secure rules and being careful with regular expressions. In the string matching rules cvachovecj gives you above, almost everything is a "regular expression" even though he isn't using them as such. That can be a bit dangerous. However, I do believe they should be regular expressions, just stronger ones. For instance, if you put in his rule above and it worked as mikefryar was hoping it would, it would ignore any IP that began with 1.1.1.1 or 2.2.2.2. That would include IP's like 1.1.1.10 through 1.1.1.19 and 1.1.1.100 through 1.1.1.199. Just saying if you want things done right, be as complete as possible. Adjusting his regular expressions to be
ip helper-address 1.1.1.1\r
and
ip helper-address 2.2.2.2\r
should do the job since it terminates the string at the end of line (I still want to use a "$" to do that!!). However, you can also combine the two rules using reg-ex's and if you want to be a little more nit-picky and bind the beginning of the line too, you could try
^\s\+ip helper-address (1.1.1.1|2.2.2.2)\r
Now, as to why the rule just plain doesn't work. If you go back to the examples @mikefryar gave, specifically the vlan100 example:
interface Vlan100
ip address 1.2.3.4 255.255.255.0
ip helper-address 1.1.1.1
ip helper-address 2.2.2.2
ip helper-address 3.3.3.3
ip helper-address 4.4.4.4
!
The example compliance rule cvachovecj gave will pass this on without a problem. Why? Because it fulfills the rule! Sure it violates the first part where it says it must not contain "ip helper-address", but it does fulfill the second part of the OR here, where it has both the "1.1.1.1" and "2.2.2.2" helper-addresses. So, as long as you have those two IP's as helper addresses, this rule will be ok no matter how many other helper-addresses you might have defined there too...
Another thing you should be careful about, and this is in how the config block is bounded. Yes, it will find all instances of actual "interfaces" in your config, which is great. But as-is it will also find every other command in your config file that has the keywork "interface" in it. So, lets say you have commands like "passive-interface" in EIGRP, it will pick that as the start of a config block (for every instance!). Or, if you have something like "ip tacacs source-interface Loopback0", or other source interfaces like NTP, logging, SNMP, etc. etc... Every one of those will be treated like the start of a config block in the Compliance engine! So, you're just about doubling the work the engine does by allowing it to do this. How are you allowing it? Once again, by not binding it to a more specific matching clause. The cure? Change it to a regular expression and make it more specific. Something as easy as:
^interface
will do. Sure, it might still pick up loopback interfaces and such since the word interface is at the start of the line. If you want to get fancier, you could do something like this instead than:
^interface (Fast|Gig|Vlan)
to only have it pick up those types of interfaces.
More efficient rules means the rules processing will take less of your time and CPU AND you won't get surprise results that you don't want!!
The bad thing is, I'm not exactly sure right now how to fix this using the current engine, at least where you can write a remediation rule that would fix it. I do know how to find all unwanted "ip helper-address"'s for you, it was discussed just a bit ago on how to kind of hack the compliance engine to do this type of thing. You can find the discussion here: Re: Automoted Config clean up
Unfortunately, the remediation part of this solution won't work because the helper-addresses are contained in the "interface" config block (rather than their own "ip-helper" config block). The only reason the remediation portion of that discussion worked was because the command was a global IOS command that wasn't within a config block. However, it will help you find which configs have invalid helper-addresses and you can go fix them manually. cvachovecj example will work in some specific instances, but not all unfortunately...
HTH!!