Call4Cloud | MMP-C | Autopilot | Device Preparation

User Context in ConfigMgr 2012 Applications

Patch My Pc | install & update thousands of apps

Every now and then someone will post to the forums claiming that ConfigMgr is not running an application as the user when the deployment type is set to “Install for User” or not running it as system when set to “Install for system”. Well, it’s time to put this one to rest once and for all. To do this, I ran the following simple VBScript which outputs the username to a text file called whoami.txt in the root of the C drive.

1
2
3
4
5
6
7
8
9
10
Const ForAppending = 8
 
Set WshNetwork = WScript.CreateObject("WScript.Network")
Set fso = WScript.CreateObject("Scripting.FileSystemObject")
 
info = WshNetwork.UserDomain & "\" & WshNetwork.UserName
 
Set outputFile = fso.OpenTextFile("C:\whoami.txt", ForAppending, True)
outputFile.WriteLine info
outputFile.Close

The following table shows the results of each of the test cases. Nothing surprising here, in all cases, the result is as expected.

 Deployed to system collection,
Required
Deployed to system collection,
Available
Deployed to user collection,
Required
Deployed to user collection,
Available
Install as system domain\SYSTEM domain\SYSTEM domain\SYSTEM domain\SYSTEM
Install as user domain\jsandys domain\jsandys domain\jsandys domain\jsandys

Using the above script, you can test this yourself (if you don’t believe me).

One potential major caveat here is that Windows Installer has the ability to “elevate” during the installation of an MSI. Based upon some initial feedback from the product group, this happens for all MSI deployment types set to “Install as user”. I don’t know the ramifications or effects of this though and thus this will be the subject of a future blog post (once I figure out how to best test it and determine the results).

3 thoughts on “User Context in ConfigMgr 2012 Applications

  1. Nice work! But the results are unsettling for anyone using detection scripts. Here’s why:

    It looks like the overriding rule for installation contexts is this:

    “When an application is ‘Install as System’ the account used to install the application is ‘domainSYSTEM'”

    That seems to be so regardless of whether the application is deployed to a user or a system.

    Detection scripts on the other hand, use a different rule (see https://serverfault.com/a/699736/115232):

    “When an application is deployed to a user, a PowerShell detection script for that application is run as that user.”

    That seems to be so regardless of whether the application is “Install as system” or “Install as user”.

    The unsettling result is that an application that is both “Deployed to user collection” and “Install as system” will use the system context for installation, but the user context for detection. That is likely to cause problems if the person writing the detection script isn’t aware of the mismatch.

    Regards,

    @alx9r

    1. Yes and no. I may address the above directly in a future post, but one key thing for my post that I eluded to was that I used the Script Deployment Type. The results from the linked page above appear to have used the Windows Installer Deployment Type. This may be significant and there could be a difference. TBD

    2. Thank you so much for your comment. I had no idea why my detection was failing, and it’s because of the user context! thanks for the heads up!

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  69  =  77

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.