Blog von Haiko Hertes zu allen Themen rund um Microsoft, Cloud und Datacenter
Da ich in den letzten Monaten immer wieder Artikel und Videos verschiedenen Themen des SCCM geschrieben bzw. produziert habe, möchte ich diese hier gerne übersichtlich verknüpfen und diesen Artikel auch bei Bedarf künftig aktualisieren.
Das sind sie also nun, meine SCCM-Artikel und Videos:
Letzter Stand der Aktualisierung: 27.10.2015
Viel Spaß damit!
Schreibe einen Kommentar...Da ich heute im SCCM-Kurs danach gefragt wurde, und auch länger nichts mehr geschrieben habe, heute ein kurzer Artikel aus der SCCM-Welt…
Während des Setups vom System Center Configuration Manager 2012 bzw. 2012 R2 müssen einige Prerequisite-Files heruntergeladen werden:
Diese Dateien umfassen u.a. Sprachdateien, Silverlight, SQL Express und andere “Hilfsdateien” die der SCCM für sich oder seine Clients benötigt:
Alternativ kann man umschalten auf “bereits heruntergeladene Dateien”. Dies ist insbesondere dann sinnvoll, wenn der künftige Standortserver keinen Internetzugang hat. Doch woher kommen diese Dateien dann? Sicher, man könnte sich auf einem anderen Server MIT Internetzugang soweit durch das Setup klicken, dass man dort die Dateien herunterladen kann. Was aber, wenn man KEINEN Server mit Internetzugang hat?
Dafür gibt es eine Lösung: SetupDL.exe!
Diese Anwendung befindet sich auf der SCCM-DVD in SMSSETUP\BIN\x64: (Mit SHIFT-RECHTSKLICK kann man sich “den Pfad kopieren”)
Entweder kann die Anwendung per Doppelklick…
… oder per Kommandozeile gestartet werden:
Durch Angabe eines Zielpfades beginnt der Download der Dateien (ca. 650MB):
Anschließend kann man diese Dateien für den künftigen SCCM-Siteserver zur Verfügung stellen…
Schreibe einen Kommentar...Ich habe euch ein Video erstellt, in dem ihr sehen könnt wie ihr:
Das Ganze zeige ich am Beispiel einer Single-Server-Lösung für eine Stand-alone Primary Site, lässt sich aber auf viele andere Szenarien übertragen.
Viel Spaß mit dem Video!
2 CommentsAuf Anregung einiger Teilnehmer habe ich heute ein Video erstellt, das zeigt, wie man die OSD-Komponenten des System Center Configuration Manager 2012 R2 nutzt, um Betriebssysteme zu verteilen. Das Operating System Deployment stützt sich dabei auf WDS/PXE und DHCP.
Das Video könnt ihr hier finden:
Die Folien dazu sind hier zu finden:
Viel Spaß dabei!
Schreibe einen Kommentar...Will man Office 2013 (oder eine andere Version) über den System Center Configuration Manager 2012 R2 (oder auch ältere Versionen) automatisch und ohne Benutzerinteraktion installieren, so bedarf es ein paar kleiner Kniffe.
Den gesamten Ablauf, wie hier vorzugehen ist, möchte ich im Folgen aufzeigen. Wichtig ist, dass man als Quelle eine Volumenlizenz-DVD benötigt. Diese erkennt man am “admin”-Ordner auf der DVD im Stammverzeichnis.
Zunächst muss der Inhalt der Office 2013 DVD auf ein freigegebenes Verzeichnis kopiert werden, in meinem Fall der Ordner “Sources”, welcher auf dem SCCM-Standalone-Server existiert und als “\SOURCES” freigegeben ist:
Anschließend wird das “Microsoft Office-Anpassungstool” (engl.: “Office Customization Tool”) über den Aufruf der setup.exe mit Parameter gestartet:
setup.exe /admin
Hier wird nun eine neue Setupanpassungsdatei erstellt:
Außerdem lässt sich das künftige Office-Dateiformat wählen:
Nun können diverse Anpassungen am künftigen Setup gemacht werden. Zu Beginn kann man z.B. die Unternehmensdaten hinterlegen:
Außerdem muss die Lizenzierung sowie das Verhalten der Benutzeroberfläche festgelegt werden:
Hier wird dem Lizenzvertrag zugestimmt, die Anzeigeebene auf “Grundlegend” gestellt sowie die beiden unteren Checkboxen angewählt und die obere Checkbox abgewählt.
In den Setup-Eigenschaften wird noch mit einer neuen Eigenschaft “SETUP_REBOOT” und deren Wert “Never” ein Neustart nach dem Setup unterdrückt:
Um den “Welcome-Screen” beim ersten Start zu deaktivieren ist unter “Benutzereinstellungen ändern” / “Microsoft Office 2013” / “Datenschutz” / “Trust Center” der Eintrag “Bestätigungs-Assisten […] deaktivieren” auf “Aktiviert” zu setzen:
Weiterhin können bei Bedarf weitere Anpassungen gemacht werden, z.B. die zu installierenden Programmbestandteile:
Abschließend werden die Einstellungen in einer neuen Datei im “Updates”-Pfad unterhalb des Stamm-Pfades der Office-Installation abgespeichert:
Nun da die MSP-Datei erstellt wurde, kann im SCCM ein neues Anwendungs-Objekt für Office 2013 erzeugt werden:
Dabei ist “Windows Installer (MSI-Datei)” als Typ auszuwählen und über den “Durchsuchen”-Dialog die proplusww.msi unterhalb des “proplus.ww”-Ordners zu öffnen:
Unter den “Allgemeinen Informationen” können bzw. müssen einige Informationen hinterlegt bzw. geändert werden. So kann man weitere Produkt-Details zur Installation angeben. In jedem Fall muss man im Feld “Installationsprogramm” die MSI gegen den Eintrag “setup.exe” austauschen und sicherstellen, dass als “Installationsverhalten” der Eintrag “Für System installieren” ausgewählt ist.
Anschließend muss der “Bereitstellungstyp” des neuen Anwendungsobjektes geöffnet werden, da hier noch Änderungen vorgenommen werden müssen:
Auf dem Reiter “Inhalt” muss im Pfad des “Inhaltsort” abschließende “\proplus.ww” entfernt werden…
… und auf dem Reiter “Programm” im Feld “Deinstallationsprogramm” statt MSI-Weges einfach nur “Setup.exe /uninstall” eingetragen werden:
Bei Bedarf können auf dem Reiter “Anforderungen” noch selbige definiert werden. Da ich hier eine 64-Bit-Installation verwendet habe, ist natürlich auch das entsprechende OS nötig:
Ist man damit fertig, kann man das Office-Anwendungs-Objekt jetzt wie gewohnt verteilen und anschließend für die gewünschte (idR. extra dafür neu anzulegende) Gerätesammlung bereitgestellt werden…
1 KommentarMit Hilfe des System Center Configuration Manager 2012 / 2012 R2 ist es sehr einfach möglich, Windows- und Microsoft-Updates an die Clients und Server des eigenen Netzwerkes zu verteilen. Im Hintergrund arbeitet hierzu der bekannte WSUS-Dienst, welcher wiederum mit Microsoft kommuniziert, um die Updates von dort zu beziehen.
Wäre es nicht auch gut, wenn man auf ähnliche Weise auch Anwendungen von anderen Herstellern patchen könnte? JA! Und man kann!
Das einzige was man neben WSUS und dem SCCM braucht, ist der System Center Update Publisher, kurz SCUP. Mit diesem kann man Updates anderer Hersteller aus “externen Katalogen” beziehen. Und das beste: SCUP ist kostenlos!
Im Folgenden möchte ich die Installation und Einrichtung von SCUP zeigen. Ausgangslage ist ein installierter SCCM mit einer einzigen Primary Site (stand-alone), einem installierten WSUS und einem darauf laufenden Software Update Point (SUP).
Als erstes muss SCUP heruntergeladen werden. Dies geht über diese Quellen:
https://technet.microsoft.com/de-de/systemcenter/bb741049.aspx
bzw.
https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11940
Nach dem Download kann die Installation durchgeführt werden, welche jedoch Admin-Rechte benötigt:
Wenn es sich bei dem WSUS-Server um einen Windows Server 2008 R2 oder älter handelt, dan ist die Installation eines Patches nötig, der während des SCUP-Setup angeboten wird:
Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0!
Um nun überhaupt Updates via SCUP auf dem WSUS veröffentlichen zu können, ist noch etwas Vorarbeit nötig. Diese Vorgänge sind etwas genauer hier dokumentiert (dies betrifft idR nur den Windows Server 2012 / 2012 R2):
https://technet.microsoft.com/en-us/library/hh134747.aspx#PublishToServer2012
Folgende Schritte sind im Wesentlichen nötig:
Regedit.exe, dort bis HKEY_CLASSES_ROOT\AppID\{8F5D3447-9CCE-455C-BAEF-55D42420143B} durchhangeln und dann den Eigentümer von diesem Pfad ändern sowie für “SYSTEM” und die “Administratoren” den Vollzugriff vergeben (Durch einen Klick auf die Bilder werden diese in größerer Auflösung gezeigt):
Nun kann der “System Center Update Publisher” über das Startmenü gestartet werden – dies sollte aber “Als Administrator” geschehen, da es sonst später zu einem Fehler kommt / kommen kann.
Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet:
Als erstes sind die Optionen zu öffnen:
Dort muss nun die Verbindung zum WSUS-Server konfiguriert werden (dabei Port beachten – WSUS 4.0 läuft auf 8530 (non-SSL) bzw. 8531 (SSL)):
Nun fehlt noch ein Zertifikat zum signieren der Updates. Hier kann auch ein selbstsigniertes Zertifikat erzeugt und verwendet werden. Dies geschieht über den “Create”-Button:
Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert:
Das WSUS-/SCUP-Zertifikat muss nun in die “Trusted Publishers” (Vertrauenswürdige Herausgeber) und die “Trusted Root Certificates” (Vertrauenswürdige Stammzertifizierungsstellen) des Computer-Kontos (WSUS/SCUP-Server) importiert werden, vorher muss es natürlich exportiert werden:
Nun können die ersten Updates über den SCUP veröffentlicht werden. Dazu muss zunächst ein Katalog hinzugefügt werden:
Beispielhaft verwende ich hier den “Adobe Reader X” Katalog:
Danach können die Updates aus diesem Katalog in den SCUP importiert werden:
Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden:
Diese neue Veröffentlichung (Bei mir heißt sie “März 2015”) kann nun veröffentlicht werden. Dazu wird sie unter “Publications” ausgewählt, die jeweiligen Updates markiert und dann auf “Publish” geklickt.
Dabei sollten die Updates vom SCUP signiert werden:
Nun kann im SCCM eine erste Synchronisierung durchgeführt werden. Diese ist nötig, damit der SUP (SCCM) “erfährt”, dass es nun auch Adobe als neuen Hersteller und Adobe Reader als Produkt gibt:
Die letzte Meldung zeigt an, dass die Synchronisierung abgeschlossen ist. Nun kann das neue Produkt (in meinem Fall der Adobe Reader) für die Verteilung durch den SUP aktiviert werden:
Dabei ist auch der Reiter “Klassifizierungen” zu beachten – wenn das gewünschte Update ein “Sicherheitsupdate” ist, SUP aber nur “Wichtige Updates” synchronisiert, dann wird man nicht zu einem positiven Ergebnis kommen.
Nun ist noch einmal eine Synchronisierung des SUP nötig, damit dieser die bekannten Updates vom WSUS “kennenlernt”.
Danach stehen die Updates, in meinem Fall für den Adobe Reader, im SCCM wie ein reguläres Windows Update zur Verfügung und können verteilt und bereitgestellt werden:
Viel Spaß damit!
2 CommentsDa ich in der letzten Zeit immer wieder gefragt wurde, wie man einen Linux-Computer zur Verwaltung von SCCM hinzufügen kann, möchte ich dies hier kurz darstellen.
Zunächst benötigt man hierzu die Installationsquellen für den Configuration-Manager-Client für Linux bzw. Unix. Diese lassen sich über den Splash-Screen der SCCM-DVD besorgen:
Über diesen Link gelangt man (je nach Sprache) auf einer Microsoft-Webseite, z.B. dieser:
http://www.microsoft.com/de-de/download/details.aspx?id=39360
Beim Klick auf “Herunterladen” steht noch die Wahl, welche Version benötigt wird:
Die heruntergeladene EXE-Datei muss nun noch mittels Doppelklick entpackt werden:
Nach dem Entpacken müssen die Dateien auf das gewünschte Linux-/Unix-System kopiert werden. Beispielhaft verwende ich dazu SSH:
Nach dem Kopieren der Dateien muss die Datei “install” noch ausführbar gemacht werden. Dies geschieht mittels
1 | chmod +x install bzw. sudo chmod +x install |
chmod +x install bzw. sudo chmod +x install
Nach diesem Vorgang kann die Installation gestartet werden. Als Parameter sind der Name eines Management-Point-Servers, der Site-Code sowie die notwendige Linux-Version anzugeben:
In meinem Fall lautet der Aufruf:
1 | ./install –mp srv1.kurs.intern –sitecode PS0 ccm-Universalx64.tar |
./install –mp srv1.kurs.intern –sitecode PS0 ccm-Universalx64.tar
Sobald die Installation komplett ist, muss der Client noch im SCCM genehmigt werden:
Nun ist der Client im SCCM registriert. Das lokale Logfile des Clients befindet sich unter
/var/opt/microsoft/scxcm.log
Dieses kann z.B. mit Hilfe des Aufrufs
1 | tail -F /var/opt/microsoft/scxcm.log |
tail -F /var/opt/microsoft/scxcm.log
beobachtet werden.
Will man nun z.B. einen Policy-Abruf oder einen Hardware-Inventur-Zyklus erzwingen, ist dies mit den Aufrufen
1 | /opt/microsoft/configmgr/bin/ccmexec -rs policy |
/opt/microsoft/configmgr/bin/ccmexec -rs policy
bzw.
1 | /opt/microsoft/configmgr/bin/ccmexec -rs hinv |
/opt/microsoft/configmgr/bin/ccmexec -rs hinv
möglich.
Bei Bedarf kann man sich z.B. noch eine Gerätesammlung für alle Linux-/Unix-Systeme anlegen. Als begrenzende Sammlung verwendet man sinnvollerweise “Alle Systeme”. Die Mitgliedschaft lässt sich mit der Abfrageregel auf “Systemressource / Betriebssystem-Name und –Version” realisieren:
Viel Spaß beim Ausprobieren!
Schreibe einen Kommentar...Der System Center Configuration Manager (SCCM) 2012 R2 bietet die Möglichkeit, Anwendungen für Benutzer als “verfügbar” bereitzustellen. In dieser Kombination (und nur dort) lässt sich auch eine Genehmigungsanforderung einschalten:
Der Benutzer hat nun die Möglichkeit, die Software über den Application Catalog (Anwendungskatalog) anzufordern:
Wurde die Anforderung vom Benutzer ausgelöst, so taucht sie dann in der SCCM-Konsole auf:
Leider ist es nicht vorgesehen, dass man das Eintreffen einer neuen Anforderung per E-Mail o.ä. meldet und in der Regel sitzt kein Admin den ganzen Tag vor der GUI und wartet auf neue Anforderungen. Also muss man eine andere Lösung schaffen, dies weitgehend zu automatisieren.
Eine Variante wäre, bei Eintreffen eben eine E-Mail zu versenden. Dazu muss man das Eintreffen einer Anforderung automatisiert feststellen können. Und dazu ist die PowerShell sehr gut geeignet:
Der Aufruf dazu lautet:
Get-CMApprovalRequest | Where-Object {$_.CurrentState -eq 1}
(CurrentState ist der Zustand der Anfroderung; “1” bedeutet, sie ist neu und unbearbeitet, “4” bedeutet z.B., sie ist bereits genehmigt)
Mittels Format-Table o.ä. könnte man die Ausgabe noch aufbereiten:
Nun lässt sich diese Ausgabe z.B. in eine E-Mail verpacken. Ein komplettes Skript könnte dann so aussehen:
1 2 3 4 5 6 7 8 9 10 | $FromAdr = admin@abc.de $ToAdr = receiver@abc.de $SMTPSrv = send.abc.de $MailSubject = "New SCCM Application Approval Request" If((Get-CMApprovalRequest | Where-Object {$_.CurrentState -eq 1} | Measure-Object).Count -gt 0) { $Mailtext = Get-CMApprovalRequest | Where-Object {$_.CurrentState -eq 1} | ft Application,User,Comments -Auto Send-MailMessage -from $FromAdr -to $ToAdr -subject $MailSubject -body $Mailtext -smtpServer $SMTPSrv } |
$FromAdr = admin@abc.de $ToAdr = receiver@abc.de $SMTPSrv = send.abc.de $MailSubject = "New SCCM Application Approval Request" If((Get-CMApprovalRequest | Where-Object {$_.CurrentState -eq 1} | Measure-Object).Count -gt 0) { $Mailtext = Get-CMApprovalRequest | Where-Object {$_.CurrentState -eq 1} | ft Application,User,Comments -Auto Send-MailMessage -from $FromAdr -to $ToAdr -subject $MailSubject -body $Mailtext -smtpServer $SMTPSrv }
Wenn man (z.B. während der Einführungsphase vom System Center Configuration Manager) den bisherigen WDS-Server (Windows Bereitstellungsdienste / Deployment Services) weiterhin nutzen will, aber parallel die Betriebssystembereitstellung (OSD) von SCCM benötigt, dann besteht im Wesentlichen das folgende Probleme:
Da PXE auf Broadcasts basiert, kann es nur einen PXE-Server geben, den der Client letztlich kontaktiert (man kann per Verzögerung dafür sorgen, das einer immer schneller ist als der andere). Wenn man nun also PXE am SCCM aktiviert, dann ist es quasi Glückssache, ob der Client zuerst die Meldung vom WDS oder zuerst die von SCCM empfängt – in den meisten Tests war SCCM schneller. Damit bleibt also nur eine der beiden Technologien nutzbar.
Aber es gibt eine Lösung! Diese ist leider a) nicht wirklich dokumentiert und b) seitens Microsoft auch nicht unterstützt (man hört aber, das selbst Microsoft diese Lösung intern einsetzen soll).
Die Lösung besteht darin, dem Benutzer am Client die Wahl zu lassen, welchen der gefundenen PXE-Server er nutzen will. Um dies zu erreichen, ist am WDS-Server (also derjenige, der nicht der SCCM-Server ist) ein Registry-Key zu setzen:
Zusätzlich muss am SCCM in den eigenschaften des Distribution-Points (Verteilungspunkt) für eine ausreichende Verzögerung gesorgt werden (würde man zuerst den PXE vom SCCM booten, dann hat der RegKey dort keine Wirkung, da dieser nur auf den WDS-eigenen PXE-Provider wirkt, nicht aber auf den vom SCCM):
Wenn nun ein Client einen PXE-Boot versucht (und die Verzögerung ausreichend war, dass sich zuerst der Nur-WDS-PXE-Server meldet), dann bekommt der Benutzer zusätzlich zu der Möglichkeit, per F12 vom Netzwerk zu booten eine weitere Option: F11 für eine Server-Auswahl!
Drückt man jetzt F12, wird wie gewohnt DIESER WDS-Server genutzt und von dort mittels PXE gebootet. Drückt man jedoch F11, werden zuerst alle verfügbaren WDS-Server erkannt:
Danach bekommt man eine Auswahl-Liste mit allen gefundenen PXE-Servern:
Hier kann nun der jeweilige PXE-Server gewählt werden. Der WDS-Server selber steht an erster Stelle, an zweiter Stelle steht hier der SCCM mit aktiviertem PXE.
Auf diese Weise ist es möglich, WDS und SCCM oder mehrere WDS-Server parallel zu betreiben. Natürlich muss die entsprechende DHCP-Infrastruktur aufgebaut sein, damit PXE überhaupt funktionieren kann!
Schreibe einen Kommentar...Auf einem unserer SCCM-Server ist mir aufgefallen, dass sich das Laufwerk C:\, welches großzügig bemessen ist, nahezu komplett gefüllt hat. Eine einfach Analyse mit TreeSize brachte folgendes zum Vorschein:
Wie auf dem Screenshot zu sehen ist, hat das receive-Verzeichnis unter "C:\Program Files\Microsoft Configuration Manager\inboxes\despoolr.box\receive" eine beachtliche Größe bekommen. Aber was sind das nun für Dateien? Zuersteinmal kann man allgemein sagen, dass dies Daten sind, die auf dem lokalen Verteilungspunkt (“Distribution Point”, DP) verteilt werden sollten und hier während der Empfangs-Phase zwischengespeichert wurden. Aber um welches Paket handelt es sich?
Dazu kann man das Logfile bemühen. Unter “C:\Program Files\Microsoft Configuration Manager\Logs” liegen die verschiedenen Log-Dateien, für diesen Zweck zuständig ist die despool.log (oder auch despool.lo_, falls die ursprüngliche despool.log ihre maximale Größe erreich hatte). Öffnen kann man die Logdateien am besten mit dem SCCM-eigenen Tool “CMTrace”, welches unter "C:\Program Files\Microsoft Configuration Manager\tools\cmtrace.exe" zu finden ist. Dort kann man nun mittels des Fernglas-Symboles suchen:
Als Suchtext kann der Name der größeren Datei verwendet werden, hier also “PKGhl61p.TRY”. Dabei kommt dann auch der Paketname zum Vorschein:
Hier in diesem Fall also “CAS00045”. Nun kann man in der Configuration Manager Konsole unter “Überwachung / Verteilungsstatus / Inhaltsstatus” den Status für des betreffende Paket prüfen:
Da das Paket (mittlerweile) erfolgreich auf den lokalen DP kopiert wurde, kann man die *.TRY-Datei also löschen. Dass dies nicht automatisch vom System gemacht wurde, dürfte hier in diesem Fall daran liegen, dass die Verteilung über WAN auf Grund der Größe des Paketes mehrfach gescheitert ist…
Schreibe einen Kommentar...