Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: DunkelHut am 04.04.11 - 09:27:18
-
Grundlage
- Lotus Domino 8.5.2FP1
- Lotus Notes Traveler-Version: 8.5.2.1 Build 201012031608
- 4 User die Traveler in Summe mit fünf Geräten nutzen
Szenario
- Serverumzug von Stadt1 zur Stadt2
- neuen externen DNS Namen (FQDN) in Stadt2 eingerichtet (feste IP DNS, RDNS und MX qualitativ wie in Stadt1)
- Server umgezogen
- DNS Einträge, wie MX-Name und IP entsprechend nun für neue IP verändert
- Server Online gebracht
- alles soweit ok, Domino inkl. Traveler arbeiteten und schoben Daten
- Neue DNS Einstellungen und Server von extern via mxtoolbox.com geprüft
- einziger Makel, "Warning - Reverse DNS does not match SMTP Banner"
- Hier gab es zwei Möglichkeiten das zu regulieren, zum einen in dem man der notes.ini
einen Eintrag "SMTPGreeting=servername.domain.com SMTP Server ready at %S (https://www-304.ibm.com/support/docview.wss?uid=swg21089235)" hinzufügt
ODER eben im Serverdokument den Fully Qualified Internet Host Name anzupassen - Ich habe mich da für den zweiten Weg entschieden, weil sich ja auch tatsächlich der FQIHN geändert hat.
- Eine neue externe Prüfung via mxtoolbox.com brachte auch dann keinen "SMTP Banner" Makel mehr.
- ergänzend sei vermerkt, daß ich nach der Änderung des FQIHN im Serverdokument die externe Server URL für den Traveler im Ursprung belassen habe (wegen der laufenden Geräte) und die URL entsprechend extern auf die neue URL umgelenkt habe. Der "alte" Eintrag funktionierte also.
Problem
- Der Lotus Notes Traveler verweigert nach der Anpassung des Fully Qualified Internet Host Name im Serverdokument die weitere Arbeit
- Ich habe nach einigen Versuchen mich dann dazu entschieden, den Traveler runterzuschmeißen und neu zu installieren. Allerdings war es mir NICHT möglich vorher die Geräte und Nutzer ordnungsgemäß zu entfernen, da die Traveler Konfiguration ja vergurkt war.
- Vor der Neuinstallation habe natürlich dann im Serverdokument die externe Server URL des Traveler entsprechend des neuen Fully Qualified Internet Host Name angepasst (http://domain/servlet/traveler).
- Ebenso habe ich vor der Neuinstallation vom Traveler kontrolliert, ob durch die Traveler Deinstallation das Traveler Verzeichnis im Programm- und Data-Pfad von Domino entfernt wurde.
- Wenn ich nun aber wieder User in den Traveler über die URL: http://domain/servlet/traveler einbinden konfigurieren möchte, kommt nun statt der Konfigurationsseite folgendes:
Benutzerstatus (Name Vornamel/Domino-Domain)
Beim Überprüfen der Benutzer-ID CN=Vorname Nachname/O=Firma wurde vom Lotus Notes Traveler-Server ein interner Fehler festgestellt. Setzen Sie sich mit dem Serveradministrator in Verbindung.
Für CN=Vorname Nachname/O=Firma wurden keine Geräte synchronisiert.
Letzte Aktualisierung: Montag, 4. April 2011 8.32 Uhr CEST
Lotus Notes Traveler-Version: 8.5.2.1 Build 201012031608 (neuer externer domain name)
- Der Fehler tritt unabhängig davon auf ob der User bereits im Traveler angelegt/verwaltet war oder nicht
Eigener Standpunkt
- Ich bin mir absolut sicher das Ich die externen Veränderungen wie DNS und MX sauber durchgeführt habe.
- Allerdings stehe ich nun vor besagter Lotus Notes Traveler Problematik und komme an diesem Punkt im Moment nicht weiter.
- Es wäre nett wenn mir da jemand ein paar Anregungungen, etwas Hilfestellung geben könnte.
Danke für´s Lesen und eure Gedanken....
Gruß
Stefan
-
Die LotusTraveler.nsf hast Du auch gekillt?
-
Die LotusTraveler.nsf hast Du auch gekillt?
Hallo Martin,
nein, daran habe ich nicht gedacht. Danke für den Hinweis.
Ich deinstalliere jetzt den Traveler noch einmal und "kille" dann auch die LotusTraveler.nsf.
Wäre toll wenn es so einfach wäre... :-)
Ich gebe natürlich entsprechend Feedback.
Gruß
Stefan
-
Die LotusTraveler.nsf hast Du auch gekillt?
Hallo Martin,
die LotusTraveler.nsf wird, wie auch die Verzeichnisse vom Traveler, bei der Deinstallation sauber entfernt.
Daran liegt es leider nicht...
Der Teil der Meldung :
- Benutzerstatus (Name Vornamel/Domino-Domain)
Beim Überprüfen der Benutzer-ID CN=Vorname Nachname/O=Firma wurde vom Lotus Notes Traveler-Server ein interner Fehler festgestellt. Setzen Sie sich mit dem Serveradministrator in Verbindung.
weist ja an sich auf den Kernfehler hin.
Der andere Teil der Meldung:
- Für CN=Vorname Nachname/O=Firma wurden keine Geräte synchronisiert.
Letzte Aktualisierung: Montag, 4. April 2011 8.32 Uhr CEST
Lotus Notes Traveler-Version: 8.5.2.1 Build 201012031608 (neuer externer domain name)
hingegen ist ja an sich korrekt.
Hast Du noch eine andere Idee ?
Ergänzend zu meinen Ausführungen, sei noch erwähnt, das der parallel zu Traveler laufende BES den alten FQIHN offensichtlich auch vermisst und zur Zeit ebenso nicht syncronisiert, was aber im Moment kein Problem im Moment ist, da ich den sowieso neu aufsetzen wollte.
Wichtig ist dabei ist vielleicht die Information das da ein weiterer Dienst wohl mit dem FQIHN wohl auch ein Problem hat.
Das streut aber NICHT in die übliche BES vs. Traveler Problematik, da beide vorher in friedlicher Koexistenz mit einander harmonierten.
Da Fehlersuche und DNS Änderung/Umschreibung der alten Domain im selben Zeitfenster laufen, ist mein Plan B ist nun dem Domino in zweiTagen wieder den alten FQIHN zu geben. Allerdings wäre es doch auch nicht minder interessant den Fehler zu finden.
Vielleicht hat ja noch jemand eine Idee, was man denn besser machen könnte, wo denn evtl. noch Hand anzulegen wäre um die Traveler Betriebsbereitschaft herzustellen.
Danke für die Unterstützung
Stefan
-
Firewall, ... ist unter dem neuen FQDN auch offen (ja ich weiß, trivial, aber ...)?
https://www-304.ibm.com/support/docview.wss?uid=swg21294566
http://www-10.lotus.com/ldd/dominowiki.nsf/dx/Checklist_for_Debugging_Connectivity_Issues_with_Lotus_Notes_Traveler
Die Meldung bekommst Du im Browser, wenn Du Dich mit einem PC hin verbindest, oder?
-
Hallo Martin,
die Frage mit der Firewall ist berechtigt, ich bekomme besagte Fehleraufschrift aber eben auch ohne Firewall wenn ich http://localhost/servlet/traveler aufrufe, von daher kann man die Firewall als Fehlerquelle erst einmal auschließen. Die Firewall- und NAT-Regeln gehen werden auch über Objekte geregelt in die wiederum die neue öffentliche IP eingepflegt ist. Die Fehlerausschrift ist auch geräteunabhängig, denn auf den iPhone´s und Defy´s bekommt man via WEBbrowser die gleiche Fehlermeldung angezeigt.
Die Links die Du geschickt hast sind interessant, offerieren mir aber bis auf die Möglichkeit einen DUMP zu erzeugen und den IBM zuzuschicken keine wirkliche Hilfe zu diesem Fehler. Jedoch ist es eben so das ich die Zeit lieber selber zur Fehlersuche nutze als da irgendwie auf zweifelhaften IBM Support zu warten. Mein letzter Kontakt dahin bestand in Rückfrage von IBM wo sie um eine Fehlerbeschreibung baten und das nach dem ich denen da eine mehrseitige Ausarbeitung habe zukommen lassen. Nennenswert ist dabei das IBM ein eigenes Callcenter betreibt nur um die blöde Downloadseite zu supporten die sie inzwischen nun repariert haben..., ergo ich möchte meine schlechten Erfahrungen da nicht noch vertiefen und die Zeit lieber sinnvoll nutzen als sinnlos auf IBM Support zu hoffen und zu warten.
Mein Dominosystem ist noch klein genug das man noch pragmatisch an Lösungswege rangehen kann.
Mit Neuinstallation des Travelers kommt ja, wie ich auf Grund Deiner Anregung zweifelsfrei feststellen konnte, eine neue "LotusTraveler.nsf". Lustiger Weise finden sich dann dort schrottige Einträge drin, wie User OHNE Geräte-ID die jedoch einmal vorhanden war. Allerdings auch User mit Geräte-ID bei denen allerdings kein Sync aktiv ist. Scheinbar müssen irgendwo noch Einträge sein die dann zurückgeschrieben werden ???
Die LotusTraveler.nsf lässt sich auch über die Server-Console ansprechen als auch bedingt konfigurieren (nur User mit Geräte-ID). Alle Traveller Consolen-Befehle lassen sich auch ausführen, nur führt das eben nicht wirklich weiter, denn ein Befehl wie "mach mich jungfräulich" gibt es für die Travelerdatenbank nach meinem Kenntnisstand nicht.
Inzwischen habe ich jetzt auch aus einer Datensicherung die "alte(n)" Traveler Verzeichnisse und Datenbank extrahiert und versuche mal Plan C, in dem ich die rückgesicherten Orginale einspiele und dann schaue was der Traveler so treibt. Zur Not stelle ich eben dann den alten FQIHN wieder her und setze den "SMTPBanner" zu Fuß über die notes.ini. Damit sollte Domino dann erst mal wieder rund, wenn auch gleich nicht optimal laufen. Wenn man die Leute aus dem Nacken hat, sucht es sich auch irgendwie entspannter. Ich kann die "Traveler-Übungen" ja dann auch auf meinem "Spielsystem" machen...
Wenn Dir/euch da noch etwas als Lösung einfallen sollte, wäre das eine gute Sache.
Wenn ich etwas neues herausbekomme poste ich es selbstredend hier.
Vielen Dank für Deine Hilfe und Unterstützung.
Gruß
Stefan
-
Ergebnisse
...mein Plan C brachte leider nur einen kleinen Erfolg.
- die Traveler Datenbank steht wieder und die Einträge darin sind auch komplett.
- die Geräte werden als online ausgewiesen
Veränderungen
- VORHER
- Benutzerstatus (Name Vornamel/Domino-Domain)
Beim Überprüfen der Benutzer-ID CN=Vorname Nachname/O=Firma wurde vom Lotus Notes Traveler-Server ein interner Fehler festgestellt. Setzen Sie sich mit dem Serveradministrator in Verbindung.
Für CN=Vorname Nachname/O=Firma wurden keine Geräte synchronisiert.
Letzte Aktualisierung: Montag, 4. April 2011 8.32 Uhr CEST
Lotus Notes Traveler-Version: 8.5.2.1 Build 201012031608 (neuer externer domain name)
- NACHHER
- Benutzerstatus (Vorname Nachname/Domain)
Beim Überprüfen der Benutzer-ID CN=Vorname Nachname/O=Domain wurde vom Lotus Notes Traveler-Server ein interner Fehler festgestellt. Setzen Sie sich mit dem Serveradministrator in Verbindung.
Apple-iPhone3C1: Online und es stehen keine Synchronisationsanforderungen vom Server an.
Letzte Aktualisierung: Montag, 4. April 2011 22.28 Uhr CEST
Lotus Notes Traveler-Version: 8.5.2.1 Build 201012031608 (alter externe domain name)
Resumé
- Offensichtlich gibt es auch beim Domino ein paar Türen die man nicht öffnen sollte.
Ich habe noch einmal verschiedene Szenarien probiert, das Ergebnis ist nach wie vor unbefriedigend.
Immerhin sind die Geräte und User nun wieder vorhanden und online.
Das Traveler nicht synct ist wohl nun die letzte Hürde.
Der Consolenbefehl "tell traveler reset Appl87101Kxxxxx Vorname Nachname" wurde zwar erfolgreich in der Console quittiert, es hat sich aber qualitativ nichts geändert.
Nach Stand jetzt und heute fällt mir nun erst einmal nichts mehr ein, als auf Löschung des alten reverse DNS zu warten um dann DNS, reverse DNS und MX wieder auf den alten Domainnamen einzustellen in der Hoffnung das der Domino inkl. Traveler wieder in seiner Mitte ankommt.
Wenn jemand noch ein paar gute Einfälle hat...
Gruß
Stefan
-
Dass es daran liegt, dass irgendwo noch ein dns-Server eine Umstellung nicht mitbekommen hat?
Was ich noch nicht mitbekommen habe: Wenn Du Dich von Deinem PC auf die Traveler-URL verbindest, funktioniert das dann mit dem Anmelden, ...?
Hast Du die Clients testweise auch schon neu konfiguriert?
-
was geben denn folgende Treveler Tell Befehle als Ergebnis aus?
Push AllStatus Zeigt die Statuswerte aller Benutzer und Geräte an
Push cmStatus Zeigt den Status von ConnectionManager an
Push cpStatus Zeigt den Status von ChangeProcessor an
Push lsStatus Zeigt den Status von ListenerStore an
Push mStatus Zeigt den Status des Überwachungsprogramms an
Push scStatus Zeigt den Status von StateController an
Push Status benutzer Zeigt die Statuswerte des Benutzers und seiner Geräte an
Reset gerät benutzer Erzwingt das Zurücksetzen der Synchronisation für ein Gerät.
Wenn Traveler auf einem separaten Domino-Server läuft: ist der Domino-Server mit dem MailDBs "notes-technisch" erreichbar?
-
Dass es daran liegt, dass irgendwo noch ein dns-Server eine Umstellung nicht mitbekommen hat?
Was ich noch nicht mitbekommen habe: Wenn Du Dich von Deinem PC auf die Traveler-URL verbindest, funktioniert das dann mit dem Anmelden, ...?
Hast Du die Clients testweise auch schon neu konfiguriert?
Hallo Martin,
interne DNS Änderungen sind an sich gleich aktiv, in größeren Umgebungen in der Regel spätestens nach 15-20 Minuten. Externe DNS Änderungen teilweise komplett ca. einem Tag weltweit nach ca. zwei Tagen. Da rede ich jetzt aber eben von dynamischer Aktualisierung. Ich nehme als externen DNS auch immer die von Google (8.8.8.8 und 8.8.4.4) weil die nun einmal am aktivsten und auch wohlbetreutesten sind.
Externe reverse DNS Einträge dauern in der Regel etwas länger, weil da oft immer noch eine menschliche Komponente mit dran beteiligt ist. Bei der Telekom kann man inzwischen den Eintrag selbst online generieren, wobei dann die Umsetzung doch noch reichlich einen Tag dauert. Das nimmt bestimmten Veränderungen eben auch die Spontanität.
Wenn ich mich auf die Traveler URL verbinde ist das Ergebnis auf allen Clients gleich, sprich es kommt die selbe Fehlermeldung. Dadurch ist es eben auch nicht möglich einen neuen Client einzurichten. Unabhängig davon ob der User schon Traveler Nutzer war oder nicht. die Meldung die ich hier aufgezeigt habe ist das einzigste was ich unter der Traveler URL bekomme.
Ich könnte jetzt sicherlich per Console einen User samt Gerät aus der Traveler-Datenbank löschen, einen Reset durchführen o.ä. aber der WEBteil ist eben vergurkt und damit nicht bedienbar.
Der Client selbst bietet wenig Spielraum, da kannst Du nur Passwort oder Beschreibung ändern bzw. Push an oder ausschalten. Selbst löschen kannst Du ihn nicht selbst.
Gruß
Stefan
-
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.
-
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?
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
-
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.
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
-
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
-
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
-
Fürs nächste Mal: Best Practice bei Wechsel der IP - 1 Woche vorher die TTL der DNS-Einträge auf 2h runtersetzen.
Hallo Martin,
guter Tip !!! ...aber wie kann man das steuern wenn man keinen eigenen öffentlichen nameserver betreibt ???
Die Einträge generiert, oder ändert man doch über die Plattform des Hosters. Da habe ich aber noch keine Möglichkeit gefunden den TTL Wert zu ändern. Ich habe mir jetzt zwar mal schnell was gegoogelt (http://board.star-hosting.de/wbb/?page=thread&threadID=1251), aber mir fällt im Moment keiner von den mir bekannten Hostern ein der das anbietet
- :-: 1&1
- :-: internet24
- :-: Telekom
Gruß
Stefan
-
Bei meinem kann ich das: http://www.easyname.eu/ - den hab ich mir aber auch sehr genau ausgesucht :)
Das sind genau die Details, die IMHO einen OK-Anbieter von einem sehr guten Anbieter unterscheiden.
-
...Danke für den Tip :)