While server rules are accessed only from the Configuration document, the individual rule entries themselves do each have their own document.

In the individual rule document when a server rule is created, it is assigned an OrderNum. The first rule created is assigned 0, with each subsequently created rule being incremented by 1. The actual rule formula is stored in an entry $FilterFormula, which is a @Function formula representation of the rule.

In the Configuration document, the $FilterFormulaCount field is a counter that is created with registering the first rule and counts one up with every new rule that is created. When a rule is enabled, the individual rule document’s $FilterFormula field is written to a $FilterFormula_n field in the Configuration document. The n value is dependent on the OrderNum field value from the individual rule document.

Note: Because the n value for the $FilterFormula_n initially starts at 0 and the $FilterFormulaCount starts at 1, the highest $FilterFormula_n n value is expected to be 1 lower than the $FitlerFormualCount value. It is also possible that the $FilterFormulaCount value is not decremented when rules are deleted. This behavior will have no effect on the proper execution of server rules.

Another important field stored in the Configuration document is $FilterSeqNo. This field contains a numeric text value that is incremented when any rule is updated, enabled, or disabled. The Router, which executes server rules, checks this value to see if it has been incremented. If the value has been incremented. then the rules are reloaded from the Configuration document.

If you issue the Domino console command “set rules”, Domino will register the active rules. You will see a status message similar to the following:

Successfully registered 2 system filters.

The amount of system filters returned is the amount of active server rules.

Because enabled server rules are stored in Configuration documents, and there are other server specific fields in the Configuration documents, it is critical that you do not make a copy of a Configuration document as the basis of a Configuration document for a second server. For example, you want to create a Configuration document for Server B, so you copy the document from Server A and modify the necessary changes. This action can cause unexpected server rule execution, which may not be resolved by simply disabling or deleting the rules from the copied server document.
If this issue should occur, then the following instructions can be used to ‘clean up’ the stored server rules in the Configuration document:

1. Disable all rules using the configuration user interface.
2. Delete any undesired rules using the configuration user interface.
3. Create a LotusScript agent with the code below. The agent should be designed to act on a collection of “None” or Selected Documents.

Dim s As New notessession
Dim doc As notesdocument
set doc=s.documentcontext
Forall ff In doc.Items
    If ff.type = 1536 And Lcase(Left(ff.name,15)) = "$filterformula_" Then
        Call ff.remove
    End If
End Forall
doc.~$FiltersSeqNo= Cstr(Cint(doc.~$FiltersSeqNo(0))+1)
Call doc.Save(True, True)

4. Open the Configuration document, and execute the agent.
5. From the server console issue the command: set rules
6. Enable rules as desired from the configuration user interface.

{Source Lotus Software KnowledgeBase}