Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Sunday, July 12, 2015 9:43 AM
Hi
I create Applications script based. in the deployment type I set the installation behavior to install for system.
when I try to uninstall a program from the Software Center I get the following error:
Executing Command line: "blablabla" /SILENT with user context
ScriptHandler::EnforceApp failed (0x8007010b).
AppProvider::EnforceApp - Failed to invoke EnforceApp on Application handler(0x8007010b).
CommenceEnforcement failed with error 0x8007010b.
Method CommenceEnforcement failed with error code 8007010B
++++++ Failed to enforce app. Error 0x8007010b. ++++++
how come the uninstall command runs with user context and not with system context?!
is it even possible to modify it?
thanks for the help
Tamir Levy
All replies (8)
Sunday, July 12, 2015 11:39 AM
CommenceEnforcement failed with error 0x8007010b.
Method CommenceEnforcement failed with error code 8007010B
++++++ Failed to enforce app. Error 0x8007010b. ++++++
Error code *0x8007010b says ***The directory name is invalid.**Check your detection method and uninstallation command line if you have set them correctly or not.
Eswar Koneti | Configmgr Blog: www.eskonr.com | Linkedin: Eswar Koneti | Twitter: eskonr
Monday, August 3, 2015 7:31 AM
Yes, it was a combination of two issues
I fixed the one with the 0x8007010b.
but I still wonder how come the install \ uninstall process runs in user context?
as I said - on the deployment type it set to install for system and whether or not user is logged on.
I still created the deployment as available and not required because I want the users to choose if they want to install the software. but not all my users are local admins. so I want to make sure there will be no failures here.
Tamir Levy
Monday, August 3, 2015 8:34 AM
Provide some more lines from the log. The snippet you posted is misleading.
Torsten Meringer | http://www.mssccmfaq.de
Tuesday, August 4, 2015 7:14 PM
I'm not next to that environment though it's a principal question.
when I deploy an application to run for system, whether or not user logged on, and I run the installation manually from the software center - should I see in the logs it's running with user context and not with system context??
thanks
Tamir Levy
Tuesday, August 4, 2015 7:18 PM
when I deploy an application to run for system, whether or not user logged on, and I run the installation manually from the software center - should I see in the logs it's running with user context and not with system context??
The log is a little bit misleading that's why I asked you to post some more lines. You'll find the context being used (system vs user) further down in the log.
Torsten Meringer | http://www.mssccmfaq.de
Tuesday, October 6, 2015 6:23 PM
In short, selecting "Install for System" on the user experience tab of the deployment type does force the application to both install and uninstall as SYSTEM. You are seeing "with user context" in AppEnforce.log because you clicked "Install" either in the Application Catalog or in Software Center. However, "user context" does not mean that it was executed with the user's access level (see proof below for details and for your own testing). As Torsten has pointed out, you must look for the line in AppEnforce.log that says "Execution Context" to see how it was executed.
The long answer is that "with user context" and "with system context" as displayed in the AppEnforce.log file have nothing at all to do with actual account or access level used to execute the command line. Instead, it simply indicates that a user triggered the install (user context) or the system triggered the install (system context). I, too, was confused by these poorly worded log entries and believed that my own scripts were failing to install because of insufficient privileges. I have since proven otherwise through experimentation as seen in the following proof. There must be something else going wrong and, unfortunately, I have not yet found a solution to my own problem or yours. However, I hope this answer will prevent others from wasting time worrying about permissions when the real issue must be elsewhere.
Proof:
Create a new application with a script-based deployment type and select "Install for System" on the user experience tab. Create a simple batch file that echoes the output of "whoami /groups" to a text file to see which account is actually being used to run the script.
Example script (the permissions of the target directory won't matter because, as you will see, it runs as SYSTEM):
mkdir c:\temp
echo I am running as: >c:\temp\whoami.txt
whoami /groups >>c:\temp\whoami.txt
Now distribute the content and deploy the application to either a device or user collection and be sure to select "Available" and not "Required" or if you do select "Required" be sure to set the deadline to some future date and make the deployment available at the current time or some time in the past so you can manually trigger the instal before the deadline. Trigger the install by clicking "Install" in either Software Center or the Application Catalog depending on which type of collection you used earlier. Inspect the AppEnforce.log and you will find that it has executed the command "with user context" the same as in your original post. Now inspect whoami.txt created by the script and you will find that the script did indeed execute as SYSTEM because the output of "whoami /groups" contains "Mandatory Label\System Mandatory Level" along with other conclusive evidence.
In conclusion, we cannot rely on that particular line of AppEnforce.log to tell us anything about the access level used to execute the command line. As Torsten has pointed out, AppEnforce.log gives us that information on the line containing the words "Execution Context" elsewhere in the log.
Tuesday, October 6, 2015 6:33 PM
In conclusion, we cannot rely on AppEnforce.log to tell us anything about the access level used to execute the command line.
That conclusion is not true ... only the last part in bold is a bit misleading:
+++ Starting Install enforcement for App DT "Youcam Script Install" ApplicationDeliveryType - ScopeId_BA8E951E-C5D9-48D0-962E-A103BB5E28DE/DeploymentType_97ce20c6-0d3d-4913-8079-6fdc55377615, Revision - 1, ContentPath - C:\windows\ccmcache\21, Execution Context - System AppEnforce
10/2/2015 2:17:24 PM 5552 (0x15B0)
A user is logged on to the system. AppEnforce 10/2/2015 2:17:24 PM
5552 (0x15B0)
Performing detection of app deployment type Youcam Script Install(ScopeId_BA8E951E-C5D9-48D0-962E-A103BB5E28DE/DeploymentType_97ce20c6-0d3d-4913-8079-6fdc55377615, revision 1) for user.
AppEnforce 10/2/2015 2:17:24 PM
5552 (0x15B0)
+++ Application not discovered. [AppDT Id: ScopeId_BA8E951E-C5D9-48D0-962E-A103BB5E28DE/DeploymentType_97ce20c6-0d3d-4913-8079-6fdc55377615, Revision: 1]
AppEnforce 10/2/2015 2:17:24 PM
5552 (0x15B0)
App enforcement environment:
Context: Machine
Command line: "youcam_setup.cmd"
Allow user interaction: No
UI mode: 0
User token: not null
Session Id: 2
Content path: C:\windows\ccmcache\21
Working directory:
AppEnforce 10/2/2015 2:17:24 PM
5552 (0x15B0)
Prepared working directory: C:\windows\ccmcache\21
AppEnforce 10/2/2015 2:17:24 PM
5552 (0x15B0)
Prepared command line: "C:\windows\ccmcache\21\youcam_setup.cmd"
AppEnforce 10/2/2015 2:17:25 PM
5552 (0x15B0)
Executing Command line: "C:\windows\ccmcache\21\youcam_setup.cmd" with user context
AppEnforce 10/2/2015 2:17:25 PM
Torsten Meringer | http://www.mssccmfaq.de
Tuesday, October 6, 2015 7:06 PM
Thank you for pointing that out. I have updated my conclusion in light of your comment and I now realize that I should have read the entire log more carefully. Had I caught that line earlier I wouldn't have needed to go so far as to create the batch file running whoami although it is still good to have a second source of proof to back up the fact that it is executing the command line as System even if the "with user context" log entry is so misleading.