Archiv für die Kategorie » System Center «

15 | 08 | 2016

SCCM 2012: Programm bei jedem Login ausführen

Geschrieben von um 10:32 Uhr

Man sollte meinen, dass es die einfachste Aufgabe der Welt wäre: ein Skript bei jeder Benutzeranmeldung im Kontext eben dieses Benutzers auszuführen. Tatsächlich aber ist dieser Ausführungsmodus bei SCCM, zumindest bis inklusive 2012R2, nicht vorgesehen! Die beste Annäherung an den gewünschten Zustand ist, das Skript einmal pro Benutzer bei der Anmeldung auszuführen.

So klappt’s aber dennoch:

  • das Skript als Programm in einem Paket definieren. Für das Paket einstellen, dass der Content lokal gecacht bleiben soll
  • Im Programm einstellen, dass bei Bereitstellung an Computer es einmal für jeden User ausgeführt werden soll, und dass das Programm „Immer neu gestartet“ werden soll, also unabhängig vom Erfolg oder Misserfolg
  • Und nun der Trick: In der Bereitstellung (an eine Computer-Sammlung) neben dem Zeitplan „so schnell wie möglich nach dem Logon“ auch einen Zeitplan mit einem (weit in der Zukunft liegenden) festen Datum eintragen

Damit wird das Programm bei jedem Login jedes Benutzers ausgeführt.

Tags » , , , , , , , «

+

23 | 10 | 2013

SCCM 2012 und „Installation dieser Anwendung durch die Task Sequenz erlauben“

Geschrieben von um 9:21 Uhr

SCCM 2012 SP1, mehrere Tausend Clients, kurz vor Feierabend:

Kunde: Wir wollen Anwendungen, die einer Maschine zugewiesen sind, bereits beim Betriebssystem-Roll-Out installieren. Dafür müssen alle Anwendungen (das sind in diesem Fall mehrere Hundert, schön mit einem mehrschichtigen Ordnerbaum „strukturiert“) mit dem Flag „Installation dieser Anwendung durch die Task Sequenz erlauben“ versehen werden. Geht das zu automatisieren?

Ich: Ja, mit PowerShell dürfte das ohne weiteres gehen. Klar, so eine grundlegene Eigenschaft muss doch eine separate PowerShell-Property haben, die man zum Filtern auslesen und auch nach Belieben setzen kann, oder?

Nun, mal wieder geirrt 😉 Wie so oft bei SCCM 2012 und dessen PowerShell-Unterstützung. Bin wohl von Exchange verwöhnt. Die gesuchte Eigenschaft heißt „AutoInstall“ und ist Bestandteil der XML-Beschreibung der Anwendung, also des SDMPackageXML-Attributes. Bei nicht gesetztem Haken ist das Tag übrigens nicht auf „false“ gesetzt, sondern fehlt einfach im XML-Quelltext.

Anwendungen mit gesetztem Haken identifizieren geht aber durchaus mit reinem PowerShell:

Get-CMApplication | foreach { if ($_.SDMPackageXML -like '*<AutoInstall>true</AutoInstall>*') {Write-Host $_.LocalizedDisplayName }}

Dementsprechend sind auch die Anwendungen ohne den gesetzten Haken wie folgt zu finden:

Get-CMApplication | foreach { if ($_.SDMPackageXML -notlike '*<AutoInstall>true</AutoInstall>*') {Write-Host $_.LocalizedDisplayName }}

Die Anpassung des Wertes ist hingegen mit reinen PowerShell-Mitteln nicht möglich – man muss sich, wie so oft bei SCCM, des WMI-Providers bedienen. Die Anpassung funktioniert – wie übrigens in der GUI auch – nur bei Anwendungen, die nicht „Außer Kraft gesetzt“ sind. Hier ist das Ergebnis (die ersten beiden Zeilen sind an die konkrete Umgebung anzupassen):

# hier die Daten der konkreten Site eintragen:
$SiteServer = "MySiteServer"
$SiteCode = "XYZ"

# Module der SCCM-Verwaltung laden
[System.Reflection.Assembly]::LoadFrom((Join-Path (Get-Item $env:SMS_ADMIN_UI_PATH).Parent.FullName "Microsoft.ConfigurationManagement.ApplicationManagement.dll")) | Out-Null
[System.Reflection.Assembly]::LoadFrom((Join-Path (Get-Item $env:SMS_ADMIN_UI_PATH).Parent.FullName "Microsoft.ConfigurationManagement.ApplicationManagement.Extender.dll")) | Out-Null
[System.Reflection.Assembly]::LoadFrom((Join-Path (Get-Item $env:SMS_ADMIN_UI_PATH).Parent.FullName "Microsoft.ConfigurationManagement.ApplicationManagement.MsiInstaller.dll")) | Out-Null

# Alle Anwendungen enumerieren und durchgehen
$Applications = Get-WmiObject -ComputerName $SiteServer -Namespace root\SMS\site_$SiteCode -class SMS_Application | Where-Object {$_.IsLatest -eq $True}
$Applications | ForEach-Object {
    $Application = [wmi]$_.__PATH
    $ApplicationXML = [Microsoft.ConfigurationManagement.ApplicationManagement.Serialization.SccmSerializer]::DeserializeFromString($Application.SDMPackageXML,$True)
    If (!$ApplicationXML.AutoInstall -and !$Application.IsExpired) { # die zweite Bedingung prüft das Ausserkraftsetzen der Applikation
        Write-Host $ApplicationXML.Title" wird für Installation in TS aktiviert..."
        $ApplicationXML.AutoInstall = "true"
        $UpdatedXML = [Microsoft.ConfigurationManagement.ApplicationManagement.Serialization.SccmSerializer]::SerializeToString($ApplicationXML, $True)
        $Application.SDMPackageXML = $UpdatedXML
        $Application.Put() | Out-Null
    }
}

Der Skript kann hier heruntergeladen werden.

Tags » «

+

29 | 06 | 2013

Server 2012/IIS8: Bei Root-Zertifikaten aufpassen!

Geschrieben von um 13:15 Uhr

Vor einiger Zeit musste ich innerhalb einer SCCM 2012-Installation einen Web Based Management Point einrichten. Enterprise PKI hatte der Kunde schon am Start, ein Paar Zertifikatsvorlagen udn Autoenrollment-Einstellungen mussten angepasst werden, das war aber nicht weiter wild. Nun mochte aber der Management Point, sobald man ihn auf HTTPS umstellen, sich nicht initialisieren.

Hintergrund: Der MP läuft im IIS. Nach der Grundinstallation versucht er – unter zertifikatsbasierter Authentifizierung – zum sich selbst zu verbinden und eine Liste der Management Points abzufragen. An dieser Stelle bereits loggte der IIS den Fehler 403.16 mit dem erweiterten Fehlercode 2148204809 (in hex 0x800b0109), was soviel bedeutet wie CERT_E_UNTRUSTEDROOT. Sowohl das Server- als auch das Client-Zertifikat sind von der gleichen Issuing CA ausgestellt, somit ist die RCA ebenfalls die gleiche, sie ist per GPO eingetragen, alle Test laufen ohne Beanstandungen durch – was ist also das Problem?

Nun, die Lösung war einfach, auch wenn die Ursache eher als „Bug“ denn als „Feature“ einzustufen ist. Im „Trusted Roots“ des Servers (wie auch jeder anderen Maschine in diesem AD, da die PKI-GPO ganz oben gelinkt ist) befand sich ein Zertifikat von Thawte, welches zwar für eine „Thawte Primary Root CA“ ausgestellt war, jedoch nicht von ihr selber signiert, sondern von einer „Thawte Primary Server CA“. Insofern ist diese Root CA genaugenommen keine Root CA, und das Zertifikat hätte woanders rein gemusst. Man sollte aber meinen, das betrifft uns nicht, da wir ja nur mit Zertifikaten aus der internen PKI hantieren. Bis IIS 7.5 würde das auch stimmen. IIS 8 hingegen verzeiht einem Derartiges nicht und legt das oben beschriebene Verhalten an den Tag. Dazu gibt es auch einen Fast Publish-Artikel: http://support.microsoft.com/kb/2802568.

Entdeckt wurde das Verhalten anscheinend im Zusammenhang mit Lync 2013. Welch Wunder 😉

Tags » , , , , , «

+