Ich versuche, dieGruppenrichtliniePowerShell-Modul zum Bearbeiten und Lesen lokaler Gruppenrichtlinieneinstellungen auf einemeigenständigeWindows 2012R2-Server.
Wenn ich versuche, dieGet-GPOReportCmdlet:
Get-GPOReport -All -ReportType Xml
Ich erhalte die folgende Fehlermeldung:
Get-GPOReport: Der aktuelle Sicherheitskontext ist keiner Active Directory-Domäne oder -Gesamtstruktur zugeordnet. In Zeile:1 char:1
+ Get-GPOReport -ReportType Xml -all
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo: NotSpecified: (:) [Get-GPOReport], ActiveDirectoryOperationException
+ FullyQualifiedErrorId: System.DirectoryServices.ActiveDirectory.ActiveDirectoryOperationException,Microsoft.GroupPolicy.Commands.GetGpoReportCommand
Ich habe auch versucht, meinen Servernamen anzugeben:
Get-GPOReport -ReportType Xml -all -server devserver01
Aber ich bekomme den gleichen Fehler.
Ich bin auf diesem Server angemeldet, Administratorwährend ich diese Befehle ausführe. Ich habe auch die Gruppenrichtlinien-Verwaltungskonsole installiert, die eineVoraussetzung.
Die Fehlermeldung:
Der aktuelle Sicherheitskontext ist keiner Active Directory-Domäne oder -Gesamtstruktur zugeordnet.
Schlägt vor, dass ich als Domänenbenutzer angemeldet sein sollte, aber wie erwähnt handelt es sich hierbei um einen eigenständigen Server, der nicht Teil einer AD-Domäne ist.
Ist es nicht möglich, die Cmdlets des GroupPolicy-Moduls auf einem eigenständigen Server zu verwenden?
Antwort1
Group Policyscheint ein Synonym zu sein Local Security Policyund in der IT sprechen wir oft so. Ähnlich wie Kleenex als Ersatz für ein Taschentuch.
Leider ist es ein wenig daneben. Wenn Microsoft sich darauf bezieht, Group Policy Objectsmeinen sie genau das ... einGruppeEinstellung oder eine Einstellung, die auf eine Gruppe von Objekten angewendet werden könnte.
Wenn Technet also von GPOs spricht, ist damit der Kontext einer Domäne gemeint und nicht eine einzelne lokale Sicherheitsrichtlinie.
LeiderNEINSie können die GPO-Cmdlets nicht auf einem eigenständigen Server verwenden.
Antwort2
Technisch gesehen ist dies nicht richtig. Wenn Sie auf einem WORKGROUP-Computer oder einem Computer in einer nicht vertrauenswürdigen Domäne arbeiten, können Sie die Tools mit dem Befehl runas /netonly ausführen, um die Anmeldeinformationen bereitzustellen.
Sie müssen dann sowohl die Parameter -Server als auch -Domain angeben https://david-homer.blogspot.com/2023/08/activedirectory-powershell-error-get.html