SUPER! DANKE! 
Das hat wunderbar funktioniert.
Bei der Sache mit dem AdminP geb ich Dir schon recht - mach ich normalerweise auch so. Die neuen Gruppen haben allerdings iene andere hierarchische Struktur und eine neuen Mitarbeiterzuordnung. durch die fehlende Alt-Neu Zuordnung hab ich mich für die Neuanlage entschieden.
So, nach längerer Zeit hab ich nun wieder ein Problem, was mich ein wenig zur Verzweiflung bingt und daher diesen Thread verursacht ....
Ablauf:
Wir haben in unseren Serveradressbuch (Domino 8.5.2) eine umfangreiche Reorganisation der Gruppen vorgenommen. Die Gruppen wurden in einem parallelen Adressbuch per Importskript neu erstellt und dann in das produktive Adressbcuh kopiert.
Nachdem Gruppen mit nur einem Mitglied (ja, sowas haben wir hier leider) erst nach einem manuellen Speichern des Dokuments korrekt übernommen worden sind, haben wir mal auf alle neuen Gruppendokumente mit Hilfe eines Agenten einen Refresh durchgeführt >>> @Command([ToolsRefreshSelectedDocs]);@All
Problem:
Nun werden die Dokuemtne zwar korrekt verarbeitet, aber beim Aufruf einer Gruppe steht der Fokus immer auf den letzten Reiter "Administration" anstelle des ersten Reiters "Basic".
Das ist gerade in der Phase mit den neuen Verteilern ziemlich schlecht, da die Benutzer natürlich nicht drauf kommen, dass Sie das Register wechseln müssen, um die Gruppenmitglieder zu sehen.
Lösungsversuche:
Ich habe nun eine Aktualisierung der Gestaltung, einen Schablonenwechsel (hierzu ein Template aus alter funktionierender Version erzeugt), einen fixup -J und einen compact -c laufen lassen.
Leider alles ohne Erfolgt. Die Sortierung ist immer noch falsch.
Umfeld:
* Neu angelegte Dokuemnte werden korrekt angezeigt
* Bei einer Änderung eines "falschen" Dokuments bleibt der Fehler bestehen
* Auch bei einer Kopie der Datenbank bleibt der Fehler bestehen
* Wird der Agent auf ein Personendokument ausgeführt, tritt der gleiche Fehler auf
Fazit:
Ich hab nun leider keine Idee mehr, wie ich das in den Griff bekomme.
Ich bin würd jeden Vorschlag dankbar.
PS:
* Falls es ein dummer Fehler ist, bitte ich meine Unwissenheit zu entschuldigen
* Falls ich die Lösung in der Hilfe oder im Forum über die Suchfunktion zu finden gewesen wäre, bitte ich meine Unfähigkeit zu entschuldigen
FEHLER BESEITIGT!
Eine Diskusion regt doch immer wieder die graune Zellen an. 8-)
Gerade als ich Dir schreiben wollte, dass ich wohl die events4.nsf für den Verursacher halte fiel mir bei der detailierteren Problembeschreibung auf, dass ich ja "nur" aufgrund des fehlenden Serverdokuments den alten Server nicht mehr hochfahren und mit diesem replizieren kann.
Also hab ich mir eine alte Version der names.nsf aus der Datensicherung geholt und das alte Serverdokument rüberkopiert. Dann die lokale Names.nsf auf dem alten Server gelöscht und diesen gestartet.
Und nun ist die Fehlermeldung weg.
Auch nachdem ich die names.nsf wieder bereinigt und den alten Server wieder heruntergefahren habe. Anscheinend wollte sich der Adminserver einfach nur noch kurz verabschieden.
Recht sentimental der Gute ....
Leider nein ...
wir haben zwar zwei 2-Node-Cluster, hier handelte es sich aber um einen stand-alone-Server einer Dienststelle.
Die Fehlermeldungen kommen auf dem (nicht geclusterten) Adminserver, auf dem die DDM-Collection eingerichtet war.
Meinst Du es hilft etwas, wenn ich einen Server mit dem gleichen (alten) Namen aufsetze?
Hat wirklich keiner eine Idee? :o(
Wir haben schon alles versucht, was uns eingefallen ist . Es gibt in der events4 kein einziges Dokument mehr, in dem der alte Server vorkommt. In der names.nsf wurde vom adminP auch schon alles gelöscht (leider). un dtrotzdem habe ich jede alle 10 Sekunden die Meldung "Unable to replicate with server xxx" auf der Konsole.
Beim Löschen eines Servers aus der Domäne bin ich leider zu spät auf den folgenden Hinweis in der Adminhilfe gestoßen:
Achtung Überprüfen Sie, welche Server in der Server-Erfassungshierarchie enthalten sind, bevor Sie einen Server in der Domäne außer Betrieb nehmen. Wenn Sie planen, einen Server außer Betrieb zu nehmen, entfernen Sie ihn aus der Hierarchie und nehmen Sie ihn dann außer Betrieb. Wenn Sie den Server nicht entfernen, kann dies zu Problemen bei der Datenzusammenführung führen, wenn diese nach Außerbetriebnahme des Servers ausgeführt wird.
Ich bin da leider erst aufgrund der Fehlermeldungen auf der Console des collectionservers auf den Hinweis gestossen - der Server ist leider schon vollständig durch den AdminP aus der Domäne gelöscht und lässt sich daher auch gar icht mehr starten.
Leider finde ich keine Hinweise, wie ich die genannten "Probleme" (Konsolenmeldung "unable to replicate with server xyz") denn nun bereinigen könnte. Ich finde keine Konfigurationsdokumente, die noch auf den alten Server verweisen.
Kann mir jemand einen Rat (oder Suchhinweis) geben?
mea culpa, mea maxima culpa ... 
Anschienend werde ich den Anforderungen an einen Fragesteller in diesem Forum einfach nicht gerecht ....
hm, und wie kann ich verhindern, dass es zu einer Veränderung der Arbeitsumgebung durch eine Proxyauthentifizierung kommt?
Ich kann den Proxy schlecht rausnehmen - der Benutzer hätte sonst keine Möglichkeit, verlinkte Inhalte in einer Mail anzeigen zu lassen.
... der ist in allen Umgebungen gleich: "proxy:8080"
Hier wird unser normaler Web-Proxy angesprochen (Zugriff nur nach Auth).
Wie sollte dieser denn für eine spontante Verschlüsselung verantwortlich zeichnen?
Gleich mal vorweg: Ja, ich habe die Foren durchsucht und Ja, ich habe auch die KB durchforstet.
Problem:
Es kommt immer häufiger vor, dass bei Usern, die mit zwei Arbeitsumgebungen arbeiten (unterschiedliche IDs für den normalen und den Personalrats-Account) sich ungewollt eine der Arbeitsumgebungen (meist die normale) verschlüsselt. Im Reiter Erweitert/Allgemein ist dann das Feld "Nur für Benutzer" entsprechend gefüllt.
Das - für mich - Unerklärliche daran ist, dass ich beim Erstellen von zusätzlichen Arbeitsumgebungen dieses Feld in allen vorhandenen Arbeitsumgebungen mit einem "*" fülle.
Anfangs hatte ich die Benutzer in Verdacht (Bedienungsfehler) allerdings hatte ich nun selbst auch genau dieses Problem. Ich kann mir nicht erklären, wodurch dieses Feld "automatisch" geändert wird.
Hat jemand eine Idee?
Dankeschön - ich hab das mal in der Konfig der beiden Mailserver aktiviert. Dann sollte ich morgen hoffentlich etwas mehr User sehen ...
-> d. h. ich muss auch auf JEDEM Server in der Domäne das license tracking aktivieren, damit die lokale Registrierung läuft?
Tja, dann hab ich wohl ein Verständnisproblem.
Ich kann NICHT herauslesen, ob die Aktivierung auf einem Server ausreichend ist - in der (deutschen) Version steht auch nur "Wählen Sie den Server aus ...". Dies lässt offen, ob es sich hierbei um den Administrationsserver handelt oder um den Server, auf dem die Benuter arbeiten.
Der Administrationsprozess läuft nachts - zu diesme zeitpunkt ist hier kein user auf einem Server aktiv. also müssen die Daten von gestern Nachmittag stammen - da waren aber ca. 400 User (gesamt > 1000 user) aktiv.
In der Datenbank (auf dem Adminserver) werden aber nur 32 User aufgeführt ...
ich hätte da mal eine Frage:
Gestern (gegen mittag) habe ich das license tracking auf unserem Adminserver aktiviert. Die USERLICENSES.NSF wurde heute nach korrekt angelegt - weist aber nur einen winzigen Bruckteil unserer tatsächlichen User auf.
Ist das normal? Muss ich erst ein paar Tage warten, bis sich die Datenbank füllt? Oder muss ich das licese tracking auf allen Servern einschalten? Die Dominohilfe ist da für mich nicht ganz klar:
Enabling or disabling license tracking
Use this procedure to either enable or disable License Tracking.
1.From the Domino administrator, click the Configuration tab.
2.Choose Server - Configurations.
3.Select [color=CC0000]the[/color] server and click Edit Configuration.
4.On the Basics tab, in the License Tracking field, click Disabled or Enabled according to what you want to do.
5.Click Save and Close.
Ich hab mal wieder eine Frage:
Wie kann ich feststellen, in welchem Ornder ein Dokument in der Maildatenbank verschoben wurde?
Ich finde leider kein Feld, aus dem ich diese Information entnehmen könnte.
Hintergrund: Es kommt immer wieder vor, dass Benutzer Mails in einer komplexen Ordnerstruktur "verstecken" - und dann nur noch über "Alle Dokumente" wieder finden.
Ich sehe mich nun mit der Anforderung konfrontiert, den Benutzern sagen zu müssen, wo sie ihr Dokuemnt abgelegt haben.
Habe hierzu weder im Forum noch in der KB was finden können - vermutlich ist die Frage zu trivial ... :cry:
Hm, wir sind da ein wenig großzügiger mit dem Speicher umgegangen.
Wir haben zwei 2-Node-Notescluster, jeder mit einer redundanten SAN-Anbindung mit gespiegelten Volumes eingerichtet.
Hat natürlich zur Folge, dass sich jede DB vierfach auf dem Storage findet - aber ausgefallen ist seit Inbetriebnahme noch nix!
Hm, ist die Namensänderung in der Names.nsf auf im Feld "Internet-Adresse" vorgenommen worden? Ist die namensänderung in den Besitzereinstellungen der Mail-DB geändert?
-> würde ich mal prüfen
Hm, bin ich gar nicht gewöhnt, dass ich gar keinen Tipp bekommen - ist die Frage so dumm oder so schwierig?
Ich habe eine Anforderung, das Naviagtionsprotokoll eines Users zu extrahieren. In der Noteshilfe finde ich nur den folgenden Hinweis:
Notes protokolliert Ihre Navigation, unabhängig davon, ob Sie in einer Datenbank, einem Dokument oder auf einer Webseite gearbeitet haben. Sie können in geöffneten Datenbanken oder Webseiten navigieren, indem Sie die in der Navigationssymbolleiste angezeigten Schaltflächen verwenden. Folgende Schaltflächen sind enthalten: "Zurück", "Vor", "Stopp", "Aktualisieren", "Suchen".
Kann mir jemand sagen, wo/wie dieser Verlauf gespeichert wird? :-?
