Markus Bäker

Für die OS Installation wird in SCCM ein WinPE Bootimage eingesetzt. Über die Konsole lässt sich hier auf einfache Art und Weise zusätzliche Treiber einbinden. Relevant ist dies im Allgemeinen nur für sehr neue Netzwerk bzw. SATA Treiber, da Windows 7 von Haus aus schon sehr viele Geräte unterstützt.

Manchmal ist es schwierig den passenden Treiber zu finden. Hilfreich dabei ist die PCI Device ID. Mit dieser eindeutigen ID kann man den Hersteller (VEN_XYZ) und das entsprechende Gerät (DEV_…) über eine Google Suche ermitteln.

Um diese ID zu ermitteln muss man zuerst die Kommandozeilen Option im WinPE Boot Image aktivieren (Eigenschaften des Images).

Danach kann man per F8 eine Kommandozeile auf dem System mit den fehlenden Treibern starten und per

wmic nic get PNPDeviceID

bzw.

wmic idecontroller get deviceid

die IDs ermitteln. Ein Beispiel der Ausgabe ist im folgenden Bild dargestellt:

Relevant sind hier nur die PCI\VEN… Einträge.

SCCM 2007 hat eine relativ gute Verwaltung der Treiber für eine Betriebssysteminstallation (OSD), die auch automatisch erkannt und installiert werden. Gerade wenn man viel Zeit und Mühe in die Pflege dieser Liste gesteckt hat, möchte man vielleicht auch bereits installierte Systeme mit den Treibern aktualisieren.

Mir ist keine SCCM interne Möglichkeit bekannt dies umzusetzen. Auch eine versuchsweise erstellte Tasksequenz, die nur die Treiberauswahl beinhaltet bricht auf einem Zielsystem ab, da es nicht im richtigen Kontext (WinPE) ausgeführt wird.
Read more…

Heute mal wieder eine kurze Powershell Zeile, um alle in Enteo hinterlegten PnP-IDs in den Driver Packages auszulesen und auszugeben.

Interessant kann diese Liste sein, um sie mit einer Enteo-externen Inventur zu vergleichen oder zu überprüfen, ob eine neue Hardware bereits unterstützt wird.

(Get-EmdbSoftwarePackage -recurse -Filter "SchemaTag=PnpPackage" |

where {$_.PnPEnabledIdList -ne $null}) |

foreach-object{$_.PnPEnabledIdList.Split(",")} > c:\temp\pnpids.txt

Zuerst wird in allen Software Paketen nach dem Typ PnPPackage gesucht. Aus diesen Ergebnissen werden alle Treiber ohne PnP Ids ausgefiltert. Das Ergebnis ist eine kommaseparierte Liste pro Treiber-Paket, die beim Komma getrennt wird. Am Ende steht eine Liste mit jeweils einer PnP Id pro Zeile:

[...]
OPTIONBUS\GTHSM501_DBG
OPTIONBUS\GTHSM501_DBG2
OPTIONBUS\GTHSM501_GPSD
OPTIONBUS\GTHSM501_GPSC
OPTIONBUS\GTHSM501_APP
OPTIONBUS\GTHSM501_APL
PCI\VEN_8086&DEV_105E&SUBSYS_105E8086
PCI\VEN_8086&DEV_105E&SUBSYS_005E8086
PCI\VEN_8086&DEV_105E&SUBSYS_115E8086
PCI\VEN_8086&DEV_105E&SUBSYS_125E8086
PCI\VEN_8086&DEV_105E&SUBSYS_135E8086
PCI\VEN_8086&DEV_105E&SUBSYS_704E103C
PCI\VEN_8086&DEV_105E
PCI\VEN_8086&DEV_105F&SUBSYS_005F8086
PCI\VEN_8086&DEV_105F&SUBSYS_115F8086
PCI\VEN_8086&DEV_105F&SUBSYS_125F8086
PCI\VEN_8086&DEV_105F&SUBSYS_704F103C
PCI\VEN_8086&DEV_105F
PCI\VEN_8086&DEV_1060&SUBSYS_00608086
[...]

Dadurch, dass der PDFCrator keinen unsignierten Druckertreiber installiert, ist eine Paketierung auch unter Windows 7 x64 relativ einfach. Trotzdem ist die integrierte Yahoo/PDFForge Toolbar bei der Installation hartnäckig und lässt sich erst nach einigen Versuchen ausklammern. Die hier vorgeschlagene Vorgehensweise wurde mit der PDFCreator Version 1.2.2 erfolgreich getestet.

Zuerst verwende ich wie üblich eine install.cmd für den Aufruf:

rem http://de.pdfforge.org/forum/open-discussion/6236-silent-install-without-toolbar
"%~dp0PDFCreator-1_2_2_setup.exe" /verysilent /norestart /sp /LOADINF="%~dp0pdf.ini" /forceinstall

Sie startet das Setup mit den notwendigen Parametern für eine automatische Installation. Die eigentlichen Einstellungen sind in der pdf.ini Datei hinterlegt:

[Setup]
Lang=german
Dir=C:\Program Files (x86)\PDFCreator
Group=PDFCreator
NoIcons=0
SetupType=custom
Components=program,ghostscript,images2pdf,helpfiles,helpfiles\german,languages,languages\english,languages\german
Tasks=winexplorer
Toolbar=0
DontUseYahooSearch=0

Relevant für das Unterdrücken der Tollbars sind die letzten beiden Punkte: Toolbar=0 und DontUseYahooSearch, um den Versuch der Veränderung der Default Suche im IE zu verhindern.

Dieser Blog beschäftigt sich hauptsächlich mit technischen Aspekten von Systemen und im Speziellen mit den Microsoft System Center Produkten.

Gerade bei der Einführung neuer Produkte ist der ROI (return of investment) und somit betriebswirtschaftliche Aspekte nicht unwichtig.

Daher hier ein paar Punkte, die mit dem Ersetzen von einem anderen Softwareverteilungstool durch SCCM Einsparungen bringen kann:

• Schnellere Paketierung durch App-V, da weniger wechselseitige Abhängigkeiten überprüft werden müssen
• Weniger Wartezeit für den Anwender durch App-V: Auch wenn er seinen Arbeitsplatz wechselt steht seine Software ihm zur Verfügung, da diese ihm folgt und nur ihm an diesem Rechner angeboten wird.
• Schnellerer Hardware-Modellwechsel durch OSD von SCCM: Treiber werden bei der OS-Installation dynamisch nachgeladen. Ein neues Modell kann so im Idealfall nur einfaches einbinden der noch fehlenden Treiber integriert werden.
• Schnellere Neuinstallation: Je nach Supportpolicy steht im Fehlerfall irgendwann eine Neuinstallation des Rechners an. Gerade wenn dem Benutzer kein anderer PC zur Verfügung steht, sollte diese Installation so schnell wie möglich sein. SCCM verwendet hier ein imagebasiertes Rollout und ermöglicht durch Multi-Cast eine sehr schnelle Installation auch an mehrere Ziele parallel.
• Patch-, Softwareinstallationen und OS-Neuinstallation in der Nacht: Der Benutzer wird während seiner Arbeitszeit nicht gestört. Die Rechner werden per integriertem Wake-on-Lan (WOL) abends gestartet und nach Abschluss der Installationen wieder heruntergefahren
• Powermanagement: einigen Anwendern ist die Boot-Zeit zu lange, daher lassen sie den Rechner über Nacht durchlaufen. Dies erhöht die Stromkosten und erhöht das Brandrisiko in den Büroräumen. SCCM beinhaltet ab SCCM 2007 R3 ein Powermanagement und kann so konfiguriert werden, dass sie Rechner in den Abendstunden schneller schlafen legen. Um dem Anwender trotzdem ein schnellen Start am Morgen zu ermöglichen ist ein WOL am morgen möglich

Dies stellt nur ein Auszug von möglichen Einsparungspotentialen dar. Gerade durch das Powermanagement kann ein Betrieb viel Geld einsparen. Für genauere Berechnungen anhand von Excel Tabellen stehe ich und mein Arbeitgeber gerne zur Verfügung

Einige der wenigen Neuerungen im Service Pack 1 für Windows 2008 R2 ist Dynamic Memory für die Hyper-V Rolle. Eine gute Erklärung findet man unter http://blogs.technet.com/b/virtualization/archive/2010/07/12/dynamic-memory-coming-to-hyper-v-part-6.aspx.

Zum Testen habe ich einen der Hyper-V Server Knoten im Cluster mit der Betaversion ausgestattet. Wie im Artikel oben beschrieben wird das Verändern des genutzten Speichers durch die Gast-OS durchgeführt. Dazu scheint Microsoft ein neues Device in den VMBus einzuhängen.

Da es ein neues Feature ist, findet die VM mit Windows 2008 Server SP2 noch keinen Treiber dafür. Ich werde daher weiterprobieren

Da ich selber immer wieder diese Umgebungsvariable suche, werde ich sie mal selber hier dokumentieren. Zwar weiß ich, dass es bereits 10.000 mal im Web beschrieben ist, aber so finde ich es hoffentlich schneller wieder

Setzt man die Umgebungsvariable devmgr_show_nonpresent_devices auf 1, so zeigt der Device Manager bei der Ansicht Show Hidden Devices auch Treiber von Geräten, die nicht mehr an das System angeschlossen, aber immer noch installiert sind. Dies ist u.a. interessant, wenn man eine Netzwerkkarte austauscht und beim Konfigurieren der neuen Netzwerkkarte Windows meldet, dass die IP Adresse bereits an einer anderen Karte hängt. Deinstalliert man dann diese ausgeblendete Karte ist der Fehler gelöst.

Zum Kopieren:

set devmgr_show_nonpresent_devices=1

devmgmt.msc

Während einer OS Installation über SCCM (MDT) ist die Installation der aktuellen HP Treiber durch das passende Support Pack sehr einfach möglich. Firmware Updates fand ich bis jetzt schon schwieriger.

Eine sehr einfache Möglichkeit ermöglicht die Firmware Update CD:
Die CD (ISO File) einfach entpacken (z.B. mit 7Zip) und als Paket im SCCM einbinden. Im Root des Paketes eine Batch Datei mit folgendem Inhalt anlegen:

"%~dp0FW840.2009_0209.17compaqswpackageshpsum.exe" /s /romonly /use_location "%~dp0FW840.2009_0209.17compaqswpackages"

(Falls die ISO Datei in den Unterordner FW840.2009_0209.17 entpackt wurde). Der Aufruf nutzt HPSUM um sämtliche Windows Firmware Updates zu installieren. Dieses Paket als Softwareinstallationstask einbinden. Nach der Installation wäre ein Neustart sinnvoll.
Von der Reihenfolge würde ich die Firmwareupdates vor dem Supportpack installieren, da einige aktuelle Treiber eine aktuelle Firmware benötigen.

Treibermanagement in SCCM ist recht einfach gestaltet, trotzdem sollte man eine gewisse Organisation und Vorsicht walten lassen. Daher mal diesmal ein paar Basics:

Eindeutiges Zeichen für einen Fehler ist folgender Bluescreen (0xc000035a):

Schaut man sich die Boot Image Treiber genauer an, so erkennt man schnell einen Intel Storage Treiber.  Unter Drivers kann man ebenfalls erkennen, dass der Treiber folgende Plattformen vorgesehen ist: “All x64 Windows Server 2003 (Non R2), All x64 Windows Server 2003 R2, All x64 Windows Server 2008, All x64 Windows Vista, All x64 Windows XP Professional […]“.

Interessant ist auch ein Blick in das Image selber. WIM Dateien kann man sehr elegant mit 7Zip anschauen. Die Datei unter 1windowssystem32drivers hat folgende Eigenschaften:

Auch hier ist eindeutig ein x64 Treiber zu erkennen. Sobald man den Treiber aus dem Boot Image entfernt und neu deployed ist der Treiber entfernt und im Image nicht mehr auffindbar. Das Booten danach funktioniert sofort wieder.

Merke: Treiber immer genau anschauen und nur in die Image/Packages hinzufügen wo sie benötigt werden. (s.a. Post zu Broadcom Treibern)

Manchmal macht es sogar Sinn sich dieEigenschaften der  Treiberdatei selber anzuschauen.

Gerade Windows Installation für Templates werden häufig mit kleinen Platten (ich verwende 10GB für das System) installiert. Dies reicht für den Großteil der Installationen aus, wenn man versucht größere Datenmengen auf extra Disks zu legen. Trotzdem kommt es immer wieder vor, dass der Platz nicht reicht. Seit ESX 3.5 (Update 2?) kann man Disks im laufenden Betrieb vergrößern.

Windows erkennt dies auch automatisch. Leider kann Windows 2003 nur NIcht-Systemplatten mit Boardmitteln vergrößern. Bevor jetzt ein ein Neustart mit einem Festplattenpartitionierungsprogramm gemacht wird möchte ich auf ein kleines aber sehr mächtiges Tools hinweisen: DriveSnapshot (www.drivesnapshot.de): Dieser Imagebackuptool kann viel mehr als die meisten wissen.

Mit der grade einmal 150KByte ausführbaren Datei kann man auch im laufenden Betrieb die Systemplatte vergrößern. Dafür gibt es versteckte Kommandos, die man sich mit -!? anzeigen lassen kann.

In diesem Fall gibt ein snapshot -!resizepart c: die maximal mögliche Vergrößerung an. Ein snapshot -!resize c: 30000 vergrößert dann die c Partition auf 30000 MByte. Vorher wird ein Chkdisk (read only) durchgeführt, um sicherzugehen, dass der Datenträger in einem korrekten Zustand ist.

Diesen Weg habe ich bereits dutzende Male auf virtuellen Maschinen angewandt. Die Betreiber waren immer wieder begeistert, wie schnell ich die Systeme vergrößern konnte!

Merke: VMWare ESX und DriveSnapshot sind ein gutes Team