Gelöst Header based Routing - DB Änderung greift nicht

[zuberth]

Hallo,

Wir hatten gestern eine Migration, bei welcher das Header based Routing angepasst werden musste. An sich waren nur kleine Anpassungen erforderlich, u.a. eine Änderung auf SQL-Level in den Tabellen "InboundSendConnector" und "OutboundSendConnector", wo IP-Adressen im grün markierten Bereich geändert werden mussten:



Danach funktionierte das Routing nicht mehr korrekt. Neustart der Rollen, des Servers, der SQL-Instanz haben nicht geholfen. Erst nachdem via GUI die Kosten des betroffenen Eingangs-/Ausgangs-Konnektor tiefer gesetzt und und gespeichert wurden, funktionierte das Routing wie zuvor, auch noch nachdem die Kosten wieder zurück auf die ursprünglichen Werte gesetzt wurden.

Ich vermute, dass es nicht die Änderung der Kosten an sich war, welche die Funktion wieder hergestellt hat, sondern dass mit dem Speichern noch eine weitere Änderung geschrieben wird, welche erforderlich ist und beim Editieren auf SQL-Level nicht stattfindet, analog zur eine Business-Logik in einem ERP-System. Ich weiss es nicht wirklich. Das Vorgehen hat jedenfalls geholfen. Vielleicht von Interesse in einer ähnlichen Konstellation.

Gruss
Thomas Zuber

 

[JanJäschke]

Danke für den Input Thomas, so stolpern vlt. auch noch andere drüber.

Die Intranet Rolle bekommt durch die DB Änderung nichts davon mit und repliziert entsprechend auch nichts zu den Gateways.
Somit bleibt nur: DB des Gateways mit editieren oder aber (und das ist besser) in der NCC einmal öffnen und wieder speichern, eine Änderung sollte nicht zwingend notwendig sein

Charmanter wird es natürlich wenn eine solche Konfiguration direkt per UI geht (Nein ich kann kein ETA nennen)

 

[MichiH]

Moin zusammen und ein gesundes, frohes und erfolgreiches Jahr.

Ich hatte gerade ein ähnliches Problem wie Thomas, allerdings hat hier weder das Öffnen und Speichern im NCC geholfen, noch eine Anpassung der Kosten.
Auch ein Update von 15.2 zu 15.4 hat nicht geholfen.

Letztendlich blieb mir nur die Konnektoren zu löschen, die GW Rolle einmal durchzustarten und die Konnektoren dann neu anzulegen.
Dabei ist mir aufgefallen das bei der Neuanlage der Konnektoren die Einträge für das header-based Routing ("headerMatches":{"comparison":"None","matches":[]}) nicht mehr automatisch angelegt werden.
@JanJäschke : Bug oder Feature

 

[MichiH]

Ich habe noch eine Macke gefunden:
Editiert man die routing Bedingungen im SQL Studio, speichert diese und geht dann nochmal im NCC auf den bearbeiteten Konnektor und speichert dort nochmal wird die eingefügte Bedingung gelöscht und im SQL Studio steht dann wieder "headerMatches":{"comparison":"None","matches":[]}
Das ist zwar gerade nur in einer PoC Installation aber das Verhalten ist wohl eher nicht gewollt...

Gilt übrigens sowohl für die inbound- als auch für die outbound-sendconnetors

 

[JanJäschke]

Hallo Michi,

beim ersten lesen wirkt es so als würdest du die SQL Änderungen auf dem GW machen.
Machst du sie dort oder bist du in der Intranet Rollen Datenbank zugange?


Gruß,
Jan

 

[MichiH]

Hallo Michi,

beim ersten lesen wirkt es so als würdest du die SQL Änderungen auf dem GW machen.
Machst du sie dort oder bist du in der Intranet Rollen Datenbank zugange?


Gruß,
Jan

Moin Jan,

frohes Neues Jahr.
Nein, ich mache die Änderungen normalerweise nur auf der Intranetrolle und repliziere sie dann durch das Öffnen und speichern des entsprechenden Konnektors. Ich habe das mehrere Male getestet und eigentlich immer darauf geachtet, das ich nur die Intranetrollen DB offen hatte. Aber es kann natürlich so sein, das ich da durcheinander gekommen bin.

Ich habe jetzt nochmal mit einem Kollegen zusammen das Ganze durchgespielt und kann den beschriebenen Fehler nicht mehr reproduzieren. Daher erst einmal Entwarnung und sorry für den Aufruhr.

Allerdings habe ich bei den outbound Sendekonnektoren noch ein Routing Problem, resp. die Bedingungen greifen nicht richtig. Hättest Du Zeit das die Tage mal mit mir in einer Sitzung durchzugehen? Oder soll ich ein Ticket aufmachen?

Hier eine kurze Beschreibung: Ich muss alle ausgehenden E-Mails durch ein weiteres Mailsystem schicken, bevor der NSP die E-Mails nach extern versendet. Dafür habe ich zwei Regeln für ausgehende E-Mails angelegt, die jeweils die IP Adressen der Exchange Server und des anderen E-Mailservers im IP Filter hinterlegt haben.
Dann gibt es zwei outbound Sendekonnektoren bei denen das header-based Routing aktiviert ist und habe dort die angewendete Regel als Bedingung hinterlegt. (Das gleiche Konstrukt gibt es übrigens auch in eingehender Richtung und dort funktioniert auch alles)
Nur ausgehend kommt die Fehlermeldung "5.4.4 No send connector is defined for the domain contoso.de"

Mir gehen im Moment etwas die Ideen aus

 

[JanJäschke]

Ersteres sind schon einmal sehr gute Neuigkeiten

Für die Folgeproblematik erstell am besten einmal ein Troubleshooting log, dann sehen wir direkt was NSP auswertet.
Das Log gerne dann einmal als Ticket rein - bezieh dich gerne auf diesen Thread, dann landet das in der Regel wider bei mir und wir schauen was da los ist

LG
Jan

 

[MichiH]

Ersteres sind schon einmal sehr gute Neuigkeiten

Für die Folgeproblematik erstell am besten einmal ein Troubleshooting log, dann sehen wir direkt was NSP auswertet.
Das Log gerne dann einmal als Ticket rein - bezieh dich gerne auf diesen Thread, dann landet das in der Regel wider bei mir und wir schauen was da los ist

LG
Jan

Hi Jan,
geht los.

LG
Michi

 

[MichiH]

Moin in die Runde,

so, das Problem mit den ausgehenden Sendekonnektoren konnte ich gestern zusammen mit dem Support lösen. Die Ursache war, das auf beiden Konnektoren eine SMTP Header Prüfung auf den X-NoSpamProxy-Rule Header aktiviert war. Bei den eingehenden Sendekonnektoren funktioniert das super, das dort der Header von der GW Rolle gesetzt wird. Bei den ausgehenden Sendekonnektoren wird der Header nicht eingetragen und somit laufen beide Prüfungen auf Fehler.

Nach ein bisschen Fummeln und Testen haben wir jetzt eine funktionierende Konfig bei der für das erste Routing auf die internen IP Adressen von den Exchange Servern geprüft wird. Das externe Mailsystem fügt während der Verarbeitung einen eigenen X-Header ein, dessen Wert wir dann bei dem zweiten NSP Sendekonnektor, der dann nach außen sendet, abprüfen. Wichtig dabei ist, das der Default Outbound Connector geringere Kosten als der Konnektor für das Routing zum externen Mailsystem.

@JanJäschke : Hast Du vielleicht eine kleine Doku, welche X-Header in welcher Richtung von den Gateways eingefügt werden? Das würde echt helfen.

Dabei ist mir aufgefallen das bei der Neuanlage der Konnektoren die Einträge für das header-based Routing ("headerMatches":{"comparison":"None","matches":[]}) nicht mehr automatisch angelegt werden.
@JanJäschke : Bug oder Feature

Ich habe mir heute auch nochmal das Thema mit der Neuanlage von Konnektoren und den Parametern für das Header-based-Routing in der Version 15.4.0.373 genauer angeschaut und dabei folgendes herausgefunden:
Wenn man einen neuen Sendekonnektor (inbound oder outbound) mit dem Assistenten anlegt, fehlen in der Datenbank der Intranetrolle die Routingparameter und die ID am Ende stimmt nicht mit dem Index in der Datenbank überein:

In der Datenbank der Gatewayrolle wird der Eintrag aber korrekt angelegt:

Workaround: Einmal im NCC den neu erstellten Sendekonnektor öffnen und speichern, danach ist auch der Eintrag in der Datenbank der Intranetrolle korrekt:


Ich hoffe das diese Info's dem einen oder anderen bei seinem Troubleshooting helfen können.

Grüße
Michi

 

[JanJäschke]

Danke für die ausführliche Beschreibung

Einen Doku Abschnitt welcher Header in welche Richtung wann zur Verfügung steht gibt es leider nicht :/
Ich nehme aber den Gedanken mal mit wenn es um die UI für das Header Based Routing geht