Der benötigte Dienst ist nicht vorhanden - Was jetzt?

Eine Frage die immer wieder in verschiedenen Foren auftaucht. 

Man möchte z.B. den Starttyp eines Dienstes verändern, jedoch wird der benötigte Dienst in der GPMC (bzw. dem GP Management Editor) nicht angezeigt.

Stellen wir uns also z.B. vor, wir möchten den Starttyp des Dienstes "Bluetooth Support Service" auf "Automatisch" setzen. Im GP Management Editor (den wir von einem Server 2008 R2 starten) fehlt jedoch dieser Dienst:

Die Lösung des Problems ist relativ simpel.

Einfach irgendeinen vorhandenen Dienst auswählen.
In diesem Beispiel "Block Level Backup Engine Service".

Jetzt die gewünschten Einstellungen setzen.

Anschließend muss die erzeugte .inf Datei manuell bearbeitet werden.

Dazu zu \\domain.local\sysvol\domain.local\Policies\{GUID}\Machine\Microsoft\Windows NT\SecEdit wechseln.

Hier die Datei "GptTmpl.inf" bearbeiten.

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Service General Setting]
"wbengine",2,""

Der Dienstname muss von "wbengine" auf "bthserv" geändert werden.

Wichtig hierbei, es muss der tatsächliche Dienstname verwendet werden, nicht der Anzeigename.

Anschließend wird der Dienst im GP Management Editor angezeigt.

Alternativ können Dienste auch über Group Policy Preferences konfiguriert werden. Jedoch kann hierbei die Sicherheit (die ACLs) des Dienstes nicht bearbeitet werden.

Update 21.08.2012

Vielen Dank an "bttr" für den Hinweis.

Zusätzlich zu der vorgestellten Methode gibt es noch einen alternativen Workaround. 

Mit dem "sc" - Tool kann auf dem Client (auf dem die Policy per GPMC verwaltet wird) ein temporärer Dienst angelegt werden.

sc create Foo binPath= Bar

Nachdem die Policy konfiguriert wurde, kann der Dienst wieder entfernt werden.

sc delete Foo

"Apply once and do not reapply" - aber so war das nicht gemeint!

Group Policy Preferences sind schon eine tolle Sache.
Mal eben schnell und flexibel ein paar Einstellungen verteilen.

Was aber wenn diese Einstellungen wirklich nur "Preferences" sein sollen?

Im übertragenen Sinne also "Voreinstellungen".

Auch das ist kein Problem.
In den Eigenschaften jedes Items lässt sich eine Checkbox aktivieren:
"Apply once and do not reapply".

Was passiert hier also?
Wie weiß der Client, dass dieses Item schon einmal angewendet wurde?

Das Geheimnis verbirgt sich in der dazugehörigen XML Datei.
Wird die Checkbox aktiviert, so wird in dieser Datei ein Eintrag erzeugt:

<Filters><FilterRunOnce hidden="1" not="0" bool="AND" id="{2B28F5C1-237A-4EDB-8318-F2B862493D89}"

Die genannte ID ist natürlich generiert und unterscheidet sich zwischen den
einzelnen Policies und Items.

Diese ID wird auf dem Client gespeichert:

HKCU\Software\Microsoft\Group Policy\Client\RunOnce

HKLM\Software\Microsoft\Group Policy\Client\RunOnce

Ist unter diesen Schlüsseln bereits die ID des Items enthalten,
wird es nicht erneut angewendet.


In einer perfekten Welt wäre hier der Artikel am Ende und alle wären glücklich. 

Aber das wäre natürlich zu einfach. Die RunOnce GUID bereitet mehr Probleme als vermutet.

Es gibt verschiedene Situationen bei denen es zu ungewünschten Effekten kommen kann:

Kopieren von Items:

 

Wird ein Item in der GUI kopiert, bleibt dummerweise die ID im XML File gleich, was zur Folge hat, dass das kopierte Item nicht angewendet wird.

Sollen also z.B. fünf Dateien kopiert werden und es wird ein Item angelegt und anschließend vier mal kopiert, so wird nur die erste Datei kopiert.
Die folgenden vier Dateien (Items) werden nicht kopiert, da bereits die ID hinter den genannten Registry-Keys hinterlegt sind.

Das genannte Verhalten habe ich bereits hier reklamiert:

http://social.technet.microsoft.com/Forums/nb-NO/winserverGP/thread/ab2fa3c8-3ad0-4068-8a99-da70f7f1f34e

Im Nachhinein musste ich feststellen, dass diese teilweise schon seit 2009 bekannt ist, jedoch immer noch keine Lösung seitens Microsoft vorliegt.

Item Level Targeting und RunOnce:

Erschwerend hinzu kommt, dass "Apply once and do not reapply" nicht wirklich mit Item Level Targeting (Zielgruppenadressierung) zusammen spielt.

Auch wenn die Bedingungen des ILT nicht erfüllt sind, wird die ID des RunOnce Filters in die Registry gespeichert.

Das Item wird also nie mehr angewendet, auch wenn die Bedingungen des Item Level Targeting irgendwann erfüllt sein sollten.

Fehlende Fehlerprüfung:

Auch hier wurde nicht (oder wenig) mitgedacht.

Selbst wenn das Item nicht korrekt angewendet werden konnte,
die ID wird auch dann in der Registrierung hinterlegt.

Besserung in Sicht:

Die gute Nachricht, zwei der drei Fehlerquellen werden mit SP1 für Windows 7 bzw. Server 2008 R2 beseitigt.

Verantwortlich hierfür ist dieser Hotfix:
http://support.microsoft.com/kb/2284538/en-us

Was bleibt, das Kopieren der Items.
Dieses erzeugt auch unter SP1 noch denselben Fehler.

Update 20.08.2012

Die gute Nachricht, unter Windows Server 2012 wird beim Kopieren von Items eine neue ID erzeugt!

GUID zu Name, Name zu GUID

Namen sind Schall und Rauch.

Das weiß jeder, der sich bereits einmal mit Active Directory, Datenbanken oder ähnlichen Systemen befasst hat.

Genauso ist es auch bei den Gruppenrichtlinien.

Der Anzeigename einer Richtlinie kann jederzeit geändert werden. 

Der Globally Unique Identifier (GUID) jedoch bleibt immer gleich.

Da der Mensch sich von Natur aus jedoch solche Zeichenfolgen nicht unbedingt merken kann, wird oftmals der Anzeigename benutzt.

Wie komme ich aber am schnellsten von der GUID auf den Namen?
Oder vom Namen auf die GUID der Richtlinie?


Microsoft selbst nennt einige Wege.
Einer davon, das Skript "search.vbs".

http://support.microsoft.com/kb/216359/en-us

Wo wird also der Name der GPO gespeichert?

Noch unter Windows 2000 Zeiten wurde der Name in der GPT.ini innerhalb des
GPT (Group Policy Template) gespeichert

Wir reden also von:

\\domain.local\sysvol\domain.local\Policies\{GUID}\GPT.ini

Ab Windows 2003 wird jedoch nur noch ein Dummy Name an dieser Stelle gespeichert. In der Regel displayName=Neues Gruppenrichtlinienobjekt.

(dies unterscheidet sich natürlich zwischen den Sprachversionen der GPMC).

Der eigentliche Name steht da wo er hingehört, im AD.

Zu finden unter:

CN=Policies,CN=System,DC=domain,DC=intern
Attributname: DisplayName

Was fällt uns also noch ein?

Die GPMC Sample Scripts.

Ja eine Möglichkeit.

Dort gibt es unter anderem ein Skript namens "ListAllGPOs.wsf".

 

Was gibt es noch?

Ja richtig PowerShell!

Dort gibt es ein cmdlet mit dem Namen "Get-GPO".

Problem nur, dieses Modul muss erst einmal importiert werden...

Ok, noch einmal einen Schritt zurück.

Im Prinzip lässt sich der Name bzw. die GUID mit jedem Tool ermitteln, dass LDAP spricht.

Was könnte man also benutzen das ohnehin schon an Bord ist?
dsquery! Jeder Server der das Feature "AD DS Snap-Ins and Command-Line Tools" installiert hat (was DCs logischerweise haben sollten :-) ) kann dsquery benutzen.

Um das Ganze abzukürzen, hier ein kleines Batchfile mit dem ihr nach Name oder GUID suchen könnt:

@echo off

:choice
cls
set /p gpname=Please enter name or GUID:
Echo
cls

Echo.
Echo List of GPOs
Echo.

Dsquery * domainroot -filter (objectCategory=groupPolicyContainer) -attr Name DisplayName -limit 0 | find "%gpname%" /i
Echo.

set /P c=Do you want to search again [ENTER/N]?
if /I "%c%" EQU "" goto :choice
 
rem Die letzte Zeile kann nach Bedarf weggelassen werden.
rem if /I "%c%" EQU "N" exit

Es erscheint dieser Prompt:

Danach das Ergebnis:

Old School, aber funktioniert.

The lies of GPOs! #6

#6

"In der GPMC gibt es keine Suchfunktion"

Kurz und knapp: Es gibt sie doch!
Leider versteckt sich diese Suche etwas:

Rechtsklick auf die Domäne > Suche

 

Danach erscheint dieser Dialog:

Was aber wenn ich eine bestimmte Einstellung suche?
 

Auch kein Problem. 

ADMX Vorlagen lassen sich durchsuchen. 

Rechtsklick > Filteroptionen

Anschließend kann beliebig gefiltert werden.

Leider muss man anmerken, dass keine dieser Methoden wirklich zeitgemäß ist. Was man vermisst ist eine "live-search", die Policies und Einstellungen sofort filtert ohne dass man in eine direkte Such- oder Filtermaske wechseln muss. Nunja, man kann nicht alles haben ...

CSEs die ohne Richtlinienänderung Einstellungen erneut setzen

Wie im vergangenen Post bereits angekündigt, werden Richtlinien unter gewissen Umständen auch ohne Änderung der Versionsnummer der Group Policy erneut angewendet.

Das Verhalten der Client Side Extensions wird jedoch auch durch einen Registrykey beeinflusst. Dieser Key nennt sich "NoGPOListChanges" und ist zu finden unter:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\GUID\

Existiert dieser Key nicht oder er ist auf 0x1 gesetzt,
werden die Einstellungen dieser CSE auch ohne Versionsänderungen erneut angewendet.
Ich habe mir einmal die Mühe gemacht, eine Liste zu erstellen, mit dem Standardverhalten der folgenden CSEs:

Name ohne Änderung angewendet Audit Policy Configuration Ja Deployed Printer Connections Ja Enterprise QoS Ja Folder Redirection Ja Group Policy Applications Ja Group Policy Data Sources Ja Group Policy Device Settings Ja Group Policy Drive Maps Ja Group Policy Environment Ja Group Policy Files Ja Group Policy Folder Options Ja Group Policy Folders Ja Group Policy Ini Files Ja Group Policy Internet Settings Ja Group Policy Local Users and Groups Ja Group Policy Network Options Ja Group Policy Network Shares Ja Group Policy Power Options Ja Group Policy Printers Ja Group Policy Regional Options Ja Group Policy Registry Ja Group Policy Scheduled Tasks Ja Group Policy Services Ja Group Policy Shortcuts Ja Group Policy Start Menu Settings Ja IP Security Ja Microsoft Offline Files Ja Software Installation Ja 802.3 Group Policy Nein CP Nein Internet Explorer Branding Nein Internet Explorer Machine Accelerators Nein Internet Explorer User Accelerators Nein Internet Explorer Zonemapping Nein Microsoft Disk Quota Nein QoS Packet Scheduler Nein Registry Nein Remote Desktop USB Redirection Nein Scripts Nein Security Nein TCPIP Nein Windows Search Group Policy Extension Nein Wireless Group Policy Nein

Die vollständige Liste incl. GUIDs der CSEs findet ihr hier:

https://skydrive.live.com/redir.aspx?cid=62a6d19ffda7f555&resid=62A6D19FFDA7F555!112&parid=62A6D19FFDA7F555!110

Nun muss nur noch definiert werden, was man hier unter "angewendet" versteht. Einige CSEs wie z.B. "Software Installation", "Folder Redirection" können bekanntlich nur im Vordergrund ausgeführt werden.

Wenn man also von "die Policy wurde erneut angewandt" spricht, so ist das nicht ganz korrekt. Die Einstellungen der CSE "Software Installation" werden also beim Background-Refresh erneut gezogen, die eigentliche Anwendung der Policy kann jedoch nur im Vordergrund erfolgen, d.h. beim nächsten Startup oder Logon.

The lies of GPOs! #5

#5

"Nur geänderte Gruppenrichtlinien werden erneut angewendet"

Jede Richtlinie speichert die aktuelle Version der Richtlinie an zwei Stellen.
Einmal im Active Directory und einmal in der gpt.ini.

Die gpt.ini liegt im Sysvol des Active Directory unter \\domain.intern\sysvol\domain.intern\Policies\{GUID}.

Es wird sowohl die Version der User- als auch Computerpolicy gespeichert.
Wie der gespeicherte Wert berechnet wird, lässt sich hier nachlesen:

http://blogs.technet.com/b/grouppolicy/archive/2007/12/14/understanding-the-gpo-version-number.aspx

Die allgemein verbreitete Meinung:
Policies werden nur dann erneut angewendet, wenn sich die Versionsnummer ändert.

Testumgebung:

OK, schauen wir uns das in einer Testumgebung einmal an.

In diesem Beispiel wurden drei GPOs angelegt.
In den Richtlinien wurde als Beispiel das Logging für GPOs aktiviert.

Beispiel gpo1:

In gpo2 wurde das Logging für "Datenquellenrichtlinien-Verarbeitung" aktiviert.
In gpo3 wurde das Logging für "Geräterichtlinienverarbeitung" aktiviert.

Wurden die Richtlinien bereits angewandt und wir führen ein "gpupdate" aus,
werden die Richtlinien nicht erneut angewendet.

Dies wird im gpsvc.log vermerkt:
GPSVC(3f0.1850) 12:46:19:400 ProcessGPOs: Processing extension Registrierung
GPSVC(3f0.1850) 12:46:19:400 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3f0.1850) 12:46:19:400 CompareGPOLists:  The lists are the same.
GPSVC(3f0.1850) 12:46:19:400 CheckGPOs: No GPO changes and no security group membership change and extension Registrierung has NoGPOChanges set.

Änderung an gpo1:

Wenn wir nun also gpo1 ändern, so sollte diese erneut angewendet werden.
Die Richtlinien gpo2 und gpo3 jedoch nicht.

Um es zunächst ohne Logfile zu überprüfen, ändere ich manuell mittels regedit alle Werte ab, die von den Policies gesetzt werden.

Per Policy werden diese Werte gesetzt:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
    LogLevel    REG_DWORD    0x2 von gpo1
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
    LogLevel    REG_DWORD    0x2 von gpo2
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
    LogLevel    REG_DWORD    0x2 von gpo3

Diese Werte ändere ich manuell per regedit auf:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x3
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x3
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x3

Wenn nun nur gpo1 erneut angewendet wird, sollte das Ergebnis wie folgt aussehen:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x2 durch die änderte gpo1 gesetzt
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x3 gleichbleibend, da gpo2 nicht verändert wurde
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x3 gleichbleibend, da gpo3 nicht verändert wurde

Das Ergebnis ist jedoch:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x2
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x2
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x2

D.h. es werden alle Policies erneut angewendet, obwohl nur Policy "gpo1" geändert wurde.

Zu erkennen ist das auch im gpsvc.log:
GPSVC(3b0.444) 15:58:28:765 ProcessGPOs: Processing extension Registrierung
GPSVC(3b0.444) 15:58:28:765 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3b0.444) 15:58:28:765 CompareGPOLists:  Different version numbers found

...

GPSVC(3b0.444) 15:58:28:859 ParseRegistryFile: Entering with <\\domain.intern\sysvol\domain.intern\Policies\{A52DB6EF-C428-4FA6-AC0E-C614891A9CC1}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:859 SetRegistryValue: LogLevel => 2  [OK]
...
<\\domain.intern\sysvol\domain.intern\Policies\{A8CD3DB6-5A58-4437-82EB-DDD14A062AA6}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:875 SetRegistryValue: LogLevel => 2  [OK]
...
<\\domain.intern\SysVol\domain.intern\Policies\{4F685E24-6F86-4088-B45C-E9BA66B06B6C}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:906 SetRegistryValue: LogLevel => 2  [OK]
...

Fazit:

In diesem Beispiel wurden also auch Policies angewandt, deren Versionsnummer sich nicht geändert hat (gpo2 und gpo3).

Das Geheimnis - Ändert sich eine GPO innerhalb einer CSE (Client Side Extension), so werden alle Policies, welche Einstellungen dieser CSE besitzen, erneut angewendet.

Habe ich also zum Beispiel 100 GPOs verlinkt, die Einstellungen innerhalb der "Administrative Vorlagen" beinhalten und ich ändere nur eine GPO von diesen, so werden die "Administrativen Vorlagen" von allen 100 Policies erneut angewendet!

Zusätzlich zu diesem Verhalten, lässt sich pro CSE einstellen, ob Einstellungen auch ohne Änderungen übernommen werden sollen.
Dieses Thema werde ich jedoch erst im nächsten Post behandeln.

The IP Address is not a valid DNS address ...

Diesmal ein Phänomen aus dem Bereich DHCP/DNS.
Beim Hinzufügen eines DNS Servers in den Bereichsoptionen des DHCP Servers erscheint folgende Fehlermeldung:

"The IP Address x.x.x.x is not a valid DNS address, do you still want to add it ?"

Bei dieser Fehlermeldung kommen einem erst einmal folgende Gedanken in den Sinn:

• Wurde eine falsche IP-Adresse angegeben?
• Ist der DNS Server vom DHCP Server aus erreichbar?
• Lassen sich Adressen per nslookup auflösen?
• Liegt eine Fehlkonfiguration am DNS Server vor?
• Blockiert eine Firewall ggf. den Netzwerkverkehr?

Nachdem alle diese Fragen geklärt sind und der Server aber sich dennoch nicht ohne Fehlermeldung hinzufügen lässt, stellt sich letztendlich noch die Frage:

• Wie ermittelt der DHCP Server ob es sich um einen gültigen DNS Server handelt? 

Gute Frage. Innerhalb der Technet-Pages finden sich keine relevanten Informationen. Auch sonst nur wenige Suchergebnisse die sich mit diesem Thema befassen.

Deshalb, schauen wir doch einmal was hier passiert.
Dazu hier ein Mitschnitt mittels WireShark:

Nach einer kurzen Analyse lässt sich feststellen, es wird folgende Abfrage ausgeführt: "Standard Query SOA".
Vermeintlich wird also der "Start of Authority" Eintrag abgefragt.
Ok, vielleicht fehlt dieser DNS Eintrag auf dem betreffenden Server.
Dies lässt sich per DNS SnapIn ermitteln oder per nslookup:

nslookup -type=soa domain.local dnsserver.domain.local

Auch das scheint nicht der Fehler zu sein.
Der SOA Record ist vorhanden. Fehlen ggf. noch andere DNS Einträge?
Die benötigten DNS-Records für das Active Directory lassen sich mittels
dnslint /ad prüfen:

http://support.microsoft.com/kb/321045/de
Auch hier, soweit keine Fehler ersichtlich.
Ok, nun also noch einmal ein Blick auf den WireShark Mitschnitt.

Recursion desired: Do query recursively.
Recursion available: Server can do recursive queries.

In einigen Mitschnitten erscheint auch:

Recursion available: Server can't do recursive queries.

Es scheint also eine Prüfung stattzufinden, ob der angegebene DNS Server
"recursion queries" durchführen kann.

Als "recursion query" bezeichnet man den Vorgang, wenn ein Client Anfragen an den DNS Server stellt, dieser die Anfragen aber nicht beantworten kann und deshalb die Anfragen an einen weiteren DNS Server weiterreicht.

Ok, nun sind wir also wieder einen Schritt weiter.

Üblicherweise werden die recursion queries and die "Root Hints" weitergegeben.
Zumindest dann, wenn keine Forwarder eingerichtet wurden.

Hier die Liste der default Root Hints:

Die recursion lässt sich auch direkt am DNS Server testen:

In diesem Falle schlägt diese, wie erwartet, fehl.
Ein Blick in die Firewall des Unternehmens verrät, dass diese Anfrage dort geblockt wird. Nachdem eine Ausnahmeregel definiert wurde, lässt sich der DNS Server ohne Fehler im DHCP Server hinzufügen.
Der recursion test ist ebenfalls erfolgreich.

Fazit:
Beim Hinzufügen eines DNS Servers prüft der DHCP Server (besser gesagt das DHCP Snap-In) ob der DNS Server "recursion queries" ausführen kann.
Hat der DNS Server keine Verbindung zu den Root Hints bzw. die Verbindung ist vorhanden aber die vorhandenen Firewall Richtlinien verhindern die Kommunikation, lässt sich der DNS Server nicht hinzufügen.