1. die Voraussetzungen für eine SCCM-Installation (inklusive SQL-Server) schafft und
2. den System Center Configuration Manager 2012 R2 installiert.

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!

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.

Vorbereiten der automatisierten Installation

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:

Erzeugen der SCCM-Anwendung

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…

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:

$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
}

Der Fehlertext lautet: „Der Benutzer, der Setup ausführt, muss am zentralen Zielverwaltungsstandort über die RBA-Sicherheitsrolle „Infrastrukturadministrator“ oder „Hauptadministrator“ verfügen. Überprüfen Sie, ob der Benutzer über die richtige Rolle verfügt.“

Die englische Fehlermeldung hierzu lautet: „The setup login user does not have sufficient permission to configure replication with specified central administration site“

Da der User bereits vorher an einem anderen Standort zu Installation problemlos genutzt wurde und auch über die Hauptadministrator-Rolle („Full Administrator“) verfügte, musste es ein anderes Problem sein.

Nach einigen Tests und Recherchen konnte ich den Fehler finden und beseitigen. Die beiden Standorte (Standort der CAS und Standort der neu zu installierenden Primary Site) sind über Site-to-Site-VPNs mit Hilfe vom ISA-Server bzw. Forefront TMG verbunden. Hier gibt es eine Filter-Regelung namens „Strikte RPC-Einhaltung erzwingen“ („Enforce strict RPC compliance“):

(Zu finden unter „Webzugriffsrichtlinie“ / „RICHTLINIE“ / „Protokolle“ / „Filterung“ / „RPC-Protokoll konfigurieren“)

Nach dem ich diese Option auf beiden Seiten deaktiviert und die VPN-Verbindungen neu aufgebaut hatte, ließ sich die neue Primary Site problemlos installieren, da nun DCOM-Traffic zulässig war.