12
Fehler beim Installieren des RD-Verbindungsbrokers
Hallo zusammen,
ich habe einen Windows Server 2019 als VM auf einem ESXi 6.7 U2 frisch installiert. Mit dem Assistenten liessen sich anschließend die Remotedesktopdienste ebenfalls problemlos installieren. Nach der Installation der AD DS startete der RD-Verbindungsbroker nicht mehr. Folgende Fehler, die ich meinem Problem zuordne, habe ich im Ereignisprotokoll gefunden:
- Der First Counter-Wert, der dem Registrierungsschlüssel 'HKLM\SYSTEM\CurrentControlSet\Services\MSSQL$MICROSOFT##WID\Performance' zugeordnet ist, kann nicht abgefragt werden. SQL Server-Leistungsindikatoren sind deaktiviert.
- Der Dienst "MSSQL$MICROSOFT##WID" konnte aufgrund des folgenden Fehlers nicht unter NT SERVICE\MSSQL$MICROSOFT##WID mit dem aktuell konfigurierten Kennwort angemeldet werden:
Anmeldungsfehler: Dem Benutzer wurde der angeforderte Anmeldungstyp auf diesem Computer nicht zugeteilt.
- Der Dienst "Interne Windows-Datenbank" wurde aufgrund folgenden Fehlers nicht gestartet:
Der Dienst konnte wegen einer fehlerhaften Anmeldung nicht gestartet werden.
- Der Dienst "Remotedesktopverwaltung" ist vom Dienst "Interne Windows-Datenbank" abhängig, der aufgrund folgenden Fehlers nicht gestartet wurde:
Der Dienst konnte wegen einer fehlerhaften Anmeldung nicht gestartet werden.
- Der Dienst "Remotedesktopverwaltung" wurde mit dem folgenden dienstspezifischen Fehler beendet:
%%2284126209
Ich habe dann die RDS-Dienste komplett deinstalliert. Bei erneuter Installation lassen sich der RD-Sitzungshost sowie Web Access für Remotedesktop einzeln installieren, der RD-Verbindungsbroker jedoch nicht. Das Problem scheint an den Rechten für die WIndows interne Datenbank zu liegen. Die Funktionsebene des alten DC ist Server 2008r2. Nach dem, was ich im Netz gefunden habe ( https://social.technet.microsoft.com/Forums/de-DE/002b9710-91ab-4062-a94 ... ) , habe ich In der Gruppenrichtlinie der Domaine die Rechte für das Starten als Dienst für Netzwerkdienst, Dienst und Netzwerk vergeben und den neuen DC zu der Windows-Autorisierungsgruppe hinzugefügt. Bisher kein Erfolg.
Kann jemand helfen?
ich habe einen Windows Server 2019 als VM auf einem ESXi 6.7 U2 frisch installiert. Mit dem Assistenten liessen sich anschließend die Remotedesktopdienste ebenfalls problemlos installieren. Nach der Installation der AD DS startete der RD-Verbindungsbroker nicht mehr. Folgende Fehler, die ich meinem Problem zuordne, habe ich im Ereignisprotokoll gefunden:
- Der First Counter-Wert, der dem Registrierungsschlüssel 'HKLM\SYSTEM\CurrentControlSet\Services\MSSQL$MICROSOFT##WID\Performance' zugeordnet ist, kann nicht abgefragt werden. SQL Server-Leistungsindikatoren sind deaktiviert.
- Der Dienst "MSSQL$MICROSOFT##WID" konnte aufgrund des folgenden Fehlers nicht unter NT SERVICE\MSSQL$MICROSOFT##WID mit dem aktuell konfigurierten Kennwort angemeldet werden:
Anmeldungsfehler: Dem Benutzer wurde der angeforderte Anmeldungstyp auf diesem Computer nicht zugeteilt.
- Der Dienst "Interne Windows-Datenbank" wurde aufgrund folgenden Fehlers nicht gestartet:
Der Dienst konnte wegen einer fehlerhaften Anmeldung nicht gestartet werden.
- Der Dienst "Remotedesktopverwaltung" ist vom Dienst "Interne Windows-Datenbank" abhängig, der aufgrund folgenden Fehlers nicht gestartet wurde:
Der Dienst konnte wegen einer fehlerhaften Anmeldung nicht gestartet werden.
- Der Dienst "Remotedesktopverwaltung" wurde mit dem folgenden dienstspezifischen Fehler beendet:
%%2284126209
Ich habe dann die RDS-Dienste komplett deinstalliert. Bei erneuter Installation lassen sich der RD-Sitzungshost sowie Web Access für Remotedesktop einzeln installieren, der RD-Verbindungsbroker jedoch nicht. Das Problem scheint an den Rechten für die WIndows interne Datenbank zu liegen. Die Funktionsebene des alten DC ist Server 2008r2. Nach dem, was ich im Netz gefunden habe ( https://social.technet.microsoft.com/Forums/de-DE/002b9710-91ab-4062-a94 ... ) , habe ich In der Gruppenrichtlinie der Domaine die Rechte für das Starten als Dienst für Netzwerkdienst, Dienst und Netzwerk vergeben und den neuen DC zu der Windows-Autorisierungsgruppe hinzugefügt. Bisher kein Erfolg.
Kann jemand helfen?
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: 497655
Url: https://administrator.de/contentid/497655
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
12 Kommentare
Neuester Kommentar
Moin,
Gruß
cykes
Zitat von @dbox3:
Hallo zusammen,
ich habe einen Windows Server 2019 als VM auf einem ESXi 6.7 U2 frisch installiert. Mit dem Assistenten liessen sich anschließend die Remotedesktopdienste ebenfalls problemlos installieren. Nach der Installation der AD DS startete der RD-Verbindungsbroker nicht mehr. Folgende Fehler, die ich meinem Problem zuordne, habe ich im Ereignisprotokoll gefunden:
Was genau hast Du denn vor? Willst Du einen RDS-Server (aka. "Terminalserver") auf einem DC laufen lassen -> ganz schlechte Idee! Einen RDS-Server sollte man separat betreiben als Member-Server.Hallo zusammen,
ich habe einen Windows Server 2019 als VM auf einem ESXi 6.7 U2 frisch installiert. Mit dem Assistenten liessen sich anschließend die Remotedesktopdienste ebenfalls problemlos installieren. Nach der Installation der AD DS startete der RD-Verbindungsbroker nicht mehr. Folgende Fehler, die ich meinem Problem zuordne, habe ich im Ereignisprotokoll gefunden:
Gruß
cykes
Hallo cykes,
Ich weiss, das es nicht empfohlen wird. Aber für meine Umgebung mit wenigen Zugriffen lohnt es sich nicht, einen separaten TS parallel zum DC zu betreiben. Zumal ich bereits einen Exchange als Nicht-DC habe und nicht für jede Rolle einen Extra-Server möchte. Das Szenario müsste aber gehen, auch wenn nicht optimal. Die Frage ist, warum lässt sich der Broker nicht installieren.
Gruß
dbox3
Ich weiss, das es nicht empfohlen wird. Aber für meine Umgebung mit wenigen Zugriffen lohnt es sich nicht, einen separaten TS parallel zum DC zu betreiben. Zumal ich bereits einen Exchange als Nicht-DC habe und nicht für jede Rolle einen Extra-Server möchte. Das Szenario müsste aber gehen, auch wenn nicht optimal. Die Frage ist, warum lässt sich der Broker nicht installieren.
Gruß
dbox3
Du willst doch aber den RDS-Usern bestimmt auch noch weitere Programme zur Verfügung stellen, die ggf. auch nicht auf einem DC laufen sollten. Außerdem gibst Du natürlich "normalen" Benutzern Zugriff auf den AD, was sicherheitstechnisch zumindest äußerst fragwürdig ist. Wenn da nur ein RDS-Nutzer mal einen Trojaner öffnet, macht der im Nullkommanix auch Deinen DC platt.
Ansonsten mal folgendes durchlesen: https://support.microsoft.com/en-gb/help/2833839/guidelines-for-installi ...
oder das: https://www.wintips.org/how-to-install-remote-desktop-services-terminal- ...
Den Broker wirst Du wohl auf einem DC nicht installiert bekommen.
Außerdem hast Du die Installationsreihenfolge bereits initial nicht eingehalten:
- zuerst AD DS und zum DC promoten
- dann RDS Rolle installieren/konfigurieren
Ansonsten mal folgendes durchlesen: https://support.microsoft.com/en-gb/help/2833839/guidelines-for-installi ...
oder das: https://www.wintips.org/how-to-install-remote-desktop-services-terminal- ...
Den Broker wirst Du wohl auf einem DC nicht installiert bekommen.
Außerdem hast Du die Installationsreihenfolge bereits initial nicht eingehalten:
- zuerst AD DS und zum DC promoten
- dann RDS Rolle installieren/konfigurieren
Ich weiss, das es nicht empfohlen wird. Aber für meine Umgebung mit wenigen Zugriffen lohnt es sich nicht, einen separaten TS parallel zum DC zu betreiben.
Doch
Zumal ich bereits einen Exchange als Nicht-DC habe
das ist auch gut so
und nicht für jede Rolle einen Extra-Server möchte.
Dann musst du wohl mit Problemen (s.o) rechnen, gut so.
Das Szenario müsste aber gehen,
müssen tut es nicht.
auch wenn nicht optimal.
gar nicht
Die Frage ist, warum lässt sich der Broker nicht installieren.
weil es eben nicht so ist, dass das "müsste".
Nebenbei, für manche sind 3 Benutzer wenige, für manche 30, kommt immer auf die Relation an.
So viel dazu, wenn du es jetzt nicht ordentlich machst, fliegst du in absehbarer Zeit sowieso darüber, nicht ohne Grund darf/soll/muss ich derzeit so viele Netze fixen, direkt von Anfang an ordentlich gemacht erspart einem (und der Firma) viel Geld und Arbeit.
Viele Grüße,
Christian
certifiedit.net
Es mag alles stimmen und gegen best practices verstoßen. Tatsache ist, das System läuft in gleicher Weise auf einem Win2008r2 seit 12 Jahren ohne größere Probleme. Ich werde euren Ratschlägen sicher folgen und noch eine VM mit 2. Server 2019 als DC aufsetzen. Die Frage ist damit jedoch nicht beantwortet: warum lässt sich der Verbindungsbroker nicht installieren? Auch wenn es nicht empfohlen wird, müsste es doch gehen. oder nicht!?
Auch wenn es nicht empfohlen wird, müsste es doch gehen. oder nicht!?
Wenn 2012R2 gleich 2019 wäre, warum solltest du es neu installieren. Nein MS blockiert das aus gutem Grund inzwischen, weil viele eben damit Probleme hatten (mit gutem Grund).
Der Support für Win2008r2 läuft im kommenden Jahr aus, sonst würde ich mir nicht die Mühe machen. Aber OK. Schließlich, wenn ich es richtig verstanden habe, ist ein Verbindungsbroker bei einem Server nicht zwingend erforderlich. Oder? Danke für die Tipps.
Naja, die Frage wäre außerdem, wofür Du den Connection Broker überhaupt brauchst in Deiner (Zitat) "kleinen Umgebung mit wenigen Zugriffen".
Der wird eigentlich nur bei RDS-Farmen zum Loadbalancing - das brauchst Du ja bei "wenigen Zugriffen" nicht wirklich. Außerdem liegen zwischen 2008 R2 und 2019 Welten. Und auch schon bei 2008 R2 war es empfohlen, den Broker auf einer separaten Maschine laufen zu lassen.
Außerdem genügt auch ein Broker pro Umgebung, wenn diese ordentlich konfiguriert ist.
Was mich mal interessieren würde: Bastelst Du da an Produktivsystemen Deines Arbeitgebers herum, bist Du dein eigener Chef oder ist das eine Testumgebung (was sich eher nicht so anhört)? Im ersten Fall würde ich mir SEHR GUT überlegen, ob ich die Verantwortung dafür übernehmen kann/will. Bei Trial & Error bis es kracht gibt es ganz schnell richtigen und kostenintensiven Ärger.
Da Du ja auch demnächst das AD migrieren willst, lies Dir die Schritte besser vorher durch und leg nicht einfach los bis Du auf die ersten Fehler läufst. Hier kannst Du mal die Schritte ordentlich aufgelistet von em-pie nachlesen: Active Directory Migration 2008 R2 auf 2019
Das ist keinesfalls etwas, was man mal nebenbei beim Sonntagskaffee macht und will auch in einer kleineren Umgebung ordentlich geplant sein.
Wenn Du Dir einmal das AD ordentlich vermurkst hast, kannst Du das nicht mehr so einfach wieder geradebiegen.
Der wird eigentlich nur bei RDS-Farmen zum Loadbalancing - das brauchst Du ja bei "wenigen Zugriffen" nicht wirklich. Außerdem liegen zwischen 2008 R2 und 2019 Welten. Und auch schon bei 2008 R2 war es empfohlen, den Broker auf einer separaten Maschine laufen zu lassen.
Außerdem genügt auch ein Broker pro Umgebung, wenn diese ordentlich konfiguriert ist.
Was mich mal interessieren würde: Bastelst Du da an Produktivsystemen Deines Arbeitgebers herum, bist Du dein eigener Chef oder ist das eine Testumgebung (was sich eher nicht so anhört)? Im ersten Fall würde ich mir SEHR GUT überlegen, ob ich die Verantwortung dafür übernehmen kann/will. Bei Trial & Error bis es kracht gibt es ganz schnell richtigen und kostenintensiven Ärger.
Da Du ja auch demnächst das AD migrieren willst, lies Dir die Schritte besser vorher durch und leg nicht einfach los bis Du auf die ersten Fehler läufst. Hier kannst Du mal die Schritte ordentlich aufgelistet von em-pie nachlesen: Active Directory Migration 2008 R2 auf 2019
Das ist keinesfalls etwas, was man mal nebenbei beim Sonntagskaffee macht und will auch in einer kleineren Umgebung ordentlich geplant sein.
Wenn Du Dir einmal das AD ordentlich vermurkst hast, kannst Du das nicht mehr so einfach wieder geradebiegen.
Ich bin mein eigener Chef und will tatsächlich auf den neuen Server umziehen. Bis der Umzug perfekt ist, ist der alte Server ja da. Den Broker brauche ich tatsächlich nicht. Das Problem bei der Installation hat nur einfach gestört und ich war mir nicht sicher, ob dahinter andere Probleme stecken könnten. Wenn es von MS einfach nicht supportet wird, ist das Ganze nicht so schlimm. Danke aber für die Hilfe.
Gruß
dbox3
Gruß
dbox3
Und wie viele Benutzer hängen dahinter?
Das sind 15 Benutzer. Eine Erweiterung um weitere 5-10 ist geplant.
OK, bei einer kleinen Umgebung dachte ich nun an 3-5 Mann, aber so wie ich oben sagte, ist alles relativ, hier macht ggf. bereits ein zweiter RDS Sinn. Ich würde dir raten, such dir hierfür einen kompetenten Partner, wenn du willst können wir uns auch gerne mal über das Projekt (und ggf die anschliessenden Themen IT-Sec und Co) unterhalten.
Viele Grüße,
Christian
certifiedit.net
Viele Grüße,
Christian
certifiedit.net
