Domino 9 und frühere Versionen > ND8: Administration & Userprobleme

[geloest] Problem mit Lotus Notes Traveler nach Änderung des FQIHN

<< < (3/4) > >>

Driri:
Ich bin kein Admin, aber es gibt ja mehrere Stellen im Serverdokument, wo der Hostname auftaucht. Hast Du das an allen Stellen angepaßt (Tab Basics, Tab Internet Protocols / HTTP und Tab Lotus Traveler) ?

Gibt es irgendwelche Web-Konfigurationsdokumente, die da dazwischenschießen könnten ?

Ist der Server nur für Traveler da oder wird der auch für die Standard-Domino-Dienste genutzt ? Wenn nur für Traveler, würde ich den Server evtl. mal einfach komplett neu aufsetzen.

DunkelHut:

--- Zitat von: Neo am 05.04.11 - 08:43:37 ---was geben denn folgende Treveler Tell Befehle als Ergebnis aus?
Wenn Traveler auf einem separaten Domino-Server läuft: ist der Domino-Server mit dem MailDBs "notes-technisch" erreichbar?

--- Ende Zitat ---

Hallo Neo,

die von Dir angeführten Traveler Befehle liefern in Summe ein Ergebnis, sagen aber eben auch aus das der Server nicht syncronisiert. So wie es für mich scheint, läuft der Travelerdienst an sich inzwischen fast störfrei, ich kann eben nur keine Initialzündung zum syncroniseren einleiten oder einfach die Clients neu einbinden.

Ich habe für Traveler, BES und Mail in Summe auch nur einen Server, die Summe der User ist überschaubar und wie ich schon sagte, lebten die Dienste schon vorher in friedlicher Koeexistenz.

Danke für Deine Unterstützung....
Gruß
Stefan

DunkelHut:

--- Zitat von: Driri am 05.04.11 - 09:27:21 ---Ich bin kein Admin, aber es gibt ja mehrere Stellen im Serverdokument, wo der Hostname auftaucht. Hast Du das an allen Stellen angepaßt (Tab Basics, Tab Internet Protocols / HTTP und Tab Lotus Traveler) ?

Gibt es irgendwelche Web-Konfigurationsdokumente, die da dazwischenschießen könnten ?

Ist der Server nur für Traveler da oder wird der auch für die Standard-Domino-Dienste genutzt ? Wenn nur für Traveler, würde ich den Server evtl. mal einfach komplett neu aufsetzen.

--- Ende Zitat ---

Hallo Driri,

ja, ich hatte diese ganzen Anpassungen gemacht, was nach meiner Sicht jetzt und heute aber auch nicht notwendig war. Die Änderungen haben ja auch erst zu dem Fehler geführt der den Traveler in der vorliegenden Form abgeschossen hat. Man kann sich den ganzen DNS-Kram ja auch extern so zurecht konfigurieren das es wieder passt. Einzig und allein extern der MX Eintrag muss forward und reverse auf die neue Domain abgestimmt sein, ebenso wie intern das SMTP-Banner, sonst kann man und sollte auch den ganzen Kram eigentlich so lassen.

Alles läuft von einem Server aus. das wird sich zwar ändern weil ich bald noch ein paar Server bekomme, aber im Moment ist das eben so und hat auch bislang so gereicht. Ist halt nur blöd wenn eine Komponente streikt hast Du dann eben eine Gesamtbaustelle...

Danke für Deine Gedanken...
Gruß
Stefan

DunkelHut:
Lösung

* Der Schlüssel zum Erfolg lag im eigenen internen DNS Server.
* Wenn man einen Domaincontroller einrichtet, wird man im Zuge der Installation nach dem Namen der Domain und im Besonderen nach der Extension der Domain gefragt.
* Im Allgemeinen wird an dieser Stelle domain.local für interne Domain gewählt, was DNS technisch zur Folge hat das alle DNS Anfragen die nicht domain.local meinen an externe DNS Server weitergeleitet werden.
* Ich hatte mich damals dazu entschlossen die Domain als EIN Haus zu sehen und innerhalb dieses Hauses eben dann zu vermitteln. Somit bekam meine interne Domain eben domain.com.
* Die Konsequenz dieser Entscheidung brachte es mit sich, daß der interne DNS Server die komplette Struktur kannte und somit keine Anfragen bezüglich der eigenen Domain mehr forwarden musste, denn ich betreibe alle Internetdienste wie Mail, WEB etc. auf eigenen Servern am eigenen Standort.
* Somit wurde mail.domain.com eben nicht ge-forward-ed sondern eben direkt an server04.domain.com vermittelt.
Damit bleibt eben eine Menge Traffic im internen Netzwerk und lungert nicht irgendwo draußen rum.
* Das hat auch einen nicht zu unterschätzenden Perfomancevorteil.
* Aus mir im Moment noch nicht bekannten Gründen, konnten Traveler und BES aber nach der Umstellung mit dieser Konstellation nicht mehr umgehen. Der Dominoserver jedoch hingegen in alt bekannter Art schon.
* Ich habe testweise meinem internen DNS Eintrag für den Mailserver nun die externe IP Adresse gegeben, den Domino restartet und schon rappelte es wieder so wie es immer war, alles schön friedlich vor sich hin.
* Ergo habe ich den DNS Eintrag so belassen und das Problem hat sich damit geklärt.
* Die Traveler Konfigurationsseite http://server/servlet/traveler ist wieder OHNE Fehler ansprechbar.
* Der BES hat seinen Betrieb auch wieder stillschweigend aufgenommen und mit vollen Backen die die aufgelaufen Mails verteilt.
Einschränkung

* Die Traveller-Clients haben nicht wieder von selbst die Replizierung aufgenommen, sondern ich musste dieses sogenannte Exchangeprofil auf den Smartphones wieder neu generieren.
Tip

* Um das bestehende "Exchange-Traveler-Profil" auf dem iPhone zu löschen, muss man in der Menuestruktur wie folgt eintauchen: Einstellungen, Allgemein, Profil. Wer den Button zum löschen, wie bei anderen Syncprofilen üblich, unter Einstellungen, "Mail, Kontakte, Kalender", Accounts sucht, wird dort so wie ich erst einmal die Stirn runzeln.
Resumé

* Wie es immer so ist, das Problem sitzt meißtens vor dem Rechner...  :-\
* Statt in Aktionismus zu verfallen eben einfach nachdenken. Wie man eben so schön sagt: "Aktionismus ist Ausdruck geistiger Windstille". Den Spruch vor Augen, hätte ich es mir sparen können, sinnloser Weise an 25 Ecken rumzufummeln, denn die Lösung lag ja direkt vor meinen Augen.
* Wenn man einen Dominoserver von Stadt1 zu Stadt2 umzieht, reicht es aus wenn man die Änderungen zum FQIHN und MX im DNS ausführt. Am Domino und seinen Erweiterungen muss man nichts ändern.
* Ergänzend sei bemerkt das bei öffentlichen DNS Einträgen (A-Record) eine TTL (Lebenszeit) von 24 Stunden und bei Reverse DNS Einträgen (RDNS oder PTR) eine TTL (Lebenszeit) von 48 Stunden gesetzt ist. Ergo bei Domainumzügen in Hektik zu verfallen, bringt nix.
Dankeschön
Dankeschön für eure Hilfe und Fachkompetenz.
Allein der Fakt das die offerierten kompetenten Lösungsansätze nicht zur Lösung des Problems führten, haben mir verdeutlicht das die Lösung des Problems außerhalb der Dominoumgebung zu suchen ist.

Gruß
Stefan

m3:
Fürs nächste Mal: Best Practice bei Wechsel der IP - 1 Woche vorher die TTL der DNS-Einträge auf 2h runtersetzen.

Wenn man dann unmittelbar vor der HW-Übersiedelung die neue IP ins DNS einträgt, ist die Änderung weltweit meist durch, bevor der Server mit der neuen IP an der neuen Location wieder hoch kommt ;)

Aber fein, dass Du Dein Problem lösen konntest und Danke für die Rückmeldung.  :D

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete