Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: 0xse am 08.03.12 - 11:02:14
-
Hallo zusammen,
ich habe ein paar Benutzer einem anderen Zertifizierer zugeordnet, den AdminP Request bestätigt, etc. Jetzt steht im Personendokument drin "Namensänderung: Ausstehend" und unter Zertifikate auch die Änderungsanforderung. Der Ablauf funktioniert.
Benutzer 1:
Startet den Notes Client neu, der holt sich direkt den neuen Namen. Läuft.
Benutzer 2:
Startet den Notes Client neu, nichts passiert. Nochmal gemacht, nichts passiert. Nach 3 Stunden nochmal neugestartet, holt sich den neuen namen. Läuft.
Nach welcher Logik holt sich der Notes Client die Namensänderungen beim Domino ab? Bzw. wie kann ich ihn "zwangsmotivieren" sich die beim nächsten Client Start abzuholen?
VG
Edit:
Client 8.5.2
Server 8.5.2
-
Notes Client ??
Eigentlich passiert am Notes Client gar nichts....!?
Wo genau ist denn bei User 1 etwas geändert worden (clienttechnisch) ?
-
Hallo,
die Namensänderung in der ID wird beim Zugriff auf den Homeserver abgeschlossen. Ein Neustart des Clients ist dafür nicht nötig. Dass es manchmal länger dauert als üblich, ist mir auch schon aufgefallen. Ich vermute, es liegt daran, dass manchmal der Servercache ein zügigeres Arbeiten verhindert.
Gruß
Wolfgang
-
Eigentlich passiert am Notes Client gar nichts....!?
Dazu habe ich gerade einen High Prio Call bei IBM laufen weil > 50x Gegenzertifikatsabfragen auf dem Client aufpoppen, trotz korrekter Konfig. Ist vor 5 Minuten an die 2. Instanz eskaliert worden. Da passiert schon was, nur halt das falsche :P
Danke für die Info Wolfgang. Ich werde das mal austesten mit Cache leeren, View Zugriffe protokollieren, etc... irgendworan muss es ja liegen :)
-
Eigentlich passiert am Notes Client gar nichts....!?
Dazu habe ich gerade einen High Prio Call bei IBM laufen weil > 50x Gegenzertifikatsabfragen auf dem Client aufpoppen, trotz korrekter Konfig. Ist vor 5 Minuten an die 2. Instanz eskaliert worden. Da passiert schon was, nur halt das falsche :P
Danke für die Info Wolfgang. Ich werde das mal austesten mit Cache leeren, View Zugriffe protokollieren, etc... irgendworan muss es ja liegen :)
Eine Namensänderung kann auch komplett ohne Client erfolgen, lediglich die ID wird beim Serverzugriff entsprechend geändert sonst nichts......
Deshalb kann ich nicht nachvollziehen, welche Änderung am ersten Client erfolgt sein soll.........???
-
Du erzählst QUATSCH @Cebe...
Wenn Du eine Namensänderung anstösst, dann bleibt die in einem bestimmten Status so lange, bis der User sich das erste Mal bei seinem Mail- Home- Server anmeldet. ERST DANN läuft die eigentliche Umbenennung los (in ACLs, Leserfeldern, Mail, etc.). Wäre es anders, dann könnte der User gar nicht mehr auf "Seine" Datenbanken / Dokumente zugreifen, wenn die schon umbenannt wären, aber seine ID noch auf dem alten Stand ist...
Und da ist auch die Erklärung für die Verzögerung: Bei der Umbenennung sind ggf. verschiedene Server beteiligt (im dümmsten Fall 3):
1. Der Server, auf dem die Umbenennung angestoosen wird (also der, den der Admin grade offen hat)
2. Der Admin- Server der Domain
3. Der Mail- Home- Server des Benutzers.
Wenn diese drei (im Normalfall sind es zwei) Server nicht regelmässig replizieren, und die versteckten Ansichten in names.nsf und admin4.nsf nicht up to date sind auf dem Mail- Home- Server, dann kriegt der Client die Änderung (noch) nicht mit. Um das zu beschleunigen macht man also:
- Replikation names.nsf / admin4.nsf auf den Admin- Server
- tell adminp pro new auf dem Admin- Server
- Prüfen, ob die Umbenennung in der Admin4 angestossen wurde
- ggf. bei Umzertifizierung die Umzertifizierung durch Auswahl des neuen Zertifizierers abschliessen
- Replikation names.nsf / admin4.nsf auf Mail- /Home- Server des Users
- Shift + Strg + F9 in Home- Server des Benutzers
- ggf. dbcache flush am Home- Server
- User greift auf eine Datenbank auf dem Mail- Home- Server zu, ID wird umbenannt
- zurückreplizieren auf Admin- Server von names.nsf / admin4.nsf
- tell adminp pro new (ggf. mehrfach)
-
Du erzählst QUATSCH @Cebe...
Wenn Du eine Namensänderung anstösst, dann bleibt die in einem bestimmten Status so lange, bis ....
Ganz meinerseits Tode, ich behaupte Du erzählst "QUATSCH"......
Das was Du beschreibst war früher mal so.........ist aber schon seit Jahren anders....
Der hierarchische Name in der ID wird lediglich irgendwann umbenannt, ansonsten ist die ID nicht mehr der Initiator für die Namensänderung !
Wann hast Du denn Deine letzte Namensänderung durchgeführt und auf welchem Release ?
-
Ich benenne mehrmals wöchentlich Anwender (Rel. 8.53 Server) um und es verhält sich exakt so wie Tode es sehr ausführlich beschrieben hat.
-
Und ich habe heute erst 2 Namensänderungen durchgeführt OHNE das mit der ID anzustossen................Ist schon merkwürdig....... :o
Vielleicht habe ich hier ja das rumdum Sorglospaket..... :D
-
... bevor Du aber nicht mit der ID auf den Homeserver zugreifst, ist der Prozess nicht in allen Teilen durchgelaufen. Da fehlt noch ca. die Hälfte.
Gruß
Wolfgang
-
Ich kann von meiner Seite aus auch nur Tode's Aussage bestätigen.
-
Kenn ich nur so wie es Tode beschrieben hat.
Sobald der User sich erneut anmeldet läuft der ganze Prozess im Hintergrund ab.
Wenn der User, wie es bei uns häufig vorkommt, umgetauft wird (Heirat) und zu dieser Zeit bereits nicht mehr aktiv ist, bleibt mir nix anderes übrig mich mit der User-ID anzumelden um die Namensänderung komplett abzuschliessen.
Falls das übersehen wird, kann ich den ganzen Vorgang nochmal durchführen, sobald der User wieder im Haus ist und die letzteren Fälle habe ich massig.
-
Danke für die Unterstützung... ich hatte schon an meinem Verstand gezweifelt... Aber bei der Lektüre der Admin- Hilfe habe ich keinen Hinweis darauf gefunden, dass es geändert worden wäre...
habe nur diesen Eintrag gefunden (http://totalcsi.com/help/help85_admin.nsf/f4b82fbb75e942a6852566ac0037f284/befac7e4a9a63b0f852574d50009c0db?OpenDocument), und das Bild scheint mich ja zu bestätigen: "Person accepts new name before change request expires" ist immer noch notwendig... was da nicht steht, ist, dass diese "acceptance" heutzutage normalerweise passiert, ohne dass der Benutzer gefragt wird, das macht der Client alleine...
(http://totalcsi.com/help/help85_admin.nsf/f4b82fbb75e942a6852566ac0037f284/befac7e4a9a63b0f852574d50009c0db/Body/0.352?OpenElement&FieldElemFormat=gif)
-
@Tode - Muss da ein Stück weit zurückrudern, früher musste man explizit der Namensänderung zustimmen, heute wird diese im DD sofort vollzogen.
Danach geht es erst wieder weiter, wenn mit der ID auf den Server zugegriffen wird, ohne dass eine Zustimmung erfolgt, das passiert alles im Hintergrund, insofern hast Du natürlich recht.
Trotz alledem bleibe ich bei meiner Aussage, dass auf dem Notes-Client nichts geändert wird, als der Name der ID.
-
Und mit dieser Aussage hast Du (fast) vollkommen recht (Wenn man von den Anpassungen in der Arbeitsumgebung, notes.ini und im persönlichen Adressbuch absieht...
-
Und mit dieser Aussage hast Du (fast) vollkommen recht (Wenn man von den Anpassungen in der Arbeitsumgebung, notes.ini und im persönlichen Adressbuch absieht...
... und in lokalen Repliken des Mailfiles und in lokalen Archiven des Mailfiles (nach der nächsten Archivierung) :-) Fehlt noch was?
Gruß aus Stuaget
Heiggo
-
Und damit sind wir wieder bei der ursprünglichen Frage angekommen ;-)
- Replikation names.nsf / admin4.nsf auf den Admin- Server
> Admin-Server ist auch der Homeserver des Benutzers
- tell adminp pro new auf dem Admin- Server
- Prüfen, ob die Umbenennung in der Admin4 angestossen wurde
- ggf. bei Umzertifizierung die Umzertifizierung durch Auswahl des neuen Zertifizierers abschliessen
> AdminP hat über den CA den neuen Schlüssel im Personendokument hinterlegt, FullName ist auch umbenannt
- Shift + Strg + F9 in Home- Server des Benutzers
> Aktualisiert alle Ansichten in der aktuellen DB. Meinst du das NAB?
- ggf. dbcache flush am Home- Server
> Probiert, auch mit einem drop all davor, hat nichts gebracht
- User greift auf eine Datenbank auf dem Mail- Home- Server zu, ID wird umbenannt
> User greift auf eine DB zu, wird aber nicht umbenannt > Problem ;) Erst später wird er umbenannt (erster Beitrag, s.o.)
- tell adminp pro new (ggf. mehrfach)
> Nicht notwendig, der erste Schritt des AdminP ist ja gelaufen, dann ist der Client dran. Der Rest sind verzögerte Anforderungen, die laufen dann in der Nacht oder bei einem process all.
Heißt... ggf. eine Ansicht nicht aktuell... Ich werde das mal mit einem Benutzer probieren. Wenn keine Änderung ankommt, einfach mal im NAB alle Ansichts-Indizes neu aufzubauen. Vlt. hilfts :)
VG
-
Ich vermute auch einen Defekt in einer der NAB- Ansichten, so dass sich diese nicht korrekt refresht... Hatte leider in letzter Zeit häufiger so phänomene mit Ansichten im NAB. Eventuell mal komplett neumachen die Ansichten (mit updall -R und updall -C)
-
Getestet und einfach mal mit [Strg]+[Shift]+[F9] neu aufgebaut, Client holt sich die Änderung, läuft. Thx @ll :)