11

I have finally had success using PowerShell detection scripts on clients with AllSigned execution policy. (hint: It started working after installing the latest service pack and using Adam Meltzer's workaround.)

Now that it's practical to use PowerShell scripts for application detection, it makes me wonder the following things:

  1. In what context does the SCCM client run the PowerShell detection scripts? System? User?
  2. Does the context depend on whether you select "Install for user" or "Install for system" in the Deployment Type?

Documentation is pretty sparse on this topic. The best resource I have found for SCCM PowerShell detection scripts is this Kloud blog post, however, it is silent on the matter of context.

alx9r
  • 1,643
  • 3
  • 16
  • 37

1 Answers1

14

Empirical Results

I wrote some PowerShell that, when run as a detection script, dumps the environment variables that the detection script sees to a log file. That script is at the end of this answer.

I then cause this script to be run by the SCCM client by deploying a Deployment Type with different "Installation Behavior" and "Logon requirement" parameters. The results are in the table below:

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 are usernames
  • cnX are computer names

Analysis

The above results are surprising because the context that a detection script runs in seems to depend in part upon whether the Application was deployed to a user or a system. This was enough of a surprise that I ran the tests a second time. The results were consistent.

We can tentatively draw the following hypotheses from the table above:

  1. When an Application is deployed to a user, a PowerShell detection script for that Application is run as that user.
  2. When an Application is deployed to a system and the Deployment Type is installed for the system, a PowerShell detection script for that Application is run as the system.
  3. When an Application is deployed to a system and the Deployment Type is installed for the user, a PowerShell detection script for that Application is run as the logged-in user.

The above three hypotheses are supported by the test results. There may well be some other variables that weren't tested where these hypotheses do not hold. They are, at least, a good set of initial assumptions when using PowerShell detection scripts.

Mismatched Contexts (Beware!)

Jason Sandys documented a similar test of the rules for installation context. If you read that post carefully, you might notice that the rules for installation context and detection script context are not quite the same. Here are the offending rules:

When an Application's installation behavior is set to "Install as System" the installer is run as system [regardless of deployment to user].

When an Application is deployed to a user, a PowerShell detection script for that Application is run as that user [regardless of whether installation behavior is set to "Install as System"].

This means that an Application that has installation behavior “Install as system” and is deployed to a user collection will use the system context for installation, but the user context for detection.

Someone writing detection scripts for Applications where installation behavior is "Install as System" should be careful to avoid relying on any part of the environment that changes between the system and user contexts. Otherwise, detection of an Application deployed to a system collection may succeed while detection of the exact same Application deployed to a user collection fails.

Script

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)
}
alx9r
  • 1,643
  • 3
  • 16
  • 37
  • +1 for a solid SCCM question and answer. I do hope the SCCM community here grows as it's really the only thing I keep a look out for (email subscription for the tags.) Here, have some extra rep as a motivation to keep 'em comin. – MDMoore313 Jun 18 '15 at 12:29
  • 2
    Thanks @BigHomie. I'm filtering for SCCM too...but I miss a bunch because there's no practical way to get that filtered stream [on mobile](https://meta.stackexchange.com/questions/244379/is-there-any-mobile-friendly-way-to-access-filtered-feeds). – alx9r Jun 18 '15 at 15:32
  • 2
    Excellent SCCM question! Come join @BigHomie and I - custodians of the [sccm] tag. There are literally a couple of us. –  Jun 23 '15 at 16:55
  • Darn Skippy, @kce has the best questions this side of the Windows tag too. – MDMoore313 Jun 23 '15 at 20:30