Nicht funktionierender GPO Central Store unter Server 2012 R2

Ich wollte neulich ein paar Windows 10 GPOs setzen und lud dafür die Windows 10 ADMX Dateien von Microsoft (https://www.microsoft.com/de-DE/download/details.aspx?id=48257) runter.

Seltsamerweise war das nun keine ZIP-Datei mehr, sondern eine Installation mit EULA usw. Das ganze installierte sich dann nach C:\Program Files (x86)\Microsoft Group Policy\ und ich musste die Dateien manuell in den Central Store unter \\FQDN\SYSVOL\FQDN\Policies\PolicyDefinitions\ verschieben. Microsoft, ey.

Seltsamerweise waren die frisch in den Central Store kopierten ADMX-Vorlagen nicht sichtbar. In der Gruppenrichtlinien-Verwaltung bzw. in Gpedit war lediglich von „Vom lokalen Computer abgerufene Richtliniendefinitionen“ die Rede. Hmpf.

Der Fehler tratt auf allen DCs in der Domäne auf, es konnte also leider nicht am DC liegen.
Kopierte ich die Dateien in den lokalen Store der ADMX-Dateien unter %Systemroot%\PolicyDefinitions waren sie in Gpedit sichtbar, was jedoch keine wirklich Lösung des Problem war. Microsoft, ey.

Ich recherchierte1 ein wenig, löschte zwischendurch den kompletten Inhalt von PolicyDefinitions unterhalb des FQDNs doch es halt irgendwie nichts. Gpedit griff auf allen DCs immer nur auf den lokalen ADMX Store zu.

Als letzte Verzweifelungstat hatte ich die Idee, den Central Store komplett neu anzulegen, also nicht nur den Inhalt von PolicyDefinitions zu löschen, sondern den gesamten Ordner. Da der Central Store zunächst nicht zum Standard eines DCs gehört, gilt folgende Anleitung seit Microsoft Windows Server 2008 von Microsoft: https://support.microsoft.com/en-us/kb/929841.

Das ganze brachte den ersehnten Erfolg. Alle DCs fanden nun den Central Store. Was auch immer da los war. Microsoft, ey.

1 googelte mich zu Tode

Datenträgerbereinigung ohne Desktopdarstellungs-Feature unter Server 2008 R2

Da auf Nicht-Terminalservern das Feature der Destopdarstellung eigentlich nichts zu suchen hat, die Server aber trotzdem (hoffentlich) Updates bekommen, ist hin un wieder eine Bereinigung durch die Datenträgerbereinigung nötig.

Um die Datenträgerbereinigung ohne Desktopdarstellungs-Feature unter Server 2008 R2 nutzen zu können, müssen nur zwei Dateien an einen anderen Ort kopiert werden.

C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.1.7600.16385_none_c9392808773cd7da\cleanmgr.exe
muss nach
c:\windows\system32\

und

C:\Windows\winsxs\x86_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.1.7600.16385_de-de_b4bbf0180b1c4f68\cleanmgr.exe.mui

muss nach
c:\windows\system32\de-de\

Nun kann man ganz normal die cleanmgr.exe über „Ausführen“ öffnen. Yay.

Lieblingstweets 2016-03

Endlich wieder Lieblingstweets und kein Technikkrempel. Hurra.

Server 2008 R2 Terminalserver Standarddrucker und die mysteriöse Event-ID 1530

Hallo Fans,

Ich hatte vor Wochen bei einem Kunden das Problem, dass sich die verbundenen Standard-Drucker von verschiedenen (aber natürlich nicht allen) Benutzern mit Terminalserver-Profil nach Ab- und Wiederanmeldung auf den lokalen Standard-Drucker des Servers änderten.

Ca. 20% der betroffenen Benutzer meldeten zusätzlich, dass zuvor installierte Drucker nicht reproduzierbar nach Ab- und Wiederanmeldung verschwunden waren.

Im Anwendungs-Eventlog wurde parallel dazu bei der Abmeldung eines betroffenen Users die Warnung mit ID 1530 protokolliert:

Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß.

DETAIL –
1 user registry handles leaked from \Registry\User\S-FAKE-USER-SID:
Process 564 (\Device\HarddiskVolume2\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-FAKE-USER-SID\Printers\DevModePerUser

Irgendwas verhinderte also das korrekte Zurückschreiben von HKEY_CURRENT_USER in HKEY_USERS, sodass bei der nächsten Anmeldung des Benutzer falsche Werte aus HKEY_USERS geladen wurden.
Die Einstellungen unterhalb von HKCU\Software\Printers\ und HKCU\Software\Microsoft\Windows NT\CurrentVersion\, in denen die User-Druckereinstellungen gespeichert sind, sahen jedoch in einem Vorher-Nachher-Vergleich vollkommen identisch aus.

Jedoch fiel auf, dass zum Teil seit mehreren Jahren außer Betrieb genommene Drucker laut Registry immer noch verbunden sein sollten.

Die manuelle Bereinigung durch Löschung aller Einträge unterhalb der folgenden Schlüssel (falls vorhanden) brachte schließlich den Erfolg:

– HKCU\Printers\Connections
– HKCU\Printers\DevModes2
– HKCU\Printers\DevModePerUser
– HKCU\Printers\Settings

– HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Devices
– HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PrinterPorts
– HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
– HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Devices

Anschließend musste eine noch eine Abmeldung des Users vom Terminalserver erfolgen.
Nach erneuter Anmeldung war nun kein freigegebener Drucker mehr installiert, da alle korrekt aus der Registry gelöscht worden waren.
Zuletzt konnten die freigegebeben Drucker erneut installiert und dieses Mal auch nach Ab- und Wiederanmeldung des Benutzers genutzt werden. Hurra.

CPU-Takt unter Server 2012 R2 mit installierter Hyper-V-Rolle

Vor einiger Zeit fiel mir auf, dass sich die AMD Turion CPU meines baremetal Domainencontroller laut Taskmanager nicht mehr runtertaktete. Ich konnte mich jedoch defintiv daran erinnern, dass sie das in der Vergangenheit getan hatte. In der Zwischenzeit hatte ich eigentlich „nur“ Veeam und die Hyper-V-Rolle installiert, also musste es irgendwie damit zusammenhängen.

Auch mein Hyper-V-Host zeigte dieses Phänomän und so langsam glaubte ich daran, dass das CPU-Throttling durch die Installation der Hyper-V-Rolle deaktiviert wurde und bekam ob des astronomischen Stromverbrauchs ein klitzekleines bisschen Panik.

Beruhigen konnte mich erst CPU-Z, was mir dann den korrekten CPU-Takt anzeigte:

cpu_z_vs_taskmanager_cpu_clock_hyper_v

Also alles halb so wild. Es handelt sich offenbar um einen Bug in Server 2012 R2 in Kombination mit der Hyper-V-Rolle. Mal sehen, was Server 2016 in den nächsten Monaten mit sich bringt.

Integrierten AdBlocker ab IE9 über GPO aktivieren und konfigurieren

Um einen Kunden vor drive-by Crypto-Locker-Infektionen (wie hier bei heise.de beschrieben) zu schützen, beschäftigte ich mich neulich mit dem integrierten AdBlocker im Internet Explorer ab Version 9.

Der IE bringt dafür die Funktion des Tracking-Schutzes im Menü unter Extras -> Tracking-Schutz mit. Dabei handelt es sich um einen (sehr simplen) AdBlocker, der anhand von TPLs (Tracking Protection List, die eigentlich nur mit dem IE kompatible AdBlock Listen sind) Werbung blockt, wie es auch Add-ons wie AdBlock Plus oder uBlock tun.

Microsoft selbst bietet unter https://www.microsoft.com/de-de/iegallery verschiedene Listen an, die über einen simplen Klick installiert und aktiviert werden können. Interessant war jetzt die Anforderung, dass ganze unternehmensweit auszurollen. Folgende Registry-Schlüssel müssen dafür unter HKCU erstellt werden, damit das ganze funktioniert:

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE
– Name: Filtering Mode
– Type: REG_DWORD
– Value: 0

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: Enabled
– Type: REG_DWORD
– Value: 1

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: Name
– Type: REG_SZ
– Value: EasyList Germany und EasyList

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: Path
– Type: REG_SZ
– Value: %AppDataDir%\Local\Microsoft\Internet Explorer\Tracking Protection\{8C91C7B9-F137-456B-B662-E789A9E86528}.tpl

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: Url
– Type: REG_SZ
– Value: http://easylist-msie.adblockplus.org/easylistgermany+easylist.tpl

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: TTL
– Type: REG_DWORD
– Value: 2

Wichtig ist dabei, dass andere Filterlisten andere URLs und IDs haben, über die sie in der Registry gesteuert werden können.
In meinem Beispiel wird die Easylist + Easylist Germany alle 2 Tage von adblockplus.org heruntergeladen und in AppData des Users unter der listeneigenen ID gespeichert.

Das ganze sollte dann in der GPO ungefähr so aussehen:

TPLinIE

Es gibt (wie es leider fast zu erwarten war) keinerlei weitere Konfigurationsmöglichkeit des Tracking-Schutzes. Keine Ausnahmen, kein manuelles Hinzufügen. Einzig kann der komplette Adblocker über das Menü aktiviert bzw. deaktiviert werden.