Bug in "Benutzer verschieben": Mailfile wird gelöscht

[Tode]

Ich bin hier gerade über einen üblen Bug(?) im 10er Server gestolpert und wüsste gerne, ob das jemand hier reproduzieren kann:

Folgendes Szenario:

Ich habe 2 Server im Cluster, und einen dritten Server hinzugefügt. Nun Sollen einige Benutzer diesen dritten Server als Mail- Home- Server bekommen, also habe ich einen "Benutzer verschieben" Prozess gestartet mit den Einstellungen aus dem angefügten Screenshot. Die Option "Alte Repliken auf dem alten Cluster löschen" ist dediziert NICHT angehakt.

Trotzdem sind am nächsten Tag alle Repliken auf dem alten Mail- / Homeserver der Benutzer gelöscht (auf dem dritten, unbeteiligten Clusterpartner sind die Datenbanken unangetastet).

Und so wie im zweiten Screenshot sehen die Admin- Anforderungen aus: Nicht nur wurde -trotz deaktivierter Option- eine Mailfile- Deletion angestossen, sie wurde auch noch automatisch approved, angeblich vom Admin, und angeblich am nächsten Morgen. Ich kann zu 100% ausschliessen, dass das wirklich passiert ist: Die Hälfte der Anforderungen wurde von mir erstellt, und angeblich von mir bestätigt. Ich war aber am darauf folgenden Tag als die Dokumente erstellt wurden gar nicht dort.
Die andere Hälfte, die der lokale Admin angestossen hat, wurde genauso approved, angeblich von ihm, und auch er schwört Stein und Bein, dass er das nicht gemacht hat.

[CarstenH]

Die Serverkombination mit 2x Cluster + 1x separat habe ich gerade nur als 9er Release und mit dt. LP da, falls bis heute Abend noch niemand testen konnte kann ich das mal in kleiner Umgebung als R10 nachbauen und schauen was passiert.
Was ich sehe: deutscher Adminclient, Server scheinen engl. ohne LP, was ich nicht sehe sind die verwendeten Versionen und welcher der Adminserver ist. Gern per PN.

Was mir (ohne Test) beim Lesen auffällt ist die Aussage "am nächsten Morgen", das klingt ungewöhnlich.
- wie sind bei euch die Ausführungszeitpunkte der AdminP-Requests in den Serverdokumenten gesetzt? Insbesondere wegen "am nächsten Morgen".
- hat das Bestätigungsdokument eine (halbwegs) runde oder eine krumme Zeit?
- wie viel Zeit lag zwischen Anforderung und Bestätigung?
- sind ID's des ursprünglichen Anforderers (der Löschung) und Bestätiger identisch?
- auf welchem Server entstand das Bestätigungsdokument?
- gibt es Anpassungen an admin4 oder 3rd-party-apps die noch mitspielen?

HTH
Carsten

[Tode]

OK: Admin Client ist 9.0.1FP9. Alle beteiligten Server sind 10.0.1FP3.

Der Ablauf ist so, dass die Admin- Anforderung am Abend von mir um 18:00 Uhr angestossen wurde, und alles, was ohne Benutzerbeteiligung abläuft innerhalb der üblichen Replizierintervalle bis 18:40 durchgeführt war. Anbei die Zeiten der Antwort- Dokumente auf die Tasks:

Check Mail Server's Access - Server Alt - 18:10
Create New Mailfile Replica - Server Alt - 18:21
Maintain Trends Database Record - Server Alt - 18:34
Add New Mailfile Fields - Admin Server - 18:22
Monitor New Mailfile Fields - Server Neu - 18:32
Replace Mailfile Fields - Admin Server - 18:40
NÄCHSTER TAG NACH ANMELDUNG USER:
Push Changes to New Mail Server - Server Alt - 08:25
Get Mail File Information for Deletion - Server Alt - 08:26
Approve Mail File Deletion - Meine ID (angeblich) - 08:51
Request Mail File Deletion - Admin Server - 08:51
Delete Mailfile - Server Alt - 09:03

Ich habe mal viele weitere "Push Changes to New Mail Server"- Requests geprüft, und die laufen wohl wirklich nach der nächsten Useranmeldung los: Teilweise am gleichen Tag noch um 19:17, dann 23:48 oder nächster Tag 06:53.

In allen Fällen ist dann die "Get Mail file Information" eine Minute später, und der angebliche Approval zwischen 10 Minuten und 30 Minuten später (vermutlich Replizierintervall zwischen Mailserver und Adminserver)...

Anforderer und Bestätiger sind immer identisch: DIe Löschungen, die vom anderen Admin angefordert wurden, wurden angeblich von ihm bestätigt, und Löschungen, die ich angefordert habe, angeblich von mir...

Das Bestätigungsdokument wird auf dem Adminserver erstellt.

Habe übrigens das Ganze gerade mal auf einem weiteren Cluster der Domäne getestet, der nur aus 2 Partnern besteht: User auf Clusterserver 1, Benutzer verschoben auf Clusterserver 2: Trotz Einstellungen gemäss Screenshot ist jetzt die Datenbank auf Clusterserver 1 gelöscht... vollautomatisch... gruselig...

[jgr]

Hallo Torsten,
Das Problem hatte ich auch.

Ich konnte und habe das FP2 installiert.
Das ist ein Regression Bug aus irgendeiner 8er Version.

Wen genauere Infos gewünscht sind muss ich nochmal suchen.

Gruß
Jan

[Tode]

Ok, interessant @Jan, Danke für die Info. Wenn Du mir da noch ne SPR- Nummer dazu hättest, dann würde mir das helfen.

[jgr]

Regression in 10.0.1
SPR# SMOYB9JMCN - Adminp was incorrectly creating a Monitor Stub request for a Create Replica request, in effect treating it as a Move request. This has been corrected. A workaround is to disable the exchange unread marks option or manually create the replica from the UI

Schön, das Chats nicht verschwinden  

[Tode]

Super, Danke erst mal.

[CarstenH]

Ich konnte noch die älteren Cases via #LO48624 im Google Cache finden, gab es wohl bereits in 8.5.1, 8.0.1 und 7.0.2

http://webcache.googleusercontent.com/search?q=cache:P6ctbDmP7JUJ:www-01.ibm.com/support/docview.wss%3Fuid%3Dswg1LO48624+&cd=2&hl=de&ct=clnk&gl=de

Hilft vielleicht bei HCL wenn man sich drauf bezieht.

Und ja, gruselig trifft es.

Carsten

[Tode]

Super, danke für Dein "Google Foo", meins war gestern nicht erfolgreich.

Der Kunde ist -eigentlich- ein echt Treuer Domino- Fan (betreue den jetzt seit über 10 Jahren), aber mit den Bugs der letzten Zeit knirschen die Admins schon heftig mit den Zähnen, und die Akzeptanz bei den Usern schwindet... Gerade mit der Cluster- Erweiterung, die eigentlich total einfach sein sollte, haben wir uns so viele Probleme eingefangen, dass es keinen Spass mehr macht:

- User, die auf den neuen Server umgestellt wurden, bekommen die Arbeitsumgebung nicht angepasst (oder zurückgesetzt), so dass der Client noch weiter den alten Server adressiert (anderer Forums- Post)
- Nachdem sie dann doch umgestellt wurden, versucht der Client beim Zugriff auf Overlay- Kalender für die anderen Benutzer immer noch auf den alten Server zuzugreifen
- Auf dem alten Server fehlen aber die ganzen Repliken wegen dieses Bugs... und ein Failover passiert nicht...

[Manfred W.]

aber mit den Bugs der letzten Zeit knirschen die Admins schon heftig mit den Zähnen, und die Akzeptanz bei den Usern schwindet

Ja, das macht echt keinen Spaß mehr.
Einerseits freut man sich, weil endlich wieder was vorwärts geht. Aber Software-Tests gehören nicht zu den Stärken von HCL. Besonders ärgerlich sind auch die Schablonen-Bugs. Wenn man mit einer angepassten Mailschablone arbeitet, rollt man nicht mal eben schnell eine neue aus. Client-/Server-Hotfixes sind da ein deutlich kleineres Problem.

[DomAdm]

Hallo,
nur mal so als Hinweis.
Es gibt auch Dritttools die sowas machen wie das hier:
https://support.oneidentity.com/de-de/technical-documents/identity-manager/8.0/administration-guide-for-connecting-to-ibm-notes/44#TOPIC-858937

"
Automatic Confirmation of AdminP Requests

Certain AdminP requests have to be confirmed first by the administrator before they can be run. It is possible to confirm them automatically with the One Identity Manager. Prerequisite for this is regular synchronization of the Admin4 database.

To confirm pending AdminP requests regularly

    Configure and set the schedule "IBM Notes automatic AdminP request confirmation" in the Designer.

For more detailed information about editing schedules, see the One Identity Manager Configuration Guide.

Confirmation of the following requests has currently been implemented:

    Approve MailfileDeletion
    Approve MovedReplicaDeletion
    Approve ReplicaDeletion
"

[CarstenH]

Anpassungen an den AU mache ich mittlerweile fast ausschließlich direkt in den NAB's indem ich einfach alle Nutzer nur noch mit Roaming einrichte(n lasse).

Dadurch stehen alle PAB's auf dem Cluster für HelpDesk- und Admin-Änderungen mit Agents oder iQ.Suite-Jobs zur Verfügung und man kann mal eben Nutzer ohne AdminP zwischen den Servern wandern lassen, lokale Mailboxen aktivieren usw.

Die Probleme beim Cluster-Failover betreffen (nach meiner Erfahrung) eher die Eclipse-Komponenten.

Carsten