Juhu! Endlich wieder ein paar neue Management Packs (MP) auf der SCOM 2007 Front!. Nach langem wurde wieder das Core OS MP aktualisiert.
Folgende Änderungen wurden dabei gemacht:
The September 2011 release (version 6.0.6957.0) of the System Center Monitoring Pack for the Windows Server Operating System includes the following changes:
Optimized operating system performance collection rules.
Bei einem Kunden haben wir momentan das Problem, dass es für jeden per OSD neu installierten Rechner zwei Einträge gibt. Einer mit einem aktiven Client und ein zweiter ohne Client aber mit den Active Directory Gruppen. Da die Verteilung von individueller Zusatzsoftware per AD Gruppen erfolgt ist dies ein Problem, da zwar die Collectionzuordnung erfolgt, als Ziel aber der falsche Client verwendet wird. Aktiv ist das neue Delta-Discovery (5min) von R3 und auch eine relativ kurzes Full-Discovery.
Die SCCM Produkt Gruppe hat zu diesem Problem bereits einen Workaround beschrieben, der anhand der Anleitung auch sehr gut umzusetzen war:
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.
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.
In seltenen Fällen kommt es noch vor, dass man eine alte Software auf einem aktuellen Windows 7 installieren muss. Damals haben die Entwickler nicht mit einem neuen Betriebssystem gerechnet oder erwartet, dass man rechtzeitig neue Lizenzen kauft. Teilweise hängt an der Client Software entsprechende Backend-Systeme, die nicht so einfach aktualisierbar sind.
Hat man es somit mit einem MSI Paket zu tun, dass einem aufgrund von nichtunterstütztem Betriebssystem den Dienst verweigert (s. Bild), so kann man verschiedene Wege wählen:
Windows selber bietet die Möglichkeit an, die Kompatibilität zu korrigieren. Dazu wählte man im Kontextmenü des MSI-Pakets (“Rechter Mausklick”) den Punkt “Troubleshoot compatibility”. Genutzt wird dabei das Windows 7 eigene “Microsoft Diagnostic Tookit” (msdt.exe) mit dem Bereich PCWDiagnostic. Dieser wäre auch scriptbar. Weitere Informationen findet man unter http://technet.microsoft.com/de-de/library/ee424379%28WS.10%29.aspx und den entsprechenden weiterführenden Links.
Elegant finde ich auch die Möglichkeit den entsprechenden Check direkt aus dem MSI File zu extrahieren. Dazu ist noch nicht einmal ein MSI Admin Studio oder ähnliches notwendig. Eine VBScript Datei und die Funktionalität des MSI Installers reichen aus. Zu finden ist dieses hilfreiche Skript unter http://lazynetworkadmin.com/content/view/20/1/
Eine häufig bemängelte Einschränkung des SCCM 2007 ist es, dass die darin enthaltene Updateverteilung keine Updates automatisch freigeben kann. In größeren Umgebungen ist dies im Allgemeinen auch nicht wünschenswert, da neue Microsoft Updates zuerst getestet und dann erst verteilt werden sollten.
Bei Antivirendefinitionen macht ein solches Vorgehen keinen Sinn. Tests gegen alte und neue Viren oder gegen bestimmte Clients, um False-Positives zu erkennen kann man ein paar Mal machen, sobald Updates mehrfach am Tag kommen ist dies nicht mehr sinnvoll.
Forefront Client Security 2010 integriert sich so tief in den SCCM, dass auch für die Definitionsverteilung der SCCM genutzt werden kann. Hat dieser keine aktuellen Definitionen, so kann der Client auf eine Freigabe (UNC-Pfad), einen WSUS oder Microsoft Updates ausweichen. Als WSUS wird natürlich der auf dem Client hinterlegte verwendet, der bei einem SCCM Client immer der vom Server gemanagte WSUS sein muss.
Daher wäre es wünschenswert, wenn dieser die Definitionsupdates automatisch freigibt. Generell ist es nicht empfehlenswert in einen vom SCCM verwalteten WSUS einzugreifen. In diesem Szenario ist es die einzige sinnvolle Lösung.
Um das (von mir ebenfalls schon umgesetzte) Verfahren nicht erneut beschreiben zu müssen, verlinke ich einfach auf den nachfolgenden Blog Post:
Ich arbeite als Systemingenieur in diversen Kundenprojekten bei der TechniData IT Service GmbH, die u.a. Standorte in Karlsruhe und Markdorf unterhält.
Juhu! Endlich wieder ein paar neue Management Packs (MP) auf der SCOM 2007 Front!. Nach langem wurde wieder das Core OS MP aktualisiert.
Bei einem Kunden haben wir momentan das Problem, dass es für jeden per OSD neu installierten Rechner zwei Einträge gibt. Einer mit einem aktiven Client und ein zweiter ohne Client aber mit den Active Directory Gruppen. Da die Verteilung von individueller Zusatzsoftware per AD Gruppen erfolgt ist dies ein Problem, da zwar die Collectionzuordnung erfolgt, als Ziel aber der falsche Client verwendet wird. Aktiv ist das neue Delta-Discovery (5min) von R3 und auch eine relativ kurzes Full-Discovery.
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.
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:
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).
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.
In seltenen Fällen kommt es noch vor, dass man eine alte Software auf einem aktuellen Windows 7 installieren muss. Damals haben die Entwickler nicht mit einem neuen Betriebssystem gerechnet oder erwartet, dass man rechtzeitig neue Lizenzen kauft. Teilweise hängt an der Client Software entsprechende Backend-Systeme, die nicht so einfach aktualisierbar sind.
Eine häufig bemängelte Einschränkung des SCCM 2007 ist es, dass die darin enthaltene Updateverteilung keine Updates automatisch freigeben kann. In größeren Umgebungen ist dies im Allgemeinen auch nicht wünschenswert, da neue Microsoft Updates zuerst getestet und dann erst verteilt werden sollten.
