Domainadmin hat keine Rechte für control.exe
Hallo Community,
ich stehe leider schon direkt am Anfang vor einem Problem.
Erst einmal mein Vorhaben:
- Windows Server 2019 Domänen Controller / DNS
- Windows Server 2019 Exchnageserver 2019
Den Domänen Controller habe ich soweit installiert, jedoch
habe ich keine Rechte als Domainadmin den Netzwerkadapter
zu bearbeiten. Als lokaler Admin ebenfalls nicht mehr.
Da dies bei unserem Windows Server 2011 noch ging, ist nun
meine Frage: Ist das normal oder hab ich was falsch gemacht?
Neuinstallation schon 3 mal, jedoch immer das gleiche Ergebnis.
ich stehe leider schon direkt am Anfang vor einem Problem.
Erst einmal mein Vorhaben:
- Windows Server 2019 Domänen Controller / DNS
- Windows Server 2019 Exchnageserver 2019
Den Domänen Controller habe ich soweit installiert, jedoch
habe ich keine Rechte als Domainadmin den Netzwerkadapter
zu bearbeiten. Als lokaler Admin ebenfalls nicht mehr.
Da dies bei unserem Windows Server 2011 noch ging, ist nun
meine Frage: Ist das normal oder hab ich was falsch gemacht?
Neuinstallation schon 3 mal, jedoch immer das gleiche Ergebnis.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 396743
Url: https://administrator.de/forum/domainadmin-hat-keine-rechte-fuer-control-exe-396743.html
Ausgedruckt am: 22.12.2024 um 16:12 Uhr
31 Kommentare
Neuester Kommentar
Zitat von @Spirit-of-Eli:
Der Server 2019 ist total voll mit Bugs.
Ich habe sogar alle Installationen aus meiner Testumgebung geschmissen.
Der Server 2019 ist total voll mit Bugs.
Ich habe sogar alle Installationen aus meiner Testumgebung geschmissen.
Wann hast du denn die letzte Installation vorgenommen? Afaik läuft es seit ca 2 Wochen nun endlich.
Zitat von @certifiedit.net:
Wenn du Unterstützung (Dienstleistung) brauchst, schreib mir gerne eine PN/Mail.
Wenn du Unterstützung (Dienstleistung) brauchst, schreib mir gerne eine PN/Mail.
Moin,
Dein "0 sex 0 sex 0 sex - Ruf mich an!" nervt langsam.
lks
Zitat von @Lochkartenstanzer:
Moin,
Dein "0 sex 0 sex 0 sex - Ruf mich an!" nervt langsam.
lks
Zitat von @certifiedit.net:
Wenn du Unterstützung (Dienstleistung) brauchst, schreib mir gerne eine PN/Mail.
Wenn du Unterstützung (Dienstleistung) brauchst, schreib mir gerne eine PN/Mail.
Moin,
Dein "0 sex 0 sex 0 sex - Ruf mich an!" nervt langsam.
lks
Das ist aber eben die Nachfrage. Nervt dich die Nachfrage nicht auch in einem Administrator-Board?
Übrigens, frohe Weihnacht.
Zitat von @RenWin:
Hallo Community,
ich stehe leider schon direkt am Anfang vor einem Problem.
Erst einmal mein Vorhaben:
- Windows Server 2019 Domänen Controller / DNS
- Windows Server 2019 Exchnageserver 2019
Den Domänen Controller habe ich soweit installiert, jedoch
habe ich keine Rechte als Domainadmin den Netzwerkadapter
zu bearbeiten. Als lokaler Admin ebenfalls nicht mehr.
Da dies bei unserem Windows Server 2011 noch ging, ist nun
meine Frage: Ist das normal oder hab ich was falsch gemacht?
Neuinstallation schon 3 mal, jedoch immer das gleiche Ergebnis.
Hallo Community,
ich stehe leider schon direkt am Anfang vor einem Problem.
Erst einmal mein Vorhaben:
- Windows Server 2019 Domänen Controller / DNS
- Windows Server 2019 Exchnageserver 2019
Den Domänen Controller habe ich soweit installiert, jedoch
habe ich keine Rechte als Domainadmin den Netzwerkadapter
zu bearbeiten. Als lokaler Admin ebenfalls nicht mehr.
Da dies bei unserem Windows Server 2011 noch ging, ist nun
meine Frage: Ist das normal oder hab ich was falsch gemacht?
Neuinstallation schon 3 mal, jedoch immer das gleiche Ergebnis.
Das Problem kann ich im Übrigen bestätigen. Installationsdatum 28.11.2018 - abgesehen von ein paar Tests ist da nichts drauf.
Wenn ich über die Einstellungen gehe und dann auf Netzwerk und Internet und dann auf Ethernet und dann auf "Adapteroptionen ändern" bekomme ich das gleiche Fehlerbild.
Version 1809 - 17763.194
Der Aufruf der Systemsteuerung über das Startmenü geht problemlos.
Gebe ich control.exe ein wird mir zwar das entsprechende Icon angezeigt, aber beim Klick passiert rein gar nichts.
Zitat von @bitnarrator:
Moin, ich kann gleiches bestätigen - frische Testumgebung mit Server2016 als DC und Win10 1809 als Client..
Auch ich habe unter Netzwerkverbindungen keinen Zugriff auf die Adaptereinstellungen... Als Domain-Administrator angemeldet....
Moin, ich kann gleiches bestätigen - frische Testumgebung mit Server2016 als DC und Win10 1809 als Client..
Auch ich habe unter Netzwerkverbindungen keinen Zugriff auf die Adaptereinstellungen... Als Domain-Administrator angemeldet....
Meinst du auf dem Client oder auf dem Server?
Weil uns geht es hier gerade um den Server 2019?!
Also gleiches Phänomen bei Win10 1809?
Guten Tag,
es gibt eine Lösung für den Server 2019.
*Update.... Gilt auch für Server 2016*
Das Problem tritt bei allem auf was über die Einstellungen (Zahnrad) bzw. direkt in die Suche eingegeben wird.
Entweder kommt die o.g. Fehlermeldung oder es passiert gar nichts.
Workaround über CMD funktioniert mit fast allem, aber eben nur mit fast allem
Bei mir hat folgendes geholfen: (Drei Server 2019, neu aufgesetzt, Domain Admin keine Rechte)
Den Editor für lokale Gruppenrichtlinie über CMD mit Administratorrechten öffnen (gpedit.msc) und den folgenden Wert auf Aktiv setzen
Auf den Pfad "Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen" wechseln und dort den Wert für "Benutzerkontosteuerung: Administratorgenehmigungsmodus für das integrierte Administratorkonto" von Nicht definiert auf Aktiviert ändern.
Einmal Abmelden und wieder Anmelden, alles ist gut....
es gibt eine Lösung für den Server 2019.
*Update.... Gilt auch für Server 2016*
Das Problem tritt bei allem auf was über die Einstellungen (Zahnrad) bzw. direkt in die Suche eingegeben wird.
Entweder kommt die o.g. Fehlermeldung oder es passiert gar nichts.
Workaround über CMD funktioniert mit fast allem, aber eben nur mit fast allem
Bei mir hat folgendes geholfen: (Drei Server 2019, neu aufgesetzt, Domain Admin keine Rechte)
Den Editor für lokale Gruppenrichtlinie über CMD mit Administratorrechten öffnen (gpedit.msc) und den folgenden Wert auf Aktiv setzen
Auf den Pfad "Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen" wechseln und dort den Wert für "Benutzerkontosteuerung: Administratorgenehmigungsmodus für das integrierte Administratorkonto" von Nicht definiert auf Aktiviert ändern.
Einmal Abmelden und wieder Anmelden, alles ist gut....
Hallo bhwe-de,
besten Dank für die Lösung. Ich habe das bei meinen Systemen, die dieses Verhalten zeigen, einmal eingestellt und mir sind da noch Sachen aufgefallen.
Durch die Änderungen in der GPO im Bereich der Computerkonfiguration, hat bei mir "nur" neu anmelden nicht gereicht, die Änderungen wurden erst übernommen als ich den Server einmal neu gestartet hatte. Ist das korrekt oder hätte es wirklich durch eine einfache Neuanmeldung schon ziehen müssen?
Auf meinem Fileserver hatte ich in den NTFS Berechtigungen auf den Freigaben plötzlich keinen Adminzugriff mehr, um die NTFS Berechtigungen für die Benutzer setzen zu können. Erst als ich die Vererbung wieder eingeschaltet hatte und der Standard DomänenBenutzer hinterlegt war, wurden mir im Reiter "Sicherheit" als Administrator wieder die "normale" uneingeschränkte Ansicht angezeigt. Vererbung abgeschaltet, DomänenBenutzer und lokale BenutzerGruppe raus geschmissen, schon hatte der Admin keinen Adminzugriff mehr.
GPO Einstellung deaktiviert, erhalte im Eventlog zudem auch nebst control.exe die ID's 1008 und 2003, dass in dem System32 Ordner WMI Leistungsdatenindex relevante DLL's nicht mehr zur Verfügung stehen.
Da ich bei der Einrichtung der Domäne diverse GPO's erstellt und auch die Standard GPO's verändert habe, in nicht gerade wenigen Punkten, vermute ich, dass der "Fehler" oder dieses Verhalten der Adminrechte in einem anderen Punkt der GPO's geregelt wird.
Ich habe leider keinen klaren Anhaltspunkt und wäre daher Dankbar wenn jemand noch eine andere Idee zu dem Verhalten hat.
PS: DomainAdmin Konto an einem Win10 Client angemeldet, nichtmal dieses Konto hat "echte" AdminRechte.
Ich bleibe selber auch an dem Fehler dran, da ich dieses Verhalten in meinen Systemen nicht haben möchte.
Auch wenn es mit anderen Wegen lösbar ist, ist dieses Verhalten halt doch etwas "störend".
Danke an Alle für Tipps und Unterstützung.
VG
FloVie
besten Dank für die Lösung. Ich habe das bei meinen Systemen, die dieses Verhalten zeigen, einmal eingestellt und mir sind da noch Sachen aufgefallen.
Zitat von @bhwe-de:
Auf den Pfad "Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen" wechseln und dort den Wert für "Benutzerkontosteuerung: Administratorgenehmigungsmodus für das integrierte Administratorkonto" von Nicht definiert auf Aktiviert ändern.
Einmal Abmelden und wieder Anmelden, alles ist gut....
Auf den Pfad "Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen" wechseln und dort den Wert für "Benutzerkontosteuerung: Administratorgenehmigungsmodus für das integrierte Administratorkonto" von Nicht definiert auf Aktiviert ändern.
Einmal Abmelden und wieder Anmelden, alles ist gut....
Durch die Änderungen in der GPO im Bereich der Computerkonfiguration, hat bei mir "nur" neu anmelden nicht gereicht, die Änderungen wurden erst übernommen als ich den Server einmal neu gestartet hatte. Ist das korrekt oder hätte es wirklich durch eine einfache Neuanmeldung schon ziehen müssen?
Auf meinem Fileserver hatte ich in den NTFS Berechtigungen auf den Freigaben plötzlich keinen Adminzugriff mehr, um die NTFS Berechtigungen für die Benutzer setzen zu können. Erst als ich die Vererbung wieder eingeschaltet hatte und der Standard DomänenBenutzer hinterlegt war, wurden mir im Reiter "Sicherheit" als Administrator wieder die "normale" uneingeschränkte Ansicht angezeigt. Vererbung abgeschaltet, DomänenBenutzer und lokale BenutzerGruppe raus geschmissen, schon hatte der Admin keinen Adminzugriff mehr.
GPO Einstellung deaktiviert, erhalte im Eventlog zudem auch nebst control.exe die ID's 1008 und 2003, dass in dem System32 Ordner WMI Leistungsdatenindex relevante DLL's nicht mehr zur Verfügung stehen.
Da ich bei der Einrichtung der Domäne diverse GPO's erstellt und auch die Standard GPO's verändert habe, in nicht gerade wenigen Punkten, vermute ich, dass der "Fehler" oder dieses Verhalten der Adminrechte in einem anderen Punkt der GPO's geregelt wird.
Ich habe leider keinen klaren Anhaltspunkt und wäre daher Dankbar wenn jemand noch eine andere Idee zu dem Verhalten hat.
PS: DomainAdmin Konto an einem Win10 Client angemeldet, nichtmal dieses Konto hat "echte" AdminRechte.
Ich bleibe selber auch an dem Fehler dran, da ich dieses Verhalten in meinen Systemen nicht haben möchte.
Auch wenn es mit anderen Wegen lösbar ist, ist dieses Verhalten halt doch etwas "störend".
Danke an Alle für Tipps und Unterstützung.
VG
FloVie
Hallo FloVie,
sorry für die späte Antwort...
In der Tat verursacht diese Einstellung, das nicht mehr für den Domain-Admin im direkten Zugriff zur Verfügung steht was es eigentlich sollte.
Nur der lokale Admin der Maschine hat dann noch die Berechtigungen.
Tatsächlich hat es bei mir geholfen nur eine Neuanmeldung bei den Servern zu machen und alle Berechtigungen waren wieder da.
Wenn du, wie angegeben, natürlich einiges an den GPO gemacht hast kann es auch sein das die Einstellungen der Computerkonfiguration überschrieben wurden.
Man kann natürlich auch über die GPO diese Einstellungen an allen Maschinen ändern, ich denke es ist mit einem Update gekommen aber bei Server 2016/19 scheint es eine Standarteinstellung nach Neuinstallation zu sein.
Ich finde es auch sehr störend und im Grunde ist es ja kein Fehler sondern NUR eine Einstellung. Aber bei MSFT kann einem auch keiner diesbezüglich helfen.
LG
M
sorry für die späte Antwort...
In der Tat verursacht diese Einstellung, das nicht mehr für den Domain-Admin im direkten Zugriff zur Verfügung steht was es eigentlich sollte.
Nur der lokale Admin der Maschine hat dann noch die Berechtigungen.
Tatsächlich hat es bei mir geholfen nur eine Neuanmeldung bei den Servern zu machen und alle Berechtigungen waren wieder da.
Wenn du, wie angegeben, natürlich einiges an den GPO gemacht hast kann es auch sein das die Einstellungen der Computerkonfiguration überschrieben wurden.
Man kann natürlich auch über die GPO diese Einstellungen an allen Maschinen ändern, ich denke es ist mit einem Update gekommen aber bei Server 2016/19 scheint es eine Standarteinstellung nach Neuinstallation zu sein.
Ich finde es auch sehr störend und im Grunde ist es ja kein Fehler sondern NUR eine Einstellung. Aber bei MSFT kann einem auch keiner diesbezüglich helfen.
LG
M
Hallo zusammen,
es müssen knapp 3,5 Jahre rum gehen und man setzt sich einen neuen Server auf, damit man das Problem versteht.
Das hier so beschriebene "Fehlverhalten" ist von MS glaube so gewollt und eine Härtung des Sicherheitskonzeptes.
Ich habe mir in der neuen Domain einen Account erstellt und diesen in die Gruppe "Administratoren" unter "DOMAINNAME\Builtin" gesteckt. Nennen wir diesen Account mal "Admin". Als nächstes habe ich mir einen Account angelegt, nennen wir den mal "DAdmin" und dieser ist Mitglied der Gruppe "Domänen-Admins" in "DOMAINNAME\Users". Das Konto eines lokalen Administrators hat volle Rechte, der Admin hat volle Rechte der DAdmin darf die Control.exe nicht öffnen. Das ist genau das Verhallten was wir festgestellt hatten.
Nutzt man nun den "Admin" aus der Builtin kann ich auf dem FS und dem Printserver alles machen was ich will. Perfekt. Muss ich Änderungen an der Domain vornehmen, nehme ich den DAdmin und selbst wenn der AD-Controller eine andere IP braucht, mache ich das easy mit dem Admin-Account.
Fazit für mich, ich habe nun normale Benutzer, Desktop-Administratoren für die PC's, einen Admin für die Server und einen DAdmin für die Domain. Ergo, ein Account bleibt in einer Admin-Gruppe, das Konzept sieht es nicht vor, dass ein Admin-Account in mehreren Admin-Gruppen ist. Somit muss ich auch keine GPO anlegen und das System läuft äußerst smoooth.... I love it!
Hoffe damit dem ein oder anderen noch helfen zu können.
VG
FloVie
es müssen knapp 3,5 Jahre rum gehen und man setzt sich einen neuen Server auf, damit man das Problem versteht.
Das hier so beschriebene "Fehlverhalten" ist von MS glaube so gewollt und eine Härtung des Sicherheitskonzeptes.
Ich habe mir in der neuen Domain einen Account erstellt und diesen in die Gruppe "Administratoren" unter "DOMAINNAME\Builtin" gesteckt. Nennen wir diesen Account mal "Admin". Als nächstes habe ich mir einen Account angelegt, nennen wir den mal "DAdmin" und dieser ist Mitglied der Gruppe "Domänen-Admins" in "DOMAINNAME\Users". Das Konto eines lokalen Administrators hat volle Rechte, der Admin hat volle Rechte der DAdmin darf die Control.exe nicht öffnen. Das ist genau das Verhallten was wir festgestellt hatten.
Nutzt man nun den "Admin" aus der Builtin kann ich auf dem FS und dem Printserver alles machen was ich will. Perfekt. Muss ich Änderungen an der Domain vornehmen, nehme ich den DAdmin und selbst wenn der AD-Controller eine andere IP braucht, mache ich das easy mit dem Admin-Account.
Fazit für mich, ich habe nun normale Benutzer, Desktop-Administratoren für die PC's, einen Admin für die Server und einen DAdmin für die Domain. Ergo, ein Account bleibt in einer Admin-Gruppe, das Konzept sieht es nicht vor, dass ein Admin-Account in mehreren Admin-Gruppen ist. Somit muss ich auch keine GPO anlegen und das System läuft äußerst smoooth.... I love it!
Hoffe damit dem ein oder anderen noch helfen zu können.
VG
FloVie
Wie gesagt, meine Vermutung ist halt, dass MS das wirklich so beabsichtigt hat. Sobald ich den UserAccount in den Domain-Administrator stecke, darf der Account fast nichts mehr am System ändern. Ist der Account zugehörig zu den Administratoren, geht alles wie es soll. Ich benutze den Domain-Admin nun nur noch für die Domainkonfiguration, alles andere mache ich über ein Konto, welches nur der Gruppe Administratoren zugehörig ist, in der AD als auch per Sicherheitsgruppe auf den Servern. Das hat alle meine Probleme gelöst.
Beste Grüße
FloVie
Beste Grüße
FloVie