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.

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:

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:

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.

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.

Hier ein kurzer Abriss wie PXE und unknown Computer in SCCM 2007 R2/R3 funktioniert:

1. Client bootet per PXE
2. Client holt sich per Broadcast eine DHCP Adresse vom DHCP Server, steht dieser nicht im gleichen Subnetz, dann muss er per IP Helper Adresse bekannt gemacht worden sein (Achtung: keine Bootoptionen notwendig)
3. Client sendet ein weiteres PXE Broadcast Paket um seinen Installationsserver zu finden (auch hier: IP Helper Eintrag!)
4. Der Dienst WDSServer auf dem SCCM erhält diese Nachricht und leitet sie an den integrierten PXE Filter von SCCM weiter
5. der SCCM Thread wertet die Anfrage aus (Logs zu finden unter SMS_CCM\Logs\smspxe.log, das SMS_CCM Verzeichnis liegt parallel zum “Microsoft Configuration Manager” Verzeichnis)
6. Er überprüft, ob die MAC bzw. GUID des Rechners in der Anfrage in der SCCM Datenbank bekannt ist
7. Falls ja, überprüft er, ob eine Tasksequenze für eine Neuinstallation zugeordnet ist und kein letzte PXE-Boot eingetragen ist (Auf dem Client in der MMC Console einen Rechten Mausklick und “Clear Last PXE Advertisement” auswählen um dieses Flag zu entfernen)
8. Falls nein, überprüft er, ob “Unkown Computer Support” in den Einstellungen aktiv ist (Site Systems\Servername\ConfigMgr PXE Service Point Eigenschaften und “Enable unknown computer support”). Ist dies der Fall sucht er sich die Collections heraus, in denen das “Unknown Computer” Objekt in der entsprechenden Prozessorarchitektur (x64, x86) vorhanden ist. Liegt auf einer eine erzwungene Task Sequence, dann sendet er dem Client das darin hinterlegte Win PE Boot Image und eine normale SCCM OS Installation startet.

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:

Vor einigen Tagen hat Microsoft den System Center Updates Publisher (SCUP) in der Version 2011 veröffentlicht.  Er beinhaltet einige interessante Neuerungen:

• Automatic Updates mit SCCM: zuerst wird ein Update nur als metadata veröffentlicht ohne das eigentliche Update herunterzuladen. Bei einer späteren Synchronisation ließt der SCUP aus dem SCCM (System Center Configuration Manager 2007 oder höher) aus, ob Clients dieses update benötigen. Ist dies der Fall, dann lädt er das komplette Update herunter und stellt es in den WSUS zur Verteilung bereit
• Software update Cleanup Wizard: Ermöglicht es nicht mehr benötigte Updates zu bereinigen, indem sie auf expired gesetzt werden
• …

Herunterzuladen ist das Tool unter http://www.microsoft.com/downloads/en/details.aspx?FamilyID=083f45ca-1ede-4f7a-be74-77854c3a9b01.

Gerade bei einer Installation von SCCM 2007 braucht man viele Voraussetzungen. Besonders im Bereich IIS sind viele Features hinzuzufügen.

Hilfreich ist hier ein kleines Script von Jörgen Nilsson, das einen Großteil der Voraussetzungen automatisch installiert:

http://ccmexec.com/?p=1036