Dans quel contexte les scripts de détection SCCM Powershell s'exécutent-ils?

J'ai finalement réussi à utiliser des scripts de détection PowerShell sur des clients avec une AllSignedpolitique d'exécution. (indice: il a commencé à fonctionner après avoir installé le dernier service pack et utilisé la solution de contournement d'Adam Meltzer .)

Maintenant qu'il est pratique d'utiliser des scripts PowerShell pour la détection d'applications, cela me fait me demander les choses suivantes:

1. Dans quel contexte le client SCCM exécute-t-il les scripts de détection PowerShell? Système? Utilisateur?
2. Le contexte dépend-il si vous sélectionnez «Installer pour l'utilisateur» ou «Installer pour le système» dans le type de déploiement?

La documentation est assez clairsemée sur ce sujet. La meilleure ressource que j'ai trouvée pour les scripts de détection SCCM PowerShell est ce billet de blog Kloud , cependant, il est silencieux sur la question du contexte.

Résultats empiriques

J'ai écrit un PowerShell qui, lorsqu'il est exécuté en tant que script de détection, transfère les variables d'environnement que le script de détection voit dans un fichier journal. Ce script est à la fin de cette réponse.

Je fais alors exécuter ce script par le client SCCM en déployant un type de déploiement avec différents paramètres "Comportement d'installation" et "Exigence d'ouverture de session". Les résultats sont dans le tableau ci-dessous:

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        

• unX sont des noms d'utilisateur
• cnX sont des noms d'ordinateur

Une analyse

Les résultats ci-dessus sont surprenants car le contexte dans lequel s'exécute un script de détection semble dépendre en partie du fait que l'application a été déployée sur un utilisateur ou sur un système. Cela a été assez surprenant que j'ai effectué les tests une deuxième fois. Les résultats étaient cohérents.

Nous pouvons provisoirement tirer les hypothèses suivantes du tableau ci-dessus:

1. Lorsqu'une application est déployée sur un utilisateur, un script de détection PowerShell pour cette application est exécuté en tant que cet utilisateur.
2. Lorsqu'une application est déployée sur un système et que le type de déploiement est installé pour le système, un script de détection PowerShell pour cette application est exécuté en tant que système.
3. Lorsqu'une application est déployée sur un système et que le type de déploiement est installé pour l'utilisateur, un script de détection PowerShell pour cette application est exécuté en tant qu'utilisateur connecté.

Les trois hypothèses ci-dessus sont confirmées par les résultats du test. Il peut bien y avoir d'autres variables qui n'ont pas été testées là où ces hypothèses ne se vérifient pas. Ce sont, au moins, un bon ensemble d'hypothèses initiales lors de l'utilisation de scripts de détection PowerShell.

Contextes incompatibles (attention!)

Jason Sandys a documenté un test similaire des règles pour le contexte d'installation. Si vous lisez attentivement cet article, vous remarquerez peut-être que les règles pour le contexte d'installation et le contexte du script de détection ne sont pas tout à fait les mêmes. Voici les règles incriminées:

Lorsque le comportement d'installation d'une application est défini sur "Installer en tant que système", le programme d'installation est exécuté en tant que système [quel que soit le déploiement vers l'utilisateur].

Lorsqu'une application est déployée sur un utilisateur, un script de détection PowerShell pour cette application est exécuté en tant que cet utilisateur [que le comportement d'installation soit défini sur «Installer en tant que système»].

Cela signifie qu'une application qui a le comportement d'installation «Installer en tant que système» et qui est déployée dans une collection d'utilisateurs utilisera le contexte système pour l'installation, mais le contexte utilisateur pour la détection.

Quelqu'un qui écrit des scripts de détection pour les applications où le comportement d'installation est «Installer en tant que système» doit faire attention à ne pas compter sur une partie de l'environnement qui change entre le système et les contextes utilisateur. Sinon, la détection d'une application déployée sur une collection système peut réussir tandis que la détection de la même application déployée sur une collection d'utilisateurs échoue.

Scénario

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