Entries tagged as deployment

SCCM: OSD Task Sequence failure-0x80004005 - Möglichkeit 2

Im Beitrag "CCM: OSD Task Sequence failure-0x80004005" erwähnte ich schonmal was das Problem sein kann, das zu dieser Fehlermeldung führt.
In Ergänzung dazu möchte ich eine weitere Fehlerquelle erwähnen, die bei mir mal wieder zu dieser Meldung führte, aber andersartig gelagert war.

Im Logfile stand etwas davon, dass der Download irgendeiner Komponente fehlgeschlagen sei. Weitere Details jedoch konnte ich nicht finden. Also blieb nur nachdenken und recherchieren.
Nach Abbruch der Sequenz konnte ich mich an meiner frischen Installation anmelden, die aussah, als wäre sie erfolgreich durchgelaufen. Ich prüfte was installiert worden war und was nicht und stellte fest, dass von X zu installierenden Anwendungen nur Y installiert waren. Der Fehler musste also an der Stelle auftreten, nachdem die Xte Anwendung erfolgreich installiert wurde.
Ich sah also in den Eigenschaften meiner Task-Sequenz nach und fand an der besagten Stelle den Eintrag für den Flash Player, und wurde mir das Problem klar.

Ich hatte zuvor die aktuelle Flashplayer_10.2.153.1.exe abgelegt und mein Programm dafür aktualisiert. Die Ankündigung des Programms auf den einzelnen Maschinen hingegen schlug laut Logfile der Ankündigung jedoch fehl. Somit könnte es also ein Zusammenhang mit dem Programm und meiner abgebrochenen Task Sequenz geben.
Die Fehlermeldung im Ankündigungs-Log sagte, dass die angegebene Datei nicht gefunden werden könne und das obwohl die Angaben im Programm alle korrekt waren.
Schließlich aber wurde mir klar was ich vergessen hatte: die Aktualisierung des DPs !!!
Nachdem ich dies gemacht hatte, kündigte ich den Flashplayer erneut an und diesmal lief die Installation fehlerfrei durch.
Damit dürfte dann auch meine Task Sequenz komplett durchlaufen, wenn das der Fehler gewesen sein sollte.

Ich löschte also die PXE-Ankündigung für die zu installierenden Maschinen und löschte diese auch nochmal aus dem AD.
Nach einem Neustart booteten sie in PE und - siehe da - wurden nach erfolgreichem Durchlauf der Sequenz fehlerfrei installiert.

Damit zeigt sich wieder, dass man alles denken und an verschiedenen Ecken suchen muss, um eine Fehlermeldung im SCCM zu beheben.
Ist aus meiner Sicht recht nervig, weil die Meldungen eindeutiger sein könnten...

Vergabe von Changerechten per SCCM

Software ist mit dem SCCM schnell verteilt; was aber, wenn die Anwendung bzw. der User danach Changerechte (Schreibrechte) auf das Installationsververzeichnis benötigt, diese aber nicht hat ?
Lösen könnte man dies per GPO, ist jedoch nur ein geringer Teil von Installationen bei einer handvoll Usern betroffen, kann man hierzu auch den SCCM einsetzen.

Zum Zuge kommt in diesem Zusammenhang "ICACLS.exe", das mit Windows Vista und Windows 7 daherkommt. Vorherige Windows-Versionen nutzen noch XCACLS bzw. CACLS.
Um die Changerechte mit ICACLS zu vergeben, setzt man einen Kommandozeilenbefehl ab. Hierzu legt man ein Programm im SCCM an, über das die Anforderung ausgeführt wird.
Da die Änderungen am Installationsverzeichnis natürlich erst nach der Installation der jeweiligen Anwendung erfolgen können, ist es sinnvoll ein Paket anzulegen und darin zwei Programme.
Programm 1 verweist auf die ausführbare Datei der zu installierenden Anwendung und Programm 2 beinhaltet die Kommandozeile. Für Programm 2 legt man fest, dass seiner Ausführung zuerst die von Programm 1 vorweg geht ("Ein anderes Programm zuerst ausführen" => Verweis auf Programm 1). Damit wird also zunächst die Anwendung (Programm 1) installiert und anschließend die Berechtigungsänderung durch Programm 2 am Verzeichnis vorgenommen.

Mit folgender Kommandozeile lassen sich schließlich Schreibrechte, auch auf Unterordner, vergeben:

icacls C:\Programme\Anwendung /grant "Domain Users":(OI)(CI)M

In meinem Beispiel wird somit "ICACLS" aufgerufen und ihm mitgeteilt, dass die Änderungen für den Installationspfad "C:\Programme\Anwendung" gelten sollten. "C:", "Programme" und "Anwendungen" sollten natürlich durch die eigenen Pfadangaben oder durch Umgebungsvariablen wie z.B. %PROGRAMFILES% ersetzt werden.
Der Befehl "/grant" sagt es eigentlich schon aus: vergebe die entsprechenden Berechtigungen für... . Für, im Falle dieses Beispiels "Domain Users". Hier könnte auch administrator oder HMustermann stehen. Bestehen Benutzername oder Gruppe aus zwei getrennten Wörtern, müssen sie in Anführungszeichen ("") gesetzt werden.
Nach den zu berechtigenden Benutzern folgt ein Doppelpunkt zur Trennung zwischen Angaben und Parametern, die wiederum in Klammern folgen.
In diesem Beispiel sollen die Objekt- und Containervererbungen ((OI) und (CI)) gesetzt werden. Das "M" steht abschließend für "Modify", also für die gewünschten Schreibrechte, während "F" für Vollzugriff ("Full Access") oder "N" für keinen Zugrif ("No Access") beispielsweise stehen würden.

Eine vollständige Befehlsliste sowie Beispiele erhält man über den Aufruf von "icacls /?" (ohne die "") im Command-Prompt.


Zu guter Letzt fügt man dem Paket mit den beiden Programmen einen Distribution Point hinzu, aktualisiert diesen und kündigt Programm 2, also das, dem Programm 1 vorausgeht, für seine Rechner an. Damit erspart man sich zwei Ankündigungen, da Programm 2 Programm 1 zuerst loslaufen lässt.


Weitere Informationen zu CACLS.EXE und ICACLS.EXE findet man auf Winfaq.de .

SCCM: Tasksequenz bricht mit Fehler 0X8007005 ab

Gestern lief die Tasksequenz noch fehlerfrei, heute bricht sie mit Fehler 0X8007005 ab; allerdings nicht auf allen Rechnern, sondern nur auf denen, auf denen sie schonmal ausgeführt und Windows erfolgreich installiert wurde.
Die Meldung im Fehler-Log unter X:\Windows\Temp\smstslog\smsts.log ist dabei nicht allzu aussagekräftig.

Das Problem scheint von der zuvorigen Disk-Partition zu stammen und dadurch, dass WinPE ein Problem zu haben scheint, damit umzugehen.
Abhilfe schafft in diesem Fall, die Eingabeaufforderung während der Tasksequenz mit F8 aufzurufen, sofern man dies im Boot-Image aktiviert hat, und folgendes einzugeben:

- Diskpart
- Select Disk 0
- Clean
- Exit

Die Partitionierung sollte damit erfolgreich aufgehoben sein.
Danach löscht man die PXE-Ankündigung für den betroffenen Rechner und bootet diesen neu.
War die Ausführung erfolgreich, sollte die Tasksequenz wie gewohnt starten und ablaufen.


SCCM: Welcher Treiber für die Task Sequenz ?

Nervig, wenn man im SCCM sämtliche Vorbereitungen getroffen und abgeschlossen hat, die Task Sequenz aber nicht anlaufen will und stattdessen der Rechner neu startet.
Der Grund hierfür ist oftmals ein fehlender Netzwerktreiber. Und auch wenn man die entsprechenden Treiber von der Herstellerseite heruntergeladen in den SCCM importiert und zum Boot Image hinzugefügt hat, will's dennoch nicht so recht klappen.
Abhilfe schafft da ein Umweg, sofern man einen Rechner installiert, auf dem bereits Windows (OEM) oder ein anderes Betriebssystem (vor-)installiert ist, über das man die Möglichkeit hat, sich Infos zum Treiber zu holen.

Hilfreich ist dazu u.a. "SIW", ein Tool, das einem alle Systemkomponenten und installierten Softwarepakete anzeigt, sowie ein Blick in den Gerätemanager und die Eigenschaften der Netzwerkkarte und deren Treibers.

Und so kann man sich über SIW das Modell des Netzwerkadapters anzeigen lassen und dieses notieren. Anschließend ruft man den Gerätemanager auf, wechselt in den Knoten "Netzwerkadapter", ruft die Eigenschaften der aufgeführten Netzwerkkarte auf und lässt sich die Treiberdetails anzeigen. Sollten im Gerätemanager an der Stelle der Netzwerkkarte kein gelbes Icon erscheinen und die Treiber somit erfolgreich installiert sein, findet man die entsprechenden Infos und notiert sie sich.

Damit hat man dann Hersteller und Modell der Karte sowie die Treiberdatei, die - hoffentlich erfolgreich - unter (Windows) installiert ist.
Mit diesen Angaben sucht man auf der Herstellerseite nach dem entsprechenden Modell und lädt sich die Treiber herunter.
Nun kann sein, dass das Treiberpaket - wie zum Beispiel bei Intel - mehrere Unterordner beinhaltet. Intel NIC-Treiber haben gerne mal drei Verzeichnisse, die mit 51x, 61x, 62x beispielsweise anfangen. In diesem Fall öffnet man einfach die Verzeichnisse von oben nach unten, wirft einen Blick hinein und schaut, welches Verzeichnis den Treiber, den wir zuvor notiert haben, beinhaltet.

Hat man diesen ausfindig gemacht, importiert man diesen - bzw. das Verzeichnis - in den SCCM, packt ihn dabei gleich ins Boot Image, aktualisiert dessen Distirbution Points und probiert's von vorne.
Spätestens jetzt sollte die Task Sequenz anlaufen und der Rechner nicht mehr booten.


Die Gründe für einen Reboot können natürlich auch andere sein und sind in den Logfiles zu finden. Ich jedoch beziehe mich mit diesem Eintrag bewusst auf das Problem mit einem fehlenden Netzwerkkartentreiber.

Aktivierung von Office 2010 nach Silent Installation

Office 2010 wurde erfolgreich per Silent Mode verteilt/installiert, erfodert dann aber beim ersten Programmstart eine Produktaktivierung - online oder telefonisch -, wenn man keinen KMS einsetzt.
Der Lizenzkey wurde für die Installation bereits mitgegeben (XML-File oder MSP) und wird nicht mehr benötigt. Wie lässt sich also der Dialog unterdrücken ?
Diese Funktion lässt sich leider nicht so einfach finden, denn hierzu gibt es weder eine Einstellung per Policy oder im MSP (Admintool), noch ein Switch/Parameter, der für die Installation verwendet werden kann.

Um den Aktivierungsdialog zu unterdrücken und die Aktivierung ebenfalls silent durchzuführen, muss ein VB-Script gestartet werden, das sich im Office 2010-Installationsverzeichnis befindet.
Folgende Kommandozeile, die per Batch ausgeführt oder im SCCM für eine Ankündigung hinterlegt werden kann, führt dieses aus:

c:\windows\system32\cscript C:\"Program Files (x86)\Microsoft Office\Office14\OSPP.VBS" /act

Der "Program Files"-Pfad muss dabei dem eigenen Installationspfad (z.B. D:\Anwendungen\Office2010\...) angepasst werden.

Im SCCM erstellte ich hierfür beispielsweise ein Paket (ohne Quelldateien) und darin ein Programm ("Office 2010 Aktivierung"), dem ich diese Programmzeile mitgab:

c:\windows\system32\cscript "C:\Programme\MicrosoftOffice2010\Office14\OSPP.VBS" /act

Achtet hier insbesondere auf die Anführungszeichen ("") im Programmpfad ! Im obigen Beispiel stehen diese hinter C:\, im unteren davor.
Oben dürfte dies der Fall sein, damit die Zeichenkette inkl. Leerzeichen (...Program Files (x86)...) ausgeführt wird, während ich Pfadangaben in Programmzeilen von Programmen im SCCM gerne allgemein mit Anführungszeichen hinterlege.

Die Ausführung über eine Ankündigung via SCCM jedenfalls funktionierte reibungslos und so installierte ich zunächst Office 2010 im Hintergrund und ließ die darauffolgende Ankündigung die "stille" Aktivierung durchführen.

Page 1 of 3, totaling 13 entries