Beiträge von KETE

    Hallo Klinge,


    wenn ich Dich richtig verstanden habe, so hast Du nur diese Adressbuch auf dem Server abgelegt, damit alle Personen (der Gruppe bzw. alle die über die ACL Zugriff bekommen) es erreichen können. Du hast es aber nicht direkt am Server eingebunden (Directory Assistance oder per Eintag in der Notes.ini des Servers).


    Wenn das so ist, dann bleibt Dir nur der Weg das Adressbuch an jedem Client, der das Adressbuch verwenden soll, als lokales Adressbuch in der Notes.ini des Clients einzutragen.


    Den entsprechenden Eintrag hast Du ja schon aus dem vorherigen Beitrag. Einfach in die Ini-Datei des Client folgendes eintragen:


    names=names.nsf, Servername!!Verzeichnis\dateiname.nsf


    Dann verwendet der Client das Adressbuch auf dem Server wie ein lokales Adressbuch und löst die Adressen/Gruppen beim senden für den Server auf.


    Gruß,
    Kete

    Hi,


    allen anderen Repliken? D. h. ihr replziert mehrere Datenbanken mit diesem einen Kunden? Oder meinst Du andere Kunden?


    Wenn mehrere DB's mit dem selben Kunden repliziert werden, wird dann immer die selbe Zugriffsgruppe für die Replizierung genommen? Ich denke dabei daran, dass evtl. die Zugriffgruppe in der Quell- und Zieldomäne evtl. unterschiedliche Inhalte hat!?!


    Der Server des Kunden versucht es aber auch direkt oder per Passthru?


    Gruß,
    Kete

    Hi,


    wenn ich Dich richtig verstanden habe läuft bei dir jeden Tag ein compact -s10 -b und Dein Server ist Transaktionsprotokolliert.


    Wenn das so ist, würde ich den compact Parameter nicht von klein -b auf gross -B ändern es sei denn, Du lässt jede Nach ein Fullbackup laufen. Bei dem -B Parameter wird, wie schon gesagt, die Datenbank Grösse auf der HD reduziert, allerdings wird der Datenbank damit auch eine neue Datenbankinstanz-ID (DBIID) zugewiesen. Damit sind die alten Transaktionsprotokolle nicht mehr mit der Datenbank mit der "neuen" DBIID in Verbindung zu bringen. Ergo brauchst Du nach dem compact -B ein neues Fullbackup, nachdem Du dann wieder nur die Transaktions-Logs sichern brauchst.
    Ebsenso verhält es sich bei dem compact -c (copystile) auch hier wird der DB eine neue DBIID zugewiesen und Du brauchst ein neues Fullbackup.


    Also ich würde die Option bei Transaktionsprotokollierung nicht einfach mal so umstellen. Zumindest nicht ohne den Backup Aspekt gelöst zu haben.


    Zu Lösung Deines ursprünglichen Problems würde ich einmal ein compact -c über eine der Datenbanken laufen lassen und danach das "Problem" beobachten. Natürlich den compact nur kurz vor dem nächsten Fullbackup laufen lassen.


    Gruß,
    Kete.

    Hi,


    wie sieht es den mit den Einträgen für alternative Internet Domänen Aliase im primären Domänen Dokument aus?
    Wird dort die "alte" Domäne aufgeführt oder gar noch als primäre geführt?


    Der Router macht definitiv bei Notes mehrere Lookups wenn es mehrere Internet Domänen gibt und er die EInträge im Domänen Dokument findet. Dann sucht er zwar als erstes nach einer Internet die auf info@xxx.de lautet, wenn er diese nicht findet schaut er sich die Einträge in dem Domänen Dokument an und ersetzt die Maildomäne nach dem @-Zeichen und sucht erneut mit den Domänen aus den beiden Feldern primäre/aliases und versucht es mit den Kombinationen. Wenn man hier nicht ziemlich aufpasst findet der Router einen ungewollten Treffer und stellt die E-Mail doch noch zu.


    Ein Blick in das primäre Domänen Dokument würde ich deshalb mal auf jeden Fall werfen.


    Gruß,
    Kete

    Hi,


    sind den alle Server in der selben Domäne?
    Wenn nicht, ist den die berechtigte Servergruppe in allen Directories gleich bzw. berechtigt den "fremden" Server überhaupt dazu Dokumente in der Quell Domäne/DB/Docs zu lesen?


    GRuss,
    Kete

    Hi Zevir,


    ich kenne keinen Weg, über den Domino Administrator, diese Information aus dem OS raus zu bekommen.


    Gruß,
    Kete

    Hi,


    schon mal ein Mail-In-Dokument für den Server angelegt?
    Da kannst Du ja eine Internet Adresse für den Server hinterlegen.


    Wieso steht eigentlich in dem From Feld der Server als Absender und nicht der User? Es sollte hier doch eher der jeweilige User stehen den der Server über das Principal Feld auflösen kann.


    Gruss
    Kete

    Hi Meckes,


    ich glaube, dass Du die Belastung durch den Administrationsprozess ziemlich überschätzt. Dieser ist eigentlich schon dafür ausgelegt, die Belastung gleichmässig zu verteilen z. B. werden Leser- und Autorenfelder in den Dokumenten erst am WE geändert.


    Ich jedenfalls, habe noch keine Performanceeinbrüche durch den Administrationprozess auf einem Server verspürt.


    Naja, selbst wenn Du Dein Vorhaben in die Tat umsetzt (was höchst wahrscheinlich nicht wirklich was bringen wird), den Adminstrationserver für die Domäne auf eine zusätzliche HW zu konfigurieren, wird dennoch ein nicht unerheblicher Teil der Administrationsaufgaben von anderen Servern in der Domäne ausgeführt. D. h. der jeweilige Administrationsserver einer Domäne führt nicht alle Anforderungen selber aus.


    Kleiner Tipp am Rande: Wenn Du Dir wirklich Sorgen darüber machst, der Administrationsprozess könnte auf Deinen produktiven Server zuviel Last verursachen, dann hast Du aller Wahrscheinlichkeit nach eine zu schwache HW zur Verfügung. Deshalb würde ich lieber über den Erwerb einer neuen, leistungsfähigeren HW nachdenken oder wenigsten ein oder zwei Riegel mehr Speicher nachlegen. Davon hast Du und Deine User wesentlich mehr.


    Gruß,
    Kete

    Hi,


    ich würde nur in den aussersten Notfällen eine Notes Datenbank per Filesystem kopieren. Die können dabei schon öffter mal defekt auf dem Zielsystem ankommen.


    Wieso registrierst Du nicht einen temporären Server und replizierst die Datenbanken auf die neue Maschine. Anschliessend musst Du nur noch aus dem neuen Server den alten machen und fertig bist Du.


    Der grosse Vorteil dieser Aktion ist die enorme Zeitersparniss auf Deiner Seite :)
    Die Relizierung kannst Du tagsüber machen lassen und die Umkonfigurierung der Server sollte auch nicht länger als 0,5 - 1 Std. dauern. Das kann man locker WOchentags nach Feierabend machen und kommt noch früh nach hause :-)).


    Gruß
    Kete

    Hallo,


    wie hast Du denn die Berechtigungen auf die Datenbank vergeben.
    Das ist doch eigentlich der selbe Fall wie bei einer deligierten Maildatenbank wo man im Namen von jemanden eine E-Mail schreiben kann. Hier wird doch auch die reichtige Rückadresse eingetragen.


    Mal ne andere Frage: Wie hast Du denn das Mail-In-Dokument angelegt? Voll hirarchisch? Dann solltest Du auch so den Besitzer eintragen. Vielleicht hilft das schon, denn dann kann der Router die Internet Adresse des Besitzers richtig auflösen.


    Gruß,
    Kete

    Hallo Dietrich,


    bekanntlich führen ja "Viele Wege nach Rom". Mit den Infos, die Du zu Deiner
    Ist-Situation aufgeführt hast, hast Du ja schon einen Weg eingeschlagen, indem
    Du eine neue DOmäne mit einer neuen Organisation auf einer neuen MAschine erstellt hast.
    Wenn Du Deinen Ansatz weiter verfolgen willst, dann kannst Du folgendes machen.


    Bei der Umstellung gibt es zwei Teile und zwar einmal den Server- und
    den Client Part.


    Bei meiner Ausführung setze ich mal einiges an Know How auf Deiner Seite vorraus,
    sowie folgende Annahmen:


    1. Die beiden Server (alt und neu) stehen in einem LAN und können sich erreichen.
    2. Du hast Zugriff auf alle beteiligten Zertifizierer (alte und neue Umgebung) sowie
    die benötigten Kennwörter.
    3. Du hast Zugriff auf ein Backup aller User ID Dateien sowie diese Kennwörter.
    4. Die ACL's aller Datenbanken haben mindestens die Gruppe "LocalDOmainServers" als
    Manager eingetragen.
    5. Du kennst die Kennwörter der aktuell von Deinen Anwendern verwendeten User ID-Dateien.
    6. Du bist wahnsinnig genug, dass alles an einem WE durchziehen zu wollen. Wenn nicht,
    dann solltest Du von dem aufgezeigten Weg abweichen und evtl. kleinere Gruppen bilden,
    die Du in die neue Struktur überführen willst. Die nötigen Querzulassungen einrichten
    und Verbindungsdokumente zur Replizierung und Mailübertragung. Die Directories aus-
    tauschen und sicherstellen, dass alle Mitglieder der DOM1 die Mitglieder der DOM2
    per E-Mail erreichen können und umgekehrt. Sowie die Replizierung genau planen bzw.
    endscheiden welche Datenbanken (ausser Mail DB's) Du im ersten Schritt in die neue
    Umgebung mitnehmen willst.



    Server Part - mögliche Vorgehensweise (Du willst alles an einem WE durchziehen):


    1. Kopiere aus dem alten Directory alle Certifier in das neue Directory, sowie aus dem
    neuen Directory alle Certifier in das alte Directory.
    2. Erstelle im alten Directory eine Querzertifikat zur neuen Organisation aus.
    3. Erstelle im neuen Directory eine Querzertifikat zur alten Organisation aus.
    4. Trage in der Gruppe "LocalDomainServers" im alten Directory den neuen Server ein
    und im neuen Directory den alten Server. Damit sollten die Zugriffe auf die DB's
    vom neuen Server aus möglich sein.
    5. Erstelle von allen Datenbanken, die auf den neuen Server müssen ein Replikrumpf
    auf dem neuen Server. Ein Replikrumpf reicht an dieser Stelle, die DB's werden später
    vom neuen Server inizialisiert und repliziert.
    6. Erstelle ein Verbindungsdokument im Directory des neuen Servers nur für die
    Replizierung (NUR PULL Replikation). Wähle ein kurzes Intervall von 15 Minuten.
    Damit trägt der neue Server die ganze Last der Replikation und Änderungen werden nicht
    in die alte Umgebung zurück repliziert
    7. Lass den neuen Server replizieren, dass kann auch schon die ganze Woche über so laufen.
    8. Kopiere alle Gruppen-, Personen-, Verbindung-, Domänen-, Konfigurations-, Programm-,
    Mail-In-Dokumente aus dem alten Directory und füge sie im neuen Directory ein.
    9. Ändere in allen Dokumenten, die Du übernimmst die Domino Domäne sowie, wenn nötig, den
    Servernamen. Hier solltest Du auf die Personendokumente achten, das die Änderung bei allen
    Personen durchgeführt wird.
    10. Wirf noch einmal einen Blick in das Serverdokument (Sicherheit) vom neuen Server,
    ob hier alle alten Gruppen berücksichtigt werden.
    11. Evtl. vorhandene externen Notes Partner, mit denen Du in Verbindung steht,solltest
    Du die Veränderung Ankündigen und ggf. schon einmal eine neues Querzertifikat/Verbindung
    mit der neuen Umgebung einrichten.


    Diese Punkte kannst alle Du gut tagsüber erledigen, dass hat bisher keinen Einfluss auf Deine
    bestehende Notes Domäne. Wenn dann der Tag der Umstellung näher rückt solltest Du:


    1. In allen Datenbanken, die Du aus der alten Umgebung hast, in der ACL den neuen
    Server als Administrationsserver eintragen. Hier ist auch wichtig das Du in den Datenbanken,
    die Leser- und Autorenfelder verwenden, die Option setzt, dass der Administrationsprozess diese
    mitändert. SOnst guckst Du später ziemlich doof aus der Wäsche......
    2. Mit dem Domino Administrator auf dem neuen Server die Personen zu einem neuen Zertifizierer
    verschieben. Denk daran, dass das diese Aktion in der Admin4.nsf noch zusätzlich bestätigt
    werden muss.
    3. Den Admin Prozess direkt anstossen, dass er sofort losläuft.
    4. Noch eine Replizierung zwischen den Servern abwarten, damit alle DB's den aktuellen Stand haben
    und anschliessend kannst Du den alten Domino runter fahren.
    5. Dich mit allen User ID-Dateien anmelden und auf den neuen Server zugreifen bzw. die
    Maildatenbank des Users öffnen. Ich baue mir dafür immer eine eigene Arbeitsumgebung.
    Hierbei sind die neue Domäne sowie der neue Server einzutragen. Damit keine Adminp Anforderung
    in der falschen Domäne landet. Das Anmelden dauert zwar eine ganze Zeit, dafür läuft der
    Umbenennungsprozess nur weiter und wartet nicht auf die Useranmeldung.



    Das sollte es erst einmal serverseitig gewesen sein.


    Nun ist es an der Reihe sich um die Clients zu kümmern. Mein Vorschlag wäre hier,
    sich ein "Master-Data" Verzeichnis zu erstellen. Dazu einfach, wenn alle Datenbanken
    auf den neuen Server repliziert sind, aber noch vor der Umzertifizierung der User:


    1. Einen neuen Notes Client installieren.
    2. Dann würde ich mir das Data Verzeichnis einmal sichern, somit kannst Du später einfacher
    erkennen welche Dateien verändert bzw. benötigt werden und welche Dateien Du löschen solltest.
    3. Notes Client auf den neuen Server konfigurieren. Einen Test User hast Du ja dort schon.
    4. Dann den Client, Deinen Vorstellungen endsprechen, einstellen (Benutzervorgaben, die
    ja in die ini-Datei geschrieben werden) und den Arbeitsbereich bzw. die Lesezeichenleiste
    mit allen Datenbanken ausstatten, die bei den Anwendern benötigt werden. Wenn Du damit fertig
    bist entferne unbedingt die Datenbank Links auf das persönliche Adressbuch sowie die Maildatenbank
    Deines Test Users. Denke auch an die Lesezeichen Leiste bzw. die Ordner dort.
    5. Wenn der Client Deinen Vorstellungen endspricht beendest Du die Anwendung.
    6. Löscht alle Datenbanken, die von Dir erstellt wurden (names.nsf, log.nsf, cache.dsk und
    alle anderen Dateien, die Du nicht verteilen willst). Dabei kannst Du Dich nun an dem gesicherten
    Data Verzeichnis orientirern.
    7. Säuberst die Notes.ini Datei von Verweisen auf den Test User wie z. B. die Variablen KeyFileName,
    Mailfile, Location, CertificateExpCheck. Location ist hier ein Sondereintrag, hier solltest Du ab
    dem zweiten Parameter löschen (das Komma stehen lassen). Bei den anderen Variblen kannst Du alles nach
    dem Gleichheitszeichen löschen. Bei WinXP Clients würde ich noch den Schlüssel "Shell_Links=1" aufnehmen
    und wenn Du kein IM Setup durchführen willst gibt es auch noch einen Eintrag für die Ini (fällt mir
    nur leider grade nicht ein).


    Das Master Data Verzeichnis solltest Du natürlich testen und soweit verfeinern bis Du zufrieden bist.


    Je nach Installation auf Deinen Clients würde ich das alte Data Verzeichnis umbenennen ggf. auch das
    alte Programm Verzeichnis. Anschliessend die neue Notes Version installieren und das Data Verzeichnis
    löschen. Dann legtst Du Dein Master Data Verzeichnis an diese Stelle. Kopierst die ID-Datei sowie
    wenn vorhanden die Datei user.dic aus dem alten in das neue Data Verzeichnis. Und meldest Dich
    mit dem User an. Denk daran, dass evtl. in der alten 5er Names noch Kontakte sind, die umkopiert
    werden sollten.


    Wenn Du damit durch bist, steht nur noch der Wechsel auf das 6er Mailtemplates an.
    Hier würde ich Dir empfehlen einen Blick in die Maildatenbanken der User zu werfen
    (mit dem Notes Designer). Es gab mal in einer frühen 5er Mailschablone einen ziemlich bösen
    Fehler. Bei dieser Version wurden die, vom User angelegten eigenen Ordner, nicht mit dem Flag gesetzt,
    dass diese bei Gestaltungsänderungen zu schützen sind. Wenn das bei Dir der Fall ist solltest Du
    auf keinen Fall einen Mail-Schablonenwechsel durchführen und erst einmal die Ordner schützen andernfalls
    gibt es diese Ordner nicht mehr nach dem Update :( :( :( Dann möchte ich nicht in Deiner Haut stecken......


    Wenn dieser Fehler aber nicht bei Deiner VErsion auftaucht fehlt eigentlich nur noch ein COnvert
    der Mailfiles und eine anschliessende Aktuallisierung der User Ordner.




    Wow, ziemlich viel Stoff, allerdings kannst Du schon ziemlich viel davon in Vorleistung erledigen.
    Trotzdem hoffe ich doch für Dich, dass Du die Umstellung nicht ganz alleine durchführen musst.
    Ein WE ist leider sehr schnell um.....


    Das alles ist natürlich nur einer der möglichen Wege, die man bei einem solchen Vorhaben gehen kann.
    Die aufgeschriebenen Vorgehensweise musst Du natürlich immer auf Deine Umgenbung anpassen und dient
    eigentlich nur zu Lernzwecken. Ich hoffe, dass ich nichts wichtiges vergessen habe, aber man kann auch nicht immer alles im Kopf behalten, sonst wird der mal eines schönen Tages zu gross ;-))


    Viel Glück bei der UMstellung,
    KETE

    Hallo Smily,


    bei der Aufgabenstellung solltest Du Dir erst einmal einen Überblick verschaffen, was als Veränderung alles ansteht.


    Grundsätzlich sind von Deiner Aufgabe sowohl der Server wie auch alle Notes Client betroffen (und letztere machen leider die meiste Arbeit). Eine umfassende Aussage ist, aufgrund der fehlenden Hintergrundinfos zu Deiner jetzigen Installation, schwer zu treffen.


    Folgende Schritte stehen dabei aber wohl aufgrund Deiner paar Zeilen an:


    1. Domino Maildomänen wechsel
    Eine Änderung der Domino Maildomäne hat erst einmal nur eine direkte Auswirkungen auf den internen (wenn Einzeldomäne und keine weiteren benachbarten oder nicht benachbarten Domino Domänen betroffen sind) Domino Mailverkehr. Hierbei solltest Du Dir anschauen, wo überall der Domino Domänen Name auftaucht wie z. B. in dem Domänendokument, Serverdokument, Verbindungsdokumenten, Personendokumenten, Gruppendokumenten, Mail-In-Datenbank Dokumenten serverseitig sowie auf den jeweiligen Client z. B. Arbeitsumgebungsdokumenten, Verbindungsdokumenten usw.


    Diesen Maildomänen Wechsel kannst Du zum größten (Server-)Teil lokal vorbereiten, indem Du die nötigen Änderungen an einer lokalen Replik des Domino Directories vornimmst.



    2. Erstellung einer neuen Organisation und User zu neuem Zertifizierer wechseln


    Wenn Du auf den neuen Maildomänen Namen gewechselt bist würde ich in Deinem bestehenden Directory eine neue Organisation einrichten. Die neue und die alte O musst Du dann jeweils Querzulassen um den jeweiligen anderen Zertifikaten zu vertrauen. Mal vorrausgesetzt, dass der Adminp Prozess in Deiner Domäne sauber läuft (wirklich in allen Datenbank ACLs ein Admin-Server eingetragen?) unterstützt Dich bei einem Zertifizierer Wechsel der Administrationsprozess und dieser erledigt die meiste arbeit für Dich. Dabei werden natürlich auch die alten Maildatenbanken bearbeitet und sind anschliessend weiter zu verwenden.


    3. Server umbenennen bzw. umzertifizieren


    Nun steht der wohl schwerste, weil weitreichenste, Schritt an.
    Wenn der Servername wirklich geändert werden muss, dann würde ich Dir raten einen neuen Server in der richtigen Organisation/Unterorganisation zu registrieren. Das ist allemal einfacher als wenn Du Dich an einer Umbenennung versuchst.
    Wenn Du einen neuen Server registrierst kannst Du mit der neuen ID Datei und der bestehenden Server Installation (SW) den Server unter dem neuen Namen bzw. ID Datei weiter betreiben. Leider reicht es nich einfach den Server runter zu fahren, die ID Datei auszutauschen und den Server mit der neuen ID Datei wieder zu starten. Allerdings ist es auch nicht soooo viel schwieriger, wenn man weiss was überall ausgetauscht werden muss. Das kann man aber in einer Testinstallation sich schnell erarbeiten.
    Nun ja und dann kommt das, wovor man sich immer gefürchtet hat ;-)). DIE CLIENTS !!!
    Hier funktioniert natürlich erst einmal fast gar nichts richtig denn, es gibt falsche Einträge in den(m) Arbeitsumgebungs Dokument(en), und alle Datenbank Links auf dem Arbeitsbereich zeigen auf einen Server, der nicht mehr existiert. Hier hat es sich als sinnvoll erwiesen schon im Vorfeld der Server Umstellung eine "Master" Desktop Datei sowie eine Bookmark.nsf + bookmark.ntf vorzubereiten und ggf. Sckriptgesteuert auf die Clients zu verteilen. Ist aber - mit Abstand - wohl die meiste Arbeit......



    Wie gesagt, dass alles ist eine mögliche Voergehensweise, ohne jede weitere Informationen, zu Deiner konkreten Ist-Situation. Diese Ausführung erhebt auch keinen Anspruch auf absolute Vollständigkeint (erst Recht nicht nach dem Genuss von ein paar kühlen Blonden ;) ). Ich habe aber noch eine kleinen Tip für Dich:


    Wenn Du schon den ganzen "Tanz" mit dem Namenswechsel hast, versuche doch zumindest für die Domäne und die Zertifizierer "neutrale" Namen durchzusetzen. Sonst, und das kann ich Dir versprechen, ist nach der Umstellung vor der Umstellung.


    Alles Gute,
    Kete

    Hi Arrow,


    nur wenn Du Wiederherstellinfos in die Zertifizieren eingefügt hast. Dann kannst Du das Kennwort zurücksetzen.
    Externe Tools die evtl. das Kennwort von aussen knacken können sind mir aktuell nicht bekannt. Könnte es allerdings auch geben.


    Gruß,
    Kete

    Hi obda,


    Du hast wahrscheinlich keinen Administartionsserver in den ACL's der Mailfiles stehen. Deshalb hat der Administrationsprozess hier auch nicht alle Arbeitschritte durchgeführt. Schau einfach mal in ACL einer Maildatenbank ob Du dort einen Eintrag für den Admin Server findest.
    Trage in alle Datenbanken den Adminserver (geht mit dem Dominoadminstrator, auch alle DB's auf ein mal!!). Dann solltest Du in der Admin4.nsf die Anforderungen noch einmal ausführen lassen (es gehört nämlich ein bisschen mehr dazu als nur den Owner eines Mailfiles umzustellen).
    Sollte eigentlich alles so funktionieren.


    Gruß,
    Kete

    Hallo,


    ich habe dieses Verhalten auch schon festgestellt (D6 Domäne). Die Fehlermeldung vom Adminp kommt wenn Du, als Administrator der den User Move anstösst, keine Rechte auf die Maildatenbank des Anwenders hast. Ich verstehe zwar noch nicht seit wann bzw. wieso der Adminp sich daran nun aufhängt, da ich als Admin noch nie Rechte auf Usermailfiles hatte.
    Unter R5 ist in der selben Domäne diese Problem nicht aufgetaucht.


    Da die Aktion (hier der move des Mailfiles) unter Deinem Namen abläuft und Du keine Rechte in der ACL des Anwenders hast, läuft auch der Verschiebeprozess via Adminp nicht.


    Eine Lösung habe ich noch nicht gefunden, als Workaround trage ich mich kurzfristig in die ACL ein und nachdem der Adminp die Replik angelegt hat wieder aus. So funktioniert es dann.


    Gruß
    KETE

    Hallo,


    ich würde mir mal eine der Datenbanken mit dem Desigern anschauen. Wie es klingt scheint die Maske für die Locations vor einem Desinwechsel gesperrt zu sein.


    D. h. das alte Gestaltungselement lässt keine Aktuallisierung zu.


    Wenn dem so ist, kannst Du mit dem Designer das Aktuallisierungs Flag entfernen und ein Schablonenwechsel sollte anschliessend die Gestaltung ersetzen dürfen.


    Nunja, leider ist das natürlich keine Lösung um evtl. hunderte von Adressbücher zu bearbeiten :-(.


    Vielleicht kennt hier aber sonst wer einen Weg um z. B. das über ein Api-Programm zu lösen.


    Gruß,
    Kete

    Hallo Dirk,


    danke für Deine Antwort. Ich bin mir durchaus bewusst, dass ich die - von mir als Beispiel - genannten Anforderungen mit dem Administrator Client erledigen kann. Bisher machen wir das ja auch so.


    Eine selbstentwickelte Lösung für die Userreistrierung/Verwaltung habe wir auch schon seit Jahren im Einsatz. Nur ist diese Lösung nun in die Jahre gekommen und die Entwicklungsabteilung hat leider nicht die Zeitressouren um dieses "interne" Projekt zügig angehen zu können :(


    Aus diesem Grund und angesichts der anstehenden Projekte bei der Zusammenführung, Trennung, Umbenennung von diversen Domino Domänen (alles muss natürlich zeitgleich mit firmenpolitischen Ereignissen stattfinden und mancher der Endscheidungsträger nimmt sogar an, dass klappt alles per Knopfdruck über Nacht) haben wir noch einmal mit unserem GF gesprochen und vollkommen überraschend ist dieser bereit für eine SW, die uns bei unsere Arbeit unterstützt einen Bugetposten zu eröffnen.


    Wie schon gesagt, ich durchforste nun das Internet nach Anbietern solcher SW und hatte vermutet, im Forum auf Administratoren zu treffen, die evtl. bei sich oder beim Kunden eine solche SW einsetzten.


    Erfahrungsberichte sind mir nämlich ein bisschen lieber als die Hochglanzprospekte und Vertriebsversprechungen von Marketingexperten (wobei ich mit dieser Aussage niemanden beleidigen will/wollte).


    Gruß,
    Kete