17
Software startet plötzlich GUI nicht mehr
Hallo,
ich bin etwas verzweifelt und brauche Hilfe.
Mir fehlt der Ansatz für meine Problemlösung.
Ich versuche mal ausführlich zu Erklären und hoffe es ist alles relevante dabei.
Windows Server 2019 wird als VM auf einem Cluster als Terminalserver betrieben.
Der Aufbau läuft so ca. seit 9 Monaten.
Auf dem Terminalserver läuft ein ERP-System (TopM, net7, wer es kennt), was ohne Installation durch Kopieren eines Ordners installiert wird. Die Windows-Anwendung ist ein ASP-Client, der sich zu einem Server im Netzwerk verbindet (Port 30003 oder alternativ 30004 , 30005).
Bis vor drei Tagen hat alles so funktioniert wie es sollte.
Aber nun verbindet sich die Software, verifiziert die Lizenz und Anmeldung aber startet nicht mehr.
Genau an dem Punkt wo das GUI angezeigt werden soll, passiert nichts mehr.
Ich habe dann folgende Dinge probiert:
1. Ereignisanzeige => keine Auffälligkeiten
2. Sytsemlog des ERP-Systems: keine Erkenntnisse
3. Rücksicherung der virtuellen Maschine auf einen Tag an dem es sicher funktioniert hat => trotzdem keine Funktion
4. Freigaben in der Firewall geprüft (Firewall auch mal deaktiviert) => keine Verbesserung
5. Virenschutz (Trendmicro) deaktiviert => keine Verbesserung
6. Zugriffsrechte auf den kopierten Ordner geprüft (mehrere Orte inkl. Desktop als Installationsort gewählt) => keine Verbesserung
7. Gruppenrichtlinien auf Einschränkungen geprüft => alles normal
8. Installation auf einem anderen 2019er-Server im Netzwerk => Funktion ohne Probleme gegeben
9. Prüfung aller möglichen Einstellungen im Kombatibilitätsmodus => keine Änderung
10. Ausführung als Administrator => keine Änderung
11. Benutzerkontensteuerung auf niedrigste Stufe eingestellt => keine Änderung
12. Auf dem Cluster und am Server sind in der fraglichen Zeit keine Windows-Updates durchgeführt worden
Hat bitte jemand einen Ansatz oder etwas ähnliches erlebt? HILFE!
ich bin etwas verzweifelt und brauche Hilfe.
Mir fehlt der Ansatz für meine Problemlösung.
Ich versuche mal ausführlich zu Erklären und hoffe es ist alles relevante dabei.
Windows Server 2019 wird als VM auf einem Cluster als Terminalserver betrieben.
Der Aufbau läuft so ca. seit 9 Monaten.
Auf dem Terminalserver läuft ein ERP-System (TopM, net7, wer es kennt), was ohne Installation durch Kopieren eines Ordners installiert wird. Die Windows-Anwendung ist ein ASP-Client, der sich zu einem Server im Netzwerk verbindet (Port 30003 oder alternativ 30004 , 30005).
Bis vor drei Tagen hat alles so funktioniert wie es sollte.
Aber nun verbindet sich die Software, verifiziert die Lizenz und Anmeldung aber startet nicht mehr.
Genau an dem Punkt wo das GUI angezeigt werden soll, passiert nichts mehr.
Ich habe dann folgende Dinge probiert:
1. Ereignisanzeige => keine Auffälligkeiten
2. Sytsemlog des ERP-Systems: keine Erkenntnisse
3. Rücksicherung der virtuellen Maschine auf einen Tag an dem es sicher funktioniert hat => trotzdem keine Funktion
4. Freigaben in der Firewall geprüft (Firewall auch mal deaktiviert) => keine Verbesserung
5. Virenschutz (Trendmicro) deaktiviert => keine Verbesserung
6. Zugriffsrechte auf den kopierten Ordner geprüft (mehrere Orte inkl. Desktop als Installationsort gewählt) => keine Verbesserung
7. Gruppenrichtlinien auf Einschränkungen geprüft => alles normal
8. Installation auf einem anderen 2019er-Server im Netzwerk => Funktion ohne Probleme gegeben
9. Prüfung aller möglichen Einstellungen im Kombatibilitätsmodus => keine Änderung
10. Ausführung als Administrator => keine Änderung
11. Benutzerkontensteuerung auf niedrigste Stufe eingestellt => keine Änderung
12. Auf dem Cluster und am Server sind in der fraglichen Zeit keine Windows-Updates durchgeführt worden
Hat bitte jemand einen Ansatz oder etwas ähnliches erlebt? HILFE!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 628749
Url: https://administrator.de/contentid/628749
Ausgedruckt am: 24.11.2024 um 21:11 Uhr
17 Kommentare
Neuester Kommentar
Moin,
Was passiert denn, wenn du den Server unter Punkt 8 mal in die selbe OU wie den Terminalserver packst (vorher einen Snapshot erstellen)?
Oder den TS aus der bisherigen OU rausnimmst?
Ist das Benutzerunabhängig?
Was passiert, wenn du am Problemserver mal das gesamte Profil eines (Test-)User löscht (= umbenennst)? Hierbei aber das Profile sowohl auf dem TS als auch auf dem Server, auf dem die Profile weggeschrieben werden, berücksichtigen.
Das klingt für mich, als wenn da eine GPO in die Suppe spuckt.
Bist du alleine in der IT oder gibt es noch Mitstreiter?
Gruß
em-pie
Was passiert denn, wenn du den Server unter Punkt 8 mal in die selbe OU wie den Terminalserver packst (vorher einen Snapshot erstellen)?
Oder den TS aus der bisherigen OU rausnimmst?
Ist das Benutzerunabhängig?
Was passiert, wenn du am Problemserver mal das gesamte Profil eines (Test-)User löscht (= umbenennst)? Hierbei aber das Profile sowohl auf dem TS als auch auf dem Server, auf dem die Profile weggeschrieben werden, berücksichtigen.
Das klingt für mich, als wenn da eine GPO in die Suppe spuckt.
Bist du alleine in der IT oder gibt es noch Mitstreiter?
Gruß
em-pie
Die Anwendung läuft und DWM zeichnet kein Fenster?
Moin.
Wirf auf dem Server mal Procmon an:
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
Damit solltest du analysieren können, ob der Prozess überhaupt startet, worauf er zugreift bzw. zugreifen will und wo es evtl. zu Fehlermeldungen kommt. Ich erinnere mich dunkel an ein ähnliches Problem, damals lag es an der Bildschirmauflösung der Maschine - der Grafikkartentreiber hatte sich ins Nirvana verabschiedet, die Auflösung lag bei VESA-Standard 640x480 Pixel, was bei RDP-Verbindungen natürlich nicht auffällt. Da wollte die Software auch nicht starten.
Cheers,
jsysde
Wirf auf dem Server mal Procmon an:
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
Damit solltest du analysieren können, ob der Prozess überhaupt startet, worauf er zugreift bzw. zugreifen will und wo es evtl. zu Fehlermeldungen kommt. Ich erinnere mich dunkel an ein ähnliches Problem, damals lag es an der Bildschirmauflösung der Maschine - der Grafikkartentreiber hatte sich ins Nirvana verabschiedet, die Auflösung lag bei VESA-Standard 640x480 Pixel, was bei RDP-Verbindungen natürlich nicht auffällt. Da wollte die Software auch nicht starten.
Cheers,
jsysde
Ja, ich habe mehrere User mit dem gleichen Problem. Es klappt bei allen Usern nicht. Habe auch drei Testuser und Admin zur Verfügung. Ich tippe auch auf GPO. Habe die Richtlinie vollständig deaktiviert, womit nur noch die Richtlinie wie für alle anderern Server gültig ist. Wie der Server unter 8. Ich habe noch Mittstreiter, die auch die Waffen gestreckt haben. Und den Hersteller des ERP der es auf das Betriebssystem schiebt (was ich sogar glauben kann).
Die Anwendung wird nach kurzer Zeit im Taskmanager als "inaktiv" angezeigt.
Beenden ist nur über den Taskmanager möglich.
Beenden ist nur über den Taskmanager möglich.
Das mit Procmon mache ich jetzt mal. Ich habe im Kompatibilitätsmodus schon mal eine niedrige Auflösung eingstellt. Dann reagiert die Anwendung nicht mehr. Ich komme so weit, dass ich Benutzername und Kennwort eingeben kann, und das wird vom Server auch als richtig geprüft. In dem Moment sollte aber das GUI öffnen....und dann hängt sich die Anwendung auf.
Grüß dich,
Benötigt die GUI ein .NET Framework? Ist das ggf. korrupt?
Gruß,
Stefan
Benötigt die GUI ein .NET Framework? Ist das ggf. korrupt?
Gruß,
Stefan
Zitat von @Tommy525600:
Ja, ich habe mehrere User mit dem gleichen Problem. Es klappt bei allen Usern nicht. Habe auch drei Testuser und Admin zur Verfügung. Ich tippe auch auf GPO. Habe die Richtlinie vollständig deaktiviert, womit nur noch die Richtlinie wie für alle anderern Server gültig ist. Wie der Server unter 8. Ich habe noch Mittstreiter, die auch die Waffen gestreckt haben. Und den Hersteller des ERP der es auf das Betriebssystem schiebt (was ich sogar glauben kann).
Ja, ich habe mehrere User mit dem gleichen Problem. Es klappt bei allen Usern nicht. Habe auch drei Testuser und Admin zur Verfügung. Ich tippe auch auf GPO. Habe die Richtlinie vollständig deaktiviert, womit nur noch die Richtlinie wie für alle anderern Server gültig ist. Wie der Server unter 8. Ich habe noch Mittstreiter, die auch die Waffen gestreckt haben. Und den Hersteller des ERP der es auf das Betriebssystem schiebt (was ich sogar glauben kann).
Eine deaktivierte GPO sorgt aber nicht zwingend dafür, dass die dahinterstehenden Einstellungen auch zurückgesetzt werden.
Setzt eine GPO einen RegKey auf 1, bleibt dieser auf 1, außer, man konfiguriert eine andere GPO, die den Key löscht oder auf 0 setzt.
Daher mein Vorschlag, einen anderen Server mal in die OU zu verschieben.
Ggf. Dann GPO für GPO wieder aktivieren und prüfen, welche der Übeltäter ist...
Hallo,
Bei derartigen Problemen stellt sich mir - wieder einmal - die Frage, was dagegen spricht, den Hersteller der Software zu fragen wie man das Problem eingrenzen kann.
Gerade bei unternehmenskritischen Anwendungen werden i.d.R. Wartungsverträge abgeschlossen, in denen entsprechende Supportkanäle enthalten sind.
Die Kontaktdaten stehen z.B. hier: Kontakt - TopM Software GmbH
Gruß,
Jörg
Zitat von @Tommy525600:
Auf dem Terminalserver läuft ein ERP-System (TopM, net7, wer es kennt), was ohne Installation durch Kopieren eines Ordners installiert wird. Die Windows-Anwendung ist ein ASP-Client, der sich zu einem Server im Netzwerk verbindet (Port 30003 oder alternativ 30004 , 30005).
Auf dem Terminalserver läuft ein ERP-System (TopM, net7, wer es kennt), was ohne Installation durch Kopieren eines Ordners installiert wird. Die Windows-Anwendung ist ein ASP-Client, der sich zu einem Server im Netzwerk verbindet (Port 30003 oder alternativ 30004 , 30005).
Bei derartigen Problemen stellt sich mir - wieder einmal - die Frage, was dagegen spricht, den Hersteller der Software zu fragen wie man das Problem eingrenzen kann.
Gerade bei unternehmenskritischen Anwendungen werden i.d.R. Wartungsverträge abgeschlossen, in denen entsprechende Supportkanäle enthalten sind.
Die Kontaktdaten stehen z.B. hier: Kontakt - TopM Software GmbH
Gruß,
Jörg
Das wird ein großer Spaß. Aber eine schlauere Idee habe ich gerade auch nicht. Ich versuche alles. Der ProcessMonitor (wie von einem anderen User empfohlen) bringt bisher keine neuen Infos.
Stefan007: Ja, braucht es. Ich schaue auch mal danach.
Stefan007: Ja, braucht es. Ich schaue auch mal danach.
Hallo altmetaller,
wir haben einen Wartungsvertrag und Kontkat zum Hersteller.
Mit dem Techniker habe ich meinen Freitag verbracht. Aber danke für den Tip!
Ach, und sorry, hab mich verklickt. Wollte den Beitrag nicht als Lösung markieren.
wir haben einen Wartungsvertrag und Kontkat zum Hersteller.
Mit dem Techniker habe ich meinen Freitag verbracht. Aber danke für den Tip!
Ach, und sorry, hab mich verklickt. Wollte den Beitrag nicht als Lösung markieren.
Hallo,
vielleicht ist dem irgendwo ein Stück Infrastruktur weggebrochen? Zum Beispiel eine bestimmte DNS-Hostnamensauflösung, ein SMB-Protokoll o.Ä.
Gruß,
Jörg
vielleicht ist dem irgendwo ein Stück Infrastruktur weggebrochen? Zum Beispiel eine bestimmte DNS-Hostnamensauflösung, ein SMB-Protokoll o.Ä.
Gruß,
Jörg
Hallo Jörg,
das ERP klappt auf allen anderen Geräten ohne Problem (etwa 60 weitere User) nur auf diesem Terminalserver nicht. Mir ist aber vor zwei Minuten noch etwas aufgefallen: Word startet auch nicht mehr....wenn es hier nicht vielleicht einen Zusammenhang gibt ?!?
Serverkommunikation klappt aber sicher, da der Terminalserver auch ohne Probleme Clientupdates von dem Server lädt und die Anmeldedaten auch verifiziert.
das ERP klappt auf allen anderen Geräten ohne Problem (etwa 60 weitere User) nur auf diesem Terminalserver nicht. Mir ist aber vor zwei Minuten noch etwas aufgefallen: Word startet auch nicht mehr....wenn es hier nicht vielleicht einen Zusammenhang gibt ?!?
Serverkommunikation klappt aber sicher, da der Terminalserver auch ohne Probleme Clientupdates von dem Server lädt und die Anmeldedaten auch verifiziert.
Microsoft hat unlängst mit Updates die Interpretation von nicht gesetzten GPOs mal wieder geändert... seit dem cumulativen Oktober-Update wird eine undefinierte GPO zum Thema SMB1 als "nicht erlaubt" interpretiert. Gab hier infolge dessen zahlreiche Leute die gefragt hatten, warum ihr Legacy-Share nicht mehr erreichbar ist.
Dann ist ebenfalls seit Oktober aus dem Add-Windowsfeature im PS v5 Install-Windowsfeature geworden..
Dann ist ebenfalls seit Oktober aus dem Add-Windowsfeature im PS v5 Install-Windowsfeature geworden..
In welchem Pfad finde ich denn die GPO für SMB1?
Ich hab es gefunden: Und ich springe gleich im Dreieck. Eine "Nettigkeit" eines Kollegen in der Gruppenrichtlinie.
Da wir bei dem Terminalserver ein wenig Probleme hatten, dass zu viele Remote-Drucker installiert wurden hat mein Kollege die Remoteverbindung von Druckern in der GPO untersagt und nur Drucker auf dem Printserver zugelassen. Leider klappt das Skript mit der Zulassung der Drucker nicht. Somit habe ich auf dem Terminalserver nicht mal einen XPS-Drucker.
Dies führt offensichtlich dazu, dass Word, Excel (und auch mein TopM) nicht starten.
Nach deaktivierung der Richtlinie klappt alles.
Da der Terminalserver die Änderung wohl erst beim nächsten Neustart ausgeführt hat, ist das ganze Thema jetzt mit 4 Wochen Verzögerung aufgetreten.
Ich danke Euch dennoch für die Hilfe und das Mitdenken. Dann ist es nicht so einsam an der Tastatur
Da wir bei dem Terminalserver ein wenig Probleme hatten, dass zu viele Remote-Drucker installiert wurden hat mein Kollege die Remoteverbindung von Druckern in der GPO untersagt und nur Drucker auf dem Printserver zugelassen. Leider klappt das Skript mit der Zulassung der Drucker nicht. Somit habe ich auf dem Terminalserver nicht mal einen XPS-Drucker.
Dies führt offensichtlich dazu, dass Word, Excel (und auch mein TopM) nicht starten.
Nach deaktivierung der Richtlinie klappt alles.
Da der Terminalserver die Änderung wohl erst beim nächsten Neustart ausgeführt hat, ist das ganze Thema jetzt mit 4 Wochen Verzögerung aufgetreten.
Ich danke Euch dennoch für die Hilfe und das Mitdenken. Dann ist es nicht so einsam an der Tastatur
Ich sag ja, irgendeine GPO 
Aber Hauptsache, das Problem ist gefunden und behoben.
Hoffentlich muss der Kollege nun ne Grillrunde für euch ausgeben
Aber Hauptsache, das Problem ist gefunden und behoben.
Hoffentlich muss der Kollege nun ne Grillrunde für euch ausgeben
