HTTP 404 Fehler nach Update

[0xFelix]

Hi,
ich habe eben unser NSP von 15.1 auf 15.2 geupdated.
Scheint auch erstmal alles geklappt zu haben, Module zeigen nun:

NoSpamProxy 15.2.0.749
Management services 15.2.24298.1549
Identity Service 1.2.63
Message Tracking Service 2.0.21
Intranet Role 15.2.24298.1549
WebApp Hosting Service 1.3.19
WebApp 1.2.2917.0
PowerShell 15.2.24298.1549
NoSpamProxy Command Center 15.2.24298.1549

Leider kommt seitdem im CC diese Fehlermeldung:

---
Error message: The HTTP status code of the response was not expected (404).

Status: 404
Response:

Program location: bei Netatwork.NoSpamProxy.IntranetServices.GatewayRoleService.GatewayRoleClient.<SystemIssueGetDetailsAsync>d__91.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Netatwork.NoSpamProxy.IntranetServices.MonitoringController.<>c.<<GetIssues>b__15_0>d.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Netatwork.NoSpamProxy.IntranetServices.IntranetRoleWebserviceController.<WrapQueryFunction>d__27`2.MoveNext()
Additional data:
Type: Netatwork.NoSpamProxy.IntranetServices.GatewayRoleService.ApiException
Source: ServiceRole:%Gateway-FQDN%
Role: Gateway
---

Message tracking ist sowohl im CC als auch in der WebApp leer.
Die Portänderung die die Version mit sich zieht habe ich berücksichtigt, ich sehe auch aktive TCP-Verbindungen auf 6062 zwischen Intranet und Gateway.
Im Eventlog auf dem Intranet taucht noch häufig dieser Fehler auf:

Failed to download message tracks from Gateway Role (hostname %Gateway-FQDN%). The server returned status NotFound - Not Found. Trying again in 0:01:00.

Daraufhin habe ich mal das IIS-Logging auf dem Gateway aktiviert, bei Refresh im CC lässt sich in dem Log dann diese Meldung finden:
2025-04-04 14:04:27 %Gateway-IP% GET /enqsig/api/version - 443 - %Intranet-IP% - - 200 0 0 7
2025-04-04 14:06:27 %Gateway-IP% GET /enqsig/api/version - 443 - %Intranet-IP% - - 200 0 0 10
2025-04-04 14:06:53 %Gateway-IP% GET /enqsig/api/version - 443 - %Intranet-IP% - - 200 0 0 6
2025-04-04 14:08:27 %Gateway-IP% GET /enqsig/api/version - 443 - %Intranet-IP% - - 200 0 0 8
2025-04-04 14:10:27 %Gateway-IP% GET /enqsig/api/version - 443 - %Intranet-IP% - - 200 0 0 7

Hier hätte ich jetzt statt HTTP Status 200 irgendwo 404 erwartet.
Oder bin ich komplett auf der falschen Spur?

Danke für die Rückmeldung und ein schönes Wochenende!

Felix

 

[StefanCink]

Ich würde bei den NSP Verbindungen die Gateway Rolle einfach entfernen und neu hinzufügen. Das wird es vermutlich lösen.
Gruß Stefan

 

[0xFelix]

Danke für den Tipp, leider kommt beim neu verbinden der Gatewayrolle im CC ebenfalls diese Meldung:

Spoiler: Error Details

Error message: The new destination connection could not be validated.
Formatted exception:
Message: The new destination connection could not be validated.
Error type: System.Exception
Error code: 2148734208
Inner exception: The HTTP status code of the response was not expected (404).

Status: 404
Response:


Error message: The HTTP status code of the response was not expected (404).

Status: 404
Response:
Program location: at Netatwork.NoSpamProxy.ManagementConsole.GatewayRoleService.GatewayRoleServiceClient.<ServerInfoAsync>d__61.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Netatwork.NoSpamProxy.ManagementConsole.GatewayComponents.GatewayRoles.ServiceRoleConnectionViewModel.<>c__DisplayClass22_0.<<ValidateRoleConnectionSettingsAsync>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Netatwork.NoSpamProxy.UI.ViewModels.MailGatewayViewModelBase.<ExecuteOperationAsync>d__59.MoveNext()
Additional data:
StatusCode: 404
Response:
Headers: System.Collections.Generic.Dictionary`2[System.String,System.Collections.Generic.IEnumerable`1[System.String]]
Formatted exception:
Message: The HTTP status code of the response was not expected (404).

Status: 404
Response:

Error type: Netatwork.NoSpamProxy.ManagementConsole.GatewayRoleService.ApiException
Error code: 2148734208
Program location: at Netatwork.NoSpamProxy.ManagementConsole.GatewayRoleService.GatewayRoleServiceClient.<ServerInfoAsync>d__61.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Netatwork.NoSpamProxy.ManagementConsole.GatewayComponents.GatewayRoles.ServiceRoleConnectionViewModel.<>c__DisplayClass22_0.<<ValidateRoleConnectionSettingsAsync>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Netatwork.NoSpamProxy.UI.ViewModels.MailGatewayViewModelBase.<ExecuteOperationAsync>d__59.MoveNext()

 

[0xFelix]

Habe aber gerade noch gesehen: Ich glaube der HTTPS-Traffic, um den es hier geht, ist der auf Port 6060/6062, deshalb hat mein Logging auf :443 wahrscheinlich nichts gebracht.
Hm mir gehen aber leider langsam die Ideen aus :S

 

[0xFelix]

Eventuell noch einen Hinweis wert:
Bei Aufruf von https://%Gateway-FQDN% vom Intranet aus, wird das Wildcard-Zertifikat unserer Domain verwendet (gültig)
Bei Aufruf von https://%Gateway-FQDN%:6062 kommt eine Rückmeldung mit Selfsigned Zertifikat "Net at Work Mailgateway"
Ich gehe aber mal davon aus das ist by Design, da das Webportal den IIS und die Kommunikation über 6062 einen Webserver von euch nutzt?

 

[JanJäschke]

Eventuell noch einen Hinweis wert:
Bei Aufruf von https://%Gateway-FQDN% vom Intranet aus, wird das Wildcard-Zertifikat unserer Domain verwendet (gültig)
Bei Aufruf von https://%Gateway-FQDN%:6062 kommt eine Rückmeldung mit Selfsigned Zertifikat "Net at Work Mailgateway"
Ich gehe aber mal davon aus das ist by Design, da das Webportal den IIS und die Kommunikation über 6062 einen Webserver von euch nutzt?

Da ist deine Annahme komplett richtig. Das sollte kein Problem sein
Das Web Portal hat bei dir auch keinerlei Probleme?
(Nur um sicher zu gehen da es der gleiche Host ist)

Hier bringt dich also zur Analyse erstmal nur Wireshark auf der Gateway Rolle weiter um sicherzustellen das die Anfragen entsprechend ch end ankommen.

Zur Sicherheit:
Neben deiner normalen Firewall hast du auch die Windows Firewall bedacht?

 

[0xFelix]

Das Web Portal hat bei dir auch keinerlei Probleme?

Ja, ist auf dem Host, wo auch das Gateway drauf ist und das funktioniert.

Hier bringt dich also zur Analyse erstmal nur Wireshark auf der Gateway Rolle weiter um sicherzustellen das die Anfragen entsprechend ch end ankommen.

Den TLS-Traffic Zwischen Gateway und Intranet auf 6062 kann ich sehen, also ich würde bislang davon ausgehen, dass es kein Netzwerkproblem ist.
Meine Vermutung wäre eher, dass irgendwas mit dem Content, den der Webserver auf dem Gateway zurück liefert, nicht passt.
Da habe ich allerdings gerade echt keine Herangehensweise, wie ich das weiter troubleshooten könnte

 

[0xFelix]

Da das Thema nun aktuer wird habe ich mal einen Supportfall aufgemacht.
Falls ihr eine Parallelbearbeitung ausschließen wollt, kann dieser Thread gern geschlossen werden.
Danke!

 

[Sören]

kann dieser Thread gern geschlossen werden

würde ich noch nicht machen, zum einen hat vlt. jemand aus der Gemeinde eine Idee zum anderen wäre es schön, wenn du dann Feedback hier gibst was die Lösung war

 

[0xFelix]

Haben das Problem gelöst
Scheinbar hatte das Update noch nicht alle Dateien auf dem Gateway geupdated, da haben also 15.1-Dateien auf dem Gateway versucht mit 15.2-Dateien auf dem Intranet zu kommunizieren, so kam der Fehler zustande.
Die eigentliche Lösung war dann ein bisschen mehr Aufwand, aber vom Prinzip her:
Noch mal explizites Update auf dem Gateway und danach "manuelles" neu verbinden von Intranet und Gateway.
Ich hoffe ich hab das einigermaßen korrekt wiedergegeben.

 

[0xFelix]

Achso eventuell für euch interessant:
Dieser Eingangstext stammt aus dem Commandcenter:

Scheint auch erstmal alles geklappt zu haben, Module zeigen nun:

NoSpamProxy 15.2.0.749
Management services 15.2.24298.1549
Identity Service 1.2.63
Message Tracking Service 2.0.21
Intranet Role 15.2.24298.1549
WebApp Hosting Service 1.3.19
WebApp 1.2.2917.0
PowerShell 15.2.24298.1549
NoSpamProxy Command Center 15.2.24298.1549

Die Management-Service.exe auf dem Gateway hatte da aber in Wirklichkeit noch 15.1., also eventuell werden da irgendwo an falscher Stelle Infos abgerufen?
Oder sind damit die Management Services auf dem Intranet gemeint?