Installation Remotedesktopdienste Windows 2019 Server schlägt fehl bzw. funktioniert nicht
Hallo zusammen,
wir haben aktuell noch einen alten Remotedesktopserver mit Windows 2008 Server im Einsatz.
Dieser soll nun durch einen Windows 2019 Server ersetzt werden. Hierzu habe ich in Hyper-V eine komplett neue virtuelle Maschine in der Standardinstallation von MS Windows 2019 aufgesetzt.
Folgendermaßen gehe ich vor:
1.) Neuinstallation Windows
2.) Vergabe feste IP-Adresse
3.) Ändern Computernamen
4.) Hinzufügen zur Domäne
5.) Starten der Installation der Remotedesktopdienste
Nun kommt es bei Aufruf der Installation bei der Angabe des Verbindungsbroker zu folgender Meldung:
Servername.domain.local => Mit dem Server konnte keine Verbindung über PowerShell-Remoting hergestellt werden.
Folgendes habe ich bereits versucht:
1.) Nochmalige Freigabe der Ports für WInRM in der Firewall => bringt nichts
2.) Firewall deaktivieren => bringt nichts
3.) Powershell aufrufen (als Admin) => Enable-PSRemoting -Force => bringt nichts
4.) Powershell aufrufen (als Admin) => Enable-PSRemoting -Force + Reboot => bringt nichts
5.) WinRM geprüft => läuft
6.) ServerManager als Admin ausführen => Bringt nichts
So langsam bin ich ratlos.
Habe sämtliche Varianten zur Installation der Remotedesktopdienste ausprobiert, also "Standardbereitstellung", "Schnellstart" aber auch Installation über "Rollenbasierte und featuerbasierte Installation". Bei letzterem wird zwar was installiert (Remotedesktoplicensing) aber nach Reboot kann keine Verbindung zum Verbindungsbroker hergestellt werden.
Hat jemand schon mal so ein Problem gehabt? Habe testweise auch mal Windows 2016 Server aufgesetzt => identisches Problem.
Bin so langsam ratlos!
In der Gruppe des AD in der der Server hinterlegt ist greift eigentlich nur die Default-Gruppenrichtlinie.
Bin für jeden Tipp dankbar!
wir haben aktuell noch einen alten Remotedesktopserver mit Windows 2008 Server im Einsatz.
Dieser soll nun durch einen Windows 2019 Server ersetzt werden. Hierzu habe ich in Hyper-V eine komplett neue virtuelle Maschine in der Standardinstallation von MS Windows 2019 aufgesetzt.
Folgendermaßen gehe ich vor:
1.) Neuinstallation Windows
2.) Vergabe feste IP-Adresse
3.) Ändern Computernamen
4.) Hinzufügen zur Domäne
5.) Starten der Installation der Remotedesktopdienste
Nun kommt es bei Aufruf der Installation bei der Angabe des Verbindungsbroker zu folgender Meldung:
Servername.domain.local => Mit dem Server konnte keine Verbindung über PowerShell-Remoting hergestellt werden.
Folgendes habe ich bereits versucht:
1.) Nochmalige Freigabe der Ports für WInRM in der Firewall => bringt nichts
2.) Firewall deaktivieren => bringt nichts
3.) Powershell aufrufen (als Admin) => Enable-PSRemoting -Force => bringt nichts
4.) Powershell aufrufen (als Admin) => Enable-PSRemoting -Force + Reboot => bringt nichts
5.) WinRM geprüft => läuft
6.) ServerManager als Admin ausführen => Bringt nichts
So langsam bin ich ratlos.
Habe sämtliche Varianten zur Installation der Remotedesktopdienste ausprobiert, also "Standardbereitstellung", "Schnellstart" aber auch Installation über "Rollenbasierte und featuerbasierte Installation". Bei letzterem wird zwar was installiert (Remotedesktoplicensing) aber nach Reboot kann keine Verbindung zum Verbindungsbroker hergestellt werden.
Hat jemand schon mal so ein Problem gehabt? Habe testweise auch mal Windows 2016 Server aufgesetzt => identisches Problem.
Bin so langsam ratlos!
In der Gruppe des AD in der der Server hinterlegt ist greift eigentlich nur die Default-Gruppenrichtlinie.
Bin für jeden Tipp dankbar!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 566911
Url: https://administrator.de/contentid/566911
Ausgedruckt am: 20.11.2024 um 11:11 Uhr
5 Kommentare
Neuester Kommentar
Moin,
google hat mir dazu ein gutes duzend Themen ausgespuckt.
.local als Domänennamen ist schon mal nicht hilfreich. Aber vermutlich so schnell nicht zu ändern.
Meist sind es DNS-Probleme.
Auch IPv6 abschalten habe bei einigen das Problem gelöst.
Aufgrund anderer fehler (und IPv6) könnte die Firewall in einem anderen Modus als "Domäne" sein.
https://rlevchenko.com/2015/05/22/rds-unable-to-connect-to-the-server-by ...
google hat mir dazu ein gutes duzend Themen ausgespuckt.
.local als Domänennamen ist schon mal nicht hilfreich. Aber vermutlich so schnell nicht zu ändern.
Meist sind es DNS-Probleme.
Auch IPv6 abschalten habe bei einigen das Problem gelöst.
Aufgrund anderer fehler (und IPv6) könnte die Firewall in einem anderen Modus als "Domäne" sein.
https://rlevchenko.com/2015/05/22/rds-unable-to-connect-to-the-server-by ...
Moin,
In der Windows-Domain keine gute Idee, da inzwischen auch einige Dienste nur mit IPv6 arbeiten.
Auf Grund von IPv6?
Liebe Grüße
Erik
In der Windows-Domain keine gute Idee, da inzwischen auch einige Dienste nur mit IPv6 arbeiten.
Aufgrund anderer fehler (und IPv6) könnte die Firewall in einem anderen Modus als "Domäne" sein.
Auf Grund von IPv6?
Liebe Grüße
Erik
Zitat von @erikro:
In der Windows-Domain keine gute Idee, da inzwischen auch einige Dienste nur mit IPv6 arbeiten.
Ich habe nicht gesagt dass es eine gute Idee ist. Soviel sollte der TO wissen und es nur als Problem-Finde-Hilfe verwenden.In der Windows-Domain keine gute Idee, da inzwischen auch einige Dienste nur mit IPv6 arbeiten.
Aufgrund anderer fehler (und IPv6) könnte die Firewall in einem anderen Modus als "Domäne" sein.
Auf Grund von IPv6?Auch weiß ich aus eigener Erfahrung, dass z.B. Fritz!Boxen hier querschiessen wenn das Netzwerk nicht korrekt aufgebaut ist.
Moin,
ich hatte genau das selbe Problem mit Windows Server 2022
Der Trick für mich war, im Server-Manager unter "Lokaler Server" die Remoteverwaltung einmal zu deaktivieren und anschließend wieder zu aktivieren.
Als Ursache vermute ich Gruppenrichtlinieneinstellungen, da wir z.B. WinRM auf diesem Weg aktivieren.
ich hatte genau das selbe Problem mit Windows Server 2022
Der Trick für mich war, im Server-Manager unter "Lokaler Server" die Remoteverwaltung einmal zu deaktivieren und anschließend wieder zu aktivieren.
Als Ursache vermute ich Gruppenrichtlinieneinstellungen, da wir z.B. WinRM auf diesem Weg aktivieren.