Troubleshooting Gruppenrichtlinien – Softwareinstallation

http://hannes-schurig.de/18/06/2010/troubleshooting-gruppenrichtlinien-softwareinstallation/

So, vorm Wochenende nochmal eine Zusammenfassung, was mich die letzten Arbeitstage so beschäftigt hat und was ich draus lernen konnte.
Also, Hauptthema ist es, nicht funktionierende Gruppenrichtlinien (GPO) ordentlich zu untersuchen und den Fehler zu finden. Augenmerk lege ich jetzt vor allem auf Softwareinstallationen via GPO, hier kommt es zu den meisten Fehlern.

Zuerst:

Funktioniert mal etwas nicht mit den GPOs ist die Fehlersuche eher
mühsam, da es keine zentrale Sammelstelle für Fehlerberichte gibt.
Zumindest wenn man nicht den Zugriff auf den DC hat, was meistens der
Fall ist. Und auch so sind die Fehler meisten clientseitig.
Das heißt unsere Suche wird vor allem auf den Computern stattfinden, bei
denen die Gruppenrichtlinie nicht wie erwartet funktioniert.

Wie gehen wir also vor:
Stimmen die Gruppenrichtlinieneinstellungen?

Zuerst sollten wir bei Problemen natürlich klar stellen, dass es
nicht an der Gruppenrichtlinie selbst liegt. Dazu ein Blick in das GPO.
Stimmt die Verknüpfung der GPO, richtige OU? Ist die Verknüpfung aktiviert und erzwungen? Ihr müsst sie nicht erzwingen aber spätestens bei Problemen sollte man zum Troubleshooting die Option aktivieren. Stimmen
die Gruppen, auf die die Gruppenrichtlinie angewendet wird? Ist der
Computer auch in der OU mit der verknüpften GP? Ist der Rechner auch in
der entsprechenden (oben geprüften) Gruppe?

Stimmt alles, dann weiter zu den Details und den Einstellungen.

Stimmen die Einstellungen? Davon sollte man ausgehen. Merkt euch die Computer- und die Benutzerversion unter Details. Ist Datum und Uhrzeit der letzten Änderung richtig? Ist der Objektstatus „aktiviert“?

Nun der knackige Teil, die Delegierung. Ich würde es einfach Rechte nennen.

Stimmen die Gruppen mit ihren jeweiligen Rechten? Authenticated Users mit Lesen drin? Bei Computereinstellungen ist das eine gute Idee.
Lesen und Lesen (durch Sicherheitsfilterung) sollte bei den Gruppen
stehen, die die Zielobjekte enthalten. Klickt auf Erweitert und gleich
nochmal auf Erweitert. Prüft hier die Berechtigungen der Gruppen nochmal
im Detail. Haben die Usergruppen die Rechte Lesen und „Gruppenrichtlinie übernehmen“? Je nach Gruppenrichtlinie solltet ihr bei den Admins das Recht „Gruppenrichtlinie übernehmen“ rausnehmen.

Stimmt alles? Gehen wir auf Nummer Sicher:
Geht in den Tab „Effektive Berechtigungen“ und gebt
dort testweise eine Person/ein Computerobjekt ein, dass die
Gruppenrichlinie übernehmen sollte. Und noch ein Versuch mit einem
Objekt, dass die Gruppenrichlinie nicht übernehmen sollte. Ist bei beiden das „Gruppenrichtlinie übernehmen“ Recht korrekt gesetzt? 1x ja, 1x nicht. Gut.

Fehlersuche auf dem Computer
Gruppenrichtliniensatz

Zuerst lassen wir uns den Gruppenrichliniensatz auf dem Computer anzeigen, wo etwas nicht stimmt:
Windows XP:
gpresult
Windows 7:
gpresult /r

Wir schauen zuerst auf die ersten Zeilen im Kopf der Ausgabe. Links WinXP- , rechts Windows 7 Ausgabe:

Wann war die letzte Aktualisierung der Gruppenrichtlinie?
Ist Datum und Uhrzeit aktuell oder liegt die letzte Aktualisierung
Tage/Wochen/etc zurück? Dann solltet ihr überprüfen, warum die
Gruppenrichtlinie nicht aktualisiert wird. gpupdate /force in die Konsole schicken und nochmal prüfen.
Von wo wurde die Richtlinie angewendet? Steht
dort ein brauchbarer DC oder vielleicht sogar gar nichts oder „Nicht
zutreffend“? Prüft, ob der Computer ordentlich in die Domäne eingebunden
ist. Löscht ggf. das Computerprofil und nehmt den Computer neu in die
Domäne.
Welche Gruppenrichtlinien wurden angewendet? Ist eure mit dabei? Wenn nicht… na dazu schreibe ich den Mist hier ja, weiterlesen.
Wurde sie gefiltert (nicht angewendet)? Dann prüft den Grund und geht der Sache nach. Google hilft bei komischen Filtergründen.
Stimmen die „Sicherheitsgruppen“? Habt ihr das Computerobjekt in die
Gruppe genommen, auf die die Gruppenrichtlinie angewendet wird?

Bei meinen 2 Beispielen ist der Computer jeweils nicht in der
benötigten Sicherheitsgruppe, SoftwareVertTEST, auf die die
Gruppenrichtlinie angewendet wird.
So schaut es aus, wenn die Gruppenrichtlinie angewendet wurde:

Links die Konsolenausgabe von gpresult /r auf einem Windows 7 System. Rechts der Report, den ich mit gpresult /h „c:\test.html“ erzeugt habe.
Es wurde jeweils die Gruppenrichtlinie übernommen. Zudem ist der
Computer jetzt auch in einigen zusätzlichen Gruppen, die er braucht, um
auf das Netzlaufwerk zuzugreifen. Denn dort liegen die ganzen Programme,
die installiert werden sollten.
Hat euer Computer-/Benutzerobjekt Zugriff auf den Share, wo die zu installierenden Programme liegen?
Geht zu dem Ordner, klickt auf Erweitert im Sicherheits-Tab, dann auf
Erweitert und in den Effektive Berechtigungen Tab und lasst euch die Rechte des Test/Problemobjekts auflisten. Wenn nicht dann müsst ihr die Gruppe, auf die die Gruppenrichtlinie angewendet wird, eintragen und Rechte vergeben.

Wir sind immernoch im exportierten HTML Reports des Windows 7
Rechners. Prüft hier die Revision der angewendeten Richtlinie. Die
Revision solltet ihr euch ja oben merken, die steht in den Details der
GPO. Computerversion steht im HTML bei den Computereinstellungen und die
Benutzerversion logischerweise weiter unten bei der Revision unter den
Benutzereinstellungen. Angegeben ist diese Version mit AD (XXX), Sysvol
(XXX). Computer und GPO solten hier 4x den selben Wert aufzeigen
(eigentlich 8x, 4x Computer- und 4x Benutzerversion).

Auf
Windows XP kann man leider keine HTML Reports erstellen (glaub ich).
Mit gpresult /z /scope computer könnt ihr euch die Details der
Computereinstellungen ansehen, mit /scope user detaillierte
Usereinstellungen. Prüft einfach manuell, ob eure neuesten Änderungen an
der GPO hier schon richtig gelistet sind.
Gruppenlinienobjekt „Nicht zutreffend“? Alte Einstellungen? Ursprung „Entferntes Paket“? Da stimmt was nicht. Auch gpupdate /force bringt die korrekten Einstellungen nicht zum Vorschein?

Gruppenrichtlinie lokal zurücksetzen

Öffnet die Registry und geht zum Schlüssel
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
Policy. Exportiert ihn und löscht ihn komplett.
Zieht den Netzwerkstecker und macht einen Neustart. Neugestartet? LAN Kabel wieder rein, gpupdate /force
und durch den Neustart sollte die Gruppenrichtlinie wieder komplett neu
übernommen werden. Noch Probleme? Den Key nochmal löschen, mit CCleaner die Registry und den PC von Tempkram bereinigen, selbe Spiel nochmal. gpupdate /force und gpresult /h (W7) bzw gpresult /z /scope computer (WinXP) durchführen, Einstellungen und Revision Number überprüfen.

Computerobjekt resetten

Nehmt den Computer aus der Domäne, löscht das Computerobjekt aus der
Domäne. Startet neu und nehmt den Computer (nach Objekterstellung)
wieder in die Domäne. Vergesst nicht, dem Computerobjekt wieder alle
Gruppen zuzuweisen, wie es sein soll. gpupdate /force und gpresult /h (W7) bzw gpresult /z /scope computer (WinXP) durchführen, Einstellungen und Revision Number überprüfen.

Ereignisanzeige

Hier ist Hilfestellung für mich schwer zu geben, obwohl die Ereignisse wirklich wichtige Hilfe geben können.
Auf jeden Fall solltet ihr die Protokolle von Anwendung und System
überprüfen. Startet den Rechner neu und schaut bei „Datum und Uhrzeit“,
wo der Neustart beginnt. Geht ab dort alle Meldungen durch, es reicht
wahrscheinlich erstmal nur alle Warnungen und Fehler durchzusehen.
Hier kann verdammt viel stehen, und ich habe eine generelle Lösung für die meisten gelisteten Probleme: Google.
Die meisten Fehler sind durchaus bekannt und müssen dann nur ordentlich
behandelt werden, kämpft euch durch das Informationsdickicht des
Internets.

Aber: Keine Panik schieben wenn dort einige
Warnungen und Fehler auftauchen, die meisten sind ganz normal. Auch
Meldungen zu Gruppenrichtlinienfehlern sind nicht immer ausschlaggebend.
Zum Beispiel hier ein Screenshot von einem W7 PC auf dem alle
Gruppenrichtlinien korrekt funktionieren und alles gut läuft:

Hier muss man einfach ein Gefühl entwickeln, welche Fehler normal sind
und welche wirklich durch GPO Probleme entstehen. Wenn auf einen
Computer mehrere Richtlinien angewendet werden (so ab 5 Richtlinien)
dann müssen Fehler nicht unbedingt von der Richtlinie kommen, die nicht
funktioniert. Nachher rennt man falschen Fehlern hinterher.

Softwareinstallationen – Fehler: %%1274 / Fehler:%%2

Fehler 1274 deutsch:
Die Zuweisung der Anwendung (…) ist fehlgeschlagen. Fehler: %%1274
Die Änderungen an den Softwareinstallationseinstellungen wurden nicht
angewendet. Die Installation (…) wird bis zur nächsten Anmeldung
verzögert (…) Fehler: %%1274

1274 Fehler englisch:
The assignment of application (…) The error was: %%1274
Failed to apply changes to software (…) deployment through Group Policy
(…) has been delayed until the next logon (…) The error was: %%1274

Dieser Fehler hat mir die letzten Tage viele Stunden Kopfschmerzen bereitet.
Wenn also Programme nicht installiert werden, obwohl das GPO auf den
Computer angewendet wird und der gpresult alles korrekt wiedergibt, dann
liegt es an Fehl(de)installationen auf dem PC. Bei
Softwareinstallationen via GPO kann das vorkommen, wenn man Programme
fehlerhaft deinstalliert und dann versucht via GPO wieder installieren
zu lassen.
So konnte ich den Fehler beheben:
Deinstalliert die Software, über die bei diesem Fehler gemeckert wird
und die nicht via GPO installiert werden kann. Wenn es sich um Patches
handelt deinstalliert ihr am besten das ganze Softwarepaket. Reinigt die
Registry und eventuell zurückbleibende Ordner. Zieht euch das Microsoft Installer Clean Up Tool und geht die folgenden Schritte durch.

Microsoft Install Clean Up Utility

Download hier.
Wird ein Programm nicht ordnungsgemäß deinstalliert oder fehlerhaft
installiert (und danach von Hand gelöscht), so kann es vorkommen, dass
der Microsoft Installer trotzdem noch Reste des Programms findet und es
deswegen zu Problemen bei einer Neuinstallation kommt.
Das Tool „Microsoft Install Clean Up Utility“ kann diese Überreste bereinigen.
Download: 1, 2, Google

Wird eins von euren gerade deinstallierten Programmen gelistet, dann
wurde es teilweise noch im System gefunden. Mit dem Tool lassen sich
diese Reste auch noch entfernen.
LAN-Kabel rausziehen und neustarten (damit beim Neustart keine Installationen/Scripts via GPO diesen Vorgang behindern).
Sollte das Programm wieder in der Liste stehen kombiniert diesen Trick am besten mit dem lokalen Registry Reset (siehe oben „Gruppenrichtlinie lokal zurücksetzen“) und gezogenem LAN-Kabel.
via

Ergänzung 1: fehlerhafte GPO Softwareinstallationen einzeln(!) zurücksetzen
Es lassen sich einzelne Anwendungen einer Softwareverteilungs-GPO zurücksetzen.
Ohne großartige Deinstallation und Reinigung durch das Install Clean Up
Utility (s.o.) wird die GPO das Produkt eigenständig auf diesem PC neu
installieren.
Dazu muss nur der korrekte Unterkey von HKLM/Software/Microsoft/Windows/CurrentVersion/Group Policy/AppMgmt/

no images were found

/ gelöscht werden. Jeder dieser SID Schlüssel in AppMgmt hat einen Wert namens „Deployment Name“, der den Namen der Software beinhaltet, die verteilt wurde (in dieser Situation fehlerhaft). Diesen Schlüssel also löschen, gpupdate /force, ggf. den Stand mit gpresult /h überprüfen, Neustart, die Software wird neu verteilt.
Mehr dazu hier im ausführlichen Artikel

Ergänzung 2: Einzelne Installationen trotz Löschung/Rücksetzung noch aktiv
Falls ein via GPO zu installierendes Paket Probleme macht und man die
GPO löscht, ein Client aber trotzdem noch versucht die entsprechende msi
zu installieren, muss man nebst dem GPO Eintrag (siehe oben
„fehlerhafte GPO Softwareinstallationen einzeln(!) zurücksetzen“ und
„Gruppenrichtlinie lokal zurücksetzen“) auch noch den Installer Eintrag
unter HKLM\Software\Classes\Installer löschen! Das Paket erschien bei
mir nie bei den installierten Programmen, weshalb ich es auch nicht
deinstallieren konnte. Es war ja auch nie richtig installiert, aber
trotzdem hat der Windows Installer sich das Produkt “gemerkt”, als wäre
es installiert.
Dieser Tipp kommt von roach.

Weitergabe oder Verwendung dieser Anleitung nur mit voller Quellen- und Autorangabe! Ich bitte euch, seid fair.

So, ich hoffe einigen von euch konnte ich helfen oder zumindest einige
Denkanstöße geben, die man manchmal in der Fülle der zu prüfenden Dinge
einfach vergisst oder übersieht. Schönes Wochende!

fehlerhafte GPO Softwareinstallationen zurücksetzen

http://hannes-schurig.de/19/08/2010/fehlerhafte-gpo-softwareinstallationen-zurucksetzen/

Es kann vorkommen, dass eine Softwareinstallation via GPO
nicht so rund läuft und die Software fehlerhaft installiert wird. Die
Gruppenrichtlinie sieht die (fehlerhaft) installierte Software und hakt
diesen Punkt also ab, die Softwareinstallation bleibt fehlerhaft.
Wenn nun auch die manuelle Deinstalltion der Software nichts daran
ändert und die Gruppenrichtlinie immernoch nicht die Software neu
zuweisen will, muss ein Trick her.
Grundsätzlich kann natürlich mein Guide zum Troubleshooten von GPO-/Softwareinstallationsfehlern helfen.

Ich möchte jetzt aber noch einen Trick ergänzen, den ich gestern entdeckt habe.

Grundsätzlich hilft bei diesem Problem (Installation fehlerhaft,
Deinstallation wird nicht erkannt) wie erwähnt das Löschen des Registry
Keys
HKLM/Software/Microsoft/Windows/CurrentVersion/Group Policy
und die komplette Gruppenrichtlinie wird erneut angewandt.

Wenn in der Softwareinstallation nun aber 5-10 Programme stehen und dann alle neu installiert werden ist das eine wirklich zeitraubende Lösung. Möglicherweise verlorene Programmfeatures, Updates, Pakete, Einstellungen durch die Neuinstallation sind auch oft ärgerlich.
Also wäre es besser nur die Installation zurückzusetzen, die tatsächlich fehlerhaft ist.

Geht in den Group Policy Key (siehe oben), dort in „AppMgmt
und ihr werdet einige GUID Schlüssel sehen. Jeder Schlüssel
representiert eine Softwareinstallation. Klickt eine GUID an und schaut
euch den Wert „Deployment Name“ an, dort steht der Softwarename, den ihr in der GPO vergeben habt.
Löscht den Schlüssel der fehlerhaften Software und startet den Computer neu.

Die GPO wird jetzt diese Software neu installieren.
Gibt es immernoch Probleme dann deinstalliert die
Software erneut, löscht alle Spuren (Regcleaner wie CCleaner), löscht
den eventuell verbliebenen Installerverweis mit Microsoft Installation
CleanUp Utility, löscht nochmal den Registry Key und rebootet nochmal
den PC. Spätestens jetzt sollte die Software so korrekt installiert
werden. Wenn nicht liegt der Fehler eher woanders

Отключаем действие групповых политик в Windows 7

http://winitpro.ru/index.php/2012/07/30/otklyuchaem-dejstvie-gruppovyx-politik-v-windows-7/

В этой статье поговорим об очередной нестандартной задаче: вопросах отключения действия групповой политики на компьютере
в составе домена Windows. Зачем, собственно, может понадобиться такая
функция? Ответ на этот вопрос в каждом конкретном случае индивидуален.
Это может быть желание регионального администратора ограничить
применение к своему рабочему компьютеру ограничений, накладываемых
групповыми политиками, и/или желание уйти из-под недремлющего ока
безопасников (и удалить на своем компьютере антивирус или же некую
программу контроля доступа к внешним носителям), либо же некая другая
«важная» причина (например, отключен task manager).
Целесообразность и потенциальные опасности отключения групповых политик
на рабочей станции в домене мы обсуждать не будет. Попробуем лишь
гипотетически разобраться: возможно ли отключить действие групповых
политик на машине Windows.

Отвечаю: да можно сделать так, чтобы на компьютер в домене не
применялись групповые политики, и для этого совершенно не нужно иметь
права domain/enterprise админа. Достаточно иметь права локального
администратора на интересующей нас машине (а это в очередной раз говорит
о том, что НЕЛЬЗЯ давать права администратора на рабочих станциях пользователям!).

Указанный ниже текст относится к клиенту на базе Windows 7, но есть
небезосновательные основания полагать, что и на других клиентских ОС
методика будет работать.

Все мы знаем, что за применение групповых политик в Windows 7 отвечает служба Group Policy Client (gpsvc), поэтому логичное действие просто отключить эту службу. Это можно сделать, загрузившись в безопасном режиме или, запустив cmd от имени system

и выполнив команду

net stop gpsvc

Но проблема в том, что через некоторое время, система сама запустит эту службу, и вы с этим поделать ничего не сможете.

Но есть более оригинальное решение: совсем запретить системе доступ к
этой службе, в результате у нее просто не будет прав на ее запуск. Как
вы помните, параметры всех служб хранятся в реестре, и наша задача –
забрать права у System целиком на службу групповых политик.

Для этого:

  • открываем редактор реестра regedit.exe
  • Находим ветку HKLM\SYSTEM\CurrentControlSet\services\gpsvc (это как раз ветка службы Group Policy Client)
  • Правой кнопкой жмем по ветке gpsrv и выбираем Permissions, затем идем на вкладку Owner и делаем себя владельцем ветки
  • Затем на вкладке Permissions удаляем права у всех, кроме своей учетной записи, в результате права будут выглядеть так
  • Затем меняем тип запуска службы Group Policy Client на «Disabled», это можно сделать, изменив значение ключа Start с 2 на 4
  • Перезагружаемся и проверяем, что после загрузки групповые политики больше не применяются.

Но есть одна проблема: при таком отключении в трее будет периодически выскакивать окно с текстом: Failed to connect to a Windows service.
Windows could not connect to the Group Policy Client Service. This
problem prevents standard users from logging on to the system.
As an administrative user, you can review the System Event Log for details about why the service didn’t respond.

Но и это предупреждение можно отключить, для чего открываем редактор реестра:

  • Ищем ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Winlogon\Notifications\Components\GPClient
  • Также становимся ее владельцем, и даем себе полные права на эту ветку
  • Делаем резервную копию данной ветки, после чего удаляем ее

Вот так достаточно просто и быстро мы полностью отключили клиент
групповых политик в Windows 7, в результате чего с компьютером можно
делать что угодно. Но не дайте администраторам домена или службе
компьютерной безопасности обнаружить себя, а то будет больно!