Time is too far in the future

[Tode]

Szenario: Hier läuft gerade ein Update von r5 auf R7.

Dabei schiesst ein Server- CMOS- Batterie- Fehler von vor langer Zeit ziemlich Quer:

Dabei ist es irgendwie passiert,
dass plötzlich das Serverdatum auf 2030 stand. Unter R5 liess sich alles irgendwie beheben,
und die Probleme waren mehr oder weniger behoben.

Jetzt -bei einem Update auf R7.0.1- und den entsprechenden Datenbank- Maintainence- Tasks kommt das Problem wieder:

Nachdem der fixup über bestimmte Datenbanken gerutscht ist, haben diese Plötzlich als Datum der letzten Änderung (Datenbankeigenschaften) einen Wert von 2030 stehen (war vorher nicht der Fall).
Jetzt kommt beim komprimieren / replizieren / Ansicht neu aufbauen / etc. immer die oben genannte Meldung.

es gibt hier einen Artikel von IBM wie das Problem zu beheben ist.

Das funktioniert auch -haben wir getestet-: Das Erstellen einer neuen Replik behebt den Fehler.
Da es sich aber um weit über 100 (Mail)-Datenbanken auf mehreren Servern handelt, hätte ich das gerne anders behoben.

Ach ja: Das Änderungsdatum der DB kommt NICHT aus einem bestimmten Dokument (habe Ansichten über die entsprechenden Datums- Felder @Modified und $Revisions gemacht) und auch nicht aus bestimmten Design- Element, das man einfach kicken könnte.

Jetzt zur Frage: Gibt es eine Möglichkeit z.B. über die API diese Datenbank- Eigenschaft programmiertechnisch umzuschiessen ?

Ich brauche keinen fertigen Code, der Hinweis auf einen entsprechenden API- Befehl würde mir schon reichen.

Thanx
Tode

[m3]

Ev. hilft das:

Replication history has to be purged from all databases on server
Deletion stubs must be purged from databases

Worst Practice: Time Travel for Beginners

[Tode]

Replication History hatten wir schon gepurged (schönes Denglisch ), aber die Deletion- Stubs.... Gute Idee, werd's mal ausprobieren. Thanx

Tode