SCCM 2007 setzt (noch) 32bit Agenten ein. Daher wird auch ein Programm zuerst einmal im 32bit Kontext ausgeführt und bekommt daher über die Redirects primär Zugriff auf das syswow64 Verzeichnis. Startet man ein regedit, so wird die 32bit Variante gestartet. Es gibt Situationen, in denen man auf jeden Fall die OS native Variante starten möchte, d.h. auf einem x64 die 64bittige und analog auf einem x86 die 32bit. Dazu kann man in einer Batchdatei überprüfen ob bestimmte Kriterien erfüllt sind, oder man verwendet direkt einen (auch mir vor kurzem ) eher unbekannten Alias: sysnative.
So kann man einen Aufruf von %windir%\system32\regedit.exe ersetzen durch %windir%\sysnative\regedit.exe. Im WOW64 Kontext wird dieser Alias erkannt und durch den Verweis auf die 64bit Variante ersetzt.
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…
Im letzten Teil wurde eine Batchdatei zur Erzeugung von CCR Dateien vorgestellt. Möchte man direkt eine komplette Collection installieren lassen, dann läßt sich dies wieder einfach mit der getcomputer.vbs Datei umsetzen:
makeccrall.cmd:
for /F %%i in ('cscript.exe //NOLOGO %~dp0getcomputer.vbs %1 smsserver sitecode') do call %~dp0makeccr.bat %%i
(auch hier wieder smsserver und sitecode durch die korrekten Daten ersetzen)
Alterntiv möchte man eventuell die Installation erzwingen, d.h. egal ob ein Client vorhanden ist oder nicht soll dieser auf jeden Fall installiert und gegebenenfalls repariert werden. Dazu muss in der CCR Datei ein zusätzlicher Parameter angegeben werden. Hierfür ist die Batchdatei forcemakeccr.cmd zuständig:
Im vierten Teil wird eine Batchdatei zum Remoterollout des SCCM Clients vorgestellt. Dazu wird ein Client Configuration Request (CCR) erzeugt und in das entsprechende SCCM Verzeichnis abgelegt. Auf dieses reagiert der Server und versucht den Client remote zu installieren (ähnlich des Clientrollouts über die MMC Konsole).
Auch diese Batchdatei benötigt wieder die Datei findip.bat aus dem ersten Teil.
@echo off
set PC=%1
set sitecode=SMS
set siteserver=SMSSERVER
if .%PC%==. set /p PC=Enter Computer Name to install SMS Client:
call %~dp0findip.bat %PC%
if %ip%.==. goto ende
:testdomain
echo Computer:%PC%
:weiter
set output="%temp%\%PC%.ccr"
echo [NT Client Configuration Request]>%output%
echo Client Type=1>>%output%
echo Machine Name=%PC%>>%output%
copy %output% \\%siteserver%\sms_%sitecode%\inboxes\ccr.box\
dir \\%siteserver%\sms_%sitecode%\inboxes\ccr.box
del %output%
:ende
set output=
set ip=
set d=
In der dritten und vierten Zeile muss der jeweilige Siteserver und der SCCM Sitecode angegeben werden. Aufgerufen wird die Batchdatei wie üblich mit dem Ziel-PC Name als Parameter.
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.
Gestern habe ich noch gefragt, ob es schon einen Agent für RHEL6 gibt. Heute stoße ich über den Hinweis, dass das Cumulativ Update 5 (CU5) schon seit 3 Tagen verfügbar ist!
Es korrigiert einen recht störenden Agent Update Bug im CU4 (beim Update des Agents, der normalerweise kein Neustart des Servers benötigt wurden automatisch andere Dienste neugestartet und hat somit zu Serviceunterbrechungen geführt) und ein paar andere Fehler. Zusätzlich beinhaltet es den Agent für Red Hat 6.
In den letzten 8 Tagen ist ein interessantes Management Pack von Microsoft veröffentlicht worden. Dabei handelt es sich um das MP für das Red Had Enterprise Linux 6 Betriebssystem. Gibt es dazu zu schon einen passenden Linux Agenten?
Neue Management Packs im Zeitraum zwischen 29.07.2011 und 06.08.2011
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:
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.
Ich arbeite als Systemingenieur in diversen Kundenprojekten bei der TechniData IT Service GmbH, die u.a. Standorte in Karlsruhe und Markdorf unterhält.