17
Update, Reboot - kein RDP und SQL mehr möglich
Hallo zusammen,
Samstag Morgen, 5 Uhr, was macht der EDVler - schaltet sich per VPN auf die Server, macht die Updates und sonstigen Dinge und startet die Server neu.
Im Detail: 2x Windows Server 2022 und 2x VM Windows Server 2012 R2. VM1 enthält Exchange und SQL, VM2 ist der Fileserver.
Ich war auf allen vieren per RDP drauf und hab eben meine Arbeiten verrichtet und dann die neu gestartet.
Auf die Bleche kam ich recht bald wieder drauf. Aber die VMs haben nicht auf die RDP-Anforderung reagiert. Schwitz. Also per per Hyper-V aufgeschaltet - alles soweit online. Freigaben funktionieren auch. Mails gehen auch rein und raus. Kurzfristig aufatmen. Aber dann der Schreck - die SQL-Datenbank für die wichtigste Software ist nicht erreichbar und die wird ab 7 Uhr benötigt.
Alles überprüft - alle Dienste laufen wie sie sollen, Freigaben alle erreichbar, Mails funktionieren auch.
Um 06.30 Uhr hab ich dann die beiden VMs einfach nochmal gestartet. Der Fileserver ist nach wie vor nicht per RDP zu erreichen. Aber die VM1 schon und SQL funktioniert auch wieder. Uff, war da nicht ein Erdbeben zu spüren?
Ich lasse jetzt für heute die Finger davon, die ersten Mitarbeiter arbeiten auch schon, da den Fileserver nochmal neu zu starten wäre ungeschickt. Aber es muss ja eigentlich auch ohne Neustart gehen.
Hat jemand eine Idee, wo das Problem liegen könnte?
Samstag Morgen, 5 Uhr, was macht der EDVler - schaltet sich per VPN auf die Server, macht die Updates und sonstigen Dinge und startet die Server neu.
Im Detail: 2x Windows Server 2022 und 2x VM Windows Server 2012 R2. VM1 enthält Exchange und SQL, VM2 ist der Fileserver.
Ich war auf allen vieren per RDP drauf und hab eben meine Arbeiten verrichtet und dann die neu gestartet.
Auf die Bleche kam ich recht bald wieder drauf. Aber die VMs haben nicht auf die RDP-Anforderung reagiert. Schwitz. Also per per Hyper-V aufgeschaltet - alles soweit online. Freigaben funktionieren auch. Mails gehen auch rein und raus. Kurzfristig aufatmen. Aber dann der Schreck - die SQL-Datenbank für die wichtigste Software ist nicht erreichbar und die wird ab 7 Uhr benötigt.
Alles überprüft - alle Dienste laufen wie sie sollen, Freigaben alle erreichbar, Mails funktionieren auch.
Um 06.30 Uhr hab ich dann die beiden VMs einfach nochmal gestartet. Der Fileserver ist nach wie vor nicht per RDP zu erreichen. Aber die VM1 schon und SQL funktioniert auch wieder. Uff, war da nicht ein Erdbeben zu spüren?
Ich lasse jetzt für heute die Finger davon, die ersten Mitarbeiter arbeiten auch schon, da den Fileserver nochmal neu zu starten wäre ungeschickt. Aber es muss ja eigentlich auch ohne Neustart gehen.
Hat jemand eine Idee, wo das Problem liegen könnte?
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: 7134604426
Url: https://administrator.de/contentid/7134604426
Ausgedruckt am: 17.11.2024 um 09:11 Uhr
17 Kommentare
Neuester Kommentar
Moin,
was ist denn mit den Ereignislogs auf der VM2?
Wenn der SH-Dienst nicht läuft, wird das nicht ohne Neustart funktionieren. Der ist zu nah am Kernel dran.
was ist denn mit den Ereignislogs auf der VM2?
Wenn der SH-Dienst nicht läuft, wird das nicht ohne Neustart funktionieren. Der ist zu nah am Kernel dran.
Moin @mpanzi,
ja, aber leider nicht nur eine bestimmte.
Sind die HV's netzwerktechnisch optimiert oder laufen diese quasi "Out of the Box" mit default Einstellungen?
Wenn ja, dann musst du einiges optimieren, den per default passiert öfters genau das was du beschreibst. 😞
Um dir genauere Tipps zu geben benötige ich jedoch weite Informationen über deine Umgebung.
Welche CPU's sind in den HV's verbaut und wie viele?
Welche physikalischen NIC's werden verwendet?
Wie sind die physikalischen NIC's konfiguriert?
Wie schnell sind die Physikalischen NIC's real am Switch angebunden (1G/10G)?
Wie ist der vSwitch konfiguriert?
Wie sind die vmNIC's der entsprechenden VM's konfiguriert?
Ja, es sind einige Fragen, aber glaub mir, jede davon ist für eine optimale und somit störungsfreie Konfiguration sehr wichtig. 😉
Das folgende PowerShell-Skript kratzt alle benötigten Informationen zusammen.
Beste Grüsse aus BaWü
Alex
Hat jemand eine Idee, wo das Problem liegen könnte?
ja, aber leider nicht nur eine bestimmte.
Sind die HV's netzwerktechnisch optimiert oder laufen diese quasi "Out of the Box" mit default Einstellungen?
Wenn ja, dann musst du einiges optimieren, den per default passiert öfters genau das was du beschreibst. 😞
Um dir genauere Tipps zu geben benötige ich jedoch weite Informationen über deine Umgebung.
Welche CPU's sind in den HV's verbaut und wie viele?
Welche physikalischen NIC's werden verwendet?
Wie sind die physikalischen NIC's konfiguriert?
Wie schnell sind die Physikalischen NIC's real am Switch angebunden (1G/10G)?
Wie ist der vSwitch konfiguriert?
Wie sind die vmNIC's der entsprechenden VM's konfiguriert?
Ja, es sind einige Fragen, aber glaub mir, jede davon ist für eine optimale und somit störungsfreie Konfiguration sehr wichtig. 😉
Das folgende PowerShell-Skript kratzt alle benötigten Informationen zusammen.
#Systeminfo auslesen
systeminfo
#Erweiterte Konfiguration der NIC's auslesen
Get-NetAdapter | Get-NetAdapterAdvancedProperty | Sort-Object -Property "Name" | FT -AutoSize
#Hardwareanbindung der NIC's auslesen
Get-NetAdapterHardwareInfo
#Linkkspeed der NIC's auslesen
Get-NetAdapter | select interfaceDescription, name, status, linkSpeed
#Konfiguration des vSwitches auslesen
Get-VMSwitch | FL
#Konfiguration der vmNIC's auslesen.
Get-VM | Get-VMNetworkAdapter | FLBeste Grüsse aus BaWü
Alex
Hallo,
RDP ist nicht alles. Bei VM kommst du ja über die Konsole drauf und kannst auch Dienste ohne Reboot neu starten.
SQL ist auch so eine Sache! Lief der denn oder nur von außen nicht erreichbar? Spontan fällt einen bei sowas zusätzlich noch die Firewall ein - fehlende Ausnahme und nach Update reaktiviert.
Gleiches gilt für RDP. Firwall, bzw. den Dienst neu starten.
Es ist alles irgendwie ein Dienst. Kommt die AD nicht hoch, kann man - sofern man Zugriff hat - auch hier den Dienst anschmeissen.
SQL: War die DB sauber unten? Oder kam kein Zugriff, da die DB wiederhergestellt wurde? Single-User Modues. Ich meine nun nicht ein Recovery. Sondern wenn der SQL korrupte DB selber zu heilen probiert.
Normal -außer vlt. beim Core Server - hat man ja vlt. sogar SQL Management Console installiert. Da fängt man immer am Anfang an: SQL Dienst da? Anmeldung am SQL. Datenbanken alle eingebunden? Nichts von Single-Mode oder Wiederherstellung zu sehenn? Einfacher SQL Query.
Dann wäre auch noch die Frage: AD Problem? Wie meldet sich die Client Softwae am SQL an? Jeder Client einzeln? Gibt es eine Middleware Software, die ggf. alleinstehend gerade nicht läuft!
SQL geht nicht - heisst ja meist: Keine Daten. Was ist Erreichbarkeit musst du dich fragen! Netz? Firewall? Dienst läuft gar nicht? SQL DB sind nicht mehr eingebunden oder im Single-Mode.
mfg Crusher
RDP ist nicht alles. Bei VM kommst du ja über die Konsole drauf und kannst auch Dienste ohne Reboot neu starten.
SQL ist auch so eine Sache! Lief der denn oder nur von außen nicht erreichbar? Spontan fällt einen bei sowas zusätzlich noch die Firewall ein - fehlende Ausnahme und nach Update reaktiviert.
Gleiches gilt für RDP. Firwall, bzw. den Dienst neu starten.
Es ist alles irgendwie ein Dienst. Kommt die AD nicht hoch, kann man - sofern man Zugriff hat - auch hier den Dienst anschmeissen.
SQL: War die DB sauber unten? Oder kam kein Zugriff, da die DB wiederhergestellt wurde? Single-User Modues. Ich meine nun nicht ein Recovery. Sondern wenn der SQL korrupte DB selber zu heilen probiert.
Normal -außer vlt. beim Core Server - hat man ja vlt. sogar SQL Management Console installiert. Da fängt man immer am Anfang an: SQL Dienst da? Anmeldung am SQL. Datenbanken alle eingebunden? Nichts von Single-Mode oder Wiederherstellung zu sehenn? Einfacher SQL Query.
Dann wäre auch noch die Frage: AD Problem? Wie meldet sich die Client Softwae am SQL an? Jeder Client einzeln? Gibt es eine Middleware Software, die ggf. alleinstehend gerade nicht läuft!
SQL geht nicht - heisst ja meist: Keine Daten. Was ist Erreichbarkeit musst du dich fragen! Netz? Firewall? Dienst läuft gar nicht? SQL DB sind nicht mehr eingebunden oder im Single-Mode.
mfg Crusher
Samstag Morgen, 5 Uhr, was macht der EDVler - schaltet sich per VPN auf die Server, macht die Updates und sonstigen Dinge und startet die Server neu.
Und was ist sonst so deine Aufgabe? Spontan mit Virtualiseirung anfangen ist recht sportlich. Kennst du die Hyper-V oder nur damit "gearbeitet"?
Wie ich oben schon schrieb: via Konsole ist immer das Mittel der Wahl. hatte es erst überlesen.
Also per per Hyper-V aufgeschaltet
Gut. Aber wie ich oben schon sagte: Dienst ist Dienst und die Anwendunge dahinter sind komplexer. Auch wenn SQL läuft musst die DB nicht da sein. Das müsste man sich auch immer in Ruhe einmal anschauen.
Neustart kann helfen, nur sieht man nichht was der SQL gerade tut. Nutzen die den Server direkt oder ERP System?
Schonmal z.B. VWware vCenter unter Windows nach Reboot angeschaut? Das dauert hier langen bis alles oben ist. Vermutest du nur dass alles immer sofort oben war, oder ist das nur geraten? Da z.B. ERP Sys doch 10 min braucht, und damit auch die Clients wieder arbeitsfähig sind.
Da müsstest du uns vlt. noch mal kurz erkären wie du getestet hast. Insbesondere auch den SQL.
Zitat von @MysticFoxDE:
Moin @mpanzi,
ja, aber leider nicht nur eine bestimmte.
Sind die HV's netzwerktechnisch optimiert oder laufen diese quasi "Out of the Box" mit default Einstellungen?
Wenn ja, dann musst du einiges optimieren, den per default passiert öfters genau das was du beschreibst. 😞
Um dir genauere Tipps zu geben benötige ich jedoch weite Informationen über deine Umgebung.
Welche CPU's sind in den HV's verbaut und wie viele?
Welche physikalischen NIC's werden verwendet?
Wie sind die physikalischen NIC's konfiguriert?
Wie schnell sind die Physikalischen NIC's real am Switch angebunden (1G/10G)?
Wie ist der vSwitch konfiguriert?
Wie sind die vmNIC's der entsprechenden VM's konfiguriert?
Ja, es sind einige Fragen, aber glaub mir, jede davon ist für eine optimale und somit störungsfreie Konfiguration sehr wichtig. 😉
Das folgende PowerShell-Skript kratzt alle benötigten Informationen zusammen.
Beste Grüsse aus BaWü
Alex
Moin @mpanzi,
Hat jemand eine Idee, wo das Problem liegen könnte?
ja, aber leider nicht nur eine bestimmte.
Sind die HV's netzwerktechnisch optimiert oder laufen diese quasi "Out of the Box" mit default Einstellungen?
Wenn ja, dann musst du einiges optimieren, den per default passiert öfters genau das was du beschreibst. 😞
Um dir genauere Tipps zu geben benötige ich jedoch weite Informationen über deine Umgebung.
Welche CPU's sind in den HV's verbaut und wie viele?
Welche physikalischen NIC's werden verwendet?
Wie sind die physikalischen NIC's konfiguriert?
Wie schnell sind die Physikalischen NIC's real am Switch angebunden (1G/10G)?
Wie ist der vSwitch konfiguriert?
Wie sind die vmNIC's der entsprechenden VM's konfiguriert?
Ja, es sind einige Fragen, aber glaub mir, jede davon ist für eine optimale und somit störungsfreie Konfiguration sehr wichtig. 😉
Das folgende PowerShell-Skript kratzt alle benötigten Informationen zusammen.
#Systeminfo auslesen
systeminfo
#Erweiterte Konfiguration der NIC's auslesen
Get-NetAdapter | Get-NetAdapterAdvancedProperty | Sort-Object -Property "Name" | FT -AutoSize
#Hardwareanbindung der NIC's auslesen
Get-NetAdapterHardwareInfo
#Linkkspeed der NIC's auslesen
Get-NetAdapter | select interfaceDescription, name, status, linkSpeed
#Konfiguration des vSwitches auslesen
Get-VMSwitch | FL
#Konfiguration der vmNIC's auslesen.
Get-VM | Get-VMNetworkAdapter | FLBeste Grüsse aus BaWü
Alex
Guten Morgen Alex,
ich bin zwar nicht der Thread-Opener, aber kannst du das genauer erläutern, welche Netzwerkeinstellungen man in Hyper-V vornehmen sollte bzw. muss um so etwas zu vermeiden ?
Ich baue gerade eine ähnliche Struktur auf …
Grüße
DC
Moin @DCFan01,
ähm, das ist eher eine etwas längere Geschichte.
Siehe ...
The Main Storry
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
an der ich ab Seite 4 kräftig mitgewirkt habe.
Und deren diverse Ausläufer ...
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
https://community.spiceworks.com/topic/2468243-the-windows-horror-story- ...
https://community.spiceworks.com/topic/2328491-with-rdma-higher-cpu-load ...
https://community.spiceworks.com/topic/2296144-windows-software-caching- ...
https://community.spiceworks.com/topic/2286588-please-do-not-use-refs-fo ...
Um eine Empfehlung auszusprechen, benötige ich auch von dir die genauen Angaben zu dem jeweiligen System und dessen Konfiguration.
Eine "pauschale" Optimierung ist bei den Servern leider nicht so einfach. 😞😭
Beste Grüsse aus BaWü
Alex
ich bin zwar nicht der Thread-Opener, aber kannst du das genauer erläutern, welche Netzwerkeinstellungen man in Hyper-V vornehmen sollte bzw. muss um so etwas zu vermeiden ?
ähm, das ist eher eine etwas längere Geschichte.
Siehe ...
The Main Storry
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
an der ich ab Seite 4 kräftig mitgewirkt habe.
Und deren diverse Ausläufer ...
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
https://community.spiceworks.com/topic/2468243-the-windows-horror-story- ...
https://community.spiceworks.com/topic/2328491-with-rdma-higher-cpu-load ...
https://community.spiceworks.com/topic/2296144-windows-software-caching- ...
https://community.spiceworks.com/topic/2286588-please-do-not-use-refs-fo ...
Um eine Empfehlung auszusprechen, benötige ich auch von dir die genauen Angaben zu dem jeweiligen System und dessen Konfiguration.
Eine "pauschale" Optimierung ist bei den Servern leider nicht so einfach. 😞😭
Beste Grüsse aus BaWü
Alex
Hallo zusammen,
uff, sooo viele Antworten, bin gerade unterwegs und kann nicht so ausführlich antworten.
Zu mir: Ich bin System- und Netzwerkadministrator und mache das jetzt schon über 20 Jahre.
Nur schonmal vorab: Die VMs habe ich nicht selbst aufgesetzt, die sind von vor meiner Zeit und die werde ich demnächst auf ein neueres OS aktualisieren. Es wurden nur erstmal die Hyper-V-Maschinen ersetzt. Ob die VMs 2022 oder noch 2019 bekommen hängt vom Hersteller der Software mit der SQL-DB ab.
Ist kein ERP-System, die User arbeiten direkt auf dem System.
Ich selbst kenne mich mit Hyper-V recht gut aus - bin vielleicht nicht DER Crack, aber ich mache das schon sehr lange und normalerweise kriege ich das selbst in den Griff bzw. habe damit eigentlich nie Probleme.
Diese SQL-DB wird von einer externen Firma betreut, damit hab ich nix am Hut.
Ich starte die Server ja nicht zum ersten Mal. Normalerweise sind die recht zügig wieder online. Aber dass ich nicht per RDP auf einen Rechner komme (bei dem es vorher funktioniert hat und der sonst auch voll erreichbar ist) ist mir noch nie untergekommen - in meiner ganzen Laufbahn noch nicht.
Daher wollte ich anfragen, ob das schonmal jemand hatte. Ich schätze, dass das RDP- und SQL-Problem irgendwie zusammenhing - also irgendwo auf Netzwerkebene. Im ersten Moment hatte ich auf ein DNS-Problem getippt, aber dann hätten die Freigaben auch nicht geklappt und RDP via IP-Adresse ging auch nicht. Die Datenbank auf dem Server war aktiv, konnte mich von dort aus einloggen. Nur per Client kam ich nicht drauf - "Server nicht erreichbar". Aber über \\Server\Freigabe kam ich auf den Server. Sehr dubios.
Zum Glück funktioniert es ja, aber würde mich trotzdem interessieren, wo das Problem war. Dass ich auf den Fileserver nur per Hyper-V komme ist kein großes Problem. Die Freigaben funktionieren einwandfrei.
Hab auch die anwesenden User angerufen, gibt keinerlei Probleme. Aber auf den Fileserver komme ich immer noch nicht per RDP.
uff, sooo viele Antworten, bin gerade unterwegs und kann nicht so ausführlich antworten.
Zu mir: Ich bin System- und Netzwerkadministrator und mache das jetzt schon über 20 Jahre.
Nur schonmal vorab: Die VMs habe ich nicht selbst aufgesetzt, die sind von vor meiner Zeit und die werde ich demnächst auf ein neueres OS aktualisieren. Es wurden nur erstmal die Hyper-V-Maschinen ersetzt. Ob die VMs 2022 oder noch 2019 bekommen hängt vom Hersteller der Software mit der SQL-DB ab.
Ist kein ERP-System, die User arbeiten direkt auf dem System.
Ich selbst kenne mich mit Hyper-V recht gut aus - bin vielleicht nicht DER Crack, aber ich mache das schon sehr lange und normalerweise kriege ich das selbst in den Griff bzw. habe damit eigentlich nie Probleme.
Diese SQL-DB wird von einer externen Firma betreut, damit hab ich nix am Hut.
Ich starte die Server ja nicht zum ersten Mal. Normalerweise sind die recht zügig wieder online. Aber dass ich nicht per RDP auf einen Rechner komme (bei dem es vorher funktioniert hat und der sonst auch voll erreichbar ist) ist mir noch nie untergekommen - in meiner ganzen Laufbahn noch nicht.
Daher wollte ich anfragen, ob das schonmal jemand hatte. Ich schätze, dass das RDP- und SQL-Problem irgendwie zusammenhing - also irgendwo auf Netzwerkebene. Im ersten Moment hatte ich auf ein DNS-Problem getippt, aber dann hätten die Freigaben auch nicht geklappt und RDP via IP-Adresse ging auch nicht. Die Datenbank auf dem Server war aktiv, konnte mich von dort aus einloggen. Nur per Client kam ich nicht drauf - "Server nicht erreichbar". Aber über \\Server\Freigabe kam ich auf den Server. Sehr dubios.
Zum Glück funktioniert es ja, aber würde mich trotzdem interessieren, wo das Problem war. Dass ich auf den Fileserver nur per Hyper-V komme ist kein großes Problem. Die Freigaben funktionieren einwandfrei.
Hab auch die anwesenden User angerufen, gibt keinerlei Probleme. Aber auf den Fileserver komme ich immer noch nicht per RDP.
Via IP oder Name? Bei DNS Problemen kannst es mal direkt über die IP probieren.
Was ist mit anderen Arten des Remoting? PowerShell Remote - geht das?
Was ist mit anderen Arten des Remoting? PowerShell Remote - geht das?
Restart-Service -Force -Name "TermService" 
Moin,
Gruß,
Dani
Der Fileserver ist nach wie vor nicht per RDP zu erreichen.
schau mal in der Ereignisanzeige die Bereiche System und Anwendungen sowie unter Anwendungs- und Dienstprotokolle gibt es ein paar Bereiche, welche mit RemoteDesktop beginnen. Findest du einen Error ala RemoteFX Problem?!Um 06.30 Uhr hab ich dann die beiden VMs einfach nochmal gestartet.
Dazu müsste doch auch was im Event Viewer zu finden sein...Gruß,
Dani
Steht das Netzwerkprofil der VMs zufällig auf öffentlich?
1
Moin @mpanzi,
na ja, ganz ohne weitere Informationen kann ich nur meine Glaskugel befragen und die sagt mir gerade, dass du bei dir RSC überall (NIC's, vSwitch, ,vmNIC's) deaktivieren solltest und RSS entweder anständig konfigurieren oder deaktivieren.
Beste Grüsse aus BaWü
Alex
Daher wollte ich anfragen, ob das schonmal jemand hatte. Ich schätze, dass das RDP- und SQL-Problem irgendwie zusammenhing - also irgendwo auf Netzwerkebene.
na ja, ganz ohne weitere Informationen kann ich nur meine Glaskugel befragen und die sagt mir gerade, dass du bei dir RSC überall (NIC's, vSwitch, ,vmNIC's) deaktivieren solltest und RSS entweder anständig konfigurieren oder deaktivieren.
Beste Grüsse aus BaWü
Alex
War denn nur der SQL server nicht erreichbar oder war die db tatsächlich nicht erreichbar? Bei virtuellen maschinen kann es vorkommen das der sql serverdienst nach einem neustart nicht gestartet wird. Wenn die dbS in ordnung sind kann man den dienst manuell starten. Hab ich bisher aber nur bei vmware vmS gesehen. Sicherheitshalber würde ich an deiner stelle mal ein dbcc checkdb machen. Geht auch im laufenden betrieb sollte es fehler in der db geben musst du weitere Schritte einleiten.
Ich will ja nicht drauf rum reiten aber angesprochen hat es noch keiner: SQL und Exchange auf der selben VM und SQL wird im wesentlichen durch Externe betreut oder mit betreut. Das ist mindestens unglücklich und sollte mit dem Update weg von 2012 R2 getrennt werden.
1
Hallo zusammen, sorry, dass ich mich jetzt erst wieder melde. War dann übers WE nicht mehr auf den Servern.
Heute wieder. Also die Protokolle geben nichts her, was auf RDP hinweist.
Müsste ja ein Fehler oder zumindest eine Warnung sein.
Im Zeitraum 13.05. von 05:00 - 07:00, gibt es 4 Fehler, ein paar Warnungen und keine kritischen Vermerke. Nichts, was auf ein Netzwerkproblem oder so hindeutet.
Aber das Problem ist zwischenzeitlich gelöst:
Den Dienst "Network Location Awareness (NLA)" neu gestartet (er war aktiv) und danach funktionierte es sofort.
Heute wieder. Also die Protokolle geben nichts her, was auf RDP hinweist.
Müsste ja ein Fehler oder zumindest eine Warnung sein.
Im Zeitraum 13.05. von 05:00 - 07:00, gibt es 4 Fehler, ein paar Warnungen und keine kritischen Vermerke. Nichts, was auf ein Netzwerkproblem oder so hindeutet.
Aber das Problem ist zwischenzeitlich gelöst:
Den Dienst "Network Location Awareness (NLA)" neu gestartet (er war aktiv) und danach funktionierte es sofort.
Zitat von @mpanzi:
Hallo zusammen, sorry, dass ich mich jetzt erst wieder melde. War dann übers WE nicht mehr auf den Servern.
Heute wieder. Also die Protokolle geben nichts her, was auf RDP hinweist.
Müsste ja ein Fehler oder zumindest eine Warnung sein.
Im Zeitraum 13.05. von 05:00 - 07:00, gibt es 4 Fehler, ein paar Warnungen und keine kritischen Vermerke. Nichts, was auf ein Netzwerkproblem oder so hindeutet.
Aber das Problem ist zwischenzeitlich gelöst:
Den Dienst "Network Location Awareness (NLA)" neu gestartet (er war aktiv) und danach funktionierte es sofort.
Hallo zusammen, sorry, dass ich mich jetzt erst wieder melde. War dann übers WE nicht mehr auf den Servern.
Heute wieder. Also die Protokolle geben nichts her, was auf RDP hinweist.
Müsste ja ein Fehler oder zumindest eine Warnung sein.
Im Zeitraum 13.05. von 05:00 - 07:00, gibt es 4 Fehler, ein paar Warnungen und keine kritischen Vermerke. Nichts, was auf ein Netzwerkproblem oder so hindeutet.
Aber das Problem ist zwischenzeitlich gelöst:
Den Dienst "Network Location Awareness (NLA)" neu gestartet (er war aktiv) und danach funktionierte es sofort.
Na gut das klingt dann stark nach Netzwerkprofil „Öffentlich“ und somit Abweisung von RDP aus fremden Subnetzen bzw. generell …
1
Nein, das Netzwerkprofil war nicht öffentlich. Das hatte ich überprüft.
Dieser Dienst isr aber genau fur die Netzwerkprofile zuständig, na sei’s drum .. hauptsache dein Problem ist vorerst gelöst
