Aktives Verzeichnis Blog

Backup und Restore von grossen Namespaces

Rol_Muc — Tue, 28 Apr 2015 06:45:18 GMT

Heute gleich nochmal ein Beitrag von Hubert aus unserem Netzwerkteam, nach längerer Zeit mal wieder etwas zum Thema DFS Namespaces. Hallo zusammen, wie ja weithin bekannt ist, sind mit Domain V2 Namespaces die Limits von 5000 Links für Domain Namespaces weggefallen. Wir sehen heutzutage bei unseren Kunden regelmässig Namespaces mit mehreren 10.000 Links und teilweise sogar über 100.000 Links.
Anmerkung: Die maximal empfohlene Grösse liegt bei 50.000 Links
Üblicherweise wird als Backup regelmässig ein dfsutil root export des Namespaces in eine Text- bzw. xml-Datei gespeichert.
Im Falle, dass der Namespace wiederhergestellt werden muss, würde man dann den Namespace wieder anlegen (von Hand oder via dfsutil) und mittels des dfsutil root import Befehls die Links und Namespace Optionen, inklusive eventueller Berechtigungen auf den Links, aus der xml Datei wiederherstellen. Soweit so gut und für kleinere Namespaces bleibt dies auch der Weg der Wahl.
Bei grösseren Namespaces macht sich allerdings eine Eigenschaft des dfsutil imports zunehmend negativ bemerkbar.
dfsutil verwendet die NetDfs Api (https://msdn.microsoft.com/en-us/library/windows/desktop/bb524802(v=vs.85).aspx) und jeder DFS Server unterhält einen Thread innerhalb des DFS Namespace Dienstes, der sich mit der Beantwortung von Requests gegen diese API beschäftigt.
Somit ist ein dfsutil import also single-threaded. Ich komme in meiner (zugegeben nicht representativen) Testumgebung auf ca. 800ms pro Link beim Import mit dfsutil.
Das macht also bei einem 5000 Link Namespace ca. 1 Stunde für den kompletten Import und mag gerade noch im Rahmen liegen.
Bei Namespaces mit 50.000 Links sprechen wir jedoch von 11 Stunden, was für einen Restore komplett inakzeptabel ist. Daher möchte ich euch heute ein Verfahren vorstellen, wie Ihr eure grossen Namespaces sichern und wiederherstellen könnt ohne stundenlang auf einen Import zu warten.
In meiner Testumgebung konnte ich damit einen 70.000 Link Namespace in unter 2 Minuten importieren ;-) Grob gesagt: Per ldifde werden die AD-Objekte der Links samt der für DFS relevanten Attribute direkt aus dem AD in eine Textdatei exportiert.
Bei der Widerherstellung werden die Objekte direkt aus der Textdatei wieder zurück ins AD geschrieben. Befehl fürs Backup:
ldifde -f .ldf -d "cn=,CN=Dfs-Configuration,CN=System,DC=,DC=" -r "(objectclass=msDFS-Linkv2)" -l "msDFS-GenerationGUIDv2,msDFS-NamespaceIdentityGUIDv2,msDFS-LastModifiedv2,msDFS-Ttlv2,msDFS-Propertiesv2,msDFS-TargetListv2,msDFS-LinkPathv2,msDFS-LinkIdentityGUIDv2,msDFS-LinkSecurityDescriptorv2,msDFS-Commentv2,msDFS-ShortNameLinkPathv2,objectclass" Bitte die durch entsprechende Werte ersetzen. Hierdurch werden alle Link Objekte des im DN angegebenen Namespaces mit den für DFS relevanten Attributen in eine .ldf Datei exportiert. Der Namespace Anchor und das Namespace Objekt selber (also die nächst höheren Ebenen) werden nicht exportiert und können somit auch nicht wiederhergestellt werden.
Der Hintergrund ist, dass nach der Löschung eines Namespaces die Wiederherstellung dieser beiden Objekte dazu führt, dass zwar ein Namespace im AD existiert, es jedoch keinen DFS Server gibt der sich für diesen Namespace zuständig fühlt. Daher ist der robustere Ansatz den Namespace über die NetDFS Api (also DFS Management Konsole, dfsutil.exe o.ä.) selber wieder anzulegen.
Hierbei werden dann die beiden Objekte im AD (Namespace und Anchor) angelegt und der ausgewählte DFS Server hostet den Namespace.
In diesen Namespace können wir dann unseren ldifde Import hinein machen. Der empfohlene Ablauf wäre also: 1. Eventuell verbliebene Reste des Namespaces im AD sowie auf den einzelnen DFS Servern löschen.
Siehe hierzu auch: https://support.microsoft.com/en-us/kb/842218/ 2. Anlegen eines neuen Namespaces unter gleichem Namen auf einem der DFS Server (siehe oben) 3. Setzen der relevanten Namespace Optionen. (im Zweifelsfall im dfsutil export nachschlagen) 4. Import der .ldf Backup Datei mit: ldifde -f .ldf –i (bevorzugt auf dem PDC) 5. Hinzufügen der übrigen DFS Server per Script (dfsutil) oder von Hand. Das Verfahren hat natürlich ein paar Rahmenbedingungen die erfüllt sein müssen: - Es muss ein Domain V2 Namespace sein - Er muss in der selben Domäne existiert haben - Vor dem Import der Links müssen das Namespace Anchor und das Namespace Objekt durch angelegen eines neuen Domain V2 Namespaces erzeugt worden sein. - Der neue Namespace muss den selben Namen haben, wie der Namespace im Backup. Weitere Überlegungen: - Da der Import an der DFSApi vorbei direkt ins AD geht, bekommen die, zu diesem Zeitpunkt im Namespace befindlichen, Server von den neuen Links nichts mit.
Daher muss entweder bis zum nächsten stündlichen Update dieser DFS Server gewartet oder der DFS-Dienst bzw. der Server neugestartet werden um ein Update zu forcieren. - Dieses Backup ist kein Ersatz für ein DFSUtil Export der Namespaces und dieser sollte somit parallel weiterhin erfolgen.
Einerseits sind im DFSUtil Export die Namespace Optionen hinterlegt (auch wenn aus diesem Backup der Namespace selber nicht wieder hergestellt werden kann), andererseits ist dies nach wie vor das geeignetste Mittel um kleinere Mengen an Links wiederherzustellen.
Hierzu die übrigen (nicht wiederherzustellenden Links) aus dem Export löschen und mittels dem merge Parameter importieren. - Da weder ein DFSutil Import noch der ldifde Import DFS Server zum Namespace hinzufügen, oder den Namespace selber anlegen können, emphiehlt es sich ein kleines Script bereitzulegen, dass
- Einen neuen Namespace mit gleichem Namen und gleichen Namespace Optionen anlegt.
- Nach dem ldifde Import die übrigen DFS Server wieder zum Namespace hinzufügt. Also!
Überlegt ob dies auch auf euch zutreffen könnte, spielt in eurer Testumgebung Backup und Restore eurer Namespaces mal durch und entscheidet ob ihr den ldifde Export zusätzlich zu einem dfsutil Export in eure Produktion übernehmen wollt.

Euer Hubert

Recieve Side Scaling RSS für File Server

Rol_Muc — Tue, 28 Apr 2015 06:38:53 GMT

...wieder einmal Hubert mit einem weiteren Gastbeitrag aus unserem Netzwerkteam: Hallo zusammen, oft stellen wir im Rahmen von Performance Problemen auf Fileservern, aber auch auf DFS-Servern fest, dass Recieve Side Scaling (RSS) nicht aktiviert ist.
Deswegen möchte ich euch heute ein Paar Informationen mitgeben, was RSS eigentlich ist, und warum es insbesondere für Fileserver eine so essentielle Bedeutung hat. Recieve Side Scaling gibt es in den Windows Betriebsystemen seit dem Scalable Networking Pack das auf Windows 2003 SP1 nachinstalliert werden konnte.
Seitdem ist es genauso wie TCP Chimney Offload und NetDMA integraler Bestandteil der Windows Server Betriebsysteme. RSS ermöglicht es den Netzwerk I/O auf mehrere CPUs zu verteilen.
Ohne RSS findet der gesamte Network I/O auf einer einzelnen CPU statt und beschränkt somit den maximalen Netzwerkdurchsatz, den die Maschine liefern kann.
Nach meinen Erfahrungen, kann eine State-of-the-Art CPU unter optimalen Voraussetzungen bis zu 7 GBit/s reinen TCP Verkehrs (ntttcp.exe) aufs Netzwerk pumpen.
Ein 10GBit/s Link kann also ohne RSS ohnehin nicht saturiert werden. Um RSS nutzen zu können muss die Netzwerkkarte und deren Treiber RSS unterstützen. Dies ist heutzutage aber bei eigentlich allen Server-Adaptern und auch bei Virtuellen Netzwerkkarten der Fall.
Damit RSS funktioniert muss es im Netzwerk-Treiber UND im Betriebssystem eingeschaltet und entsprechend konfiguriert sein. Im Windows Betriebssystem (seit 2008) ist RSS per Default eingeschaltet.
Beim Netzwerk-Treiber gibt es scheinbar Unterschiede zwischen Herstellern und Treiberversion. Neben dem Schalter „Ein/Aus“ unterstützen viele Treiber und auch das OS eine granularere Konfiguartion über die folgenden Einstellungen: RSS Base Processor Number <- Bestimm bei welcher CPU dieser Adapter anfängt zu zählen
Maximum RSS Processors <- bestimmt wieviele CPUs angefangen mit Base Processor Number RSS für diesen Adapter machen sollen.
RSS Queues <- bestimmt bei vielen moderneren Karten die Anzahl der Queues die der Treiber verwendet und sollte somit der Anzahl der RSS Processors Somit ist es möglich zum Beispiel die erste NIC für RSS über Base Processor 0 und Max Processors 4 auf die die CPUs 0 – 3 zu konfigurieren und die zweite NIC auf die CPUs 4 – 7 Anmerkung: Die genauen Bezeichnungen der Einstellungen sind von Hersteller zu Hersteller leicht unterschiedlich und manche unterstützen noch zusätzliche Einstellungen.
Weitere Information zu RSS gibt es bei den jeweiligen Netzwerkkarten Herstellern und für die Betriebssystem Einstellungen hier:
https://technet.microsoft.com/en-us/library/hh997036.aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/ff567236(v=vs.85).aspx Warum aber ist RSS gerade für Fileserver so entscheidend wichtig? Machen wir einen kurzen Abstecher in die Geschichte.
Mit aufkommen von Multi-Prozessor Maschinen, also lange bevor es RSS gab, brauchte man eine Möglichkeit auch die Fileserver-Arbeit auf mehrere Kerne zu verteilen.
Dafür gibt es im LanmanServer einen Thread der dieses Loadbalancing macht und die Arbeit den einzelnen WorkerQueues und somit den einzelnen CPUs zuordnet. Als dann mit Windows 2008 die Implementation des neuen SMB Protokolls (SMB2) anstand, stand RSS bereits als Technologie zur Verfügung.
Daher wurde entschieden den zusätzlichen Overhead durch den zusätzlichen, und mit RSS redundanten, Loadbalancing-Thread einzusparen, und die Fileservice-Arbeit auf dem selben Kern zu erledigen, der auch den zugehörigen Network I/O bedient.
Dieser Effizienz-Gewinn gilt ebenso für SMB3. Wenn also RSS abgeschaltet ist, und der gesamte Netzwerk I/O auf CPU0 läuft, wird auch die gesamte Fileservice Arbeit für SMB2 und SMB3 auf CPU0 erledigt. Also, ganz platt gesagt: Euer dicker 8-Kern Fileserver ist ohne RSS defakto ein Single-Core Fileserver. Insbesondere für CPU-intensive Operationen wie ABE-Filterung aber auch bei entsprechend stark frequentierten DFS-Namespace und Fileservern machen sich sehr schnell Performance Defizite bemerkbar, wenn RSS nicht eingeschaltet ist.
Zudem ist RSS eigentlich für alle Server Pflicht, die einen entsprechend hohen Netzwerkdurchsatz liefern müssen, oder viele gleichzeitige Verbindungen halten sollen.
Nehmt euch doch mal die Zeit und prüft auf euren File-Servern, SQL-Server, Exchange-Server, etc. wie es dort um RSS bestellt ist.
Am Besten wäre natürlich, wenn man dies gleich in die Setup-Prozeduren für neue Server mit aufnimmt.

Euer Hubert.

Account Lockout Policy Settings und der spezielle Einfluss des PDCs

Herbert Mauerer [MSFT] — Tue, 27 Jan 2015 05:44:51 GMT

Unter den Active Directory Administratoren ist Accont Lockout ein heißes Thema. Viel von der Brisanz entsteht aus den unterschiedlichen Zielen, die die Manager, AD Admins und Security Administratoren haben. In der Diskussion kommen die technischen Aspekte oft zu kurz und führen zu Missverständnissen. Oft kommen Techniker aus einer Welt, wo die Eingabe eines falschen Kennworts einen Anmeldefehlversuch zur Folge hatte, der Unix oder IBM Host lässt grüßen. In einem verteilten Verzeichnissystem wie Active Directory es ist und den aktuell im Markt befindlichen Applikationen ist das jedoch nicht mehr so einfach zu rechnen. Es gibt nämlich etliche Applikationen, welche bei einem Anmeldefehler etliche Wiederholungen machen, mit den gleichen falschen Informationen. Als Applikationen gelten hier auch die Synchronisations-Clients auf mobilen Geräten. Auch Microsoft-Applikationen haben sowas gemacht, zum Beispiel ältere Versionen von Outlook. Es gibt aktuell ein Szenario mit dem Kerberos-Client, wo der Kerberos-Client einen Retry macht, siehe diesen englischen Blog. Das ist jedoch nur ein Aspekt für frühzeitige Aussperrungen und ich denke den meisten unserer Leser ist das Thema im Allgemeinen bekannt. Wir sind neulich jedoch auf eine interessante Kombination von Events gestoßen, wo eine Aussperrung stattfindet, ohne dass man an die üblichen Limits stößt. Ausschlaggebend für das Problem ist ein sehr niedriger Wert für die Fehlversuche (LockoutThreshold). Sehr strenge Security Officers nehmen da gerne einstellige Werte. Der zweite treibende Aspekt ist ein langes Beobachtungsintervall (ObservationWindow). Wenn ein Domain Controller ein falsches Kennwort hat bei der lokalen Prüfung, leitet er die Anfrage standardmäßig an den Primary Domain Controller (PDC) weiter. Der macht die gleiche Prüfung, und sein Ergebnis ist dann maßgeblich. Wenn beide DCs das falsche Kennwort feststellen, erhöhen sie den „BadPwdCount“ um eins und „BadPasswordTime“ wird auf die aktuelle Uhrzeit gestellt. Solange der „LockoutThreshold“ nicht überschritten wird, passiert nichts weiter, denn die beiden Attribute werden nicht repliziert. Wenn „LockoutThreshold“ überschritten wird, sperren beide DCs das Konto und das wird dann repliziert (als Attribut „LockoutTime“). Es gibt zwei Events, die den „BadPwdCount“ zurücksetzen auf 0:

Der Benutzer übergibt in einem Folgeversuch das korrekte Kennwort.
Das „ObservationWindow“ läuft ab.

Das Fenster für frühzeitige Aussperrungen entsteht nun durch den Fall 1. „BadPwdCount“ bleibt auf dem PDC bestehen. Denn der PDC ist der DC, der wohl recht selten eine Anmeldung mit einem korrekten Kennwort bekommt. Das ganze passiert dann so, dass der Benutzer einige Male hintereinander zuerst ein falsches Kennwort und dann das korrekte verwendet. Beim PDC laufen aber nur die Fehlversuche auf. Wenn die Versuche von einer Applikation kommen, die etliche Retries macht, können je nach „LockoutThreshold“ schon zwei Versuche reichen. Bei langem „ObservationWindow“ wird das Problem verschärft. Denn dann hat der Benutzer keinen Bezug mehr zu vergangenen Fehlversuchen. Ich spreche hier von einem Intervall von mehreren Stunden oder sogar Tagen, denn das Maximum liegt bei 70 Tagen. Das ist im Support dann manchmal der Fall, wenn Kunden Service Requests erstellen und von „unerwarteten Kontensperrungen“ sprechen. Die Fehlversuche können sich neben dem PDC auch auf anderen DCs kumulieren, die aus bestimmten Gründen ebenfalls nur Fehlversuche bekommen. Zum Beispiel von Scripts die DCs oder bestimmte Server angehen, welche per NTLM dann an den bei ihnen lokalen DC gehen. Und wenn diese DCs AvoidPdcOnWan=1 verwenden, wird der Benutzer dort ausgesperrt, und nicht auf dem PDC. Wo ich schon AvoidPdcOnWan erwähne: Die DCs in der Site des PDC sind natürlich auch alle Kandidaten für lokal generierte Aussperrungen, dort wirkt die Einstellung nicht. Ich denke die Moral der Geschichte ist, dass Kontensperrungen ein haariges Thema sind und bleiben. Ihr müsst Euch genau überlegen, ob bei der Abwägung von Nutzen und Kosten das Pendel für Sperrungen ausschlägt. Denn egal ob man Kontensperrungen nutzt oder nicht, Auditing für fehlgeschlagene Anmeldungen und eine (automatisierte) Auswertung der Security Logs der DCs bedingen einander. Kontensperrungen erzeugen eine User-Downtime, ich nenne das immer „DDoS“ gegen Benutzerkonten (Distributed Denial of Service). Wenn Eure Domains angegriffen werden durch Brute-Force Attacken, dann ist der Kampf dagegen der gleiche, mit oder ohne Sperrungen. Ohne Kontensperrungen ist der Effekt „nur“ überlastete DCs. Die Kennwörter müssen so oder so sicher sein, und Social Engineering und MalWare welche bereits Credentials hat kann keiner der Ansätze bekämpfen. Als Security Administrator muss man sich dann zwischen einem Stein und einem harten Platz entscheiden… Rock On!

Herbert

Offline Files (CSC) Konzeptionierung

Rol_Muc — Thu, 20 Nov 2014 07:07:00 GMT

Nach lange Zeit mal wieder ein Beitrag von Hubert aus unserem Netzwerk Team. Heute geht es um das Thema Offline Files und was bei Aufbau eines dauerhaft funktionierenden Offline File Konzeptes zu beachten ist. Hallo zusammen, in letzter Zeit treffen bei uns vermehrt Support-Anfragen ein bei denen es um Offline Files Probleme geht. Die Symptome reichen von Clients, die nicht mehr Online kommen, die nicht Syncen können, die reihenweise Sync-Fehler und Konflikte werfen und Pfade die im SlowLink Modus nicht erreichbar sind, obwohl eigentlich keine Offline Files auf diesen Pfaden aktiviert sein sollten. Diese Support Anfragen haben eines gemeinsam: Die Ursache der Probleme findet sich im verwendeten Offline Files Konzept und ist nur durch ein neues dauerhaft tragfähiges Konzept zum Einsatz der Offline Files zu lösen. Die Migration von altem zu neuem Konzept zieht in aller Regel die Verwendung des FormatDatabase Registry Keys (https://support.microsoft.com/kb/942974/en-us) nach sich, da die Offline File Konfiguration auf dem Client oft komplett verstrubbelt und nur so zu bereinigen ist. Dies wirft natürlich Fragen rund um das Backup von Clients auf, die unter Umständen seit Monaten nicht mehr erfolgreich syncen konnten und zieht somit oft monatelange Migrationsprojekte nach sich. Um dies zu vermeiden, möchte ich mit diesem Blog den Admins dort draussen helfen, von vorneherein sinnvolle Offline Files Konzepte zu entwickeln, die dauerhaft funktionieren und die nötige Flexibilität bieten um zum Beispiel Daten auf der Fileserver Seite einfacher umziehen zu können. Dies sind die Punkte die bei der Erstellung eines Offline File Konzeptes zu beachten sind. 1. Die 5 Wege der Offline Verfügbarkeit Auf den folgenden 5 Wegen können Dateien in den Offline Cache des Clients gelangen, bzw. ein zugehöriges Scope und Partnerschaft innerhalb der Offline Files erstellt werden. Über diese Wege müssen wir eine administrative Kontrolle erlangen und behalten. a) Folder Redirection ohne Abschaltung des Offline Files Automatismus

Beim Einrichten einer Folder Redirection wird automatisch für jeden Umgeleiteten Ordner einzeln eine Offline Partnerschaft erstellt. Durch setzen von „Do not automaticaly make Redirected Folders available Offline“ kann dieser Automatismus unterbunden werden. Siehe https://gpsearch.azurewebsites.net/#293

b) Administrativ zugewiesene Offline Files

Per Group Policy können durch den Administrator Pfade vorgegeben sein, die vom Client Offline bereitgestellt werden müssen.

Siehe https://gpsearch.azurewebsites.net/#2056

c) Rechtsklick des Users auf Make Available Offline

Per Default kann der User zudem selber Pfade Offline bereitstellen. Dies kann über die Policy Remove Make Available Offline Command verhindert werden um somit keine unvorhergesehenen Partnerschaften z.B. auf Gruppenlaufwerke zu bekommen. Siehe https://gpsearch.azurewebsites.net/#2072

d) Caching Einstellungen auf dem File-Server Share

Auf jedem CIFS Share gibt es die Einstellungen: „Der Client kann Cachen“ (Default bei Windows), „Der Client muss Cachen“ und „der Client darf nicht cachen“.

Wenn ein Client auf ein Share zugreift, auf dem die Einstellung lautet „Der Client muss Cachen“, wird der Client in den Offline Files ein entsprechendes Scope und Offline File Partnerschaft anlegen, und die Daten vom Server heruntersynchronisieren. Hier wären die Einstellungen auf den entsprechenden Shares zu prüfen.

e) LinkTargetCaching Verhalten bei Erzeugen einer .lnk Datei auf einem Offline Verfügbaren Pfad.

Per Default wird das Ziel einer .lnk Verknüpfung Offline Verfügbar gemacht, wenn die .lnk Datei selber auf einem Offline Verfügbaren Pfad liegt. Ein User könnte Somit durch einen Shortcut in seinem My Documents Folder eine Scope für ein Gruppenlaufwerk erzeugenen, wenn er mit dem Shortcut dorthin verlinkt. Das Verhalten kann über den Registry Key LinkTargetCaching kontrolliert werden. Siehe https://support.microsoft.com/kb/817275/en-us

2. Berechtigungen auf der Fileserver Struktur Der Offline File sync findet nicht (ausschliesslich) im Rechtekontext des angemeldeten Benutzers statt, da auch Offline Daten von anderen Benutzer gesynched werden müssen, obwohl der andere Benutzer nicht angemeldet ist. Somit braucht Offline Files auf der Server Seite einen gewissen Satz an Mindest-Berechtigungen, damit ein Offline File Sync fehlerfrei stattfinden kann. Diese Berechtigungen sind in https://support.microsoft.com/kb/2512089/en-usdokumentiert. Hierbei wird zwischen Share Berechtigungen und NTFS Berechtigungen auf dem unter dem Share sitzenden Ordner, sowie der letzten Ebene in der der User dann seine Daten liegen hat, unterschieden. Wenn wir per DFS auf diese Pfade zugreifen, gelten die Berechtigungen für das Share, den Ordner darunter bzw. die Pfade runter bis zu den Userdaten ab der ersten DFS-Root Ebene. 3. Scopes und gecachte Daten Offline Files betrachtet \\Server\Share als ein Scope. Jeder Zugriff auf einen UNC Pfad wird gegen die in den Offline Files hinterlegten Scopes geprüft. Erfolgt der Zugriff auf einen Pfad der als Scope in den Offline Files existiert, läuft der Zugriff durch die Offline File Logik, die steuert ob der Zugriff aus dem Cache oder vom Server bedient wird. Daher ist ein Scope auch die Instanz die aus Sicht der Offline Files entweder Offline, oder Online ist. Fällt, also das Scope \\Server\Share offline, so werden alle Zugriffe auf Daten unterhalb dieses Pfades in den Offline Cache umgelenkt. Wurde jetzt jedoch nur ein Unterordner wie \\Server\Share\Daten\Offline_verfügbar Offline Bereitgestellt sind im Offline Modus nur Daten unterhalb dieses Ordners verfügbar. Daten auf anderen Pfaden wie \\Server\Share\Andere_Datensind im Offline Zustand nicht erreichbar, auch wenn der Client wie im Falle von Offline (Slowlink) eine Verbindung zum Server aufbauen könnte. Somit empfiehlt es sich, Daten die Offline Verfügbar sein sollen, von den Pfaden her von Daten zu trennen, die nicht offline Verfügbar sein sollen. Es hat sich in der Praxis bewährt Daten wie User Home Shares auf separate DFS Namespaces auszulagern. 4. Slowlink Mode und Background Sync. Über die Policy Configure slow-link Mode kann für einzelne Pfade kontrolliert werden, ab welchen Schwellwerten für Latenz und Bandbreite die Offline Files das Scope in den Offline Modus schalten. Siehe https://gpsearch.azurewebsites.net/#2093 Es gilt zu bedenken, dass in Windows 7 auch ohne gesetzte Policy ein Default Wert für die Latenz von 80ms gilt. Es ist zu beachten, dass in der Policy die Worte „Latency“ und „Throughput“ einzutragen sind. Die Registry kann kein Deutsch und somit mit den Worten „Latenz“ und „Durchsatz“ nichts anfangen. Beim Einsatz von Offline Files auf DFS, kann für die DFS-Root ein sehr hoher Wert definiert werden, so dass die DFS Root selber nicht aufgrund der SlowLink Detection Offline geht. Siehe auch den Blog meines Kollegen Ned Pyle zu diesem Thema: https://blogs.technet.com/b/askds/archive/2011/12/14/slow-link-with-windows-7-and-dfs-namespaces.aspx Im Offline zustand kann über die Policy Configure Background Sync gesteuert werden, in welchen Intervallen und mit welcher Varianz die Offline Files Änderungen auf Client und Server miteinander abgleichen. Siehe https://gpsearch.azurewebsites.net/#2095 Ebensowenig wie beim Foreground Sync (zum Beispiel aus dem SyncCenter heraus) kann beim Background Sync die verwendete Bandbreite eingeschränkt werden. 5. Umzug der Offline Verfügbaren Daten auf andere Pfade. Dieses Szenario gilt es nach Möglichkeit zu vermeiden! In https://support.microsoft.com/kb/977229/en-us sind abhängig von dem Weg der Offline Verfügbarkeit (Folder Redirection Automatismus vs. Jeder andere Weg) die zwei Supporteten Wege für einen Umzug beschrieben. Beiden Wegen ist gemeinsam, dass dem KB Artikel penibelst gefolgt werden muss, und bei beiden Wegen eine zeitliche Abstimmungen zwischen Aktionen auf dem Client (Sync, Logoff, Logon) und Änderungen in der Infrastruktur (Setzen von Policies, Kopieren von Daten, etc.) gefordert ist. Dies lässt sich erfahrungsgemäss schlecht bis garnicht automatisieren und ist „zu Fuss“ nur sehr schlecht für eine grössere Anzahl an Clients umsetzbar. Daher wird dringend die Verwendung von DFS als Abstraktionsebene empfohlen, um bei einem Umzug der Daten, lediglich den DFS-Link auf das neue Ziel umsetzen zu müssen. Beim Einsatz von DFS für Offline Files (und Roaming Profiles sowie mit DFSR) ist zwingend folgendes zu beachten: https://blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.aspx 6. Zu Vermeidende Konfigurationen / Szenarios Immer wieder stellen wir fest, dass bestimmte Daten auf mehreren Wegen Offline verfügbar gemacht wurden. Zum Beispiel: Folder Redirection mit Offline Verfügbarkeit auf \\Server\Share\Username\MyDocuments Zusätzlich Administrativ zugewiesene Offline Files auf \\Server\Share\Username Somit ist der Unterordner MyDocuments auf zwei unterschiedliche Arten, also doppelt, offline Verfügbar gemacht. Dies funktioniert nicht, bzw. führt zu diversen Fehlern während der Verwendung der Offline Files. Ein weiteres Problem betrifft User die mehrere Maschinen gleichzeitig verwenden. Zum Beispiel, ein Laptop mit Offline Verfügbarkeit und eine Desktop Maschine ohne Offline Verfügbarkeit. Hier gilt es zu verhindern, dass der Offline Verfügbare Client zum Beispiel durch SlowLink Mode Offline fällt, da sonst der User auf dem Laptop eine Datei im lokalen Cache ändern könnte, während er gleichzeitig mit dem Desktop die selbe Datei auf dem Server verändert. Sobald der Client wieder Online kommt, hätte er einen klassischen Sync-Konflikt. Das selbe gilt für Daten an denen mehrere User arbeiten. Diese sind für den Einsatz mit Offline Files denkbar ungeeignet. Es versteht sich denke ich von selbst, dass bevor Offline Files auf den Clients eingesetzt wird, die Clients nicht nur die aktuellen Security Updates sondern auch die aktuellsten Hotfixes für Offline Files, den Fileservice Client und die Shell installiert bekommt und ein Patch Management verwendet wird, dass diese Komponenten auch auf dem aktuellsten Stand zu halten. Ich hoffe dies hat euch ein wenig weiter geholfen. -Hubert

Was passiert, wenn DCs zu beschäftigt sind um die Last messen zu können

Herbert Mauerer [MSFT] — Thu, 23 Oct 2014 07:02:56 GMT

Wir sehen den Trend, dass bei vielen Kunden das Active Directory im Mittelpunkt des Identity Management steht. Es werden darüber Zertifikate und Group Policies verteilt, verschiedenste Netzwerk-Dienste verwenden Active Directory um Benutzer zu authentifizieren und Daten aus dem AD um sie zu autorisieren.

Dann gibt es noch eine ganze Reihe Dienste welche ihre Konfiguration im Active Directory speichern, inklusive der Einstellungen der Benutzer und anderer für den Dienst verwendete Objekte.

Andere Dienste synchronisieren regelmäßig eigene Datenbanken mit AD, bei Produkten wie dem Microsoft Forefront Identity Manager ist es praktisch der einzige Daseinszweck. Ich will jetzt keine Diskussion darüber anstoßen ob das nun Meta-Verzeichnisdienste oder virtuelle Verzeichnisse sind, und in welche Klasse der Office 365 DirSync fällt…

So oder so, die Anzahl von Komponenten, und die Menge und Komplexität der Anfragen an Active Directory hat eine nach oben offene Tendenz.

Was machen meine Domain Controller den ganzen Tag?

Nun haben die Domain Admins nicht immer ausreichend Wissen, welche Applikationen in welchen Abteilungen welche Anfragen an Active Directory stellen. In einigen Firmen scheinen die AD-Admins als letzte zu erfahren, was von anderen Abteilungen an signifikanten Änderungen geplant ist.

Es gibt auch das andere Ende der Skala. Es kann schon eine „unschuldige“ Änderung an einem Logon Script für eine Überlastung der DCs in den Morgenstunden sorgen. Das ist ein Klassiker im Bereich Domain Controller Performance.

Wir haben an dieser Stelle schon darüber geschrieben, und auch heute beginnen viele SRs mit der Beschreibung, dass die DC-Antwortzeiten hoch sind und LSASS viel CPU-Zeit verbraucht. In der Zwischenzeit ist der „Server Performance Advisor“ (SPA) aus der Zeit Windows Server 2003 ins Betriebssystem gewandert und firmiert dort als „Data Collector Sets“. Zu dem Toolset gibt es einen guten englischen Blog. Noch neuer ist die Version 3.1 von SPA, die eignet sich für Euch vor allem für das Baselining.

Die Reports dieser Datensammlungen sind in unserer Support-Arbeit ein sehr wertvolles Tool um besser zu verstehen, welche Anfragen den Domain Controller beschäftigen.

Deutlich weniger Fälle beschäftigen sich mit der Thematik DCs sind langsam, Auslastung ist aber nicht hoch. Ein paar typische Themen habe ich schon in einem Blog diskutiert.

Die „Data Collector Sets“ stoßen an Grenzen

Wir beobachten jetzt öfter bei Kunden, dass diese Data Collector Set Reports unvollständig sind, weil Dateien fehlen oder die Erzeugung des HTML-basierten Reports abbricht.

So sieht das Verzeichnis eines Berichts aus, der erfolgreich war:

16.09.2014 10:57 557.973.504 Active Directory.etl

16.09.2014 10:57 6.531 AD Registry.xml

16.09.2014 10:57 165.609.472 NtKernel.etl

16.09.2014 10:57 5.636.096 Performance Counter.blg

16.09.2014 11:07 19.841.268 report.html

16.09.2014 11:05 62.345.970 report.xml

16.09.2014 10:57 62.745 report.xsl

16.09.2014 11:05 0 rules.log

8 File(s) 811.475.586 bytes

Bei diesem Bericht hast das nicht mehr geklappt:

16.09.2014 10:25 2.027.094.016 Active Directory.etl

16.09.2014 10:25 6.530 AD Registry.xml

16.09.2014 10:25 202.244.096 NtKernel.etl

16.09.2014 10:25 5.963.776 Performance Counter.blg

16.09.2014 10:39 289.737.190 report.xml

16.09.2014 10:25 62.745 report.xsl

16.09.2014 10:38 0 rules.log

7 File(s) 2.525.108.353 bytes

Das ist jetzt kein Suchbild…neben der größeren Dateien fällt auf, dass der Bericht „report.html“ fehlt.

Wir haben mittlerweile die wichtigen Parameter für die Report-Erzeugung identifiziert:

Am Ende der Datensammlung wird der Report durch einen Prozess „tracerpt.exe“ generiert.
„tracerpt.exe“ läuft mit niedriger Priorität, „verliert“ im Rennen um CPU-Zeit also gegen einen beschäftigten LSASS-Prozess.
„tracerpt.exe“ arbeitet mit einem Thread, hat also nicht viel Vorteil von vielen CPU-Cores.
„tracerpt.exe“ braucht mehr Speicher je länger er läuft.
Der Report-Generator-Prozess „tracerpt.exe“ hat sechs Stunden um den Report zu erstellen. Danach wird er abgebrochen.
Die Einstellungen für die Datenverwaltung des vordefinierten Sets löscht die größten Sets ab einer Größe von 1 Gigabyte. Die größte Einzeldatei welche auch den meisten Aufwand erzeugt ist „Active Directory.etl“.

Ein Kunde mit sehr großzügig ausgestatteten Domain Controller (24 Serverklasse CPUs, 256 GB Speicher) hat für verschiedene Report-Größen Messungen gemacht:

Bis zum Ablauf der sechs Stunden hat „tracerpt.exe“ bis zu 12GB an Arbeitsspeicher allokiert.
In der Zeit war durchgängig ein CPU-Core zu 100% belegt. In realen Überlastszenarien müsstet Ihr die Priorität von „tracerpt.exe“ im Task Manager erhöhen, damit genug CPU-Zeit verfügbar wird.
Den größten Datensatz, welcher erfolgreich durchgelaufen ist, hatte eine „Active Directory.etl“ von 3 GB.

Ihr solltet jedoch erwarten, dass auf schlechter ausgestatteten Rechnern die Grenzen deutlich niedriger liegen, weil zum Beispiel nicht so viel Speicher frei ist oder die CPUs langsamer und anderweitig beschäftigt sind.

Was tun, sprach Zeus?

Es gibt die Möglichkeit über einen eigenen Data Collector Set einige Parameter anzupassen. Der erste Schritt ist, einen oder mehrere Klone des System AD Data Collector Set anzulegen, je nach Einsatzzweck.

Im Container „User Defined“ könnt Ihr ein neues Set anlegen:

Es läuft nun ein Assistent ab, der in mehreren Dialogen die Parameter für das neue Set abfragt.

Als erstes geben wir dem Kind einen Namen und geben auch an, dass wir ihn aus einem Template erzeugen wollen:

Auf der nächsten Seite wählen wir das Template aus. Das kann ein von diesem oder einem anderen Rechner exportiertes Set als XML-Datei sein (Auswahl nach „Browse“), oder wie in unserem Fall ein System Set „Active Directory Diagnostics“:

Der letzte optionale Schritt ist die Festlegung des Speicherorts für den Set. Hier möchtet Ihr vielleicht ein Volume mit mehr Platz oder weniger IO-Last verwenden:

Da ist noch eine Seite im Assistenten, da braucht aber nichts geändert werden. Ihr könnt nun „Finish“ anklicken.

Für ein „Big Data Collector Set“ sind wichtige Einstellungen auch hinter dem Menüpunkt „Data Manager“, da fangen wir an:

Die wichtigen Einstellungen sind die „Resource Policy“ und die „Maximum Root Path Size“. Ich empfehle, die auf die angezeigten Werte anzupassen:

Was die Größe der Datensätze angeht, solltet Ihr etwas experimentieren, was für Euren Einsatzzweck am besten funktioniert. Da können durchaus 10GB dabei heraus kommen.

Die zweite wichtige Stellschraube ist die Laufzeit des Sets, welche per Standard bei fünf Minuten und einem Report liegt. Das kann in den Eigenschaften des Sets im Reiter „Stop Condition“ angepasst werden, in vielen Fällen kann ein kürzeres Sammelintervall genauso gut funktionieren:

Ihr solltet aber nicht unter zwei Minuten gehen, da Ihr in den Reports sonst LDAP Queries nicht mehr in der Analyse seht, die in das Limit von 2 Minuten laufen. Ich würde das untere Limit bei 3 Minuten setzen.

Besonders der Neustart der Datensammlung bei vielen Daten ist eine interessante Sache. Je nach Situation kann es jedoch etwas verwirrend werden, wenn zu einem Lauf etliche Verzeichnisse existieren, und Ihr für eine volle Auswertung mehrere Reports durchsehen müsst. Aber ich meine, das ist besser als gar keine Daten.

Wenn Ihr hier lange loggen lasst und den Log bei 1GB neu startet, dann ist es sinnvoll, im „Data Manager“ viel größere Werte für die Datengröße anzulegen. Nicht dass der erste Teil des Laufs schon wieder gelöscht ist…

Wie sehe ich während eines Kollektor-Laufs wie viel Daten schon gesammelt sind?

Während der Laufzeit der Datensammlung gibt sich der Explorer recht zugeknöpft was die Größe der Dateien angeht:

Der Explorer aktualisiert das erst, wenn Ihr was mit der Datei macht. Und was am schnellsten geht ist die Datei zu löschen:

Dann ist die Anzeige aktuell.

Wenn Ihr wegen der hohen Last abschätzen könnt, dass das Datenset sehr groß wird, könnt Ihr auch die Sammlung vorzeitig anhalten:

Soll das nun alles sein?

Wir arbeiten mit unseren Entwicklern daran, die Auswertung der Datensätze performanter zu machen. Das erlaubt, größere zusammenhängende Datensätze zu erzeugen.

Ich vermute jedoch, es wird einigen von Euch bei richtig großen Reports dann durchaus auch sehr langsam vorkommen, Berichte größer als 20 MB im Browser zu handhaben. Nicht nur weil die Größe der Tabellen dem Browser zu schaffen macht, sondern sie auch Eure Aufnahmefähigkeit sprengt…

In diesem Sinne, keine viereckigen Augen wünscht

Herbert

FRS – Das Ende ist nah

dedsBarbara — Fri, 22 Aug 2014 06:18:00 GMT

… deshalb solltet Ihr auf DFSR wechseln !

Hallo Zusammen,

Vor etwa zwei Monaten (ich komme leider erst jetzt dazu, diesen Artikel zu schreiben) hat der Produktverantwortliche für DFSR und FRS angekündigt, daß FRS (File Replication Service oder Dateireplikationsdienst) in einer der nächsten Versionen nicht mehr in Windows Server enthalten sein wird.

Diese Ankündigung schien mir so wichtig, daß ich beschlossen habe, die Info auch in deutsch zur Verfügung zu stellen.

FRS wurde mit Windows 2000 Server eingeführt, DFSR mit Windows Server 2003 R2, und seit Windows Server 2008 kann DFSR auch für das SYSVOL eingesetzt werden. Seitdem wurde FRS mit jeder Betriebssystemversion in den Standardeinstellungen für neue Umgebungen immer mehr durch DFSR ersetzt.

Nachdem der Support für Windows Server 2003 im kommenden Jahr endet (14. Juli 2015), können alle dann noch supporteten Betriebssysteme im vollen Umfang, also für eigene Replikationsgruppen und für SYSVOL, mit DFSR umgehen. Deshalb besteht ab dann keine technische Notwendigkeit mehr, FRS einzusetzen, und wir werden es daher entfernen. Das geschieht möglicherweise nicht in der Version, die als erstes nach dem Support-Ende von Windows Server 2003 erscheint aber in einer der nächsten Versionen definitiv. Wir kündigen dies jetzt bereits an, um allen genug Zeit für die Umstellung auf DFSR (DFS Replikation) zu geben.

Folgen ?

Es können nach dem Ende von FRS keine DCs (Domänenkontroller, Domain Controller) mit dem neuen Betriebssystem hochgestuft werden in eine Domäne, in der das SYSVOL noch mit FRS repliziert wird. D.h. alle Aktualisierungen (Upgrades) sind solange blockiert bis das SYSVOL auf DFSR umgestellt ist.

Was nun ?

Wenn noch nicht geschehen, ist der nächste Schritt, von FRS auf DFSR zu migrieren. Das ist glücklicherweise nicht sehr kompliziert und gut getestet. Hier kommen einige links mit Anleitungen für die Migration

Schritt-für-Schritt in deutsch

Schritt-für-Schritt in englisch (kurz)

Super ausführlich mit allen Details (auch englisch)

Und hier auch noch mal die Ankündigung in englisch.

Ich wiederhole, was ich schon 2008 schrieb ...

Ab diesem Zeitpunkt ist FRS Vergangenheit.

Der König ist tot, lang lebe der König. ;-)

Oder wie es Ned sagen würde:

Gruß

Barbara

Update verfügbar der LDAP-Anfragen beschleunigt

Herbert Mauerer [MSFT] — Tue, 28 Jan 2014 06:54:13 GMT

Hallo! Ihr habt schon einige Zeit keinen Blog mehr von uns gehabt. Man könnte sagen, wir hatten viel zu tun. Manchmal kommt bei der Arbeit auch etwas Interessantes und für viele Kunden Wichtiges heraus. Wir haben nun einen Update für den LDAP Server von Windows Server 2008 R2 bekommen, der für viele Kunden eine deutliche Verbesserung der Performance mit sich bringen dürfte. Der KB Artikel dazu ist: 2862304 AD DS or AD LDS responds slowly to complex LDAP query that has a deeply nested filter on Windows Server 2008 R2 server Die Verbesserung des LDAP Query Optimizers ist in Windows 2012 R2 bereits an Bord, und die wichtigsten Verbesserungen wurden damit auf die ältere Version portiert. Ein Update für Windows Server 2012 ist ebenfalls in Arbeit. Windows Server 2012 R2 hat zusätzlich noch bessere Details zur Verbesserung der Query im Event 1644 für suboptimale Queries und auch in der STATS-Control Antwort. Ein Teil der Verbesserungen in Event 1644 sind ebenfalls zurück portiert worden: https://support.microsoft.com/kb/2800945/en-us Es gibt leider noch keine öffentlichen Informationen zu den Verbesserungen des Query Optimizers und der Events 1644. Wie sieht das Reporting für die Verbesserung aus? Ein Beispiel für eine Query auf älteren DCs wird so bearbeitet: Call Time: 578 (ms) Entries Returned: 111 Entries Visited: 18784 Used Filter: ( | ( & ( | (cn=user1*) (userPrincipalName= user1*) ) ( | (objectClass=person) (cn= user1*) ) ) ( & (cn= user1*) (objectClass=person) ) ) Used Indexes: DNT_index:7550:N; Pages Referenced: 169205 Pages Read From Disk: 0 Pages Pre-read From Disk: 426 Clean Pages Modified: 0 Dirty Pages Modified: 1 Log Records Generated: 0 Log Record Bytes Generated: 0 So sieht die neue STATS Control Antwort aus: Call Time: 125 (ms) Entries Returned: 111 Entries Visited: 111 Used Filter: ( | ( & ( | (cn=user1*) (userPrincipalName= user1*) ) ( | (objectClass=person) (cn= user1*) ) ) ( & (cn= user1*) (objectClass=person) ) ) Used Indexes: idx_cn:121:N;idx_userPrincipalName:0:N; Pages Referenced: 2826 Pages Read From Disk: 23 Pages Pre-read From Disk: 0 Clean Pages Modified: 0 Dirty Pages Modified: 0 Log Records Generated: 0 Log Record Bytes Generated: 0 Getting 111 entries: Das ist doch mal ein Unterschied. Windows Server 2012 R2 ist schneller, obwohl der Server auf IO für 23 Datenbankseiten warten musste. In den „Used Indexes“ sieht man, dass im Gutfall zwei recht spezifische Indizes ausgewählt wurden. Mit dem alten Optimizer sehen Sie allgemeine Indizes wie „DNT_index“ oder „Ancestors_index“. Damit werden oft viele Objekte in den Speicher geholt „Entries Visited“. Die Query ist auch schneller, weil deswegen auch wesentlich weniger Datenbankseiten angefasst wurden (Pages Referenced). Wenn das ohne Disk IO stattfindet, ergibt das eine hohe CPU Zeit, und ist ggf. trotzdem langsam. Bei einer Wiederholung auf Windows Server 2012 R2 habe ich den Threshold für Events 1644 herab gesetzt. Der Vorgang ist in diesem Blog beschrieben: https://blogs.technet.com/b/ad/archive/2008/04/01/how-to-create-a-mosiac-of-user-thumbnails-in-aduc-dsa-msc.aspx Die Kurzfassung ist, für den Test Diagnostics-Eintrag „15 Field Engineering“ auf „5“ und diese Registry-Einträge auf „1“ zu setzen: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Expensive Search Results Threshold (reg_dword)
Inefficient Search Results Threshold (reg_dword) Damit es auch etwas Neues zu sehen gibt, habe ich einen Filter verwendet, den auch der neue Query Optimizer nicht verbessern kann. In dem Fall geht es um ein nicht indiziertes Attribut. Ich bekomme damit folgenden Event: Log Name: Directory Service Source: Microsoft-Windows-ActiveDirectory_DomainService Event ID: 1644 Task Category: Field Engineering Level: Information Description: Internal event: A client issued a search operation with the following options. Client: [::1]:52009 Starting node: DC=w7-child1,DC=herbertm-w7,DC=com Filter: (printerName=gener*) Search scope: subtree Attribute selection: objectClass,name,description,canonicalName Server controls: Visited entries: 235 Returned entries: 3 Used indexes: Ancestors_index:313:N; Pages referenced: 2344 Pages read from disk: 0 Pages preread from disk: 0 Clean pages modified: 0 Dirty pages modified: 0 Search time (ms): 0 Attributes Preventing Optimization: printerName Deswegen ergibt das eine Volltextsuche in vielen Objekten. Das sind alle Objekte, die per Schema Definition das Attribut haben können. Es ist mittlerweile schwerer einen Filter zu erstellen, auf den der Query Optimizer keine Antwort kennt und wo es einen entsprechenden Hinweis gibt. Was ist zu tun? Ihr habt relativ gut beschäftige AD- oder LDS-Server. Nachdem die aber immer gute Antwortzeiten geliefert haben, war es nie wichtig nachzusehen, was die so beschäftigt den ganzen Tag. Mit diesem Update und vor allem den verbesserten Möglichkeiten von Windows Server 2012 R2 könnt Ihr mehr Bandbreite aus dem Server holen und auch besser untersuchen, was denn eine bestimmte Query so langsam macht. Ein schon etwas älterer Einstieg in das Thema ist auch der Blog von Hans. Viel Erfolg mit Euren jetzt noch schnelleren Servern! Euer Herbert

Powershell Script zur Gruppenrichtlinien-Verarbeitung

Rol_Muc — Mon, 19 Aug 2013 04:29:00 GMT

Hallo hier ist Michael mit einem Gastbeitrag auf dem deutschen AD Blog. Ich bin als PFE Engineer bei einem großen Deutschen Kunden eingesetzt. Der Kunde betreut ca. 160.000 Windows 7 Systeme über die ganze BRD verteilt, im Rahmen von Logon Problemen kommt es immer wieder vor das wir Troubleshooting in Richtung Domänen Controller aber auch Auswertungen der Group Policy Verarbeitung machen müssen und genau um dieses Thema geht’s heute. Seit Windows Vista stehen die meisten Informationen zum Thema GPO Verarbeitung auch wirklich in dem zugehörigen Event Log.

Log Name: Microsoft-Windows-GroupPolicy/Operational

Source: Microsoft-Windows-GroupPolicy

Einer der internen IT-Experten meines Kunden hat sich die Mühe gemacht, mittels eines PowerShell Skriptes eine Auswertung der Group Policy Ereignisse zu ermöglichen und diese strukturierter darzustellen. Dieses PS Skript wollen wir heute Vorstellen.

Systemvoraussetzungen:

- Win7 / Win2008 R2 / Windows 8 / Server 2012

- WinRM aktiv

- Powershell im Admin-Modus

Übergabeparameter:

.\GPAnalyser.ps1 -Analyse
.\GPAnalyser.ps1 -Analyse -Computer
.\GPAnalyser.ps1 -Analyse -Computer -ShowLastHours 24

Kurze Einführung:

Es gibt ein kleines Hauptmenü in dem alle GP-Verarbeitungen der letzten 12h angezeigt werden.

Über die Eingabe der jeweiligen „ID“ gelangt man zu einer genaueren Analyse dieser GP-Verarbeitung.

Ist eine GP-Verarbeitung ausgewählt, gelangt man passend zu dessen Analyse.

Hier gibt’s viel zu sehen, ggf. fehlt auch noch die eine oder andere Information, wir sind mal gespannt was euch noch dazu einfällt.

Anschließend gibt’s noch einen Experten-Modus der alle Events dieser Verarbeitung auflistet, diese Ansicht kann auch in Notepad geöffnet werden.

Wer mag, kann es gern auf Herz und Nieren testen und Feedback geben. Wir hoffen dass es euch das Arbeiten und Fehler suchen rund um GPO’s etwas erleichtert. Das PS Skript findet ihr im Anhang und in Kürze auch auf dem Microsoft ScriptCenter : https://gallery.technet.microsoft.com/

Wenn ihr Fragen habt oder auch Verbesserungsvorschläge dann immer her damit, ansonsten viel Spaß beim Testen und wir hoffen das damit eure tägliche Arbeit etwas erleichtert wird.

Gruß Michael Köppl

GPAnalyser.zip

Probleme mit dem Umwandeln von Sids in Namen

Herbert Mauerer [MSFT] — Mon, 12 Aug 2013 06:20:00 GMT

Hallo liebe Freunde des AD. Wir haben diesmal als Thema eine Warnung vor potentiellen Problemen mit Windows Server 2012 Domain Controllern. Es gibt zwar schon eine beträchtliche Liste von „Known Issues“ für Windows Server 2012, die wenigsten betreffen dem Mischbetrieb mit anderen Windows-Versionen auf Domain Controllern und Mitgliedern. Wir haben jedoch nun ein Problem gefunden, dass sehr viele Kunden betreffen könnte. Es hat mit zwei neuen Sids in Windows Server 2012 zu tun, die der Domain Controller in alle NTLM-Anmeldungen und Kerberos-Antworten packt. Viele Applikationen gehen durch die Liste der Sids im Access Token des Benutzers und möchten den Namen der Gruppe um eine Applikationsrolle zu prüfen. Ein gängiger Ansatz dafür ist zum Beispiel IsInRole aus der .Net Runtime. Wenn die Auflösung einer der Sids nicht klappt gibt es eine Exception oder Fehler wie: "An error (1301) occurred while enumerating the groups. The group's SID could not be resolved." when performing a UserPrincipal.GetAuthorizationGroups() Error 1301 (ERROR_SOME_NOT_MAPPED) returned. Die Applikationen berichten oft nicht, um welche Sids es geht, und nicht immer ist jemand mit Debugging-Können verfügbar. Ihr könnt in so einem Fall die Sids eventuell mit dem LSAP-Logging finden. Es kann sein, dass es custom Sids sind, wo die trusted Domains gerade nicht funktionieren. Aber wahrscheinlicher ist, dass es um die beiden Sids S-1-18-1 und S-1-18-2 geht, beschrieben sind die in der Tabelle auf dieser Seite: https://msdn.microsoft.com/en-us/library/cc980032.aspx

S-1-18-1 kommt ins Access Token, wenn die Anmeldung auf einer Prüfung von Credentials basiert, also zum Beispiel einem Kennwort, Zertifikat oder einer biometrischen Eigenschaft.
S-1-18-2 packt der Domain Controller ins Token, wenn die Anmeldung auf einer Kerberos S4U Proxy Anfrage basiert, also zum Beispiel eine Protocol Transition durchgeführt wurde.

Diese beiden Sids konnten bisher auf Betriebssystemen älter als Windows 8 oder Server 2012 nicht aufgelöst werden. Seit Juli gibt es nun ein Update für Windows 7 und Server 2008 R2, der das nachrüstet: 2830145 SID S-1-18-1 and SID S-1-18-2 can't be mapped on Windows 7 or Windows Server 2008 R2-based computers in a domain environment Ein Update für Windows Server 2008 wird aktuell noch geprüft. Wir schlagen vor, dieses Update auf alle Maschinen der Umgebung auszubringen, wenn eine Applikation das Token ausliest und nach den Namen für die Sids fragt. Diese Applikationen und auch die Windows Server 2012 DCs werden eher nicht weniger… So, nun kann es mit dem Deployment der Windows Server 2012 DCs endlich losgehen. Euer

Herbert

Probleme beim Wechsel Ethernet - WIFI

Rol_Muc — Mon, 22 Jul 2013 02:03:00 GMT

Hallo, nach langer Zeit gibt es mal wieder einen Gastbeitrag aus dem Windows Netzwerk Support von Frank Hennemann.
Vor kurzem habe ich an einer interessanten Anfrage eines Kunden gearbeitet. Die Ergebnisse könnten auch für andere relevant sein.

Die Problemstellung war:
Es besteht seitens des Kunden die Anforderung, dass WLAN Verbindungen nur dann aktiviert werden dürfen, wenn keine Ethernet Verbindung vorhanden ist. Dieses kann erreicht werden durch zum Beispiel: Features im BIOS von verschiedenen Herstellern oder auch 3rd Party Software. In Windows XP, Windows Vista und Windows 7 gibt es keine Möglichkeit, auf dieses Verhalten Einfluss zu nehmen. Mit Windows 8 und Windows Server 2012 gibt es ein sehr ähnliches Feature, das per default aktiv ist und mittels Gruppenrichtlinien gesteuert werden kann.

Die Policy nennt sich “Minimize the number of simultaneous connections to the Internet or a Windows Domain” und man findet sie wie folgt:

Nun zurück zu dem eigentlichen Problem: Sobald das Ethernet Kabel eines Windows 7 Clients getrennt wurde, wurde die WiFi Verbindung nicht automatisch hergestellt. Wenn man jedoch die WLAN Netzwerkkarte über ncpa.cpl deaktiviert und anschließend wieder aktiviert, so funktioniert die WLAN Verbindung wieder einwandfrei. Der Kunde setzte eine BIOS basierende Lösung ein, um den automatischen Wechsel von Ethernet auf WLAN zu erreichen.

Um der Ursache auf die Schliche zu kommen, haben wir ein detailliertes Logging aus einer privilegierten cmd.exe aktiviert.

Die Syntax lautet: 'netsh trace start wlan_dbg globallevel=0xff capture=yes persistent=yes tracefile=c:\wlan.etl'.

Sobald man den Fehler reproduziert hat, muss man das Logging mittels 'netsh trace stop‘ beenden.

Dabei wird eine Datei c:\wlan.etl erstellt, welche man mit dem Microsoft Netzwerk Monitor 3.4 öffnen kann. Man sollte allerdings die Parser im Netzwerk Monitor 3.4 noch auf ‚Windows‘ stellen.

Bei der Analyse der Daten ist dann folgende Fehlermeldung aufgefallen:

N802_MicrosoftWindowsNWiFi:CallAdapterSync Error: 2147483653 (0x80000005) OID 234946937 (0xE010179)

Um sich die Suche ein wenig zu erleichtern, kann man folgenden Display Filter verwenden:
N802_MicrosoftWindowsNWiFi.CallAdapterSync.Status == 0x80000005

Doch was bedeutet der Fehler eigentlich? Der Error Code 0x80000005 steht für ERROR_ACCESS_DENIED. Die Tatsache, dass dieser bei der Funktion CallAdapterSync auftritt, zeigt dass es ein Problem gab, Daten über den NDIS Layer zu versenden. Ein Treiber hat die Operation verweigert und den Aufruf blockiert. Nur welcher?

Letztlich war die Ursache, dass eine VPN Software eines Drittanbieters installiert war, welche eine virtuelle Netzwerkkarte erstellt hatte. Diese Netzwerkkarte wurde als Ethernet Karte betrachtet und somit konnte die WLAN Verbindung aufgrund des aktivierten BIOS Features nicht korrekt und automatisch aktiviert werden.

Den Typ bzw. das Medium einer Netzwerkkarte kann man über folgende OID abfragen:
OID_GEN_PHYSICAL_MEDIUM
https://msdn.microsoft.com/en-us/library/windows/hardware/ff569621(v=vs.85).aspx
Was sind OID’s? NDIS definiert Object Identifier (OID) Werte, um die Parameter eines Adapters zu identifizieren.
https://msdn.microsoft.com/de-de/library/windows/hardware/ff566707(v=vs.85).aspx

Eine Deinstallation der VPN Client Software hat das Problem nicht gelöst. Wenn man den Windows 7 Client ohne die VPN Software installierte, ist der Fehler nicht mehr aufgetreten. Der Kunde hat nun eine Support Anfrage bei dem Anbieter der VPN Client Software eröffnet.

Eine alternative Lösungsmöglichkeit stellt Software dar, welche entsprechende Ausnahmen für bestimmte Adapter definieren kann, um den problemlosen und automatischen Wechsel von Ethernet auf WLAN zu ermöglichen. Somit kann man solche Inkompatibilitäten adressieren und den oben beschriebenen Problemen aus dem Weg gehen.

Aus rechtlichen Gründen kann ich hier den Namen des Herstellers der VPN Client Software oder Links zu Lösungsanbietern nicht benennen. Ich hoffe, dass der Blog trotzdem für Euch interessant ist. Über ein Feedback würde ich mich sehr freuen.

Euer Frank