MS14-025 - Das Ende der gespeicherten Passwörter

Gruppenrichtlinien bieten die Möglichkeit Passwörter für gewisse Aufgaben zu setzen.

Hierbei handelt es sich um folgende Gruppenrichtlinieneinstellungen
(Group Policy Preferences):

•     Laufwerkzuordnungen

•     Lokale Benutzer und Gruppen

•     Geplante Aufgaben

•     Dienste

•     Datenquellen 

XML als Basis
Group Policy Preferences basieren auf XML Dateien.
Passwörter die für die oben genannten Einstellungen gespeichert werden, werden im SYSVOL innerhalb der betreffenden XML Dateien in einem Attribut gespeichert. Hierbei handelt es sich um das Attribut "cPassword".
Das Passwort wird nicht im Klartext in die XML Datei geschrieben. 
Das Passwort ist mittels 32-Byte AES verschlüsselt.
Diese Verschlüsselung ist relativ schwach.

Das zusätzliche Problem: 
Der Schlüssel wurde veröffentlicht und ist somit frei zugänglich.

Speichert man mittels GPP ein Passwort im SYSVOL, so wird ein Warnhinweis angezeigt.

Im Übrigen wird diese Meldung unter Windows 8 / 8.1 nicht in die jeweilige Sprache übersetzt und ist folglich immer Englisch :-)

Passwörter per GPP vermeiden
Da standardmäßig alle "Authentifizierten Benutzer" Lesezugriff auf diese Dateien haben, stellt dies also ein großes Sicherheitsrisiko dar.

MS14-025 - Microsoft reagiert
Microsoft hat nun auf diese Sicherheitslücke reagiert und ein Sicherheitsbulletin veröffentlicht. 

Eine ausführliche Beschreibung von Microsoft und weiterführende Downloadlinks findet ihr hier:

http://support.microsoft.com/kb/2962486/de

GPP Password Finder
Mit diesem Update wird einem zwar die Möglichkeit genommen, zukünftig Passwörter per GPPs zu setzen, jedoch bleiben die bestehenden Passwörter unberührt.

Policies die ein cPassword Attribut enthalten könnt ihr mittels PowerShell ermitteln. Zusätzlich habt ihr die Möglichkeit meinen "GPP Password Finder" zu verwenden. Dieser basiert nicht auf PowerShell.

https://onedrive.live.com/redir?resid=62A6D19FFDA7F555%21172

Das Programm benutzt ihr natürlich auf eure eigene Verantwortung.

Weiterführende Links
Zwei sehr gute Artikel findet ihr bei MVP Alan Burchill.


http://www.grouppolicy.biz/2014/05/remove-cpassword-values-active-directory/

http://www.grouppolicy.biz/2013/11/why-passwords-in-group-policy-preference-are-very-bad/

Internet Explorer Content Advisor wird für alle Benutzer übernommen

Zugriff auf Internet-Seiten beschränken
Der Zugriff auf Webseiten im Internet sollte immer an einem Proxyserver bzw. Firewall beschränkt werden. 

Wird der Zugriff am Proxy / an der Firewall eingeschränkt, so ergeben sich folgende Vorteile:

• Diese Lösung ist unabhängig vom verwendeten Browser
• Diese Einstellungen werden zentral am Proxy gesetzt 
• Die Einschränkungen können nicht durch das Ändern von Clienteinstellungen umgangen werden

Internetzugriff komplett sperren
Hier kursieren diverse GPO-basierende Lösungen.
Die Idee vieler Admins: Einen Proxyserver setzen der nicht existiert und dem Benutzer die Möglichkeit entziehen diesen Eintrag zu ändern.

Hier enstehen ebenfalls Probleme:

• Diese Lösung ist nicht unabhänig vom verwendeten Browser
• Dienste die auf einen Proxyserver angewiesen sind (z.B. Windows-Update Dienst der die Updates direkt von Microsoft laden soll) sind ebenfalls von dieser Einschränkung betroffen
• Ein erfahrener Benutzer kann diese Einstellung umgehen

Intranet- und Internetzugriff einschränken
Der Benutzer soll auf eine definierte Whitelist von Intra- und Internetseiten zugreifen können. 

Hier scheitern viele Proxylösungen. Die meisten Produkte können nur den Internetzugriff beschränken.

Eine Lösung auf Clientbasis bietet sich an.

Der Internet Explorer bringt eine solche Lösung bereits mit:
Den Content Advisor

Diese Funktion lässt sich über Gruppenrichtlinen steuern.
Die CSE Internet Explorer Wartung kann diese Einstellungen setzen.
Die gilt allerdings nur bis einschließlich IE 9.

Sollen diese Einstellungen für alle Benutzer des Clients/Servers gelten, so werden diese übernommen.

Definiert man jedoch eine Policy, die nur von gewissen Benutzern (bzw. Benutzergruppen) übernommen werden soll, so wirkt sich diese auch auf alle anderen Benutzer aus.

Beispiel:

• Am Terminalserver "RDS01" soll eine Benutzergruppe "KIOSK-USERS" auf eine Whitelist von Webseiten eingegrenzt werden
• Die Einstellungen werden per Internet Explorer Wartung in einer Policy gesetzt
• Die Policy wird nur von der Gruppe "KIOSK-USERS" übernommen
• Alle anderen Benutzer erhalten keine IEM (Internet Explorer Maintenance) Einstellungen

ACHTUNG:
In diesem Falle gelten die Einstellungen für alle Benutzer.

Über die Frage ob es sich hier um einen Bug handelt oder ein gewolltes Design,
lässt sich streiten.

Stellt man diese Einstellung manuell am Server als Administrator in eurem IE ein, so gelten diese auch für alle Benutzer des Clients/Servers.

Computerkonten auf allen DCs löschen

Einige Umstände machen es nötig, dass ein Client erneut in die Domäne aufgenommen werden muss. Wird zum Beispiel ein Image / Snapshot einer VM zurückgespielt, so stimmt das lokal gespeicherte Computerkennwort nicht mehr mit dem im Active Directory gespeichertem Kennwort überein.

In der Regel reicht es aus, das Computerkonto beizubehalten und nur den "Domain Join" aufzufrischen. 

Domäne raus / rein 
Der Rechner kann zunächst in eine Arbeitsgruppe aufgenommen werden:

Nach einem Reboot kann er dann wieder in die Domäne aufgenommen werden.

Ohne in die Workgroup zu wechseln 
Wer sich an dieser Stelle den Übergang in die Workgroup sparen will, der kann wie folgt vorgehen:

Wir ändern einfach den FQDN der Domäne ("my.domain") in den Netbios-Namen der Domäne "DOMAIN". Das akzeptiert die GUI als Änderung und lässt uns
damit das AD Konto auffrischen. Danach ist ein Neustart erforderlich.

Der Rechner kann natürlich auch mittels PowerShell (Add-Computer) oder netdom der Domäne hinzugefügt werden.


Computerkonto löschen? 
In einigen Fällen ist es jedoch nötig auch das Computerkonto zu löschen.
Die ist zum Beispiel der Fall, wenn ein Client umbenannt werden soll, es aber das Konto (bzw. den Hostnamen) des Clients bereits gibt.
An dieser Stelle sollte man das AD Konto löschen.

Löscht man das Computerkonto, sollte man die vollständige Replizierung der Domain Controller abwarten. Windows hat die Eigenschaft beim Domain-Join
verschiedene DCs nach einem bereits vorhandenen Konto zu durchsuchen.
Hierbei spielt die AD-Sitezuordnung keine Rolle.

Hier ein Beispiel:

Wird haben zwei DCs am Hauptstandort. DC-MAIN01, DC-MAIN02
Zusätzlich gibt es einen DC in einem Außenbüro. DC-SITE01

Das Computerkonto wird auf DC-MAIN01 gelöscht. DC-MAIN02 repliziert relativ schnell diese Änderung. Bei DC-SITE01 dauert dies jedoch länger (abhängig davon wie die Inter-Site Replikationspläne im AD gesetzt wurden).

Versucht man direkt nach dem Löschen des Computerkontos den Client wieder in die Domain aufzunehmen, dann ist die Wahrscheinlichkeit groß, dass dieser auf DC-SITE01 das noch vorhandene Konto findet und verwendet.

Der Client funktioniert erst einmal wie gewohnt. Repliziert jedoch nun irgendwann DC-SITE01 mit DC-MAIN01 oder 02, so wird das Konto gelöscht.
Egal ob dieses noch einmal geändert wurde oder nicht.


Abwarten? 
Man könnte nun natürlich einfach abwarten, bis die Löschung repliziert wurde. 
Im Zweifelsfalle dauert dies jedoch zu lange.
In kleineren Umgebungen können wir auch die Replizierung manuell erzwingen.
Dazu könnt ihr dieses PowerShell Skript verwenden:

repadmin /viewlist * | Foreach-Object `
{
  If($_)
  {
    $StrDCName = ([regex]::match($_,"(?<=DSA_LIST\[\d?\]\s\=\s).+").value)
    Write-Host "Processing "$StrDCName -for Green
    repadmin /kcc $StrDCName 
    repadmin /syncall /A /e $StrDCName 
  }
}

Hierbei werden euch alle Inter-Site Replikationen angestoßen.

Bei größeren Umgebungen ist dies jedoch zu träge und dauert ebenfalls zu lange.


Computerkonten sofort löschen 
Die einfachste Methode ist ein Skript, das die Computerkonten auf allen DCs sofort löscht.

cls
@echo off

IF NOT EXIST "%windir%\system32\dsquery.exe" (
    echo.
    echo Program will end. dsquery.exe not found
    echo.
    pause
    exit
)


set /P PC=Please enter the Computername you want to delete:
for /f "delims=" %%A in ('dsquery computer -name %PC%') do set "DN=%%A"

echo.%DN%|findstr /C:"CN=" >nul 2>&1
if errorlevel 1 (
    cls
    echo.
    echo Program will end. No Computer found in Active Directory.
    echo.
    pause
    exit
)

cls
echo.
echo dsrm %DN% -s DCNAME -noprompt
echo.
set /P c=Do you want to run the command above [Y/N]?
if /I "%c%" EQU "Y" goto choice
if /I "%c%" EQU "J" goto choice
exit

:choice
cls
echo.
for /F %%i IN ('dsquery Server -o rdn -Forest') DO (
echo.
echo Trying to delete account on %%i
dsrm %DN% -s %%i -noprompt
echo.
)
pause

Hierbei handelt es sich um ein reguläres Batch-Skript.
Auf dem Client auf dem das Skript ausgeführt wird, müssen jedoch die AD-Commandline Tools installiert sein. Installiert man mittels RSAT das Snapin "Active Directory Users and Computers", so werden diese auf dem Client per Default mit installiert. 

Nachdem ihr das Skript ausgeführt habt, wird das Konto auf allen erreichbaren DCs gelöscht und ihr könnt den Rechner ohne Probleme in die Domäne aufnehmen.

An dieser Stelle sei gesagt, alle Skripte führt ihr wie immer auf eigene Verantwortung aus.

Group Policy Caching - sinnvoll oder sinnlos?

Microsoft hat unter Windows 8.1 (bzw. Server 2012 R2) eine neue Funktion eingeführt die sich "Policy Caching" nennt.

Microsoft selbst ist jedoch relativ schweigsam wie Group Policy Caching funktioniert und wann es Verwendung findet.

Siehe TechNet:
http://technet.microsoft.com/en-us/library/dn265973.aspx#BKMK_gpresults

Was ist Group Policy Caching?
GPC (Group Policy Caching) ist ein lokaler Zwischenspeicher im Verzeichnis "C:\Windows\system32\grouppolicy\DataStore".

Dieser Speicher wird bei jedem Group Policy Refresh aktualisiert.
Es handelt sich dabei mehr oder weniger um eine Kopie der im SYSVOL befindlichen Daten. Der nächste Policy Zyklus (beim Starten oder Login) verwendet dann evtl. (später mehr dazu) diesen Cache um die Abarbeitungszeit der Richtlinien zu verringern.

Eine Sache ist hier entscheidend:
Der Group Policy Cache ist nur bei der synchronen Richtlinienverarbeitung aktiv!

Den Unterschied zwischen synchroner und asynchroner Richtlinenverarbeitung findet ihr in meinem Blogeintrag "Der große Group Policy Troubleshooting Guide - Teil 3/3 "

Wann wird Group Policy Caching wirklich verwendet?
Genau diese Frage zeigt das große Problem des neuen Features GPC.

Unter folgenden Umständen wird GPC nicht verwendet:

1. Die Richtlinienverarbeitung ist asynchron
2. Die Richtlinienverarbeitung ist synchron, jedoch ist die Einstellung "Always wait for network at computer startup and user logon" aktiviert
3. Die Richtlinienverarbeitung ist synchron, jedoch nur weil der User sich das erste Mal an diesem Gerät anmeldet 
4. Group Policy Caching ist deaktiviert
5. Der DC antwortet nicht oder der DC antwortet mit einer Zeitüberschreitung (der Zeitüberschreitungswert wird in der gleichen Policy definiert)

Unter folgenden Umständen wird GPC verwendet:

1. CSEs, die eine synchrone Verarbeitung erfordern, lösen eine synchrone Verarbeitung aus.
   
   Windows 8.1 hat nur noch zwei CSEs die eine synchrone Verarbeitung erfordern:

• Folder Redirection

• Software Installation

Die Wahrscheinlichkeit dass der GPC-Mechanismus überhaupt benutzt wird, ist relativ gering. 

Microsoft macht ebenfalls nicht deutlich, wie das genaue Zusammenspiel zwischen Group Policy Caching und Slow Link Detection funktioniert.

Der offizielle Hilfetext der Richtlinieneinstellung lässt Folgendes vermuten:

• Wird der Cache gelesen, so wird der DC kontaktiert
• Ist diese Antwort außerhalb des Timeouts (bzw. gibt es keine Antwort) so wird die Verarbeitung der Richtlinien abgebrochen und beim nächsten Background-Refresh durchgeführt
• Das Herunterladen in den Cache wird ebenfalls beschränkt, sobald eine langsame Verbindung erkannt wird. Hier werden jedoch nicht die Einstellungen dieser Policy verwendet, sondern die Einstellungen dieser Policy

Leider lässt die unvollständige Microsoft-Dokumentation das genaue Verhalten nur vermuten.

Was sind die Nachteile des Group Policy Caching?

1. Die Abarbeitungszeit der Hintergrundaktualisierung (auch gpupdate, gpupdate /force) ist deutlich höher, da die Policies in den Cache kopiert werden müssen
2. Während der Hintergrundaktualisierung wird durch das Caching sehr häufig auf das SYSVOL-Share der DCs zugegriffen
   (siehe auch http://www.grouppolicy.biz/2013/07/windows-8-1-group-policy-update-performance-changes/)
3. Während des Cachings werden alle Dateien, die sich in diesen Ordner befinden, auf den Client kopiert:
   
   \\domain.intern\sysvol\domain.intern\Policies\{GUID}\Machine 
   
   \\domain.intern\sysvol\domain.intern\Policies\{GUID}\User
   
   Hierbei wird keine Unterscheidung gemacht welche Dateien kopiert werden müssen. Liegen hier aus irgendeinem Grund große Datenmengen, so werden alle Dateien auf den Client kopiert.

Fazit
Der Grundgedanke von GPC ist gut. Jedoch findet es in der Praxis kaum Verwendung. Die vielen Außnahmen deaktivieren in der Praxis GPC.

Das Caching ist gerade im Zusammenhang mit langsamen Netzwerkverbindungen interessant. Allerdings müssen die gesetzten Schwellwerte korrekt sein. Wird ein Schwellwert überschritten, so ist GPC ebenfalls deaktiviert (genauer gesagt wird die ganze Richtlinienverarbeitung abgebrochen).

Führt man häufig manuelle Policy-Refreshs durch, so sollte man überlegen GPC ggf. zu deaktivieren. 

weiterführende Informationen:

http://sdmsoftware.com/group-policy-blog/group-policy/understanding-group-policy-caching-in-windows-8-1/

http://sdmsoftware.com/group-policy-blog/windows-8-1/clarifying-group-policy-caching-in-windows-8-1/

Group Policy Preferences und der Internet Explorer 11

Mit Windows 8.1 und Server 2012 R2 wurde auch eine neue Version der RSAT (Remote Server Administration Tools) bereitgestellt.

Die neue GPMC dieser RSAT stellt einige (wenn auch geringfügige) neue Funktionen bereit. 

Wichtige Änderungen (im Bezug auf GPPs):

• "TCP/IP Printer" Preferences unterstützen nun auch IPv6
• Das IP Address Range Targeting unterstützt nun auch IPv6
• Die "VPN-Verbindung" der Netzwerkoptionen unterstützen nun IPv6

Einigen wird aufgefallen sein, dass trotz neuen RSAT keine Group Policy Preferences für den IE 11 angeboten werden:
 

Wie ich bereits in diesem Post berichtet habe, wird in der erzeugten XML Datei eine Versionsnummer gespeichert. Dieser Eintrag gibt die minimale und maximale Versionsnummer des IE an, für den diese XML Datei gelten soll.

Erzeugt man eine "Internet Explorer 10" Preference, so wird der Eintrag max="99.0.0.0" in die XML Datei geschrieben.

Folglich sind die IE 10 Preferences auch für den IE 11 gültig!
Das bedeutet jedoch nicht, dass automatisch alle neuen Einstellungen des IE 11 in den IE 10 Preferences enthalten sind.

ADMX Settings für den IE 11

Für den IE 11 sind neue Administrative Vorlagen erschienen.
Solltet ihr einen Central Store für eure ADMX Vorlagen verwenden, empfielt es sich diesen ggf. upzudaten. 
Eine gute Anleitung hierfür findet ihr hier:
http://www.gpanswers.com/how-to-make-the-ultimate-admx-central-store/

Hier eine Übersicht der neu hinzugekommen ADMX Settings:
http://www.microsoft.com/en-us/download/details.aspx?id=25250

Jeremy's "Pak for Internet Explorer"

MVP "Jeremy Moskowitz" hat einen "Pak for Internet Explorer" erstellt, der den Internet Explorer 11 unterstützt. Diese Software bietet zusätzliche Features, die mit den regulären Group Policy Preferences nicht realisierbar sind (z.B. das Ausblenden von ganzen IE Konfiguration-Tabs).

Internet Explorer Maintenance
Wie auch schon für den Internet Explorer 10 gilt "Internet Explorer Maintenance is dead". Diese CSE ist (völlig zurecht) ausgestorben und steht auch unter dem IE 11 nicht mehr zur Verfügung. Schaut euch auch bitte den vergangen Post für den IE 10 noch einmal an.

Für den IE 11 gilt also weiterhin, man muss sich die passenden Einstellungen zusammensuchen. In der Regel ergibt dies einen Mix aus:

• Internet Settings - Group Policy Preferences
• IEAK - Internet Explorer Administration Kit
• Registry - Group Policy Preferences
• ADMX Settings für den Internet Explorer
• Ggf. 3rd Party Tools (wie z.B. "PolicyPak")

Update 06.12.2013

Das ADMX Bundle für Windows 8.1 und Server 2012 R2 findet ihr hier:
http://www.microsoft.com/en-US/download/details.aspx?id=41193

DHCP Bereiche mittels Group Policy überwachen

Jeder DHCP-Bereich umfasst eine definierte Anzahl an IP-Adressen. 
Ist dieser Bereich erschöpft, so können keine weiteren Adressen mehr vergeben werden. Das passiert meistens dann, wenn man am wenigsten damit rechnet.
Für den User hat das den unschönen Effekt, dass der Client zwar mit dem Netzwerk verbunden ist, aber aufgrund der fehlenden IP-Adresse nicht mit den anderen Clients / Servern kommunizieren kann.

Das MMC-Snapin
Der Microsoft DHCP-Server notiert dies im DHCP Snapin mit verschiedenen Warnsymbolen. Eine Liste aller Symbole incl. ihrer Bedeutung findet ihr hier:

http://technet.microsoft.com/en-us/library/cc784812%28v=ws.10%29.aspx

Diese Warnsymbole kann man leicht übersehen. Hat man nicht ständig das DHCP-Snapin geöffnet, wird man im Zweifelsfalle nicht sehen, dass ein
DHCP-Bereich erschöpft ist.


Event 1020 - an Ereignisse geknüpfte Aktionen
Zusätzlich zur Snapin Warnung wird im Eventlog ein Eintrag protokolliert.
Dieser Eintrag hat die ID 1020.

Diese Events können ab Windows Vista bzw. Server 2008 abonniert werden. 
Eine ebenfalls neue Methode seit 2008 ist das Verknüpfen von Aktionen mit Events. Verknüpft man die Aktion "E-Mail senden" mit dem Event 1020, wird jedes Mal beim Auslösen dieses Events eine Mail gesendet.

Wir erhalten eine Mail sobald ein Bereich eine gewisse Schwelle an benutzten Adressen überschreitet, wissen jedoch noch nicht um welchen Bereich es sich handelt. Bei einem DHCP-Server mit vielen Bereichen ist diese Information nicht sehr hilfreich.

PowerShell Skript
Die Aktion die an das Event geknüpft ist, kann auch die Ausführung eines Programms / Befehls sein. Wenn das passende Skript vorhanden ist, können umfangreichere Informationen verarbeitet werden.

$eventList = @()
Get-EventLog -LogName System -After (get-date).AddHours(-1) -Source DhcpServer -InstanceId 1020 | where-object  {$_.Message -notlike "*10.110*"}
| foreach-Object {
$row = "" | Select ScopeAddress, Utilization, FreeIPAddresses
$row.ScopeAddress = $_.ReplacementStrings[0]
$row.Utilization= $_.ReplacementStrings[1]
$row.FreeIPAddresses = $_.ReplacementStrings[2]
$eventList += $row
$FoundEvent="True"
}

$messageParameters = @{
Subject = "DHCP Scope Utilisation Report " + $env:COMPUTERNAME + " - $((Get-Date))"
Body = $eventList | Sort Utilization -Descending |
ConvertTo-Html |
Out-String
From = "DHCP-ALERT@domain.com"
To = "dhcp-alert@domain.com"
SmtpServer = "MAILSERVER"
}

if ($FoundEvent -eq "True")
{
    Send-MailMessage @messageParameters -BodyAsHtml
}

Das Skript führt eine Abfrage auf das System Eventlog durch.
Es werden alle Ereignisse mit der ID 1020 der letzten Stunde ausgelesen.
Diese Events werden dann per Mail an die angegebene Adresse gesendet.

Um nach Bedarf Bereiche auszuschließen, habe ich das Skript etwas modifiziert.
Bereiche (bzw. Textpassagen im Detailtext des Events) können in dieser Zeile vom Mailversand ausgeschlossen werden:

where-object  {$_.Message -notlike "*10.110*"}

In diesem Falle werden also alle Events ausgeschlossen, die "10.110" im Detailtext des Events enthalten.
 
Konfiguration per Gruppenrichtlinie verteilen
Wir haben nun gelernt, dass wir Aktionen an Ereignisse binden können.
Wir haben auch das dazugehörige Skript um diese Informationen per E-Mail zu versenden. Diese Lösung muss manuell an jedem DHCP-Server konfiguriert werden. Nun kommt das Thema Gruppenrichlinien ins Spiel.
Mit einer Kombination aus verschiedenen Group Policy Preferences und Item Level Targetings lässt sich diese Lösung ganz schnell und einfach an alle DHCP-Server verteilen.

Hier die Schritte die dafür nötig sind:

1. Schritt - GPO
Eine neue GPO erstellen

2. Schritt - Hilfsvariable
Um nicht ständig die Registry abzufragen, erstellen wir uns eine Hilfsvariable.
In diesem Falle "ISDHCPSERVER".

Damit die Variable nur bei den DHCP-Server auf "TRUE" gesetzt wird, müssen wir ein Item Level Targeting (Zielgruppenadressierung) verwenden. 
In diesem Falle wird der Starttyp des Dienstes "DHCPServer" abgefragt.
Genau genommen ist dies natürlich noch keine Garantie dass auf dem Server ein Adresspool angelegt und aktiviert ist. In der Regel ist dies jedoch der Fall.
Es können natürlich auch andere ILT verwendet werden.

Bei jedem DHCP-Server der diese Kriterien erfüllt, wird also fortan die Variable "ISDHCPSERVER" erstellt und auf "TRUE" gesetzt.
Damit dies wieder rückgängig gemacht wird (falls z.B. die DHCP Rolle deinstalliert wird), müssen wir diese Option noch aktivieren:

3. Schritt - Kopieren des Skripts
Als nächstes müssen wir das Skript auf jeden zutreffenden Server kopieren.
Das lässt sich ebenfalls mittels Group Policy Preferences realisieren.
Wir nutzen also GPP Files.

Hier verwenden wir die Hilfvariable als Targeting.

4. Schritt - Anlegen der geplanten Aufgabe

 

Zusätzlich verwenden wir hier das ILT auf die Variable "ISDHCPSERVER" und aktivieren die Option "Element entfernen, wenn es nicht mehr angewendet wird".

Hier noch der Inhalt der Batchdatei "dhcpreport.bat"

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe Set-ExecutionPolicy RemoteSigned
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe "C:\Batch\dhcpreport.ps1"
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe Set-ExecutionPolicy Restricted

5. Schritt - Einstellen der Warnschwelle 
Per Default wird das Event ab einer Bereichsauslastung von 80 % erzeugt.
Dieser Threshold kann mit einem Registryschlüssel geändert werden.
Auch hier verwenden wir wieder das gleiche ILT und die genannte Option zum Entfernen der Einstellung.

  
Die genannte DHCP Überwachung in Kombination mit GPP funktioniert erst ab Windows Server 2008 R2.

Windows Update: Fehler "0x80072ee2" unter Windows 8 - Dienst reagiert nicht mehr

In Windows 8 gibt es ein Verhalten, dass den Windows Update Dienst (wuauserv) zum Absturz bringen kann.

Für den wuauserv lässt sich ein Proxy-Server konfigurieren.
Standardmäßig ist jedoch kein Proxy für den Dienst gesetzt.

Die wuauserv Proxy-Einstellung:
Die Konfiguration kann mit diesem Befehl angezeigt werden:
 
netsh winhttp show proxy

Im Normalfall erscheint dann diese Config:

 Current WinHTTP proxy settings:

    Direct access (no proxy server).

Sucht ihr online nach Updates, werden die Proxy-Einstellungen des Internet Explorers verwendet.

Wenn ihr einen WSUS-Server konfiguriert habt, wird jedoch die Einstellung die
mittels "netsh winhttp ..." angezeigt wird, verwendet.

Fehler unter Windows 8:
Ist kein Proxy konfiguriert unter Windows 8 und man besitzt jedoch keine direkte Internetverbindung, so kann es passieren, dass die Suche nach Windows Updates nicht abgeschlossen werden kann:

Im Logfile "C:\Windows\WindowsUpdate.log" erscheinen diese Einträge:

2013-09-03    07:58:21:157     900    e30    Misc    WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None>
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: Send request failed, hr:0x80072ee2
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: WinHttp: SendRequestUsingProxy failed for <http://ds.download.windowsupdate.com/w8/2/windowsupdate/redir/wuredir.cab>. error 0x80072ee2
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072ee2
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072ee2
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: Send failed with hr = 80072ee2.
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None>
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: Send request failed, hr:0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: WinHttp: SendRequestUsingProxy failed for <http://ds.download.windowsupdate.com/w8/2/windowsupdate/redir/wuredir.cab>. error 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: DownloadFileInternal failed for http://ds.download.windowsupdate.com/w8/2/windowsupdate/redir/wuredir.cab: error 0x80072ee2
2013-09-03    07:59:24:558     900    e30    Misc    WARNING: Send failed with hr = 80072ee2.

Bei der angegebenen Datei (http://ds.download.windowsupdate.com/w8/2/windowsupdate/redir/wuredir.cab) handelt es sich um ein File, dass für den Windows-Store benötigt wird.

By design:
Nach ca. 8 Wochen Kontakt mit dem Microsoft Support lautet die finale Aussage:
By Design. D.h. "das ist einfach so".
Die Case Nummer hierzu lautet: 113070910573485

Workaround?
Mit der Fehlermeldung im Logfile könnte man sicherlich leben.
Dass jedoch sich teilweise der Windows Update Dienst verabschiedet, ist sehr unschön (und zumdem ein Sicherheitsrisiko).
Um die Funktion des Dienstes zu gewährleisten, gibt es also zwei sinnvolle Lösungen:

1. Einen Proxy-Server mittels "netsh winhttp" konfigurieren und den Download ermöglichen + Eine Proxyausname für den WSUS-Server definieren.
2. Einen Proxy-Server mittels "netsh winhttp" konfigurieren und den Download am Proxy-Server sperren + Eine Proxyausname für den WSUS-Server definieren.

Gesetzt werden kann dieser Proxy mit diesen Befehlen:

netsh winhttp set proxy myproxy:80 "*.domain.intern"

(es kann natürlich auch nur explizit der WSUS-Server ausgeschlossen werden) 

oder

netsh winhttp import proxy source =ie  

Geht das nicht eleganter?
Wir sind ja hier im GPO-Blog. Deshalb lautet die Antwort: Ja :-)

Diese Einstellung wird in einem Registry-Binary gespeichert.
Dieser befindet sich unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections und nennt sich "WinHttpSettings".

Ihr könnt also Group Policy Preferences Registry benutzen um diesen Schlüssel zu setzen:

Jetzt noch eine Zielgruppenadressierung setzen und fertig: