Revert Name Change

[alexhe]

Hallo Zusammen,

wir hatten in der letzten Zeit bei ca. 10 % der User, die wir umbenannt / umzertifiziert haben , das Problem, dass nach den Standardmässigen 21 Tagen auf einmal ein Revert Name Change in der admin4.nsf aufgetaucht ist und die ACL von dem User auf den alten Namen geändert wurde.

Ich habe dann am Client direkt überprüft was in den Sicherheitseintellungen steht und bei den Usern, die einen Revert Name Change ausgelöst haben, stand überall immer "Namensänderungen automatisch herunterladen und annehmen" .

Meine Vorgehensweise:

- User informieren, dass einen Umbenennung / Umzertifizierung statt finden wird . Diese Mail wird per Empfangsbestätigung geschickt, dass, sobald ich die Bestätigung bekomme ,dass der User die Mail gelesen hat, ich den Prozess starten kann.

- im Admin Client User markiert und auf "Rename" geklickt.

- Entweder "Change Common Name" oder "Request Move to New Certifier" ausgewählt und durchgespielt

- Bei "Request Move to new Certifier" noch zusätzlich den neuen username eingetragen


Dieser Prozess funktioniert bei 90% der User, bei 10 % eben nicht. 

Hat jemand eine Idee woran das liegen könnte bzw. einen Tipp wo ich noch suchen könnte ?

Danke!

[Tode]

Welche Versionen setzt Ihr auf dem Admin- Server ein? Es gab in einer 6er- Version einen Bug, dass der adminp die Felder, die im Adressbuch für den Revert des Name- Changes wenn nix passiert nach den 21 Tagen nicht zurückgesetzt wurden, OBWOHL alles sauber durchgelaufen ist...

Eventuell ist der ja zurückgekommen... Leider laufen alle Links auf den Artikel "swg21139262" mit dem Titel "Renamed users are reverted back to their old names after 21 days" ins leere... nur so viel: Um zu prüfen, ob es sich um einen solchen "wiederauferstandenen" Bug handelt, könntest Du mal folgende Felder (am besten per Ansicht) prüfen / monitoren, denn die sind für ein Revert back zuständig (aber eigentlich nur, wenn der Prozess nicht erfolgreich war):

FIELD AdminpOldCertificate :=@DeleteField;
FIELD AdminpOldFirstName :=@DeleteField;
FIELD AdminpOldLastName :=@DeleteField;
FIELD AdminpOldMI :=@DeleteField;
FIELD AdminpOldFullName :=@DeleteField;
FIELD AdminpOldOwner :=@DeleteField;
FIELD AdminpOldAltFullName :=@DeleteField;
FIELD AdminpOldAltFullNameLanguage :=@DeleteField;
FIELD AdminpOldInternetAddress :=@DeleteField;   
FIELD AdminpOldShortName :=@DeleteField

Hier noch ein Link zu einem Artikel, der ein -leicht abgewandeltes- Problem beschreibt:
http://www-01.ibm.com/support/docview.wss?uid=swg21161109

[alexhe]

Ich Schlauchfuchs...Versionsangaben vergessen...

Wir haben einen 8.5.2 FP4 Domino Server auf einer iSeries am Laufen
Die Clientversion ist 8.5.1FP5

Ich werd mir mal die Feler zu Güte führen, danke schonmal!

[alexhe]

Also die Felder

AdminpOldCertificate
AdminpOldFirstName
AdminpOldLastName
AdminpOldMI
AdminpOldFullName
AdminpOldOwner
AdminpOldAltFullName
AdminpOldAltFullNameLanguage
AdminpOldInternetAddress
AdminpOldShortName

sind bei den User, bei denen der Revert Name Change kam, vorhanden.

Was mir auch aufgefallen ist, dass der AdminP einfach nicht weiterläuft

Bedeutet:

Ich zertifiziere 2 User um. Bei User A erzeugt der AdminP folgende Requests in der admin4.nsf:

Move Person's Name in Hierachy
Initiate Rename in Domino Directory
Rename Person in Domino Directory
Rename in Access Control List
Rename in Person Documents
Rename Prson in Unread List
Rename Person in Free Time Database
Rename Person in Calendar Entries and Profiles in Mail File
Rename in Design Elements
Rename in Reader/Author fields

Bei User B, der nicht korrekt durchläuft und die Felder AdminPOld.. enthält hat er entgegen nur folgende AdminP Requests :

Move Person's Name in Hierachy
Initiate Rename in Domino Directory


Bei allen AdminP Requests, sowohl bei User A und B, steht auch, dass er diese erfolgreich durchgeführt hat.

Kann man den AdminP irgendwie debuggen, damit ich sehe, warum er bei User B einfach nicht weitermacht?

[Tode]

Hat der User bei dem es nicht weitergeht sich denn mal mit seinem Notes- Client an seinem Mail- Homer- Server angemeldet? Vorher geht es nämlich nicht weiter... Und wenn das in 21 Tagen nicht passiert, dann kommt eben der Revert...

[alexhe]

Wie gesagt, wir stellen sicher, dass der User arbeitet, da wir erst mit dem Change anfangen, wenn wir die Empfangsbestätigung von der Mail bekommen.

Das macht mich ja so ratlos

[ascabg]

Hallo,

Das der User die Mail geoeffnet hat, heisst nich auch folgerichtig, dass der Prozess funktionieren muss.

- Sende Mail
- User oeffnet diese und nach ca. 10 min. faehrt er den Client runter
- nun ist er fuer 3 Wochen im Urlaub und meldet sich somit nicht mehr im Notes an

Und schon hast Du ganz schnell mal die 21 Tage erreicht.


Andreas

[alexhe]

Hi Andreas,

das stimmt, so könnte es laufen.

Es war aber definitv so, dass der User gearbeitet hat, weil ich mit ihm so gut wie täglich kommuniziert habe ( hatte noch ein paralleles Projekt am laufen )



 

[karljäger]

Hallo!

Wie lange läuft der Server (AdminP) bereits? Bei uns ist es bereits 2 mal passiert, dass die Umbenennung hängen geblieben ist.
Ich bin mir recht sicher (möchte es ehrlich gesagt in der Produktion nicht unbedingt nachstellen ), dass:

• der erste Schritt der Umbenennung noch durchgeführt wurde,
• der zweite Request in der admin4 gar nicht mehr erstellt wurde (wird normalerweise vom Admin-Server erstellt.),
• andere Adminp-Requests korrekt abgearbeitet wurden.

Ein Durchstarten des AdminP am Admin-Server hat gereicht um ihn zu überreden künftige Umbenennungen korrekt durchzuführen. Namensänderungen, die bereits gestartet wurden, werden aber dabei leider nicht mehr berücksichtigt.

Passiert in Domino-Version 8.5.1FP5