Windows 2008/2008R2 DNS Server braucht viel zu viel Speicher

Veröffentlicht am März 19, 2015 von admin — Keine Kommentare ↓

Problem

Der Windows 2008/2008R2 DNS-Server („dns.exe“) konsumiert ohne Ende Speicher. Der Server startet mit 120Mb, wächst auf über 400Mb und erreicht auch gerne über 1Gb RAM. Das ist für mittlere Netzwerke mit ein paar hundert PCs ein bisschen viel.

Lösung

Standardmäßig öffnet der Windows DNS-Server einen Pool von 5000 UDP sockets (2500 IPv4 und 2500 IPv6). Unter Windows Server 2008 R2 werden für jeden Port ~2.5Kb RAM allokiert, plus zusätzliche ~7.2Kb pro Empfanspuffer fällig – und es wird pro CPU ein Buffer erstellt. Auf Maschinen mit mehreren CPUs läpper sicht das schnell ordentlich zusammen:

(2.5kb x 5000 sockets) + (32 cpus/cores x 5000 sockets x 7.2kb ) = (12500kb) + (1152000kb) = 1164500kb = ~ 1.1GB

Sinnvollerweise verringert man also die Anzahl der Sockets:

dnscmd /Config /SocketPoolSize 100

100 ist ein guter Wert (~250PCs). Die aktuelle Anzahl prüft man mit:

dnscmd /Info /SocketPoolSize

Windows 7/8 „Senden an“ Menü anpassen

Veröffentlicht am März 10, 2015 von admin — Keine Kommentare ↓

Um unter Windows die Auswahlmöglichkeiten aus dem „Senden an“ Menü der rechten Maustaste zu bearbeiten, sind nur wenige Handgriffe notwendig:

Ordner %appdata%\Microsoft\Windows\SendTo öffnen
Die gewünschte Verknüpfung erstellen

Mit Start > Ausführen > „shell:sendto“ kommt man da noch schneller hin (thx heiko)

(Verwaiste) Volumenschattenkopien auflisten und sauber löschen

Veröffentlicht am März 2, 2015 von admin — 2 Kommentare ↓

Problem

Auf einem Server können keine neuen Volumenschattenkopie-Jobs angelegt werden („Das Volumen ist bereits vorhanden“), es können keine weiteren Schattenkopien für ein DPM-geschütztes Voume angelegt werden („Die Schattenkopie mit der ID xxxxxxxxxxxxx ist bereits vorhanden“) und/oder bestehende DPM-Jobs starten nach einem Volumenwechsel nicht mehr, weil die bestehenden Jobs auf das „alte“ Volumen zeigen („Es wurde bereits eine Schattenkopie mit der ID xxxxxxxxxxx gefunden“).

Lösung

Zuerst sind die bestehnden verwaisten Schattenkopien zu entfernen, dann das Ziel-Volumen (Shadowcopy-Storage). Es gibt mehrere Möglichkeiten die Einträge der Schattenkopie-Liste eines Systems aufzuräumen.

1) Sofern die orginal-Volumenzuordnung noch existiert, ist es möglich aud der Liste der Schattenkopien die ID der betroffenen Kopie zu extrahieren:

vssadmin list shadows

Aus der ausgegebenen Liste nun einfach die Schattenkopie-ID kopieren und löschen:

vssadmin Delete Shadows /shadow={Schattenkopie-ID}

Zum Beispiel: vssadmin Delete Shadows /shadow={affeaffe-dead-beef-b444-dfafafafafdf}

2) Wenn Vssadmin dabei aber seltsame Fehler ausspuckt, hat die Zuordnung nicht (mehr) richtig funktioniert. Hier hilft es in der Regel, die betroffene Kopie direkt zu entfernen; dazu gibt es ein WMI-Interface für den VSS-WMI-Provider.

C:\>wmic
wmic:root\cli>shadowcopy list

Zeigt die vorhandene Liste an. Einzelne einträge kann man löschen. pro Eintrag erfolgt eine einzelne Abfrage:

C:\>wmic
wmic:root\cli>shadowcopy delete
"\\SERERNAME\ROOT\CIMV2:Win32_ShadowCopy.ID="{Schattenkopie-ID}" löschen (J/N/?)?

ACHTUNG! Obwohl Das Tool nach J/N fragt, wird ein „Y“ zum bestätigen benötigt *seufz*.

Wenn ein ganzes Volumen verwaist ist, zum Beisspiel wenn ein Admin darauf geschützte oder vom DPM als Ziel verwendete Partitionen entfernt, ist uns keine andere Möglichkeit bekannt, als dem Volumen eine neue Seriennummer zu geben. Das geht indem man das betroffene physikalische Array einfach löscht und neu erstellt, oder die Seriennummer einer neu erstellten NTFS-Partition mit „Volume-ID“ aus der Sysinternals-Trickkiste verändert:

C:\>volumeid T: f0000-ba00

ACHTUNG: Danach die Maschine neu starten und NICHT VERSUCHEN eine Schattenkpie anzulegen. Nach dem Neustart sollte das Volumen aus der VSS-Zielliste verschwunden sein. Das ist zu prüfen mit:

C:\>vssadmin list shadowstorage

ActiveDirectory Rechte-Vererbung via Powershell einschalten

Veröffentlicht am Januar 22, 2015 von admin — 2 Kommentare ↓

Problem

Im ActiveDirectory wurde die Vererbung von übergeordneten Rechten für Benutzer oder Computerobjekte ausgeschaltet. Obwohl es bestimmte Szenarien gibt, in denen eine solche Anpassung Sinn ergibt, führt das auslassen der Domänen-Rechtehirachie doch gerne auch zu schwer zu suchenden Fehlern.

Zum Beispiel:

ExchangeSynchronisationsfehler 86000C0A bei betroffenen Benutzern, obwohl OWA korrekt funktioniert
Dateisystems-Auflistung im Explorer schlängt mit 0x86000Cxx Fehlern Fehl
Fehler im Ereignisprotokoll von MSExchange ActiveSync mit dem Inhalt „Active directory Antwort: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0″.“

Das sind noch nicht alle Fehler, es gibt noch einige weitere. Oft auch im Zusammenhang mit BlackBerry Enterprise Servern oder -Services.

Lösung

Wenn nur ein Objekt betroffen ist: Im Benutzerobjekt auf dem Tab Sicherheit unten die „Vererbung aktivieren“ und die folgenden Meldung abnicken.

Für mehrere Objekte hilft ein kurzes PowerShell-Script. Am einfachsten ist die Anwendung, wenn man eine PowerShell ISE als Administrator ausführt (!) und das Script in den oberen Script-Teil einfügt:

Import-Module activedirectory
$OU = "OU=INDIESEROUWERDENUSERGESUCHT,DC=MEINDOMAENE,DC=TLD"
$Users=get-aduser -Filter * -SearchBase $OU
if ($Users -ne $null) {
foreach ($Entry in $Users) {
 [string]$dn = (Get-ADUser $Entry).DistinguishedName
 $user = [ADSI]”LDAP://$dn”
 $acl = $user.objectSecurity
 Write-Host "Pruefe Benutzer:" (Get-ADUser $Entry).SamAccountName
 if ($acl.AreAccessRulesProtected){
 Write-Host "Fixe Benutzer:" (Get-ADUser $Entry).SamAccountName
 $acl.SetAccessRuleProtection($false,$true)
 $inherited = $acl.AreAccessRulesProtected
 $user.commitchanges()
 }
 }
}
else {
Write-Host "Keine Benutzer in $OU gefunden"
}

Referenz: http://support.microsoft.com/kb/2579075 und http://www.techguy.at/active-directory-objekte-mittels-powershell-wiederherstellen/

Fehler 8194 bei Gruppenrichtlinienanwendung „0x8007000d die Daten sind ungültig.“

Veröffentlicht am Januar 7, 2015 von admin — Keine Kommentare ↓

Problem

Eine (oder mehrere) Gruppenrichtlinien werden unter Windows 7 oder Windows Server 2008/2008R2 nicht korrekt angewendet. Stadtdessen erscheint im Ereignisprotokoll folgender Fehler:

Ereignis-ID: 8194 
Beschreibung: Die clientseitige Erweiterung der Gruppenrichlinien konnte die Benutzerrichtlinieneinstellungen für "Domain Name {GUID}" anweden, Fehlercode "0x8007000d die Daten sind ungültig."

Die Richtiline taucht aber in einem GPRESULT fehlerfrei auf und die Richtlinie ist auf allen DC in Sysvol vorhanden.

Lösung

Dieses Problem tritt auf, weil die clientseitigen Erweiterungen der Gruppenrichtlinien verzeweifelt versuchen, die Verlaufsdatei der GPO aus dem lokalen Cache zu laden. Wenn dieser nicht (mehr) valide ist, tritt dieser Fehler auf. In der Theorie wurde das zwar mit KB979731 gefixt, aber zwischen Theorie und Praxis liegt bekanntlich die Realität.

Soforthilfe: Löschen des gesammten Inhaltes des Ordners:

C:\Users\All Users\Microsoft\Group Policy\History

Nach einem gpupdate /force klappt sofort wieder alles.