Für einen sauberen Passthrough brauchst Du zwei Verbindungsdokumente:
1. Ein Verbindungsdokument zum Passthrough, das den Common- Name des Passthrough- Servers mit einer IP- Adresse verbindet... Wenn Du die nicht hast, versucht der Client den Common- Name des Durchgangsservers über den DNS seines Providers aufzulösen,
deshalb die dtag- Adressen...
2. Das Durchgangsserver- Verbindungsdokument
Hast Du beide?
Sorry, aber damit bin ich aus diesem Thema raus...
Ich gebe gerne Hilfe zur Selbsthilfe, aber keine kostenlose Admin- Ausbildung im Domino,
denn mit Admin- Schulungen, Kundensupport, etc. verdiene ich mein tägliches Brot...
Sorry.
Da bei atnotes scheinbar keine ne Idee hat, hier das selbe nochmal (werde die beiden Posts jeweils aktuell halten):
Habe hier folgendes interessantes Problem: Es werden Mail- Policies über eine Mischung aus Expliziten und Hierarchischen Policies zugewiesen.
Das zuweisen der Mail- Policies macht ja der adminp- Prozess (alle 24 Stunden oder getriggert über tell adminp process mailpolicy).
Das funktioniert auch: Das Kalenderprofil bekommt die entsprechenden Felder "$DPLocked" und "$Policy...", der Text, dass einige Einstellungen vom Admin gesperrt wurden erscheint, und es werden Einstellungen ausgegraut. Auch nachdem man das Kalenderprofi entfernt passiert das ganze wieder.
Jetzt kommt das grosse Aber: Die Felder, die gesperrt sind per Policy werden zwar gesperrt, aber die Werte bleiben auf den vorher eingestellten Werten.
Wenn ich also per Policy sage "Process Cancelled Meetings Automatically" = "1" mit "Set Value and Prevent changes", dann wird das Feld ausgegraut und kann vom User nicht mehr geändert werden (das Prevent Changes zieht also), aber der Feldwert bleibt auf dem Standardwert ""...
Server sind 8.5.3FP2, die Clients 8.5.3 ohne Fixpack.
Das komische: Bei Benutzern, die schon länger existieren funktioniert das ganze... nur bei neu angelegten Benutzern gibt es dieses seltsame Verhalten.
Hat jemand ne Idee ausser einen Call bei IBM zu eröffnen?
Wie sehen Deine Verbindungsdokumente aus?
Hast Du einen Smart- Host im Konfig- Dokument eingetragen?
Was hast Du konfiguriert?
Mit diesen spärlichen Informationen kann man nur sagen: Dein Domino erwartet einen Domino auf der anderen Seite...
Der Domino oder eine vorgelagerte Viruswall / Spam- Appliance?
Was sagt das Domino Routing log?
Was sagt die Domino Konsole?
Wo kommen die Mails bei Euch rein?
Habt Ihre jemanden, der sich mit sowas auskennt?
Was Zertifizierst Du denn gegen? cert mit cert ? Server mit Server? Was verwendest Du: cert.id oder sichere Kopie der cert.id?
Beschreib mal genau Deine Schritte, und wann der Fehler kommt, dann kann man Dir vielleicht helfen...
Mit Designer- Rechten und dem WIssen darum, was Du tust, kannst Du natürlich diesen Menupunkt wieder einblenden... Ob das Sinn macht: imho nicht...
Und wer es unbedingt haben will, muss halt übers Menu gehen, da gibt es das ja noch...
Ganz einfach: das querysave event kann man mit Formelsprache nicht abbrechen.
Dazu musst Du das ganze in Script programmieren und continueauf false setzen...
Brigens gehört solcher code, wenn Du ihnunbedingt in Formel haben willst schlicht in die Feldvalidierung des betreffenden feldes. Und dort statt des @Prompt ein @Failure und schon wird das speichern verhindert... Aber solche absoluten elementals werden doch schon im allerersten Anfängerkurs für Entwicklung vermittelt...
Lösche mal das "OutOfOfficeProfile" sowie das "ooserviceprofile" aus der Datenbank und starte den Router neu, das sollte das Problem beheben.
Hostsystem = hosts im System... Damn you autocorrect... Danke fürs klarstellen...
Der Client findet den Server nicht, weil der vergebene Servername nicht im DNS gefunden werden kann (geraten).
Entweder Hostsystem pflegen oder Verbindungsdokument anlegen
Such zu dem Thema mal nach der INI- Variable "RFCStripUnquotedDelimiters"... der sollte Deine iNotes- Probleme (für neue Mail, bereits eingegangene sind schon kaputt) beheben...
ok... klang halt ein wenig schroff... Schon vergessen...
Trotzdem verstehe ich das Problem nicht: MS sagt in dem verlinkten Artikel, dass das eine ganz schlechte Idee ist, seine Netzwerkkarten so zu konfigurieren, und dass man nicht vorhersagen kann, welche Netzwerkkarte wann was macht.
Nochmal: Der Domino steuert nix selbst, sondern setzt sich nur auf das vom OS bereitgestellte Netzwerk auf...
Nach dem Grunsatz "Shit in -> Shit out" kann der Domino das dann auch nicht mehr besser machen, sondern allenfalls durch die von ihm verursachte Ntzwerklast noch VIEL schlimmer.
Also ich würde es nicht machen (mit meinen begrenzten Kenntnissen über Eure Umgebung und den verlinkten Artikel zugrunde legend...
Bahnhof ?????? Was soll denn bitteschön Domino mit Deiner Routing- Tabelle zu tun haben !? Und warum soll ICH Dir Eure Routing- Tabellen erklären???
Domino nimmt das Netzwerk "as is" und verändert garantiert nix an Deinen Routing- Tabellen...
Und Du solltest Deinen Ton überdenken...
Ja... Wenn Du aber willst, dass der Server nur auf eine der beiden Umgebungen reagiert, musst Du das explizit konfigurieren, standardmässig lauschen alle DOmino- Dienste auf alle konfigurierten IP- Adressen...
u.U. kann das funktionieren mit currentLog.openFileLog()... und dann ein entsprechendes File auslesen... ansonsten fällt mir spontan auch nix schlaues ein, da Ihr ja sicherlich nicht den completten Output der Domino- Konsole umleiten wollt...
Als Notes- User ist es einfacher für Dich, eine eigene Ansicht zu erstellen, die alles ausser Kalendereinträgen enthält...
Erstellen -> Ansicht -> Name vergeben -> Kopieren von klicken -> Alle DOkumente auswählen -> Selektionsformel erweitern " & ! Form = "Appointment" : "Notice" )
fertig
doch das geht...
Teile der Sametime- Verbindungskonfiguration stehen in Deinem Adressbuch unter "Konten". Diese Konten sind standardmässig allen Arbeitsumgebungen zugewiesen. u.U. hilft es, diese Konten auf einzelne Arbeitsumgebungen zu begrenzen (habs aber selbst noch nicht probiert)...
