Samstag, 31. Dezember 2011

The lies of GPOs! #4

#4

"WMI Filter sind nicht performant"

Eine Aussage, zu der auch ich mich immer wieder hinreißen ließ.
Grundlage dieses Posts ist diese Diskussion aus dem Technet Group Policy Forum:

http://social.technet.microsoft.com/Forums/de-DE/gruppenrichtliniende/thread/0c9107c8-2282-4a1f-b5e5-1c9064709908


Vorneweg, die Aussage ist falsch.
Richtig müsste es lauten "einige WMI Filter sind nicht performant".


Aber zunächst, was ist ein WMI Filter?

Ein WMI Filter ist eine von verschiedenen Möglichkeiten, den Wirkungsbereich einer Gruppenrichtlinie zu beschränken.

Bei einfachen Ausgrenzungen wie einzelnen Computern und Benutzern lässt sich dies auch über eine Sicherheitsfilterung realisieren.

Was ist aber z.B. wenn die Richtlinie nur für alle Windows Server 2008 gelten soll?

In diesem Falle kann z.B. ein WMI Filter benutzt werden.
WMI = Windows Management Instrumentation

mehr Informationen:
http://www.microsoft.com/germany/technet/datenbank/articles/600682.mspx
http://blogs.technet.com/b/askperf/archive/2007/06/12/wmi-architecture-basics.aspx

Der funktionierende Filter für unser Beispiel wäre also:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE “6.0.%” AND ProductType <> “1”

Dieser Filter kann vorab getestet werden. Z.B. mit diesem PowerShell Befehl:

Get-WmiObject -query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '6.0.%' AND ProductType <> '1'"

Wird dieser Befehl nun beispielsweise auf einem Windows 7 System ausgeführt,
erhält man kein Ergebnis.
Für einen WMI Filter innerhalb einer GPO würde dies bedeuten, der WMI Filter liefert das Ergebnis "false".  Die Policy wird nicht angewendet.


Zeiten messen:

Nun aber zum eigentlichen Problem, die Ausführungszeit eines WMI Filters.
Diese lässt sich ebenfalls mit einem PowerShell Befehl ermitteln:

measure-command {Get-WmiObject -query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '6.0.%' AND ProductType <> '1'"} 

Der Output ist wie folgt:

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 80
Ticks             : 800080
TotalDays         : 9,26018518518518E-07
TotalHours        : 2,22244444444444E-05
TotalMinutes      : 0,00133346666666667
TotalSeconds      : 0,080008
TotalMilliseconds : 80,008


Dieser WMI Filter benötigt also in etwa 80 Millisekunden auf meinem Testgerät.

Weshalb also die Idee, ein WMI Filter könnte die Abarbeitung der Gruppenrichtlinien deutlich verlangsamen?

Die Aussage selbst stammt direkt von Microsoft:

"WMI filters can take significant time to evaluate, so they can slow down logon and startup time. The amount of time depends on the construction of the query."


"...  Also, there is no time-out for WMI filters. Use them only when necessary."

http://technet.microsoft.com/de-de/library/cc758471(WS.10).aspx

Diese Aussage ist allerdings nun schon einige Jahre alt und trifft auf moderne Systeme die mit Multi-Cores arbeiten nur noch bedingt zu.

Die Testumgebung:

Um reale Daten zu liefern, hat MVP Mark Heitbrink folgende Testumgebung benutzt (vielen Dank noch einmal an dieser Stelle):

  • 200 GPOs
  • 200 WMI Filter
  • "select * from Win32_IP4RouteTable where Name like '192.168.22.%'"

Ergebnis:

Übernahme GPO Prozess mit 5 "Standard" GPOs: 0,6 - 0,7 Sekunden
Übernahme GPO Prozess mit 200 WMI GPOs: 4,3 - 4,7 Sekunden

Also eine Differenz von 3,5 - 4 Sekunden, also nahezu nichts.


langsamer Filter:

Welcher Filter kann also z.B. ein System ausbremsen?
Nehmen wir doch einmal diesen Filter:


measure-command {Get-WmiObject -query "Select * from Win32_Product where Name like '%Adobe Reader%'"}

Die Ausführung dauert auf meinem Testsystem 66 Sekunden.
(wohl gemerkt bei einem Intel Core i5)

Die schlechte Performance der Win32_Product Klasse ist bekannt.
In diesem Beispiel soll der Filter nach dem "Adobe Reader" suchen.
Ist dieser installiert, wird ein "true" zurückgegeben.

Damit die Abfrage Daten liefern kann, muss diese jedoch intern den MSI Provider benutzen. Dadurch wird ein Konsistenzcheck über alle installierten MSI Pakete ausgelöst, welcher eine Neukonfiguration und Reparaturinstallation aller Pakete startet. Je nach Anzahl der installierten MSI Pakete kann dies viel Zeit in Anspruch nehmen.

Dokumentiert ist dieses Verhalten unter diesem KB Artikel:
http://support.microsoft.com/kb/974524

Dieser Filter ist nur ein Beispiel, ein anderes wäre z.B. der WMI Provider für Active Directory. Dieser kann je nach Query ebenfalls längere Zeit in Anspruch nehmen.


Timeout?

Nun stellt sich also die Frage, gibt es einen Timeout bei der Abfrage von WMI Filtern (einer GPO)?
Gut, das hatten wir bereits geklärt oder?

"... Also, there is no time-out for WMI filters. Use them only when necessary."

Dies trifft aber ab Windows 6.0 SP2 und Windows 6.1 SP1 nicht mehr zu.
Hier wurde ein weiterer WMI Provider für GPO WMI Filter eingeführt, der alle WMI Abfragen die länger als 30s dauern mit "false" beantwortet.

Erkennbar ist dies im gpsvc.log:

GPSVC(424.49c) 12:34:17:615 ProcessGPO: Searching <cn={A865D64C-77CF-4BE5-B600-5712D1C932F9},cn=policies,cn=system,***>
GPSVC(424.49c) 12:34:17:615 ProcessGPO: Machine has access to this GPO.
GPSVC(424.49c) 12:34:17:615 FilterCheck: Found WMI Filter id of: <[***;{C7920CE4-D605-4A2E-9F1F-A3401000132E};0]>
GPSVC(424.49c) 12:34:47:585 FilterCheck: Evaluate returned error. hr=0x80041069


Leider konnte ich bisher keine offizielle Doku zu diesem Verhalten finden.
Ein weiterer Grund, den WMI Filter vorher zu messen und sorgsam auszuwählen.

Fazit:

WMI Filter sind nicht per se unperformant.
Es kommt auf den jeweiligen Filter an.

Als grober Anhaltspunkt kann der Filter vorher mittels dem PowerShell Befehl measure-command gemessen werden.

Tipp:

Die genauen Laufzeiten der WMI Filter sind im gpsvc.log erkennbar.
Das Logging kann per Registry aktiviert werden:

http://blogs.technet.com/b/deds/archive/2010/01/12/group-policy-debug-logging-gpsvc-log-in-windows-7-und-server-2008-r2.aspx


Um das Logfile vernünftig mit dem Policy Reporter von SysPro auszuwerten:
http://www.sysprosoft.com/policyreporter.shtml


Mittwoch, 28. Dezember 2011

The lies of GPOs! #3

# 3

"Gruppenrichtlinien wirken auf Gruppen"

Diesmal ein Mythos aus der Kategorie Basics, der jedoch immer wieder
anzutreffen ist.

In den Einstellungen einer GPO besteht die Möglichkeit eine Sicherheitsfilterung einzustellen.




An dieser Stelle können einzelne Benutzer, Gruppen und Computerkonten eingetragen werden. Der Name Gruppenrichtlinie lässt vermuten, dass diese
über Gruppen angewandt werden.
Einige Admins tragen an dieser Stelle die gewünschte Gruppe von Usern ein, für die die Policy gelten soll. Dies reicht jedoch noch nicht aus um eine Policy anzuwenden. Policies werden erst dann angewandt, wenn diese "verlinkt" sind.


Würde man also beispielsweise die Gruppe "Einkauf" in der Sicherheitsfilterung hinzufügen und die Policy nicht mit einer Organisationseinheit verlinken, hätte dies keine Auswirkung. Die GPO wird nicht angewandt.

Wird die Richtlinie jedoch mit einer Organisationseinheit oder ganz oben auf der Domäne verlinkt, so wird diese angewandt.

Die Sicherheitsfilterung kann die Anwendung der GPO beschränken, Richtlinien werden jedoch nicht auf Gruppen angewandt!

Jede Richtlinie ist in Computer- und Benutzereinstellungen aufgeteilt.
Beinhaltet eine Richtlinie beispielsweise Benutzereinstellungen, so muss diese auch mit einer OU verknüpft werden die User enthält.


Einfaches Beispiel, wir haben eine "Test-GPO-USR" die ausschließlich Benutzereinstellungen enthält. Die Active Directory Struktur schaut wie folgt aus:

└───domain.intern
    ├───germany
    │   ├───com
    │   └───usr
    └───usa
        ├───com
        └───usr


Die Policy soll nun für alle Benutzer der OU "germany" angewandt werden.
Dies wird erreicht, indem die Policy wie folgt verlinkt wird:

└───domain.intern
├───germany
│ ├───com
│ └───usr  ---- Test-GPO-USR
└───usa
├───com
└───usr


Wird die Policy fälschlicherweise wie folgt verlinkt, hat diese keine Auswirkung:

└───domain.intern
├───germany
│ ├───com --- Test-GPO-USR
│ └───usr
└───usa
├───com
└───usr


Die Policy muss also immer anhand ihrer Einstellungen verlinkt werden.
Enhält sie nur Computereinstellungen:
Mit einer OU, die Computerkonten enthält.

Enhält sie nur Benutzereinstellungen:
Mit einer OU, die Benutzerkonten enthält.

Natürlich gibt es auch hier, wie überall, Ausnahmen.
Diese werden allerdings an dieser Stelle nicht behandelt.

Enhält eine Policy beides, also User- und Computereinstellungen, muss diese
in unserem Beispiel wie folgt verlinkt werden:

└───domain.intern
├───germany --- Test-GPO-USR-COM
│ ├───com
│ └───usr
└───usa
├───com
└───usr


Zurück also zum Beispiel mit der Sicherheitsgruppenfilterung der Gruppe "Einkauf". Sollten in diesem Fall also nur die User der Gruppe Einkauf die Policy erhalten?
Nein. Standardmäßig ist folgende Gruppe in der Sicherheitsfilterung vorhanden:

Authentifizierte Benutzer:
Lesen
Gruppenrichtlinie übernehmen

Diese Gruppe beinhaltet alle Computer- und Benutzerkonten im AD.
Soll also anhand der Gruppe "Einkauf" gefiltert werden, muss der
Gruppe "Authentifizierte Benutzer" das Recht genommen werden, die Policy zu übernehmen.


Bedacht werden sollte allerdings, dass dies auch bedeutet, dass ebenfalls (falls vorhanden) die Computereinstellungen nicht mehr angewandt werden.

Alle Computer die den Anteil der Computereinstellungen übernehmen sollen, müssen also dazu berechtigt werden die Policy zu übernehmen.
Dies kann ebenfalls einzeln geschehen, in dem die Computerkonten in den ACLs der Sicherheitsfilterung eingetragen werden oder durch eine Gruppe, die die betreffenden Computerkonten beinhaltet.

Näheres zum Thema Sicherheitsfilterung findet ihr bei MVP Mark Heitbrink:

http://www.gruppenrichtlinien.de/index.html?/HowTo/Richtlinien_pro_Benutzer_einrichten.htm

Der Mythos Gruppenrichtlinien wirken auf Gruppen ist also falsch.

Gruppenrichtlinien wirken immer auf
Computer- bzw. Benutzerkonten.


Sonntag, 11. Dezember 2011

Procmon als Dauerläufer?

Einigen sollte "Process Monitor" ein bekannter Begriff sein.
Der Procmon ist ein äußerst hilfreiches Tool von Sysinternals.

http://technet.microsoft.com/de-de/sysinternals/bb896645


Vor einigen Jahren wurden der ehemalige Filemon (zeichnete Filezugriffe auf) und Regmon (Pendant für Registryzugriffe) miteinander verschmolzen und zusätzlich um einige Funktionen erweitert.
Herausgekommen ist dabei ein geniales Tool, der Process Monitor.


Dieses Programm eignet sich um aktuelle Zugriffe mitzuschneiden.
Was viele nicht wissen, es ist mindestens genauso brauchbar um ein längerfristiges Logging zu aktivieren.


Als Beispiel nehme ich einmal einen "Klassiker", die Frage:

Wer löscht Dateien aus meinem Verzeichnis?

Eine Möglichkeit der Überwachung ist natürlich die Überwachungsrichtlinie.
Auf NTFS Ebene können in den SACLs (System Access Control Lists) Überwachungseinträge angelegt werden.
Setzen wir also einen Überwachungseintrag auf "Unterordner und Dateien löschen", so wird beim Löschen in den betreffenden Verzeichnissen/Dateien ein Eintrag im Eventlog erzeugt. Leider ist das Ganze im Security Eventlog des

betreffenden Servers/Clients auf dem die Daten liegen sehr unübersichtlich.

Damit überhaupt überwacht wird, muss zunächst folgende Policy aktiviert werden:

Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinie\Objektzugriffsversuche überwachen

Was nun aber, wenn ich die gesammelten Logs filtern möchte und ggf. auch archivieren möchte / muss?

Der Process Monitor bietet von Haus aus eine Fülle von Möglichkeiten Daten zu filtern. Sollen nicht nur Filezugriffe geloggt werden, sondern auch Registryzugriffe, so ist der Procmon die bessere Wahl.

Fallen hier nicht zu viele Daten an?

Ja.
Per Default loggt der Process Monitor alle Registry-, Filezugriffe mit.
(um es genau zu sagen, sogar noch etwas mehr, welches aber für diesen Anwendungsfall nicht relevant ist).

Setzt man im Vorfeld die betreffenden Filter, so wird trotzdem alles geloggt.
Das kann Vorteile haben (wenn man zum Beispiel im Nachhinein einen anderen Filter benötigt als ursprünglich vermutet), in der Regel möchte man jedoch nur die definierten Daten aufheben.

Hierfür stellt der Procmon folgende Option bereit:




"Drop Filtered Events" verwirft alle Events, die nicht dem Filter entsprechen.

Wo werden die Logs gespeichert?

Standardmäßig im Pagefile.
Nun ist dies für ein längeres Logging natürlich nicht wirklich sinnvoll.

Die Events können jedoch auch in ein File umgeleitet werden
(unter File > Backing Files ...):




Mit diesem Hintergrundwissen kann es auch schon fast losgehen.
Als Beispiel möchte ich nun alle Löschungen im Verzeichnis C:\myshare
loggen. Als erstes muss ich Filter und Settings definieren.

Dazu wie folgt vorgehen:

1. Process Monitor starten
2. Nur "File System Activity" aktivieren








3. Im Menü Filter > Filter ... wählen
4. "Operation is SetRenameInformationFile" wählen
5. "Path contains C:\myshare" wählen
6. Nun unter Filter > Drop Filtered Events noch aktivieren
7. Diese Settings nun exportieren, File > Export Configuration...

Jetzt kann der Process Monitor mittels Config-File gestartet werden.
Zur Vereinfachung sind in diesem Beispiel alle Files direkt auf C:\ abgelegt:

C:\Procmon.exe /BackingFile C:\mylog /LoadConfig C:\myconfig.pmc /Quiet /Minimized

Nun ist das Logging aktiviert.
In Kombination mit etwas Scripting, kann dies auch zeitgesteuert geschehen (z.B. mittels Aufgabenplanung).

Ein mögliches Beispiel wäre:

C:\Procmon.exe /Terminate
C:\Procmon.exe /BackingFile C:\%date%%random% /LoadConfig C:\myconfig.pmc /Quiet /Minimized

Die entstandenen Logfiles können nun von jedem Client aus geöffnet werden.
Zu beachten ist jedoch, wurde das Logfile auf einem x64 OS erstellt,
so ist auch zum Öffnen des Logs ein x64 System erforderlich.

Der Prozess Monitor muss mit administrativen Berechtigungen gestartet werden.



Dienstag, 29. November 2011

GPO Loopback benötigt Leserechte für den Computer-Account - oder doch nicht?

*** Update siehe Ende des Artikels ***

Dieses mal einen außerplanmäßigen Post (nicht in der Reihe "The lies of GPOs!").

Einige benutzen den Loopbackmodus.

Im Normalfall wird für den Benutzer, der Benutzeranteil der Richtlinie angewandt, die auf der OU des Users bzw. einer darübergelegenen OU verlinkt ist. Der angewandte Computeranteil wird anhand der Position des Computerobjektes im AD gelesen.

In einigen Situationen ist dies jedoch nicht erwünscht.

Stellen wird uns beispielsweise vor, ein Benutzer meldet sich an einem Terminalserver an. Es wirken also die Computereinstellungen, die durch das Computerobjekt des Terminalservers gelesen werden.
Die Benutzereinstellungen werden allerdings anhand des Benutzerobjektes angewandt. Ein Admin eines Terminalserver möchte jedoch meistens ebenfalls Benutzereinstellungen definieren, die nur für die Anmeldung an dem Terminalserver gelten. Oftmals ist es sogar gewünscht, dass die "normalen" Benutzereinstellungen, also diejenigen die über die Position des Benutzerobjektes gefunden werden, ignoriert werden.

Dieses Verhalten lässt sich mit Loopback beeinflussen.
Das genaue Verfahren möchte ich an dieser Stelle nicht erklären,
eine übersichtliche Auflistung findet sich hier:

http://www.msxfaq.de/verschiedenes/gpo.htm

Ist Loopback aktiv, so reichte es bis einschließlich Windows XP und Server 2003 aus, wenn der User Leserechte und Rechte zum Übernehmen der Policy hatte.

Haben wir z.B. eine OU, in der 5 Terminalserver vorhanden sind und es ist eine GPO mit Usereinstellungen verlinkt, so werden diese Settings für alle Benutzer angewandt, die sich an den Terminalservern anmelden (vorausgesetzt Loopback ist aktiv).

Es besteht also keine direkte Möglichkeit, an dieser Stelle eine Beziehung zum Computeraccount herzustellen.
Möchte ich die Policy nur an 2 von den 5 Terminalservern anwenden, so ist dies nur per WMI-Filter möglich.

Ab Windows Vista wurde deshalb ein zusätzlicher Filtermechanismus eingebaut.
Damit die Benutzereinstellungen mittels Loopback angewandt werden, muss zusätzlich das Computerobjekt mindestens Leserechte auf die Policy haben.
Andernfalls werden die Benutzereinstellungen dieser Policy trotz Loopback nicht angewandt. Zu unserem Beispiel also, wird in der Policy nur Terminalserver1 und Terminalserver2 mit Leserechten eingefügt, so wird diese auch nur an diesen 2 Terminalservern übernommen und nicht an allen 5.

Wie oben im Link beschrieben, gibt es zwei Modi für Loopback.
Merge und Replace.

Nun zum Problem.
Was bisher nirgends dokumentiert ist:

Die neue Sicherheitsfilterung gilt nur für Loopback-Merge.
Nicht für Loopback-Replace.

Der offizielle KB-Artikel ist dieser hier:
http://support.microsoft.com/kb/953768/en-us

Ich habe offiziell eine Korrektur für diesen Artikel eingereicht.
Bisher ist der Artikel allerdings noch auf dem alten Stand.

Unter Loopback-Replace wird dieser neue Mechanismus nicht verwendet.

Update 07.03.2013:
Der Artikel wurde nun aktualisiert und ist deutlich präziser.

Donnerstag, 27. Oktober 2011

The lies of GPOs! #2

# 2
"Die Einstellungen einer GPO werden entfernt, wenn die Policy deaktiviert oder gelöscht wird bzw. der Rechner/User nicht mehr in dem SOM (Scope of Management) der GPO ist."

Ebenfalls ein Trugschluss.

Je nach CSE (Client Side Extension) werden Settings teilweise permanent angewandt.

Typische Beispiele:
  • NTFS oder Registry Berechtigungen
  • Eingeschränkte Gruppen
  • Softwareinstallationen (änderbar)
  • Folder Redirections (änderbar)

Ebenfalls nicht zu verachten, Settings unter Sicherheitseinstellungen>Lokale Richtlinien.

Wurde zuvor hier kein Setting definiert, ist das per GPO angewandte Setting ebenfalls "persistent" also dauerhaft.

http://technet.microsoft.com/de-de/library/cc785052(WS.10).aspx

Das Gleiche gilt für eigene Administrative Vorlagen die ihre Werte außerhalb der Bereiche:

"HKLM\Software\Policies"
"HKLM\Software\Microsoft\Windows\CurrentVersion\Policies"
"HKCU\Software\Policies"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Policies"
schreiben.


Last but not least:

GPP = Group Policy Preferences

Den Meisten nicht bekannt, GPP = Tattooing!
GPPs überschreiben gnadenlos vorhandene Einstellungen.

Beim Entfernen bleiben die Werte, die per GPP definiert wurden, vorhanden.


Deshalb, immer vorher überlegen, welche Werte sollen definiert werden und wie können diese im Zweifelsfalle wieder rückgängig gemacht werden!

Sonntag, 23. Oktober 2011

The lies of GPOs! #1

Joa...

Einer muss es ja machen.
Und zwar, diese Fragen festhalten, die immer wieder zum Thema GPO gestellt werden, aber in dem meisten Fällen falsch verstanden werden!

# 1
"GPO? Nein, nutzen wir nicht!"

Wage ich zu bezweifeln.
Habt ihr ein AD? ... Ja haben wir ...

Dann nutzt ihr auch GPOs! Ihr wisst es nur nicht!

Per Default (oh ja lieben wir nicht alle diese Formulierung? :-) ),
sind im AD zwei Policies vorhanden:

Default Domain Policy = DDP

Default Domain Controllers Policy = DDCP

Ohne diese werdet ihr nicht glücklich!
Allgemein reden wir von Sicherheitseinstellungen,
maximale Gültigkeitsdauer des TGT (Ticket Granting Ticket), maximale Gültigkeitsdauer der ausgestellten Tickets usw.
Auf die einzelnen Settings der Policy einzugehen würde den Rahmen sprengen.

Der weitere Klassiker ist jedoch die Kennwortrichtlinie (über dessen Anwendung man sich ebenfalls totdiskutieren kann!). Diese ist in der DDP definiert.


Also merke, nutze ich AD, nutze ich immer Policies.
Ob ich will oder nicht!

Nun, jetzt aber!

Für diesen Post ist es Zeit geworden.

Seit 01.10.2011 bin ich MVP im Bereich GPO!


Ja und nu?

Der Blog soll weiterhin GPO und Windows Server beinhalten.

Bleibt es ein Blog, wird es eine eigene Domain?
Ich weiß es nicht! Ich kann es einfach noch nicht sagen.



Achja, noch was fürs Auge ;-)



Donnerstag, 8. September 2011

RemoteApp per GPO verteilen

RemoteApps per GPO verteilen (unter Vista/Win 7)?

Aus der MMC des "RemoteApp-Manager" lassen sich wunderbar MSI-Files
für die Installation der freigegebenen Anwendungen erzeugen.

Nun liegt es nahe, diese per GPO über das AD verteilen zu wollen
(zumindest dann, wenn kein Softwaredistributionswerkzeug im Einsatz ist).


Eine Zuweisung auf Computerebene funktioniert fehlerfrei.
Auf Benutzerebene kann allerdings folgender Fehler auftreten:

Eventlog 107:
"... Die SQL-Abfragesyntax ist ungültig oder wird nicht unterstützt."


Dieser Fehler tritt nur dann auf, wenn UAC (User Account Control) aktiviert ist.

Wie evtl. einigen bekannt ist, lässt sich das Installationsverhalten des Windows-Installers ebenfalls per GPO beeinflussen.
Per Einstellung "Immer mit erhöhten Rechten installieren" lässt sich definieren,
dass alle Installationen (des Windows-Installers) die unter dem Benutzerkontext ausgeführt werden, mit erhöhten Rechten installiert werden.
Diese Einstellung lässt sich allerdings nicht an eine GPO binden und gilt für
alle Installationen.


In diesem speziellen Fall ändert es allerdings nichts an dem eigentlichen Fehler. Auch hier bricht die Installation mit Event-ID 107 ab.

Ob man eine Installation auf Benutzerebene zuweisen sollte,
ist eine umstrittene Frage.

Sollte es dennoch erforderlich sein die RemoteApp auf Benutzerebene zu verteilen, gibt es aktuell nur eine Möglichkeit - UAC ausschalten.






Freitag, 8. Juli 2011

DHCP Bereich abstimmen - Was passiert hier eigentlich?

Jeder kennt es wahrscheinlich, die Funktion "Abstimmen..." im Kontextmenü des DHCP Bereiches. 

Aber was passiert hier eigentlich?
Für was brauche ich das?

Was ist nun, wenn hier inkonsistente Datensätze angezeigt werden?

Der DHCP Server speichert unterschiedliche Informationen zu den vorhandenen Leases. Diese unterteilen sich in:



  • detaillierte Informationen (gespeichert in der DHCP Datenbank)
  • zusammenfassende Informationen (gespeichert in der DHCP Datenbank)

In einigen Artikeln wird fälschlicherweise behauptet,
die zusammenfassenden Informationen werden in der Registry gespeichert.
Dies ist nicht der Fall.

Stimmen die Informationen nicht überein, kann dies durch eine Bereichsabstimmung korrigiert werden.

Wann tritt das auf?

Werden falsche oder fehlende Informationen des Clients in die Datenbank eingetragen, so kann es zu Inkonsistenzen kommen.

Eine Bereichsabstimmung vergleicht diese Informationen und korrigiert (meistens) die fehlerhaften Einträge.

Donnerstag, 30. Juni 2011

DHCP Server lässt sich nicht autorisieren

Wieder einmal ein seltsames Problem.
Der DHCP Server läuft wunderbar.

Plötzlich behauptet der DHCP-Server er wäre nicht mehr autorisiert.

Gut, das sollte normalerweise kein Problem sein. Hier hinzufügen und gut is. Denkste.
Server steht bereits in der Liste.
Auch beim Rechtsklick im den DHCP-Server im Snap-In => Hier ist nur "Unauthorize" auswählbar.

Ok, ändert allerdings auch nichts am Verhalten.

Lösung:


adsiedit:

Vermeintlich registrierten Server löschen.

CN=Configuration, CN=Services, CN=NetServices.

DHCPServer Dienst neu starten => Nun lässt sich der Server wieder erfolgreich registrieren.


 

[AD / GPO] Replication Access Was Denied - oder Ungeduld wird bestraft!

Soweit zum Hintergrund:
Server 2003 SP2 DC, eine Domain keine Subdomains, Windows 2000 mixed mode,
Eventlogs sauber, dcdiag sauber, netdiag i.O.

Und nun zum eigentlichen Phänomen:
Auf den Clients werden keinerlei Group Policies abgearbeitet.
Es scheint so, als wäre keine Policy auf den User- bzw. Computeraccount verlinkt.
Die Default Domain Policy wird jedoch angewandt.
Keine Fehler im Eventlog, keine Fehler bei gpresult, jedoch keine Policies!

Wird der Domaincontroller heruntergefahren, werden die Policies auf einmal
auf den Clients übernommen (da diese einen anderen DC benutzen).

Abhilfe: dcpromo, herabstufen, hochstufen, das übliche Prozedere.
Da es natürlich schnell gehen soll, sofort nach dem Booten im Anschluss
an das Herabstufen, wieder dcpromo ausführen.
Dcpromo meckert es würde noch ein Objekt für diesen DC geben, allerdings wäre es kein Problem da dieses überschrieben wird => Ok

Nach dem nächsten Reboot dann das Problem:
"Replication Access Was Denied".
KCC beschwert sich ebenfalls, dass keine Connection Objects angelegt werden können.

Ein Blick auf das Computerkonto des DCs verrät einiges:
Als Rolle wird angegeben: "Workstation or Server"
Hier sollte eigentlich "Domaincontroller" stehen.

Abhilfe:
Das Attribut "userAccountControl" des Computeraccounts muss geändert werden. Dieses steht bei DCs auf "532480".
Bei Workstations bzw. Memberservern auf "4096".
Beschrieben hier:
http://support.microsoft.com/kb/329860/en-us

Attribut geändert, Rolle wird wieder korrekt angezeigt, Reboot, Replikation läuft!

Was lernen wir daraus?

Das man manchmal auch wirklich warten sollte!
Wartet man nach dem Herabstufen nicht lange genug,
kann es sein, dass während des Promotionvorgangs das Computerkonto nicht aktualisiert werden kann bzw. dessen Änderung durch ungünstige Replikationsvorgänge wieder überschrieben wird.



Blog eröffnet.