web-dev-qa-db-ja.com

SCCM Powershell検出スクリプトはどのコンテキストで実行されますか？

AllSigned実行ポリシーを使用して、クライアントでPowerShell検出スクリプトを使用してようやく成功しました。 （ヒント： 最新のサービスパック をインストールして Adam Meltzerの回避策 を使用した後に機能し始めました。）

アプリケーションの検出にPowerShellスクリプトを使用するのが実際的であるため、次のことを不思議に思います。

  1. SCCMクライアントはPowerShell検出スクリプトを実行しますか？システム？ユーザー？
  2. コンテキストは、展開タイプで「ユーザー用にインストール」を選択するか「システム用にインストール」を選択するかによって異なりますか？

このトピックに関するドキュメントはかなりまばらです。 SCCM PowerShell検出スクリプトで見つけた最良のリソースは このKloudブログ投稿 ですが、コンテキストの問題については触れていません。

powershellsccmsccm-2012sccm-2012-r2
11
alx9r

実証結果

検出スクリプトとして実行すると、検出スクリプトで確認された環境変数をログファイルにダンプするPowerShellをいくつか作成しました。そのスクリプトはこの回答の最後にあります。

次に、このスクリプトをSCCMクライアントが異なる「インストール動作」および「ログオン要件」パラメーターを使用してデプロイメントタイプをデプロイすることにより、クライアントによって実行されるようにします。結果は以下の表のとおりです。

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はユーザー名です
  • cnXはコンピューター名です

分析

検出スクリプトが実行されるコンテキストは、アプリケーションがユーザーとシステムのどちらにデプロイされたかに部分的に依存しているように見えるため、上記の結果は驚くべきものです。これは、2回目のテストを実行するのに十分な驚きでした。結果は一貫していた。

上記の表から次の仮説を仮に描くことができます。

  1. アプリケーションがユーザーにデプロイされると、そのアプリケーションのPowerShell検出スクリプトがそのユーザーとして実行されます。
  2. アプリケーションがシステムにデプロイされ、システムにデプロイメントタイプがインストールされると、そのアプリケーションのPowerShell検出スクリプトがシステムとして実行されます。
  3. アプリケーションがシステムにデプロイされ、ユーザーにデプロイメントタイプがインストールされると、そのアプリケーションのPowerShell検出スクリプトがログインユーザーとして実行されます。

上記の3つの仮説は、テスト結果によってサポートされています。これらの仮説が成立しない場合、テストされなかった他のいくつかの変数が存在する可能性があります。これらは、少なくとも、PowerShell検出スクリプトを使用する場合の初期の想定の良いセットです。

不一致のコンテキスト（注意！）

Jason Sandysがインストールコンテキストのルールの同様のテストを文書化しました。 その投稿を注意深く読むと、インストールコンテキストと検出スクリプトコンテキストのルールがまったく同じではないことに気付くでしょう。問題のあるルールは次のとおりです。

アプリケーションのインストール動作が「システムとしてインストール」に設定されている場合、インストーラーは[ユーザーへのデプロイメントに関係なく]システムとして実行されます。

アプリケーションがユーザーにデプロイされると、そのアプリケーションのPowerShell検出スクリプトが[インストール動作が[システムとしてインストール]に設定されているかどうかに関係なく]そのユーザーとして実行されます。

これは、「システムとしてインストール」およびのインストール動作を持つアプリケーションがユーザーコレクションにデプロイされ、システムコンテキストを使用してインストールされることを意味します。ただし、検出のためのユーザーコンテキスト

インストール動作が「システムとしてインストール」であるアプリケーションの検出スクリプトを書く人は、システムとユーザーコンテキストの間で変化する環境のどの部分にも依存しないように注意する必要があります。それ以外の場合、システムコレクションにデプロイされたアプリケーションの検出は成功し、ユーザーコレクションにデプロイされたまったく同じアプリケーションの検出は失敗します。

脚本

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