In welchem ​​Kontext werden SCCM Powershell-Erkennungsskripte ausgeführt?

Question

Ich hatte endlich Erfolg mit der Verwendung von PowerShell-Erkennungsskripten auf Clients mit AllSignedAusführungsrichtlinie. (Hinweis: Es funktionierte nach der Installationdas neuste Service Packund mitAdam Meltzers Problemumgehung.)

Da es nun praktikabel ist, PowerShell-Skripts zur Anwendungserkennung zu verwenden, frage ich mich Folgendes:

1. In welchem ​​Kontext führt der SCCM-Client die PowerShell-Erkennungsskripte aus? System? Benutzer?
2. Hängt der Kontext davon ab, ob Sie im Bereitstellungstyp „Für Benutzer installieren“ oder „Für System installieren“ auswählen?

Die Dokumentation zu diesem Thema ist ziemlich spärlich. Die beste Ressource, die ich für SCCM PowerShell-Erkennungsskripte gefunden habe, istdieser Kloud-Blogbeitrag, allerdings wird zur Frage des Kontextes nichts gesagt.

Answer 1

Empirische Ergebnisse

Ich habe PowerShell geschrieben, das, wenn es als Erkennungsskript ausgeführt wird, die Umgebungsvariablen, die das Erkennungsskript erkennt, in eine Protokolldatei schreibt. Dieses Skript befindet sich am Ende dieser Antwort.

Ich lasse dieses Skript dann vom SCCM-Client ausführen, indem ich einen Bereitstellungstyp mit unterschiedlichen Parametern für „Installationsverhalten“ und „Anmeldeanforderung“ bereitstelle. Die Ergebnisse finden Sie in der folgenden Tabelle:

Test InstallationBehavior LogonRequirement                   DeployedTo LoggedOnUser ScriptRunAs
---- -------------------- ----------------                   ---------- ------------ -----------     
1.1a Install for user     Only when a user is logged on      un2        un2          un2        
1.1b Install for user     Only when a user is logged on      cn1        un2          un2        
1.1c Install for user     Only when a user is logged on      cn1        un1          un1        
1.2a Install for system   Only when a user is logged on      un2        un2          un2        
1.2b Install for system   Only when a user is logged on      cn1        un2          cn1        
1.2c Install for system   Only when a user is logged on      cn1        un1          cn1        
1.3a Install for system   Whether or not a user is logged on un2        un2          un2        
1.3b Install for system   Whether or not a user is logged on cn1        un2          cn1        
1.3c Install for system   Whether or not a user is logged on cn1        un1          cn1        

   

• unXsind Benutzernamen
• cnXsind Computernamen

Analyse

Die obigen Ergebnisse sind überraschend, da der Kontext, in dem ein Erkennungsskript ausgeführt wird, teilweise davon abzuhängen scheint, ob die Anwendung für einen Benutzer oder ein System bereitgestellt wurde. Dies war so überraschend, dass ich die Tests ein zweites Mal durchführte. Die Ergebnisse waren konsistent.

Aus der obigen Tabelle können wir vorläufig folgende Hypothesen ableiten:

1. Wenn eine Anwendung für einen Benutzer bereitgestellt wird, wird ein PowerShell-Erkennungsskript für diese Anwendung als dieser Benutzer ausgeführt.
2. Wenn eine Anwendung auf einem System bereitgestellt wird und der Bereitstellungstyp für das System installiert ist, wird ein PowerShell-Erkennungsskript für diese Anwendung als System ausgeführt.
3. Wenn eine Anwendung auf einem System bereitgestellt wird und der Bereitstellungstyp für den Benutzer installiert ist, wird ein PowerShell-Erkennungsskript für diese Anwendung als angemeldeter Benutzer ausgeführt.

Die oben genannten drei Hypothesen werden durch die Testergebnisse unterstützt. Es kann durchaus andere Variablen geben, die nicht getestet wurden und bei denen diese Hypothesen nicht zutreffen. Sie sind zumindest eine gute Reihe von Anfangsannahmen bei der Verwendung von PowerShell-Erkennungsskripten.

Nicht übereinstimmende Kontexte (Vorsicht!)

Jason Sandys hat einen ähnlichen Test der Regeln für den Installationskontext dokumentiert. Wenn Sie diesen Beitrag aufmerksam lesen, werden Sie vielleicht feststellen, dass die Regeln für den Installationskontext und den Kontext des Erkennungsskripts nicht ganz dieselben sind. Hier sind die fehlerhaften Regeln:

Wenn das Installationsverhalten einer Anwendung auf „Als System installieren“ eingestellt ist, wird das Installationsprogramm als System ausgeführt [unabhängig von der Bereitstellung für den Benutzer].

Wenn eine Anwendung für einen Benutzer bereitgestellt wird, wird ein PowerShell-Erkennungsskript für diese Anwendung als dieser Benutzer ausgeführt [unabhängig davon, ob das Installationsverhalten auf „Als System installieren“ eingestellt ist].

Das bedeutet, dasseine Anwendung mit dem Installationsverhalten „Als System installieren“Undin einer Benutzersammlung bereitgestellt wird, wird der Systemkontext für die Installation, aber der Benutzerkontext für die Erkennung verwendet.

Wenn jemand Erkennungsskripte für Anwendungen schreibt, deren Installationsverhalten „Als System installieren“ lautet, sollte er darauf achten, sich nicht auf Teile der Umgebung zu verlassen, die sich zwischen System- und Benutzerkontext ändern. Andernfalls kann die Erkennung einer Anwendung, die in einer Systemsammlung bereitgestellt wird, erfolgreich sein, während die Erkennung derselben Anwendung, die in einer Benutzersammlung bereitgestellt wird, fehlschlägt.

Skript

function Write-EnvToLog
{
    $appName = 'script-detect-test'

    $logFolderPath = "c:\$appName-$([System.Environment]::UserName)"

    if ( -not (Test-Path $logFolderPath -PathType Container) )
    {
        New-Item -Path $logFolderPath -ItemType Directory | Out-Null
    }

    if ( -not (Test-Path $logFolderPath -PathType Container ) )
    {
        return
    }

    $logFileName = "$appName`__$((Get-Date).ToString("yyyy-MM-dd__HH-mm-ss")).txt"

    $fp = "$logFolderPath\$logFileName"

    Get-ChildItem Env: | Out-File $fp | Out-Null

    return $true
}

try
{
    if ( Write-EnvToLog ) { "Detected!" }
    [System.Environment]::Exit(0)
}
catch
{
    [System.Environment]::Exit(0)
}