Ich habe euch ein Video erstellt, in dem ihr sehen könnt wie ihr: die Voraussetzungen für eine SCCM-Installation (inklusive SQL-Server) schafft und 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!
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. 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 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:
Zum Kopieren:
$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
}
Sie möchten mehr zum System Center Configuration Manager erfahren und weitere Tips und Tricks erhalten? Dann sind Sie bei unserer SCCM-Schulung genau richtig!
Warum kompliziert und mit viel Handarbeit, wenn’s auch anders geht. Ob man nun Sharepoint einmal installiert oder des Öfteren, sollte – falls noch nicht bekannt - man sich mit mal den Sharepoint AutoSPinstaller genauer ansehen. Der AutoSPInstaller installiert, wie der Name schon prophezeit, von den Prerequesits an bis hin zum “Portal” inklusive aller Dienste alles, was das Sharepoint-Herz höher schlagen lässt.
Die Vorteile sind unter anderem “schöne” Datenbanknamen, das Deaktivieren nicht notwendiger Dienste, das Ausschalten des LoopbackChecks und der verstärkten Sicherheitskonfiguration des IE. Gefühlt, aber nicht gemessen steht der Sharepoint Server in kürzerer Zeit. Zumindest hatte ich währenddessen Zeit für ein paar Tassen Cappuccino und einen Plausch mit meinen Kollegen.
Der Autoinstaller benötigt eine XML-Konfigurationsdatei, in der sämtliche Angaben enthalten sein müssen. Nun ist es nicht jedermanns Sache sich ein XML-File zusammenzubasteln, aber auch das kann man sich mittels passendem Tool, dem AutoinstallerGUI zusammenbasteln.
Beide Tools sind auf Codeplex zu finden:
Sharepoint AutoSPInstaller und Sharepoint AutoSPInstallerGUI
Sehen wir uns mal eine typische Installation an.
Typische Singleserver Installation
Damit der AutoSPInstaller funktionieren kann, muss eine bestimmte Verzeichnisstruktur her. So sollten, wenn gewünscht, Language-Packs in ein bestimmtes Verzeichnis entpackt werden, dessen Name das Länderkürzel aufweist. Hier bspw. englisch und niederländisch.
Der Installer kann durchaus mit SP 2010 und SP 2013 umgehen. In das jeweilige Verzeichnis muss lediglich der Inhalt der DVD kopiert werden.
Unter anderem können auch Updates in die Ordner integriert werden…
Nun kann man mit dem AutoSPInstaller loslegen.
Nachdem man Key, Version, Verschiedene Settings wie Loopback disablen lässt…
..legt man ServiceAccounts, Logfile-Pfade und Settings für die Zentraladministration fest.
Als nächstes lässt sich eine Webapplication und Websitesammlung festlegen. Interessant dürfte auch sein, hier die SQL Aliase anzulegen. Ein schöner Hinweis auf eine gängige Praxis, um unabhängig vom tatsächichen Ort des SQL Servers zu sein.
Anschliessend konfigurieren wir die ServiceApplications, wie Search, AppManagement usw.
und zuletzt die Enterprise ServiceApplications.
Das Ergebnis unserer Konfiguration speichern wir als AutoSPInstallerInput.xml im Autoinstallerverzeichnis. Und schon kann es losgehen: AutoSPInstallerLaunch.bat
Im Powershellfenster können wir beobachten, was gerade passiert…
Cool, oder?
Übrigens: Lässt man den Installer mehrfach laufen, kann im Prinzip nichts schiefgehen. Das Setup kontrolliert, ob Dinge schon existieren und überspringt dann einfach den einen Schritt.
So lässt sich bspw. eine Grundinstallation, in der nur Sharepoint inkl. Prerequesits installiert wurde, durchaus mit dem AutoSPInstaller zu Ende konfigurieren.
Leider lief bei mir lediglich die englische Version des SP einwandfrei durch. Bei der deutschen Version hakelte es hier und dort.
PS: Mittlerweile steht bereits eine neuere Version zur Verfügung mit der auch Sharepoint inklusive SP1 installiert werden kann.