Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: Matze69 am 10.09.15 - 14:12:27
-
Hallo,
heute früh wollte ich an einen User eine Mail senden und der User ist nicht mehr im Adressbuch.
Die Maildatei ist noch vorhanden, da hat er gestern die letzte Mail um 18 Uhr bekommen und nachts um 2 Uhr nochmal eine.
Wie kann es sein, das ein User ohne Fremdeingriff plötzlich verschwunden ist?
Danke
-
Hatte der User Manager-Rechte auf seiner DB?
Vergiss es, das wäre der umgedrehte Fall.
-
Da gibts mehrere Möglichkeiten.
a) Agent
b) Unvorsichtiger Admin
c) korruptes Dokument welches von Fixup gelöscht wurde?
d) Replikationskonflikt?
-
und was kann ich da nun tun?
Einfach den User neu anlegen und Mail-DB zuordnen?
Wie sieht es dann mit verschlüsselten Mails aus?
-
und was kann ich da nun tun?
Einfach den User neu anlegen und Mail-DB zuordnen?
Wie sieht es dann mit verschlüsselten Mails aus?
Da sich der Schlüssel ändert ...
Wie wäre es mit einer Rücksicherung?
-
Wie Geri schon schreibt:
- names.nsf zurücksichern (allerdings nicht in das Data-Verzeichnis des Servers, am besten lokal auf den Admin-PC oder ähnliches)
- Personendokument des Users aus der Rücksicherung kopieren
- kopiertes Personendokument in das names.nsf am Server einfügen
-
Steht denn zur Ursache nichts im Log oder im Adminp?
-
Wie Geri schon schreibt:
- names.nsf zurücksichern (allerdings nicht in das Data-Verzeichnis des Servers, am besten lokal auf den Admin-PC oder ähnliches)
- Personendokument des Users aus der Rücksicherung kopieren
- kopiertes Personendokument in das names.nsf am Server einfügen
habe die names zurückgesichert. Allerdings sagt er mir beim Öffnen: Sie sind zur Durchführung dieser Operation nicht berechtigt
(trotz Admin mit voller Berechtigung)
-
(trotz Admin mit voller Berechtigung)
Müsste mich sehr täuschen, aber das zieht doch nicht bei lokalen Datenbanken?!
-
(trotz Admin mit voller Berechtigung)
Müsste mich sehr täuschen, aber das zieht doch nicht bei lokalen Datenbanken?!
aber wie kann ich dann die zurückgesicherte names.nsf öffnen?
-
Wenn die Backup-Lösung es hergibt (und das sollte jede halbwegs taugliche), dann kann die Datenbank mit einer neuen ID zurückgesichert werden.
Logischerweise nicht am Original-Speicherort.
Dann ist die DB nicht lokal, wird durch die neue ID nicht als Replik interpretiert und man kann problemlos den einen Eintrag in die aktuelle names.nsf kopieren.
-
Wenn die Datei lokal geöffnet werden soll:
- Im persönlichen Adressbuch eine Gruppe Namens "LocalDomainAdmins" erstellen
- Sich selbst in die Gruppe eintragen
- Client neu starten
Dann sollte sich die Datenbank (so sie denn eine "standard"- ACL hat) lokal öffnen lassen.
-
Wenn die Backup-Lösung es hergibt (und das sollte jede halbwegs taugliche), dann kann die Datenbank mit einer neuen ID zurückgesichert werden.
Logischerweise nicht am Original-Speicherort.
Dann ist die DB nicht lokal, wird durch die neue ID nicht als Replik interpretiert und man kann problemlos den einen Eintrag in die aktuelle names.nsf kopieren.
Wir haben als Backup-Programm Veeam und da kann ich soweit ich das gesehen habe nichts einstellen mit neuer ID.....
Das mit der Gruppe im persönlichen Adressbuch habe ich auch ausprobiert. Leider alles ohne Erfolg.
-
Kuck Dir doch mal die ACL in der aktuellen names an. Wer da drin steht sollte auch Zugriff auf die Rücksicherung haben.
-
Kuck Dir doch mal die ACL in der aktuellen names an. Wer da drin steht sollte auch Zugriff auf die Rücksicherung haben.
da stehe ich in der "Admingruppe" mit Managerrechte drin.
-
Und dann funktioniert das Vorgehen analog wie von Tode beschrieben nicht?
-
Habt ihr konsistente ACL aktiviert? Euer Backup-Tool scheint nicht wirklich für Domino ausgerichtet zu sein...
-
Das Vorgehen von Tode funktioniert nicht....
Haben konsist. ACL aktiv.
-
Eure Admin-Gruppe mit Managerrechten in der ACL des Directories heißt aber auch tatsächlich "LocalDomainAdmins" ?
-
Ich sehe zwei Wege:
- Aufsetzen eines Dummy-Servers in einer VM mit der Server-Id
- Ändern der Replik-Id über AntrID bzw. die C-Api
Mit einem Backup-System, welches eine Änderung der Replik-ID nicht unterstützt, werden immer wieder Umwege notwendig sein.
Gruss,
Thorsten
-
Vielleicht geht es auch mit einem manuell angelegtem Personendokument und den
öffentlichen Schlüssel aus der ID des User kopieren.
Gruiß Christian
-
Eure Admin-Gruppe mit Managerrechten in der ACL des Directories heißt aber auch tatsächlich "LocalDomainAdmins" ?
Unsere Admingruppe in der Names heißt anders. Habe aber nun genau diese Gruppe im lokalen Adressbuch hinzugefügt wie von Tode beschrieben. Kann die Datei aber trotzdem nicht öffnen...
Was würde denn passieren, wenn ich manuell den User neu anlege und ihm seine immer noch bestehende Mail-DB unterjuble.....
-
Du willst mit Kanonen auf Spatzen schießen, nur weil Du nicht in der Lage bist, eine lokale Datenbank mit konsistenter ACL zu öffnen?
LÖSE Dein Problem und renne nicht dreimal mit der Kirche ums Dorf, und entwickle Workarounds, die gar nicht nötig sind...
Mal ganz abgesehen davon, dass ich persönlich ganze genau wissen wollen würde, wer "einfach so" Dokumente in meinem Domino Directory löscht (wenn es ein Versehen war, ist diese Erkenntnis ja auch OK, aber was, wenn nicht....)...
-
Was würde denn passieren, wenn ich manuell den User neu anlege und ihm seine immer noch bestehende Mail-DB unterjuble.....
Wie sieht es dann mit verschlüsselten Mails aus?
Kannst Du die veeam-Sicherung nicht einfach in eine andere VM recovern?
-
Wenn dort ein Domino Server mit demselben DD läuft, dann hat man wieder das Problem der doppelten Replik-ID.
Wenn dort kein Domino Server läuft, dann hat man eine normale Rücksicherung wie auf ein lokales Laufwerk.
Gruss,
Thorsten
-
Wenn dort ein Domino Server mit demselben DD läuft, dann hat man wieder das Problem der doppelten Replik-ID.
Wenn dort kein Domino Server läuft, dann hat man eine normale Rücksicherung wie auf ein lokales Laufwerk.
Gruss,
Thorsten
Und wenn man ein eigenes Testnetz hat...
-
Hallo Matze,
wahrscheinlich denke ich zu simpel (das ist meine Stärke ;D), aber ich würde einfach:
1. das Replizieren des DD auf dem Quell-Dominoserver und ggf. vorhandenen Clusterservern ausknippsen
2. die Rücksicherung auf den Quell-Dominoserver in ein Verzeichnis unterhalb des Data-Verzeichnisses vornehmen
3. jetzt sollte das zurückgesicherte DD zu öffnen sein: also Kopieren des Personendokuments
4. Einfügen des Personendokuments in aktivem DD
5. Löschen des zurückgesicherten DD
6. Replizierung des DD auf dem Quell-Dominoserver und ggf. vorhandenen Clusterservern wieder einknippsen
7. Replizieren des DD vom Adminserver aus
Danach würde ich aber unbedingt herausfinden wollen, was die Ursache der Löschung ist ...
Liebe Grüße
René
-
Moin,
ich möchte mal behaupten, das geht noch simpler:
1) DB auf Server in Verzeichnis außerhalb des Domino-Data zurücksichern
2) set cluster_admin_on=1 auf dem Server (auch, wenn's kein Cluster ist)
3) cl copy c:\verzeichnis\ausserhalb\data\names-aus-backup.nsf restore\names-vom-wannauchimmer.nsf
Man beachte: Parameter 1: absoluter Pfad, Parameter 2: relativer Pfad im data.
Und schwupp's, hab ich eine DB-Kopie (nicht Replik) der Rücksicherung auf dem Server, wo ich dann auch per FullAccess-Admin (oder im Falle der names.nsf hoffentlich auch ohne) drankomme.
Doku dazu z.B. hier (http://www-10.lotus.com/ldd/dominowiki.nsf/dx/14022008070103WEBG4Q.htm).
Alternativer Ansatz, sofern man die passenden Möglichkeiten hat: den entsprechenden Deletion Stub identifizieren und entfernen (oder wenn's nicht weh tut, alle Deletion Stubs entfernen) und dann die Rücksicherung gegen die aktuelles names.nsf replizieren. Danach dann aber schnell wieder das Personendokument einmal neu speichern, sonst gewinnt vermutlich wieder der Deletion Stub vom Nachbarserver, wenn es einen gibt.
Ich muß aber dazu sagen, daß ich letzteren Ansatz bisher nur wenige Male mit Postfächern erfolgreich probiert habe - ob ich mich das bei der names.nsf trauen würde, weiß ich selbst noch nicht recht.. ;)
Wenn es übrigens keine Deletion Stubs in der DB gibt, würde mir das zu denken geben:
Das letzte Mal, als ich ein Phänomen mit unerklärlich verschwindenden Dokumenten hatte (allerdings auch wieder in einem Postfach), war es der Haken bei "Remove documents not modified in the last (days)" in den Space Savers der Replikationsoptionen. Worauf man mich freundlicherweise hier im Forum gestupst hat, nachdem ich da fünfmal dran vorbeigeguckt und schon Teufelswerk >:D vermutet hatte.. :)
Ciao
Sascha