web-dev-qa-db-fra.com

Dans quel contexte SCCM Scripts de détection PowerShell s'exécutent-ils?

J'ai enfin eu beaucoup de succès en utilisant des scripts de détection PowerShell sur les clients avec AllSigned Politique d'exécution. (Astuce: il a commencé à fonctionner après l'installation le dernier service de service et en utilisant Solution de contournement de Adam Meltzer .)

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

  1. Dans quel contexte le fichier SCCM fonctionne-t-il les scripts de détection PowerShell? Système? Utilisateur?
  2. Le contexte dépend-il de savoir si vous sélectionnez "Installer pour l'utilisateur" ou "Installer pour System" dans le type de déploiement?

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

powershellsccmsccm-2012sccm-2012-r2
11
alx9r

Résultats empiriques

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

Je fais ensuite exécuter ce script par le client SCCM en déployant un type de déploiement avec différents paramètres de "comportement d'installation" et de "exigence de connexion". 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 informatiques

Analyse

Les résultats ci-dessus sont surprenants car le contexte qu'un script de détection s'effectue semble dépendre de la partie si l'application a été déployée sur un utilisateur ou un système. Cela était suffisant d'une surprise que j'ai dirigé les tests une seconde fois. Les résultats étaient cohérents.

Nous pouvons attirer provisoirement les hypothèses suivantes de la table 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é comme 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 étayées par les résultats du test. Il se peut que d'autres variables ne soient pas testées là où ces hypothèses ne tiennent pas. Ils sont au moins un bon ensemble d'hypothèses initiales lors de l'utilisation de scripts de détection PowerShell.

Contextes incompatibles (méfiez-vous!)

Jason Sandys a documenté un test similaire des règles de contexte d'installation. Si vous lisez ce post avec soin, vous remarquerez peut-être que les règles du contexte d'installation et du contexte de script de détection ne sont pas tout à fait identiques. Voici les règles incriminées:

Lorsqu'un 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 à l'utilisateur].

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

Cela signifie que une application qui a un comportement d'installation "Installer comme système" et est déployé sur une collection utilisateur utilisera le contexte système pour l'installation, mais l'utilisateur Contexte de détection.

Quelqu'un d'écriture de scripts de détection pour les applications où le comportement d'installation est "Installer comme système" doit veiller à ne pas s'appuyer 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 lors de 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)
}
13
alx9r