Troubleshooting Gruppenrichtlinien – Softwareinstallation

by ·16 Kommentare

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/[random SID]/

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!

16 Kommentare

  2. Top Anleitung! Tausend Dank… ich habe es noch nicht getestet, aber nach dem Durchlesen bin ich doch sehr zuversichtlich, mein GPO Softwareinstallationsproblem zu lösen!
    Nochmals Danke für deine Zeit und dein Wissen, dass du mit der Welt teilst! Ich wäre schon oft aufgeschmissen gewesen, ohne Leute wie dich, die sich die Mühe machen, solche Blogs zu betrieben!

  4. Yes, problem solved 🙂 Ich hatte ein bisschen ein anderes Problem, und zwar hatte ich eine GPO gemacht, um Java 6 Update 27 zu installieren. Einen Tag darauf habe ich gemerkt, dass ich einen kleinen Fehler in der Bereitsstellung gemacht hatte und die .cab Datei vergessen habe. Ohne diese bleibt der PC nach dem Boot bei Bitte warten… hängen und lässt sich nicht mehr anmelden. Dann habe ich die GPO komplett entfernt, danach konnte ich wieder anmelden. Jedoch hatte ich danach das Problem, dass die neue Java Installations-GPO (die auch gleich noch eine neue Java Version Update 29 beinhaltet) nicht mehr angewendet wurde, da er immernoch versucht hat, das alte Java Update aus der alten GPO/dem alten MSI Paket anzuwenden. Dies gab dann einen MsiInstaller Fehler für die alte MSI in der Ereignisanzeige und natürlich die Folgefehler, dass er das neue Java MSI nicht installieren konnte. Ich habe dann auf einem betroffenen Client die ID der entsprechenden Richtlinie unter ..\Group Policy\AppMgmt\{SID} gelöscht. Jedoch wollte er weiterhin die alte msi installieren. Ich musste nun zusätzlich noch unter HKLM\Software\Classes\Installer\Products den entsprechenden Registryschlüssel (also die ganze Struktur unterhalb der ID der Software) der Java 6 Update 27 Pakets löschen. Am besten sucht man in der Registry unter HKLM\Software\Classes\Installer nach dem Produktnamen der Software (z.B. Adobe Flash Player oder hier Java(TM)). Danach versucht er nicht mehr, das alte MSI zu installieren sondern nimmt das Aktuelle.

    Ich hoffe, man versteht was ich hiermit sagen wollte.

    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 (der hier im Artikel erwähnt wird) 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.

    PS: Der Link zum Windows Installer Clean Up Tool ist theoretisch noch korrekt, nur wird dann dort bei MS darauf verwiesen, dass man das Tool nicht mehr anbietet, da es zu oft zu viel aufgeräumt hat und dann mit anderen Programmen Probleme auftraten. Evtl. nimmst du den Hinweis bzw. das Vorgehen mit diesem Tool gleich ganz raus.

  5. Ich bin erstaunt, dass Microsoft das Tool nicht mehr anbietet. Es hat mir gute Dienste geleistet, wo sonst jede andere Lösung versagte. Ich werde daher weder den Tipp noch den Download entfernen, vielleicht haben andere bei der Verteilung von Acrobat 9 Pro ebenfalls so viel Stress wie ich und brauchen das Tool 😉
    Ich finde auch, dass jeder Administrator bei solch gravierenden Schritte wie Deployment von Software sich ausreichend im Klaren sein sollte, was er tut. Also die nötige Vorsicht setze ich voraus.
    Und da ich bisher noch keine negativen, sondern wie gesagt nur positive, Erfahrungen mit dem Tool gemacht habe, traue ich es meinen Lesern auch zu 🙂

    Edit: Deinen Tipp habe ich mit in den Artikel geschrieben, danke für die Zusammenfassung.

  6. Vielen Dank für diese ausführlichen Tipps! In meiner Umgebung sind nur die Fehler %%1274 und %%2 aufgetreten. Zur Zeit tausche ich unseren kompletten Rechner-Pool aus und es gibt mehrere GPOs mit jeweils einem Eintrag zur Installation von Softwarepaketen. In nur einer davon ist ein Update (bzw. Deinstallation einer alten Version – danach Installation neue Version) vorgesehen. Da es auf den neuen PCs natürlich keine alte Version des betreffenden Programms gibt ist klar, dass hierbei diese Meldungen kommen. Jedoch erscheinen die Fehler %%1274 und %%2 für alle GPOs, in denen Setups eingetragen sind. Also z.B. auch für Java, Frontmotion Firefox usw. Hinterher sind jedoch alles Programme wie vorgesehen vollständig installiert – trotz dieser Meldungen.

    Das, was mich jedoch am meisten irritiert ist die unvollständige Übersicht aller installierten Programme in der Systemsteuerung. Nachdem die Gruppenrichtlinien angewendet wurden, werden dort nur noch eine Hand voll Programme aufgelistet. Keine der per GPO installierten Programme tauchen darin auf. Außerdem sind zuvor installierte Programme – wie z.B. Office-Paket und Adobe Reader – verschwunden. Sie sind vollständig installiert, nur eben ausgeblendet. Mit dem Windows Installer Cleanup Tool und auch dessen Nachfolger werden sie jedoch sichtbar.
    Woran könnte das liegen? Gibt es einen Weg, diese Liste wieder zu rekonstruieren? Es funktioniert ja soweit alles, nur wenn man mal was deinstallieren will, muss ich wohl zu einen dieser Cleanup Tools greifen.

    Viele Grüße,

    Christian

  7. Hallo Christian,

    interessante Beobachten, vor allem der letzte Absatz klingt sehr seltsam und fehlerhaft. Na gut, der erste ist auch nicht besser ^^

    Also ich würde mir Gedanken machen wenn entweder Fehler erscheinen und die Programme trotzdem installiert werden oder diese Seltsamheiten in der Softwareliste geschehen. Die Rechner sind danach zwar so ausgestattet wie gewünscht aber diese Fehlfunktionen fallen dir (oder einem anderen Admin) hundert Pro irgendwann auf die Füße.

    Wenn du sicher gehen willst wird ein dicker Reset wohl nötig sein, kann jetzt aus der Ferne natürlich keine anderen Möglichkeiten erriechen.

    Ein Reset würde ich mit dem Löschen des GroupPolicy Regkeys beginnen. Dadurch werden alle GPO Einstellungen zurückgesetzt und auch die Softwareinstallationen neugestartet. Funktioniert eine Installation nicht so richtig (was vorkommt) muss die installierte Version erst deinstalliert und mit dem Cleanup Tool restlos entfernt werden, dann nochmal den Regkey löschen und gpupdate /force abfeuern.

    Je nach Anzahl der Rechner und Software kann das aufwändig werden :/
    Ich wünsche dir also, dass diese seltsamen Probleme nicht bei allen Rechnern auftreten 😉

  8. Hallo Hannes,

    danke für deine Antwort, inzwischen konnte ich das Problem weiter eingrenzen. Sowohl mit den PCs als auch mit meiner AD-Umgebung ist alles in Ordnung.

    Das Problem kam von einem der MSI-Pakete selbst – und zwar vom Frontmotion Firefox! Ich habe einfach mal einen jungfräulichen PC genommen und die derzeit aktuelle Version 11 des MSI-File installiert – und schwups – die meisten Anwendungen sind weg. Nebenher hatte ich immer in der Registry den Schlüssel „HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall“ untersucht – darin befinden sich sämtliche 32bit-Anwendungen, die sich über die Systemsteuerung deinstallieren lassen (und die zuvor im „Computerkontext“ installiert wurden). Nach der Installation des Frontmotion Firefox ist der gesamte Schlüsselinhalt leer – nur der Firefox selbst ist übriggeblieben. Die anderen in der Systemsteuerung noch sichtbaren Anwendungen befinden sich entweder im Benutzerkontext oder in dem Computerkontext für 64bit-Anwendungen. Beides wird von der Firefox-Installation nicht berührt.

    Ich werde nun versuchen, über einen anderen PC die Schlüsselinhalte zu exportieren und einige davon bei den betroffenen Rechnern importieren und testweise die Deinstallation einer Anwendung versuchen. Ich erhoffe mir somit, die PCs in einem zumutbaren Zustand zu hinterlassen, damit nix davon jemanden mal „auf die Füße fällt“.

    Weiterhin habe ich im Frontmotion-Forum einen Eintrag gepostet – mal sehen, was der Entwickler dazu sagt. Für alle, die es interessiert:

    http://forums.frontmotion.com/viewtopic.php?f=10&t=1318

    Viele Grüße,

    Christian

  9. Hallo Hannes, bin gerade dabei, den Frontmotion aus unserem Netz zu verbannen und habe heute deine Anleitung zu der Firefox-Verteilung getestet. Funktioniert prima!

  10. Hallo Zusammen!
    Toller Tread hier!

    Bei uns ist aufgefallen, das all die Fehler: %%1274 usw. auftauchen, wenn die Softwareinstalaltion während des Betriebes stattfindet. Normalerweise wird Software nur beim Start/Anmelden installiert.
    Bei uns ist das nicht so, obwohl wir die GPO Einstellung „Richtlinienverarbeitung der Einstellungserweiterung „Anwendungen“ “ nicht aktiviert haben:(

    Ich bin noch auf der Suche, nur als Tipp für alle anderen die selber suchen

  11. Hallo Zusammen!

    weiterer Kommentar zum Fehler: %%1274

    Ich dachte ich habe die Lösung gefunden:

    Dieser Schlüssel verhindert, das während der Computer läuft und ein User angemeldet ist,
    im Hintergrund eine Software die per GPO verteilt wurde, installiert wird:

    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{c6dc5466-785a-11d2-84d0-00c04fb169f7}
    NoBackgroundPolicy
    REG_DWORD
    (1)

    Wir sind uns gerade aber nicht einig, ob dies einen Folgefehler mitsich bringt.
    Seit einstellen dieses Keys ist uns aufgefallen, das zB eine Office Installation noch immer läuft, obwohl man sich schon angemeldet hat.
    Das sind wir aber noch am testen, ob dies auch wirklich an dem Key liegt.

  12. @Ralf: Ich versteh das Problem nicht recht.
    Verteilt ihr Software per Script oder per msi Softwarepaket?

    Bei Scripten läuft die Installation bis zum Abschluss weiter, egal ob der User im Anmeldebildschirm bleibt oder sich anmeldet. Bei einer Anmeldung kann es natürlich zu Komplikationen kommen, wenn der User Features nutzt, die gerade für die Installation benötigt werden.

    Bei einem GPO Softwarepaket wird der Anmeldebildschirm so lange herausgezögert, bis die Installation abgeschlossen ist. Erst danach kann sich der User anmelden. Bei dieser Methode gibt es seltener Komplikationen aber die Möglichkeiten des eigenen Loggings und Anpassungen der Installation sind sehr begrenzt.

    Wenn du sagst, die Installation läuft im Hintergrund, obwohl der Nutzer schon angemeldet ist, klingt das nach Scriptinstallation.
    Denn Paketinstallationen sollten nach der Anmeldung tatsächlich schon abgeschlossen sein.
    Bei einer Scriptinstallation ist es aber widerum normal, wenn die Installation dann noch läuft.
    Vor allem Office 2010, die Installation dauert natürlich noch lange in die Installation mit rein.

    Wenn ich das richtig verstanden habe verändert der NoBackgroundPolicy Key nur das Verhalten der GPO Aktualisierung im Hintergrund. Der Wert liegt normalerweise bei 60-90 Minuten, eventuell mit zufälliger Varianz. Die Standardwerte der GPO Aktualisierung lassen sich in den Administrativen Vorlagen einstellen.
    Meines Erachtens wird aber trotz GPO Aktualisierung niemals eigenständig eine Installation gestartet oder anderweitig beeinflusst. Also die Aktualisierung der GPO sollte nicht mit irgendwelchen Installationproblemen zu tun haben.
    Die Aktualisierung zu deaktivieren halte ich auch für sehr bedenklich.

    Aber vielleicht verstehe ich das Problem ja noch nicht ganz.

  13. Hallo @Hannes

    Im Grunde verstehst Du die Problematik voll!

    1. ungewollte Installation wenn der Client am laufen ist:

    Ich gehe momentan davon aus das dieser Key
    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{c6dc5466-785a-11d2-84d0-00c04fb169f7}
    NoBackgroundPolicy=1
    nur der Teil der Softwareinstallation der GPO im Hintergrund verhindert. Würde also eine GPO eingestellt, die Softwareinstallation, Policys und Einstellungen usw. beinhaltet, wird zwar bei einem laufenden Client innerhalb der 60-90 Minuten die Policys und Einstellungen usw. übernommen, ABER NICHT der Teil der Softwareinstallation.
    Genau das wollen wir auch.

    Das eigentlich im Standard, eine Softwareinstallation nicht im Hintergrund durchgeführt wird, ist uns klar, ABER genau das passiert, aus unerklährlichen Gründen, bei uns trotzdem :/
    Daher genau dieser NoBackgroundPolicy Key!
    Dieser Key könnte helfen, wenn jemand genau dieses Problem hat.
    Dein Einwand sollte nicht bestehen, da NUR —-Stores configuration data for the policy setting Software Installation policy processing.—-

    2. Installation beim Start MSI/Script:

    Bis auf die Office 2010 Installation wird bei uns alles per MSI beim START des Computers verteilt.
    Per MSI verteilte Software wird schön nach einander angezeigt und ist bei der Anmeldung abgeschlossen.
    Alles Super, ABER die Office 2010 Installation wird gezwungener Maßen per Script verteilt.
    Unter XP alles Super, aber unter Windows 7 werden Scripte gestartet, aber nicht auf das Ende gewartet, so das der User sich anmelden kann, obwohl im Hintergrund noch evtl. Scripte laufen .
    Wie im Fall Office, deren Installation noch im Hintergrund läuft und es bei uns bis zu 10 Minuten dauern kann, bis wie von Zauberhand das Office plötzlich installiert und das Startmenü-Eintrag da ist.

    Das bringt bei uns Probleme mit sich, wenn MSI Software die eng mit Office arbeitet und daher nicht richtig installiert wird.
    Wir haben bis jetzt keine Lösung gefunden wie wir darauf Einfluss nehmen können.

    Einen Trick haben gerade eben noch getestet. Und Zwar das das Script zur Office 2010 Installation per GPO beim HERUNTERFAHREN gestartet wird. Dann dauert das herunterfahren zwar sehr lange ohne zu sehen das das eigentlich gerade eine Office 2010 Installation am laufen ist. Ob uns das weiter bringt ist noch offen…

    Noch einmal Danke für dein tun!
    Ich hoffe unsere Diskussion bringt auch andere Administratoren weiter 🙂
    Toll das ich hier so eine qualifizierte Disskussion gefunden habe…

    PS: Das Microsoft genau solche Probleme provoziert, wo die ja MSI und GPO erfunden haben ist mir ein Rätzel. Jeder Sch. kann per MSI verteilt werden!

    Grüße
    Ralf

  14. Hm okay, eure Probleme sind also auf die starke Verknüpfung von Office und anderen Programmen zurückzuführen. Da kann ich dann vermutlich auch nicht mehr helfen.

    Wir haben Office 2010 auch normal per Script verteilt und obwohl alle Mitarbeiter stark mit Office arbeiten gab es bei der Verteilung der Software keinerlei Probleme. Beim Systemstart startete die Verteilung, alle Office Verknüpfungen verschwanden und erst als Office 2010 nach 10+ Minuten fertig installiert war erschienen die Verknüpfungen wieder und alles funktioniert.

    Probleme mit anderen Installationen oder ungewollte Hintergrundaktivitäten hatten wir nicht.

    Warum Office 2010 keine MSI Verteilung mehr bietet erklärt ein Mitarbeiter hier.

  15. Wir lösen das jetzt erst mal so, dass bei der Erst Einrichtung eines Computers, dieser in eine (Zwischen OU) geschoben wird, in der dieser Computer erst mal nur Office bekommt. Dann wird er erst in seine bestimmte OU verschoben und somit fertig eingerichtet.

    Danke und weiterhin viel Erfolg…

Schreibe einen Kommentar