Bearbeiten von Zusätzliche Registry Einstellungen - edit Extra Registry Settings - Arbeiten ohne GPEditor
Bearbeiten von Zusätzl. Reg.-einst. - edit Extra Registry Settings
Ihr erstellt den Report einer Richtlinie und im HTML tauchen diese "Zusätzl. Reg.-einst." auf, bzw. "Extra Registry Settings". Wo kommt der Fehler her, wie ist er zu beheben und wie komm ich an die genannten Werte ran?
im GPT der Richtlinie (GPT=SYSVOL Speicherort/Datei Komponente) befinden sich die Datei/Angaben, die der Client am Ende bei der Übernahme der Richtlinien importiert und verarbeitet. In diesem Fall unseres Fehlers geht es um den Inhalt der registry.pol Datei.
Beispiel Pfad: \\gallier.ads\SYSVOL\gallier.ads\Policies\{E3BEC060-9E0E-4F32-8C2B-949F9D861FED}\Machine\registry.pol
In der Datei stehen alle Werte, die am Client in HKLM (Computerkonfiguration), bzw. HKCU (Benutzerkonfiguration) des übernehmenden Objekts geschrieben werden. Der größte Teil der Werte wird über den Bereich der Administrativen Vorlagen des GPEditors in die Datei integriert.
Der GPMC Report ist jetzt relativ simple gestrickt. Er versucht alle Inhalte der registry.pol Datei mit einem ihm bekannten ADM/ADMx Template darzustellen und einen schönen sprechenden Namen im Report darzustellen.
An der Einschränkung "der größte Teil" und an dem Fehler selbst kann man erkennen, daß das nicht immer klappt ;-)
Es gibt 2 einfache Erklärungen für diese Art von Fehler im Report.
- Der GPMC fehlen tatsächlich die notwendigen ADM/ADMx Vorlagen zur Darstellung, weil sie zB auf dem Rechner nicht zur Verfügung stehen, sie entfernt wurden, oder bei einem Update ersetzt wurden. Seit Windows 10 die die neuesten keine "All Inklusive Old Settings" Vorlagen mehr. Siehe auch ADMX Version History
- Der GPEditor hat über eine andere Schnittstelle Werte in die registry.pol Datei geschrieben, aber die GPMC versucht es mit einem ADM/ADMx Template darzustellen.
Letzteres ist eine Ausnahme, aber z.B. bei der Konfiguration des Netzwerklisten-Managers der Fall. Kümmern wir uns um den Normalfall.
Wie kann der Fehler beseitigt werden und wie kommen wir wieder an die Werte ran?
1.) Offensichtlich erste Lösung: Verwendet die richtigen ADM/ADMx Templates.
Das ist leicht dahergesagt, aber machmal garnicht so einfach. Bei zusätzlichen Vorlagen für div. Office Produkte oder Google etc. ist es recht einfach. Irgendwann hat man diese Vorlagen vom Hersteller heruntergeladen und verwendet. Man hat es schon mal runtergeladen, das kann man wieder tun. Dann wurde vielleicht das Produkt aktualisiert oder entfernt und damit auch die Vorlagen geändert, getauscht oder gelöscht. Die Werte in der registry.pol bleiben davon unberührt, es fehlt jetzt nur das Template zur Bearbeitung. Template runterladen, in den Store integrieren, Sache erledigt.
2.) Die Werte sind aus einem selbstgeschriebenen ADM, das nicht mehr existiert
Naja, irgendwer hat das ADM geschrieben, das kann er wieder tun, das Template kann erneut integriert werden und dann sind die Werte sowohl im GPEditor als auch im Report der Richtlinie wieder vorhanden.
Oder man nutzt CPM Programmierung - copy & paste & modify ;-)
ADM Templates - Beispiele von gruppenrichtlinien.de
3.) Lösung 1.) und 2.) sind umständlich, geht das einfacher?
Für den Report gibt es keine Alternative zu 1.) und 2.). Ohne Template, keine Anzeigenamen.
Entweder ihr habt ein Template oder ihr lebt mit dem Fehler. Die Richtlinien funktioniert einwandfrei. Es werden genau diese Werte in die Registry des Objekts importiert. Der Fehler ist nur dann ein Problem, wenn ich die Werte verändern möchte, sie gelöscht werden sollen oder eben nicht mehr am Client ankommen sollen.
Die Powershell bietet uns Hilfe, ob das jetzt einfacher ist, ist eine andere Frage :-)
Es gibt die Commandlets Get-GPRegistryValue, Set-GPRegistryValue und Remove-GPRegistryValue. Man könnte meinen, das "Get-" wäre in unserem Fall weniger interessant. Wir sehen ja schon im Report der GPMC den Registry Keyname und Valuename, den wir hinterher in der PoSh ändern möchten. Wir müssen den Wert nicht ermitteln. Aber, wir benötigen bei der Änderung noch eine kleine Information, die der Report nicht bereitstellt: Der Typ des Registry Values ist relevant.
Ist es ein Reg_SZ, Reg_Expand_SZ oder ein Reg_Dword? Über die Powershell lassen sich auch Reg_Multi_SZ und Reg_Binary in das Registry.pol file integrieren, was über ADM/ADMx Vorlagen nicht möglich ist. Zudem müssen wir in den cmdlets den HKLM oder HKCU Part mit angeben, der im Report fehlt, da er schon durch die Überschrift "Benutzerkonfguration", bzw. "Computerkonfiguration" klar definiert ist.
Voraussetzung: Für die Funktion der cmdlets muss die GPMC auf dem System installiert sein, auf dem die Befehle ausgeführt werden sollen. Statt des Namens kann auch die ID der Richtlinien verwendet werden und Leerzeichen werden wir immer in Anführungszeichen maskiert.
Beispiel: Ermitteln des Werts:
PS C:\> Get-GPRegistryValue -name _Edit_ohne_GPEditor -key HKLM\Software\Irgendwas -valuename multi
KeyPath : Software\IrgendwasFullKeyPath : HKEY_LOCAL_MACHINE\Software\IrgendwasHive : LocalMachinePolicyState : SetValue : {1, 2, 3, 4...}Type : MultiStringValueName : multiHasValue : True
Beispiel: Ändern eines Reg_SZ Werts von Yes auf No oder 500 auf 1000 oder Servername1 in Servername2.
PS C:\> Set-GPRegistryValue -name _Edit_ohne_GPEditor -key HKLM\Software\Irgendwas -valuename multi -value Servername2 -type STRING
Der -type kann sein: Unknown, String, ExpandString, Binary, DWord, MultiString, QWord
Beispiel: Löschen eines Eintrags
PS C:\> Remove-GPRegistryValue -name _Edit_ohne_GPEditor -key HKLM\Software\Irgendwas -valuename multi