Markus Bäker

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
[...]

Vor über einem Jahr habe ich angefangen meine SCCM Hilfsscripte hier zu veröffentlichen. Da ich noch eine ganze Reihe von diesen Batchdateien habe, kommen jetzt noch einige weitere Posts zu diesem Thema.

Im Teil 2 wurde die Batch und vbs Datei vorgestellt, um auf eine Reihe von Clients die Hardwareinventur anzustossen.

Dies geht genauso mit dem Computer Policy Update:

startmachineupdate.cmd

@echo off
set PC=%1
if .%PC%==. set /p PC=Enter Computer Name to start HINV:
call %~dp0findip.bat %PC%
if %ip%.==. goto fehler
echo Start Machine Policy Update %PC%
cscript.exe //Nologo %~dp0sendsched.vbs {00000000-0000-0000-0000-000000000021}  %PC%
goto ende
:fehler
echo Abbruch, da Rechner %PC% auf ping nicht antwortet.
:ende
set ip=

und die dazugehörige startmachineupdateall.cmd:

for /F %%i in ('cscript.exe //NOLOGO %~dp0getcomputer.vbs %1 smsserver sitename') do call %~dp0startmachineupdate.cmd %%i

Benötigt dazu wird findip.bat und getcomputer.vbs aus Teil 1 bzw. Teil 2.

Zentraler Punkt in dem Script ist die Erkennung in welchem status die Installation gerade ist. Folgende Status sind möglich:

• Installation noch nicht eingeplant
• Installation eingeplant aber noch nicht gestartet
• Installation ist angelaufen aber noch nicht beendet
• Installation ist durchgelaufen

Zur Ermittlung dierer Status greifen wir wieder auf das Auslesen von PolicyInstancen zurück. Dazu werden am Anfang einige Policy-IDs definiert, die die verschiedene Status beschreiben:
Read more…

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

DFS ermöglicht nicht nur eine einheitliche Sicht bzw. Einstiegspunkt auf die Dateien im Unternehmen, sondern ermöglicht auch ein transparentes Umziehen der Dateien von einem Server auf einen anderen.

Dabei wird zuerst eine Replikation zwischen alten und neuem Fileserver mittels DFSR eingerichtet. DFSR ist trotz des Namens unabhängig von DFS, d.h. hierfür müssen die Fileserver nicht als Ziel eines DFS Zweiges eingerichtet sein.

Sobald die Initiale Replikation abgeschlossen ist, kann der neue Fileserver als weiteres Ziel in den DFS eingehängt werden. Das alte Ziel kann dann entfernt werden (eventuell vorher ein vollständiges Backup auf dem neuen Fileserver abwarten?). Offene Dateien von Benutzern liegen immer noch auf dem alten Share und können erst repliziert werden, wenn sie die Dateien geschlossen oder sich abgemeldet haben. Daher sollte die Replikation erst gestoppt werden, wenn alle offenen Dateien geschlossen sind.

Eine mögliche Ergänzung ist es, den neuen Fileserver zuerst als Read-Only Replikat (erst ab Windows 2008 R2) laufen zu lassen, so wird sicher gestellt, dass nicht versehentlich auf dem neuen Fileserver Dateien gelöscht oder geändert werden und diese somit wieder zurück repliziert werden. Eine Änderung dieses Status bedeutet leider eine neue Initiale Replikation, d.h. DFSR kontrolliert erneut alle Dateien, ob sie sich in der Quelle oder im Ziel geändert haben. Dies bedeutet eine entsprechende Last und Verzögerung. Aus Erfahrung würde ich daher auf dieses Feature bei einer Migration verzichten.

Um die Initiale Replikation zu beschleunigen, kann man auch die Dateien zuerst auf einem anderen Weg übertragen. Hier bietet sich ein Backup oder Robocopy an. Dies hat den Vorteil, dass man das kopieren z.B. in der Nacht oder am Wochenende anstoßen und die volle Bandbreite nutzen kann. DFSR verwendet immer nur den gerade freien Anteil.

Eine Beschreibung wie die Initiale Replikation funktioniert ist hier zu finden:

http://blogs.technet.com/b/askds/archive/2008/02/12/get-out-and-push-getting-the-most-out-of-dfsr-pre-staging.aspx

Die passenden Kommandozeilen für Robocopy sind in diesem Artikel beschrieben:

http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx

ACHTUNG: Auf jeden Fall die aktuellste Robocopy Version (z.B. http://support.microsoft.com/kb/979808/en-us)  verwenden und möglichst auf einem Windows 2008 R2  Server kopieren. Auch die aktuellsten Hotfixe für DFSR können nicht schaden (eine Liste mit aktuellen Hofixen unter http://support.microsoft.com/kb/968429/en-us).

If you want to know if it is supported to run the SQL Server in a virtualized environment than this is the right article for you:

http://support.microsoft.com/kb/956893/en-us

Summaries:

1. SQL 2005 or higher is supported on Hyper-V or a hypervisor validated in the SVVP program
2. Snapshots of the VM are NOT supported.
3. Hyper-V Dynamic Memory is supported but only useful with SQL Server version Enterprise and Datacenter

Im letzten Teil habe ich beschrieben, wie man mit einer einfachen Batchdatei remote eine Hardwareinventur anstoßen kann. Was ist aber, wenn man dies auf mehreren PCs gleichzeitig machen will? Z.B. bei allen PCs, die eine bestimmte Software angeboten bekommen und somit in einer SCCM Collection sind?

Auch da hilft eine kleine Batchdatei:

starthinvall.cmd

for /F %%i in (‘cscript.exe //NOLOGO %~dp0getcomputer.vbs %1 siteserver sitename’) do call %~dp0starthinv.cmd %%i

Aufgerufen wird die Batchdatei mit den Namen der Collection, in der die Zielclients sind. Das passende getcomputer.vbs verbindet sich dann mit dem hinterlegten Siteserver und fragt in der angegebenen Site (sitename) die in der Collection hinterlegten Computer ab. Die Ausgabe (ein Computer pro Zeile) wird von der For Schleife abgefangen und an die starthinv.cmd weitergegeben.

getcomputer.vbs basiert weitestgehend auf einem Script von www.myitforum.com und wurde nur von der Ausgabe und Weiterverarbeitung angepasst.

Hier nochmal die Files als Download:

• starthinvall.cmd (261)
• getComputer.vbs (321)

Ich werde hier ab jetzt regelmäßig ein paar kleine Skripte rund um den System Center Configuration Manager (SCCM) bereitstellen. Geschrieben sind sie teilweise schon für SMS 2003 und funktionieren auch noch mit 2007.

Als erstes ein kleines Skript, um remote auf einem Client die Hardwareinventur anzustoßen:

@echo off
set PC=%1
if .%PC%==. set /p PC=Enter Computer Name to start HINV:
call %~dp0findip.bat %PC%
if %ip%.==. goto fehler
echo Start Hardware Inventur %PC%
cscript.exe //Nologo %~dp0sendsched.vbs {00000000-0000-0000-0000-000000000001}  %PC%
goto ende
:fehler
echo Abbruch, da Rechner %PC% auf ping nicht antwortet.
:ende
set ip=

Diese Batchdatei kann direkt mit dem Rechnernamen als Parameter aufgerufen werden. Wird nichts übergeben, dann fragt er nach dem Namen. Als erstes wird überprüft, ob der Rechner anpingbar und somit am Netzwerk ist. Dafür wird eine weitere Batchdatei aufgerufen, die ich nachfolgend anhängen werde. Danach wird ein VBScript aus dem SMS 2003 Toolkit 2 (http://technet.microsoft.com/en-us/sms/bb676787.aspx). Das Script sendet eine Nachricht per WMI an den Client. Jede Aktion eines Clients sind als Schedules bzw. Actions hinterlegt. Kennt man den entsprechenden Code, dann kann man diese sofort starten. In diesem Fall steht {00000000-0000-0000-0000-000000000001} für die Hardwareinventur.

Die findip.bat Datei sieht so aus:

@echo off
set ip=
set tempip=%temp%\%1.ip
ping %1 -n 1 |find /i “Antwort von” > “%tempip%”
for /F “eol=: tokens=3,* delims=: ” %%i in (%tempip%) do @set ip=%%i

if %ip%.==. goto englisch

goto ende

:englisch
ping %1 -n 1 |find /i “Reply from”>”%tempip%”
for /F “eol=: tokens=3,* delims=: ” %%i in (%tempip%) do @set ip=%%i

:ende
del %tempip%

Da die Quotes hier im Blog ziemlich verändert sind, habe ich die beiden Batchdateien noch als Download angehängt. Bitte Dateiendung entsprechend korrigieren:

• starthinv.cmd (297)
• findip.cmd (291)

Wenn bereits eine existierende SCCM Infrastruktur auf den Servern exisitert, dann macht es eventuell Sinn, den SCOM Client damit zu verteilen.

Dafür einfach ein Paket mit den Quelldateien aus dem AgentManagement Ordner vom SCOM Server erstellen.

Darin im x86 und x64 Ordner folgende Batchdatei install.cmd hinterlegen:

rem Sicherheitshalber msxml6 installieren (Voraussetzung)

msiexec.exe /i “%~dp0MSXML6.msi” /qn /m scom07 /l* “%systemroot%msxml6.log” REBOOT=REALLYSUPPRESS

msiexec.exe /i “%~dp0MOMAgent.msi” /qn USE_SETTINGS_FROM_AD=1 MANAGEMENT_GROUP=<hier name dermanagement group> MANAGEMENT_SERVER_DNS=<hier dns name  des scom servers oder gateways> ACTIONS_USE_COMPUTER_ACCOUNT=1 /m scom07 /l* “%systemroot%scomx86.log” REBOOT=REALLYSUPPRESS

Diese Batchdatei als Programm (jeweils für x86 und x64) hinterlegen. Als Collection in SCCM verwende ich im allgemeinen eine Sammelcollection, die die alle Zielsysteme hineinkommen. Darunter lege ich eine Filtercollection an, die aus den Zielsystemen nur die herausfiltert, die den Agent noch benötigen. Hier bietet sich eine Subselection als Query an, die alle Systeme ausschließt die den Dienst bereits haben. Eine Hardwareinventur (HW)  wird im Allgemeinen häufiger gemacht als eine Softwareinventur (SW). Daher erhält man die Infos über Dienst (HW) schneller zurück als Dateiinformationen aus der SW-Inventur.

Eine Query könnte so aussehen:

select SMS_R_System.ResourceID,SMS_R_System.ResourceType, SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from SMS_R_System inner join SMS_G_System_SERVICE on SMS_G_System_SERVICE.ResourceID = SMS_R_System.ResourceId where SMS_R_System.ResourceId not in (select SMS_R_System.ResourceId   from  SMS_R_System inner join SMS_G_System_SERVICE on SMS_G_System_SERVICE.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SERVICE.Name = “HealthService”)

Als Collectionlimit die übergeordnete Sammelcollection eintragen. Die Ankündigung läuft dann auf der Filtercollection.

Heute wollte ich mal wieder ein paar Blade Systeme ins ESX Cluster aufnehmen. Da ich aber bei einem bereits in einem anderen Zusammenhang ein Problem hatte, waren vorher einige Lasttests angebracht.Da momentan noch kein standardisiertes Tool eingesetzt wird, habe ich etwas im Internet gesucht und bin zufällig über ein sehr interessantes Tool mit Namen Inquisitor gestolpert. Es bietet eine Linux Live CD mit Burn-In Tests. An sich noch nichts besonderes. Interessant wird es zusammen mit der Serverkomponente, mit der solche Tests auch zentral protokolliert und verglichen werden können.

Den ersten Teil hab ich gleich erfolgreich über das ILO Board einsetzen können, den zweiten muss ich mir mal bei Gelegenheit genauer anschauen.