It always seems like every time one thing if fixed, something else breaks. This morning I was working on Project A and I needed to look something up on our ISA 2006 firewall. While I was there I decided that I would look into, and fix, something odd that was happening with Project B's rule. Well, after fixing the rule into a corrupt state, I now had a Project C to work on as well. Corrupt rules are never fun, but I was able to figure out how to fix it, but I'm sure it's NOT a supported or recommended procedure.
When I was trying to find out exactly what machine we are routing FTP traffic, I wanted to take a look at why my IMAP connections seemed to be getting mail that was MONTHS out of date. Looking up and down the list of rules, I found a duplicate IMAP(S) rule that was pointing to an old IP address of our Exchange 2007 server. I figured that somehow, that might be a reason why I'm not getting the correct e-mail. I clocked into the rule, and changed the internal endpoint to our current Exchange 2010 server, clicked Apply and then OK.
On closing out of the ISA Management Console and looking at my e-mail, I noticed that my Inbox was starting to fill up with alerts from System Center: Operations Manager telling me that there was a problem with the configuration on one of our ISA machines, specifically the one that I was logged into. Side Note: I know I should have been looking at the configuration on the Configuration server, not one of the nodes of the array, but the Configuration server is having problems of its own!!!
Logging into the Configuration server, I opened up the Management Console and noticed that the rule I had edited was missing a bunch of information. Clicking on it (right or left) brought up an error dialog stating that "there is not enough memory to perform the action." After much fumbling and scrolling up and down, I realized that the name of the corrupt rule was the same as one farther down on the list, and when I changed the IP, the rules ended up being exactly the same. This led to the node pushing the change up to the configuration server before it was really sure that it SHOULD, and so, I am stuck with this dumb ghost rule. Since I know that I couldn't affect the corrupt rule, I decided to change the name of the good rule, so they wouldn't match! Brilliant!!! (:
Things weren't quite that simple, however, and when I made any changes to anything else on the server, I wasn't able to commit the changes! I kept getting an error that the corrupt rule needed more information before the changes could be saved. Oops! I even tried Exporting the rule set, removing the offending rule from the XML file, and then Importing it back in, but I ran into the same error.
It was time to bite the bullet and following the somewhat sparse directions from this forum post, I fired up ADAM ADSI Edit to remove the offending rule, once and for all.
Even though the directions weren't the best, it was enough for me to get there, so I'll post a little bit more coherent account:
NOTE: I am pretty sure this is NOT supported. Any time you mess with ANY of the raw editing tools, you stand a big chance of messing things up beyond recovery. DO NOT USE these steps if you are not willing to accept total failure as a possible case.