• Bewerte uns auf OMR Reviews: Klick

  • NSP Forum als App inkl. Push Nachrichten (iOS): Klick

  • Wichtige Information für alle, die noch nicht auf v14.0.5.39 sind:

    Cyren Antimalware kann nicht mehr verwendet werden. Unsere Lizenz ist endgültig deaktiviert, so dass der Dienst nicht mehr nutzbar ist.
    Bitte stellt sicher, dass ihr schnellstmöglich auf die aktuelle Version aktualisiert. Bis es so weit ist, empfehlen wir die Cyren Antimalware Aktion zu deaktivieren und mindestens den lokalen Virenscanner zu aktivieren. Sollte kein anderer Scanner als Cyren aktiv sein, kommt es unweigerlich zur Abweisung von E-Mails.

    Zusätzlich raten wir dazu, die Cyren Filter zu deaktivieren, hier ist der Einfluss zwar geringer, solange alle anderen Filter korrekt durchlaufen, aber im Problemfall kommt es ebenfalls zur Abweisung.

     

    Unser Blogbeitrag wird in Kürze ebenfalls aktualisiert.

    Beste Grüße
    Euer NoSpamProxy Team

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

14.2.0: Regeln werden nicht mehr alle angezeigt

obraun

Active member
Hallo,

nach dem Update auf 14.2.0 werden mir nur noch zwei Regeln angezeigt. Vorher (es war die vorher aktuelle Version aktiv) waren es ca. zehn Stück.

Ich habe nicht in die Konfig-Dateien geschaut, aber aus den in der Nachrichtenverfolgung angezeigten bei den einzelnen Mails angewandten Regeln erkenne ich, dass die anderen Regeln noch da sind.

Gott sei Dank, dadurch hat es aber auch 24 Stunden gedauert, bis ich das Fehlen in der Anzeige bemerkt habe. Es läuft halt alles.

Viele Grüße
Oliver
 
Hallo Oliver,
am Besten einen Ticket erstellen und den Sachverhalt schildern. Bitte nicht vergessen einen Screenshot anzuhängen und die Konfigurationsdateien anzuhängen. Das Forum ist dafür der falsche Platz. Das geht vermutlich unter.

Von welcher Version bist du auf 14.2 gewechselt?


Viele Grüße,
Daniel
 
Hallo Daniel,

hatte ich gemacht. Aber da wird es wohl ein paar Wochen dauern. Nachtrag:

NoSpamProxy 15.0.0.154 ändert nichts an dem Problem.

Viele Grüße
Oliver
 
NoSpamProxy 15.0.0.154 ändert nichts an dem Problem.
War das eine Verzweiflungstat oder hast du in den Release Note in Bug gesehen, welcher darauf schließen lässt, dass damit dein Problem behoben wurde? Ich frage deshalb, weil es eine 0er Version ist. Nicht das du nun mehr Probleme hast wie vorher. Eigentlich installiert man neue Versionen erst mit 1er oder im 2er hinter dem ersten Punkt.
hatte ich gemacht. Aber da wird es wohl ein paar Wochen dauern.
Ist mir durch aus bewusst. Wir können gerne parallel mal etwas stochern.

Dazu hätte dazu folgende Ansätze und Fragen:
  • Von welcher Version bist du auf 14.2 gewechselt?
    • Ist das Upgrade ohne Fehler verlaufen? Keine Merkwürdigkeiten?
  • Gibt es aktuell im Event Viewer der Intranet Rolle von NSP Fehler und Warnungen?
    • Wenn dem nicht so ist, die Rolle einmal neu starten und Versuchen das Regelwerk aufzurufen.
    • Sind nun entsprechende Einträge im Event Viewer zu sehen?
  • Neue VM hochziehen, NSP 15.0 installieren und danach die Konfiguration der Intranet Rolle von der Instanz mit dem beschriebenen Problem einspielen. Hast du auf der neuen Instanz, das selbe Problem?
 
Vielen Dank, Daniel, für Deine Hilfsbereitschaft! Wir werden aber wohl auf den Support warten müssen; vielleicht tauchen im Laufe der Zeit auch noch mehr Betroffene auf.

Ich komme aus zeitlichen Gründen kaum dazu, das Problem gründlich zu untersuchen (Umbenennen der Regeln in den Config-Dateien womöglich?). Nur soviel:

Ich bin auf die 14.2.0 von der zuvor aktuellen Version gewechselt. Also vermutlich 14.1.x. Ich erwähne noch, dass ich beim Wechsel auf 14.0 Probleme hatte und die 14.0 daher frisch installiert habe, also auf einer neuen VM und komplett neu manuell konfiguriert, nichts übernommen. Das erwähne ich, weil es keine Altlasten aus uralt-Versionen geben kann.

Das Upgrade lief ohne Merkwürdigkeiten. Es gibt keine Warnungen in den Eventlogs, wenn ich den NSP öffne, und ich habe nach dem Wechsel auf 14.2 mehr als einmal neu gestartet (die VM, nicht die Dienste). Ich sehe aber gerade, dass es Warnungen beim Neustart des Servers gibt. Das sehe ich mir nochmal an und poste es, ich habe jetzt noch zehn Minuten.

Die Regelnamen sind teilweise recht lang und enthalten Umlaute und Minuszeichen. Vielleicht mache ich mich mal daran, sie in den Config-Dateien zu kürzen.

Nebenbei: Das Regelwerk kann ich problemlos öffnen, es werden aber nur die Regeln Nr. 2 und 5 angezeigt. Die letzte Regel, jetzt habe ich in die Konfigurationsdatei geschaut, wäre wohl Nummer 8 - "All other inbound emails" - die haben wir wohl alle. Und sie wird auch angewendet.

Wo ich jetzt schon nachschaue - Regel mit Index 1 heißt schlicht "PRTG-Regel" - dann wird es wohl nicht die Länge sein.

Das Update auf 15 war nur eine Verzweiflungstat. Es gab keine Hinweis in den Release Notes, aber schien mir trotzdem einen Versuch wert. Das Gute ist, dass meine Installation winzig klein ist und ich jederzeit den NSP rausnehmen könnte (M365). Insofern ist der schnelle Einsatz neuer Versionen mein Service für NetAtWork. Ich wüsste nämlich auch nicht, warum der Fehler nicht auch bei einer Installation mit 10 Tsd. Mailboxen auftauchen sollte, und das ist dann deutlich unangenehmer. Ich bin durchaus noch entspannt. :)

Bei dem Fehlerbild denke ich, eine Verknüpfung zwischen Konfigurationsdatei und den Daten in der DB fehlt oder passt nicht. Und da wäre es nicht undenkbar, dass duies beim Upgrade auf 15 neu erstellt worden wäre.

Neue VM... an einem späteren Wochenende.

Und Danke nochmal, dass Du Dir Gedanken gemacht hast! :)
 
Ich komme aus zeitlichen Gründen kaum dazu, das Problem gründlich zu untersuchen (Umbenennen der Regeln in den Config-Dateien womöglich?). Nur soviel:
Auf jeden Fall zuvor die die Konfigurationsdatei konsistent sichern. Neben einer Umbenennung von bestehenden Regeln ist mir auch den Kopf gegangen, was geschieht wenn du eine neu Regel hinzufügst. Wird diese und dann evtl. auch die unsichtbaren Regeln angezeigt?

Die Regelnamen sind teilweise recht lang und enthalten Umlaute und Minuszeichen.
Minuszeichen nutze ich seit Anfang (> 7 Jahre) in NSP ohne Probleme. Umlaute hingegen habe ich noch nicht genutzt - unabhängig von NSP. Weil es eben keine globale Relevanz hat.
Wo ich jetzt schon nachschaue - Regel mit Index 1 heißt schlicht "PRTG-Regel" - dann wird es wohl nicht die Länge sein.
Sehe ich auch so.

Insofern ist der schnelle Einsatz neuer Versionen mein Service für NetAtWork.
Ziehst du deinen Service von der Rechnung von NSP ab oder schreibst du einfach eine eigene Rechnung? ;)

Ich wüsste nämlich auch nicht, warum der Fehler nicht auch bei einer Installation mit 10 Tsd. Mailboxen auftauchen sollte, und das ist dann deutlich unangenehmer.
Auf eine Instanz mit mehr als 10Tsd habe ich keinen Zugriff mehr. Bei allen mir bekannten Instanzen tritt dein Problem leider nicht auf.
Bei dem Fehlerbild denke ich, eine Verknüpfung zwischen Konfigurationsdatei und den Daten in der DB fehlt oder passt nicht.
Da habe ich die Erwartungshaltung, dass bei solch einem Zustand entsprechenden Fehlermeldungen protokolliert (und angezeigt) werden. Im Best Case sogar die Intranet Rolle den Betrieb einstellt.
 
Zwischendurch - als ich eine der beiden angezeigten Regeln gerade ändern wollte, kam ein Fehler, und der ist reproduzierbar:

================================================ Timestamp: 13.12.2023 06:48:49 Terminating: True Exception: System.InvalidOperationException: The rule index is out of range. This should not be possible under normal circumstances. bei Netatwork.NoSpamProxy.ManagementConsole.Rules.RuleViewModel.ValidateGeneralSettings() bei Netatwork.NoSpamProxy.UI.Dialogs.WizardBase.<>c__DisplayClass33_0.<AddPage>b__0() bei Netatwork.NoSpamProxy.UI.Dialogs.WizardBase.PageContainer.IsValidAsync() bei Netatwork.NoSpamProxy.UI.Dialogs.WizardBase.<ValidateAsync>d__42.MoveNext() --- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde --- bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) bei Netatwork.NoSpamProxy.UI.Dialogs.DialogBase.<SaveExecutedAsync>d__76.MoveNext() --- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde --- bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state) bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) bei System.Windows.Threading.DispatcherOperation.InvokeImpl() bei System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state) bei MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(Object obj) bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) bei MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state) bei System.Windows.Threading.DispatcherOperation.Invoke() bei System.Windows.Threading.Dispatcher.ProcessQueue() bei System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) bei MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) bei MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) bei System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) bei MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam) bei MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg) bei System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame) bei System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame) bei System.Windows.Window.ShowHelper(Object booleanBox) bei System.Windows.Window.Show() bei System.Windows.Window.ShowDialog() bei Netatwork.NoSpamProxy.UI.ViewModels.MailGatewayViewModelBase.ShowItemDialog[T](T viewModel, Func`2 dialogCreator, Boolean isModal) bei Netatwork.NoSpamProxy.ManagementConsole.Rules.RuleViewModel.ShowEditItemDialog() bei Netatwork.NoSpamProxy.ManagementConsole.Rules.RuleContainerViewModel.ShowEditItemDialog() bei Netatwork.NoSpamProxy.ManagementConsole.Rules.RuleCollectionViewModel.ModifySelectedItemExecuted() bei Netatwork.NoSpamProxy.UI.Commands.DelegateCommand.Execute(Object parameter) bei Netatwork.NoSpamProxy.UI.Commands.CommandBehaviorBinding.ExecuteCommand() bei (CommandBehaviorBinding , Object , MouseButtonEventArgs ) bei System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget) bei System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target) bei System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs) bei System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised) bei System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args) bei System.Windows.UIElement.RaiseEvent(RoutedEventArgs e) bei System.Windows.Controls.Control.OnMouseDoubleClick(MouseButtonEventArgs e) bei System.Windows.Controls.Control.HandleDoubleClick(Object sender, MouseButtonEventArgs e) bei System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget) bei System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target) bei System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs) bei System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised) bei System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent) bei System.Windows.UIElement.OnMouseDownThunk(Object sender, MouseButtonEventArgs e) bei System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget) bei System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target) bei System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs) bei System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised) bei System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args) bei System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args) bei System.Windows.UIElement.RaiseEvent(RoutedEventArgs args, Boolean trusted) bei System.Windows.Input.InputManager.ProcessStagingArea() bei System.Windows.Input.InputManager.ProcessInput(InputEventArgs input) bei System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport) bei System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel) bei System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled) bei System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) bei MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) bei MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) bei System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) bei MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam) bei MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg) bei System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame) bei System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame) bei System.Windows.Application.RunDispatcher(Object ignore) bei System.Windows.Application.RunInternal(Window window) bei System.Windows.Application.Run(Window window) bei Netatwork.NoSpamProxy.CommandCenter.App.Main() ================================================
 
Hallo zusammen,
wir konnten den Fehler im rahmen des Support Tickets beheben, die Ursache hierzu ist aber noch offen und wird derzeit in der Entwicklung analysiert.
Das Regelwerk wurde während des Updates nicht komplett (nur teilweise) in die neue aktive Konfigurationsdatei der Intranetrolle geschrieben. Die Original Konfiguration wird während des Updates in das Windows Update Temp Verzeichnis geschrieben, wo auch die Update Log Dateien liegen. Von dort kann man dann das Regelwerk wieder herstellen und durch Copy & Paste in die aktive Konfiguration manuell übertragen.

Wie gesagt die Ursachensuche liegt jetzt in der Entwicklung und falls die Kollegen etwas finden wird das Setup hier entsprechend optimiert. Derzeit ist dies ein sehr seltenes Phänomen und kein allgemeines Problem!

Gruß Thomas
 
Hallo Thomas,
Die Original Konfiguration wird während des Updates in das Windows Update Temp Verzeichnis geschrieben, wo auch die Update Log Dateien liegen.
... und aus den Logdateien geht keine Ursache hervor?!
Derzeit ist dies ein sehr seltenes Phänomen und kein allgemeines Problem!
Das ist eine Sache der Perspektive. Grundsätzlich ist jeder Kunde einer zu viel. Wenn das Verhältnis 1:1000 ist, bin ich bei dir.


Gruß,
Daniel
 
Bitte etwas Geduld, wir bekommen noch Feedback bezüglich Logs (ich frage mich gerade, ob ich den Server zu schnell neu gestartet habe nach dem Update, vielleicht wollte einer der Dienste noch in eine der XML-Dateien schreiben). Sollte doch noch ein weiterer Kunde betroffen sein, kann er sich hier dranhängen, dann helfen wir ihm schnell. :)
 
Es hängt mit einer internen Migration von Informationen aus der Konfiguration in die Datenbank zusammen. Der Fehler wird unter der Referenznummer 39210 geführt und wird, wenn er behoben ist so in den Release Notes aufgeführt werden.

Vorkommen ist weiterhin sehr selten, sodass wir ihn hier nicht als kritisch eingestuft haben.
 
Zurück
Oben