cpau habe ich ja bereits vorgestellt. Sinn und Funktionsweise setze ich hier voraus 🙂

Das Ausführen von CPAU Jobs vom Netzlaufwerk funktioniert aufgrund von simplen Windows Sicherheitsprinzipien nicht. Schließlich hat ein lokales Administratorkonto kein Zugriff auf Netzlaufwerke, die ja einen Domänenaccount benötigen. Also brauche ich ein Workaround, wenn ich automatisierte Softwareinstallationen auf einem UNC Share im Unternehmen bereitstellen will.

Ziel soll es sein, jedem eingeschränkten Nutzer Admin-Softwareinstallationen dank CPAU vom Netzlaufwerk aus bereitzustellen:

So wird es dann aussehen. Der Nutzer bewegt sich auf dem Netzlaufwerk, starte eine Batch und die Installation mit Adminrechten wird gestartet.

Kurz zum Verständnis:
Der Aufbau eines cpau Systems (mit Jobs) ist grundsätzlich recht einfach:
1 Batch Script ist für den Benutzer („Userscript“). Bei Doppelklick führt es die gespeicherte Job Datei aus. Die Job Datei führt wiederum ein Login auf das Administratorkonto durch und startet eine Datei oder ein Script („Ziel-Datei/Installer“) mit den entsprechenden Rechten. Für den Benutzer müssen weder Job Datei noch die Ziel-Datei sichtbar sein.

Das Verzeichnis mit den Benutzerscripten und das Verzeichnis mit den Job- und Ziel-Dateien.

Wären Netzlaufwerke erlaubt müsste das Benutzerscript nur 1 Zeile haben:
bash“>“\\Server\Pfad\zu\cpau.exe“ -dec -file „\\Server\Pfad\zu\jobfile.job“ -nowarn -lwp

Das geht natürlich nicht. In der Job sind die Administratorcredentials gespeichert, beim Start von cpau wird das working dir auf einen lokalen Pfad gelegt und der Administrator kommt auch nicht mehr an den Server. Es bleibt nur eine Lösung: alles, was benötigt wird, lokal zu kopieren und damit lokal zu arbeiten.

Hier das Userscript:
winbatch“ line=“1″>
@echo off
echo Verzeichnis erstellen und reinigen
if not exist c:\temp md c:\temp >> nul
del c:\temp /f /s /q >> nul
echo Job Files und Ziel-Dateien lokal kopieren
copy \\Server\Pfad\zu\den\Installer\und\Jobfiles c:\temp /y >> nul
echo Lokale Jobfile ausführen
c:\temp\cpau.exe -dec -file „c:\temp\notepad.job“ -nowarn -lwp
echo Verzeichnis löschen, 1 Ziel-Datei ist in Benutzung und bleibt übrig
del %wdir% /f /s /q >> nul

Das mag jetzt etwas unübersichtlich aussehen, ist aber ein einfaches Prinzip.
Es wird ein lokaler Ordner erstellt, falls noch nicht vorhanden. Der Inhalt des Ordners wird gelöscht, falls der Ordner existieren sollte und sich noch Dateien darin befinden. Dann wird der Ordner vom Netzlaufwerk, in dem Installer und Jobfiles liegen in diesen lokalen Ordner kopiert. Die nun lokal liegende Jobfile kann jetzt ausgeführt werden. Danach wird der Ordnerinhalt gelöscht. Fertig.
Der Benutzer startet dieses Userscript vom Netzlaufwerk aus und bekommt von der ganzen lokalen Geschichte nichts mit, einige Sekunden später startet einfach die administrative Installation, die das Userscript schließlich ja hervorbringen sollte.

Nun müsst ihr das Jobfile speziell für diesen Fall generieren. Erstellt euch den temporären Ordner, falls noch nicht vorhanden. Pfad und Name genauso wie in dem Userscript benutzt. Kopiert dort den gewünschten Installer oder Ziel-Datei hinein und erstellt die Job File mit folgender Codezeile:
cpau.exe -u Administrator -p PaSsWoRt -ex „c:\temp\installer.exe“ -crc „c:\temp\installer.exe“ -enc -file „\\beliebiger\lokaler\oder\serverpfad\installer.job“

Wichtig ist, dass ihr die Jobfile mit den lokalen Pfaden der Ziel-Datei erstellt. Der Installer muss in dem selben lokalen Verzeichnis liegen, wie die Dateien durch das Userscript kopiert werden.

Ich nutze das System, wie man auf den Screenshots oben sieht, bereits produktiv im Unternehmen und es kommt sehr gut bei den Mitarbeitern an. Sollte es über einfache Aufgaben hinausreichen, bietet es sich an, das Script zu verbessern. Hier ist meine Version des Userscripts:
winbatch“ line=“1″>
@echo off
echo Variablen erstellen…
set log=\\server\laufwerk\Computer\Software\GPOs_Install\PC-Data\Updatelogs\Programmupdates.txt
set wdir=c:\updatetemp
set updatedir=\\server\laufwerk\Computer\Software\GPOs_Install\Updates\
set /a loop=0
echo Verzeichnis erstellen, reinigen und kopieren…
echo %computername% – %username% – %date% %time% startet Notepad++ Installer >> %log%
if not exist %wdir% md %wdir% >> nul
del %wdir% /f /s /q >> nul
:kopieren
set /a loop=%loop%+1
if %loop%==4 goto :Fehler
copy „\\server\laufwerk\Computer\Software\cpau.exe“ %wdir% >> nul
if errorlevel 1 goto :kopieren
copy %updatedir% %wdir% /y >> nul
if errorlevel 1 goto :kopieren
echo Installation starten…
%wdir%\cpau.exe -dec -file „%wdir%\notepad.job“ -nowarn -lwp
echo Verzeichnis löschen…
del %wdir% /f /s /q >> nul
echo %computername% – %username% – %date% %time% beendet Notepad++ Installer >> %log%
echo ################ >> %log%
goto :eof

:Fehler
echo.
echo ### Fehler beim Kopieren ###
echo Bitte informieren Sie die EDV Abteilung.
pause
goto :eof

Alle Pfade werden in Variablen gespeichert und erleichtern die Übersicht im Script. Ein Logfile wird beim Start und beim Beenden einer Softwareinstallation (hier im Beispiel Notepad++) beschrieben und ermöglicht mir das (noch relativ grundlegende ^^) Troubleshooting, falls es zu Problemen kommen sollte. Der Kopiervorgang des Installer- und Jobordners wird mit errorlevel überwacht und in einer Schleife wiederholt, sollte er fehlschlagen. Schlägt er zu oft fehl, wird eine Fehlermeldung ausgegeben. Läuft alles gut (das war bis jetzt immer der Fall), so wird die Job gestartet und der lokal liegende Installer mit dem lokalen Administrator ausgeführt.

Was der Benutzer sieht, zeige ich in dem Video ganz oben. Das passiert im Hintergrund:

Der Nachteil wird schnell klar: je mehr Softwareinstallationen ich bereitstelle und je größer die Produkte sind desto länger dauert der Kopiervorgang für jeden Benutzer bei jeder Installation, da immer der ganze Ordner kopiert wird. Das könnte man ganz leicht umgehen, in dem man in jedem Script nur die Dateien kopieren lässt, die auch wirklich benötigt werden, z.B. %programm%.job und %programm%.exe. Sollte ich das demnächst noch so programmieren werdet ihr es erfahren.

Bei Fragen und Anregungen mail me 🙂

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!

Nun ist es endlich soweit: Firefox 3.5 wurde gestern veröffentlicht.
Das finale Update erscheint somit nach vielen Alphas, Betas und RCs und ersetzt damit die letzte Version 3.0.11 nach über einem Jahr Entwicklungszeit.
Viele sind über den ungewöhnlichen Versionssprung verwundert, überspringen Softwareharesteller doch recht selten so viele Versionsnummern ohne Releases.

Was also bringt die neue Version?

firefox-3-5-taskleisten-iconEin neues Icon schmückt den Browser, sowohl das Programm Logo als auch das Taskleistenicon. Letzteres hat sich jedoch nur leicht verändert.
firefox-3-5-logo


Mehr als doppelt so schnell soll er sein, im Vergleich zum Vorgänger.
firefox-3-5-schnelligkeit2


Der private Surfmodus kann jetzt genutzt werden.
firefox-3-5-privater-modus
Das neue Spielzeug der Hobbydatenschützer und manisch paranoiden Pädophilen (laut Guttenberg hat Deutschland davon ja neuerdings einige Hundertausend) hinterlässt während des Surfens keinerlei Spuren auf dem Computer. Dazu werden alle geöffneten Fenster gespeichert und geschlossen und eine abgekapselte Fort-Knox-Instanz von Firefox gestartet.


Neben Tabs kann man jetzt auch kürzlich geschlossene Fenster wiederherstellen.
firefox-3-5-closed-windows
*hust* Epileptiker wirds freuen, nun kann man also nicht nur ganze geschlossene Browserinstanzen und Tabs sondern auch Fenster wieder neu öffnen.
Alle anderen können sich der altmodischen Methode bedienen: einfach zwei Mal überlegen bevor man klick/schließt.


HTML 5 Videos werden unterstützt.
firefox-3-5-html5-videos
Alle Webentwickler und Videoportal-Freunde dürfen jetzt die nassen Unterhöschen wechseln. *umziehen geht* Mit dem

HTML Tag lassen sich jetzt Video einbinden. Ein weiterer Schritt in ein Web ohne Flash. Noch geiler ist natürlich der Fakt, dass man nun Videos ohne Tools viel schneller und einfach herunterladen kann.


Zudem wurde natürlich ein ganzer haufen Funktionen verbessert, die es bereits in der letzten Version gab:

  • Bessere Javascript Engine für Greasemonkey
  • Bessere Awesomebar
  • Besserer Malware- und Phishingschutz
  • Besseres Tabmanaging und -dragging
  • Bessere SSL-Fehlerseiten
  • Besseres Allles *bling blink* Firefox halt

Ein Umstieg bzw. ein Upgrade ist also empfehlenswert.

get-firefox-3-5 Also, Firefox herunterladen und installieren, falls ihr das bis jetzt versäumt habt. Portable Version wie immer bei Caschy.

Wie man sicher ohne Datenverlust und so von 3.x auf 3.5 upgraden kann, beschreibt Caschy kurz und einfach. Ich hatte keinerlei Probleme mit dem Autoupdate von Firefox, musste weder Backups wiederherstellen noch neue Profile anlegen oder son Kram.

Viel Spaß also mit der neuen Version von Firefox!