SOLVED SCCM 2211 .exe Application Deployment

[DavidR]

Hello All,

Fairly new to SCCM/MECM here but I’ve done plenty of research and investigated how to deploy .exe install files on countless videos and websites and I’m still having trouble on getting this exe to install. Our mobile techs use this application called MobileFrame and the goal here is to push out version 6.4.7 to our techs. The install exe and silent commands work just fine when running locally but when I deploy via SCCM it gives me the error “0x643(1603)”.


I can’t seem to find a fix here. I was curious if anybody here could assist? Logs are copied down below for your reference.

Below is the AppEnforce log entries that appear after an attempt:

<![LOG[+++ Starting Install enforcement for App DT "Silent Exe" ApplicationDeliveryType - ScopeId_1B435557-3AE6-4504-AC32-E413A13B7785/DeploymentType_9d519680-9ac4-4a1c-a0e6-57d5f8631bfd, Revision - 3, ContentPath - C:\WINDOWS\ccmcache\1a, Execution Context - System]LOG]!><time="12:01:20.242+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appprovider.cpp:2094">
<![LOG[ Performing detection of app deployment type Silent Exe(ScopeId_1B435557-3AE6-4504-AC32-E413A13B7785/DeploymentType_9d519680-9ac4-4a1c-a0e6-57d5f8631bfd, revision 3) for system.]LOG]!><time="12:01:20.259+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appprovider.cpp:2539">
<![LOG[+++ Application not discovered. [AppDT Id: ScopeId_1B435557-3AE6-4504-AC32-E413A13B7785/DeploymentType_9d519680-9ac4-4a1c-a0e6-57d5f8631bfd, Revision: 3]]LOG]!><time="12:01:20.280+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="localapphandler.cpp:291">
<![LOG[ App enforcement environment:
Context: Machine
Command line: "MobileFrame Windows Client Setup.exe" /s /V"/quiet /qn /log c:\install.log"
Allow user interaction: No
UI mode: 1
User token: null
Session Id: 1
Content path: C:\WINDOWS\ccmcache\1a
Working directory: ]LOG]!><time="12:01:20.284+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appcontext.cpp:85">
<![LOG[ Prepared working directory: C:\WINDOWS\ccmcache\1a]LOG]!><time="12:01:20.302+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appcontext.cpp:189">
<![LOG[ Prepared command line: "C:\WINDOWS\ccmcache\1a\MobileFrame Windows Client Setup.exe" /s /V"/quiet /qn /log c:\install.log"]LOG]!><time="12:01:20.316+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appcontext.cpp:338">
<![LOG[ Executing Command line: "C:\WINDOWS\ccmcache\1a\MobileFrame Windows Client Setup.exe" /s /V"/quiet /qn /log c:\install.log" with user context]LOG]!><time="12:01:20.318+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appexcnlib.cpp:203">
<![LOG[ Working directory C:\WINDOWS\ccmcache\1a]LOG]!><time="12:01:20.320+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appexcnlib.cpp:217">
<![LOG[ Post install behavior is BasedOnExitCode]LOG]!><time="12:01:20.355+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appcommon.cpp:1054">
<![LOG[ Waiting for process 19184 to finish. Timeout = 15 minutes.]LOG]!><time="12:01:20.360+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appexcnlib.cpp:2014">
<![LOG[ Process 19184 terminated with exitcode: 1603]LOG]!><time="12:01:26.706+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appexcnlib.cpp:2023">
<![LOG[ Looking for exit code 1603 in exit codes table...]LOG]!><time="12:01:26.712+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appexcnlib.cpp:510">
<![LOG[ Unmatched exit code (1603) is considered an execution failure.]LOG]!><time="12:01:26.716+420" date="08-07-2023" component="AppEnforce" context="" type="2" thread="20436" file="appexcnlib.cpp:596">
<![LOG[++++++ App enforcement completed (6 seconds) for App DT "Silent Exe" [ScopeId_1B435557-3AE6-4504-AC32-E413A13B7785/DeploymentType_9d519680-9ac4-4a1c-a0e6-57d5f8631bfd], Revision: 3, User SID: ] ++++++]LOG]!><time="12:01:26.726+420" date="08-07-2023" component="AppEnforce" context="" type="1" thread="20436" file="appprovider.cpp:2843">

If it helps, attached is the install log that MobileFrame creates.

 

[Garth]

First off you need to read the log created by the exe setup to see what the real error is.
Secondly you need to test your exe setup using the local system account. If it doesn't work there it will never work in ConfigMgr. https://www.recastsoftware.com/resources/how-to-access-the-local-system-account/

 

[DavidR]

First off you need to read the log created by the exe setup to see what the real error is. Secondly you need to test your exe setup using the local system account. If it doesn't work there it will never work in ConfigMgr. https://www.recastsoftware.com/resources/how-to-access-the-local-system-account/

 

[DavidR]

Garth,
Thanks for the reply and sorry for the late response I’ve been held up with other projects. So I have read the exe log (it’s attached so please correct me if I’m wrong) and it looks like it fails when installing from the System account (line 146 in the log). In SCCM I’ve chosen to install for system. When I do this for other applications it works just fine but this exe doesn’t want to cooperate. I’ve read that other people have experienced this before with other exe installs…they just don’t like cooperating with SCCM. And yes following that link you’ve sent I’ve confirmed via Method #1 (Create an SCCM Package) that my local system account is working fine.

 

[Garth]

Garth,
Thanks for the reply and sorry for the late response I’ve been held up with other projects. So I have read the exe log (it’s attached so please correct me if I’m wrong) and it looks like it fails when installing from the System account (line 146 in the log). In SCCM I’ve chosen to install for system. When I do this for other applications it works just fine but this exe doesn’t want to cooperate. I’ve read that other people have experienced this before with other exe installs…they just don’t like cooperating with SCCM. And yes following that link you’ve sent I’ve confirmed via Method #1 (Create an SCCM Package) that my local system account is working fine.

For clarity, you used the exact same command within the CMD to install the app? and there are no prompt or errors when you run it from the CMD?

 

[DavidR]

For clarity, you used the exact same command within the CMD to install the app? and there are no prompt or errors when you run it from the CMD?

Correct, the same command works completely fine when it runs locally on command prompt.

 

[Garth]

Correct, the same command works completely fine when it runs locally on command prompt.

And you ran the CMD as a x86 prompt?

 

[DavidR]

And you ran the CMD as a x86 prompt?

Yes, x64 and x86 cmd locally installs fine. Via SCCM, installing x64 or x86 will fail with same error results. So here's the thought that makes me scratch my head...if you look at the failed log file I've attached, the error states 'InstallShield 12:21:01: ResolveSidForAccountName: looking up account name 'RW\SYSTEM''. That RW\ is our domain and that shouldn't be included right? When you choose to Install for System in SCCM, rather than Install for User, it should use the local SYSTEM account, correct? So that domain portion shouldn't be included there but for some reason this exe does.

If this truly is our blocking point, then I would need to create a powershell script to install this exe but I imagine I would need to include admin credentials in it as well which we really don't want to do. Unfortunately, I'm not too familiar with powershell either so perhaps there's a way to install as an admin without adding creds but I would need to research. If you agree that this is the route I'll have to go and you have any insight then it would be much appreciated.

 

[Garth]

Yes, x64 and x86 cmd locally installs fine. Via SCCM, installing x64 or x86 will fail with same error results. So here's the thought that makes me scratch my head...if you look at the failed log file I've attached, the error states 'InstallShield 12:21:01: ResolveSidForAccountName: looking up account name 'RW\SYSTEM''. That RW\ is our domain and that shouldn't be included right? When you choose to Install for System in SCCM, rather than Install for User, it should use the local SYSTEM account, correct? So that domain portion shouldn't be included there but for some reason this exe does.

If this truly is our blocking point, then I would need to create a powershell script to install this exe but I imagine I would need to include admin credentials in it as well which we really don't want to do. Unfortunately, I'm not too familiar with powershell either so perhaps there's a way to install as an admin without adding creds but I would need to research. If you agree that this is the route I'll have to go and you have any insight then it would be much appreciated.

I'm sorry I'm going to look for clarification. As what you are saying above seems to contradict your testing. And confirm that you are not testing on a DC.

You use PSExec (PSexec -s -i cmd) to open an x86 CMD? You type whoami within the open within and it says nt authority\system?

set PROCESSOR_ARCHITECTURE and it say X86

Then you run the run the exact same command line you use within ConfigMgr Program. and you are saying that it work?

 

[DavidR]

Testing my app deployment on a Domain Controller? No, I've got a test laptop here that's on our domain.

I had trouble with running PSexec, but using method 1 (https://www.recastsoftware.com/resources/how-to-access-the-local-system-account/) the whoami command returned nt authority\system and set processor_architecture returned PROCESSOR_ARCHITECTURE=x86.

Running the command "MobileFrame Windows Client Setup.exe" /s /V"/quiet /qn /log c:\install.log" on its own will not work because it doesn't have the content referenced (which would normally be included with the application deployment. But if I were to put that exe in a folder somewhere and cd to that folder...then the command would install just fine.

 

[Garth]

Running the command "MobileFrame Windows Client Setup.exe" /s /V"/quiet /qn /log c:\install.log" on its own will not work because it doesn't have the content referenced (which would normally be included with the application deployment. But if I were to put that exe in a folder somewhere and cd to that folder...then the command would install just fine.

You will need to contact the vendor to ask them what their setup is doing.

 

[SEHSCCM]

If you're lucky some vendors might have a guide for deploying their applications from SCCM. It certainly couldn't hurt to ask them.

I do agree with Garth though--it certainly feels like the content needed for your deployment package isn't making it to the local ccmcache dir on your computer.

You can find the exact folder SCCM/Software Center is using by consulting the C:\Windows\CCM\Logs\AppEnforce.log. Look for an entry that reads something like this:
Working directory C:\WINDOWS\ccmcache\n

(Tip: Utilize CMTrace.exe to open .log files for a more readable method vs. Notepad. CMTrace can be found in the following folder on your primary site server: CD.Latest\SMSSETUP\TOOLS).

Then examine that folder to see if all the install bits needed are indeed there.

As a guide, never change anything in the ccmcache folder, nor manually delete any of the content/folders therein. These are automatically managed by SCCM and aged out based on your Client Cache settings, and whether or not content on your distribution point(s) gets updated.

 

[DavidR]

If you're lucky some vendors might have a guide for deploying their applications from SCCM. It certainly couldn't hurt to ask them.

I do agree with Garth though--it certainly feels like the content needed for your deployment package isn't making it to the local ccmcache dir on your computer.

You can find the exact folder SCCM/Software Center is using by consulting the C:\Windows\CCM\Logs\AppEnforce.log. Look for an entry that reads something like this:
Working directory C:\WINDOWS\ccmcache\n

(Tip: Utilize CMTrace.exe to open .log files for a more readable method vs. Notepad. CMTrace can be found in the following folder on your primary site server: CD.Latest\SMSSETUP\TOOLS).

Then examine that folder to see if all the install bits needed are indeed there.

As a guide, never change anything in the ccmcache folder, nor manually delete any of the content/folders therein. These are automatically managed by SCCM and aged out based on your Client Cache settings, and whether or not content on your distribution point(s) gets updated.

Yes, that seems to be the case here. Some test laptops I have here are having the same issue. The content isn't being downloaded locally to the sccmcache folder as it should. I'm getting the error "The software change returned error code 0x87D00607(-2016410105)". I haven't deleted or changed anything in that folder so I'm not sure why this is happening. I did experience this problem on my laptop but over time it seemed to have corrected itself and my applications started to download locally as they should (if that option is selected). Any insight or experience with this problem?

And for my initial issue, that .exe file was adding our domain to the system account and trying to install it. So what I've done as a workaround is create an MSI using Master Packager and it's installing just fine...so long as the client actually downloads the content locally.

 

[SEHSCCM]

This almost sounds like a boundary issue. Boundaries are used in order to direct clients (generally by subnet, IP range or AD site) to a specific site server or distribution point. A few questions:

• Have you made any changes to boundaries lately?
• If you have boundaries, how are they set up? By subnet, IP range or AD site?
• Can you attach the local LocationServices.log and AppEnforce.log from a PC that installs the application OK, and a PC that fails?

The LocationServices.log details which distribution point the SCCM client is trying to pull content from, and the AppEnforce.log details what happens when the application tries to install. I suspect the PC that is failing is having trouble figuring out where the distribution point is.

Both of the above logs are located in C:\Windows\CCM\Logs on the client PC.

 

[DavidR]

• No changes made to boundaries
• Set up by AD site.
• Attached. Something I've noticed...the AppEnforceFail.log was last modified 9/13/2022 (this was a laptop I pulled out of storage today) Shouldn't this have been updated due to the install attempts? On this laptop i recently pulled out, I did run the following actions multiple times as well:

Application Deployment Evaluation Cycle
Discovery Data Collection Cycle
Hardware Inventory Cycle
Machine Policy Retrieval & Evaluation Cycle
Software Updates Deployment Evaluation Cycle
Software Updates Scan Cycle
User Policy Retrieval & Evaluation Cycle
Windows Installer Source List Update Cycle

 

[SEHSCCM]

Thanks for gathering up all of that info David, well done.

My first SCCM instructor years ago told me that logs tell you everything. I've not had reason to question that wisdom yet.

Some observations:

• To answer your question regarding the AppEnforceFail.log not showing an install attempt--That log will not have any attempt if the content for the application cannot be found.
• The answer to your issue lies in the LocationServicesFailed.log. Notice the entries stating "Unable to retrieve AD site membership." You'll notice in the LocationServicesGood.log the same line, but it indicating that PC is found in the desired AD site. Those lines tell us SCCM is not able to determine in which AD site the failing computer belongs. Think of the LocationServices.log as UPS trying to determine in which warehouse a computer you ordered resides. Once it locates the appropriate warehouse (AD site) it logs information in the DataTransferService.log regarding the BiTS transferring of that content to the local CCMCACHE dir. (Carrying the analogy further the DataTransferService.log can be thought of as UPS tracking information).
• Based on the information in the point above, verify in Active Directory Sites and Services that the subnet for the failing PC in question is in the desired AD site. Our company has hundreds of locations and I've run into the same issue you have many times. If the failing PC is in an AD site other than the one the good PC is in, you'll need to create a new boundary in SCCM, then associate that boundary to a new boundary group pointing to the proper SCCM site server and distribution point.
• On an unrelated note, I also saw in your AppEnforceGood.log where it appeared there was a detection method issue yesterday with your MobileFrameClient application. (There was a line yesterday after the app installed where SCCM couldn't detect that it was installed). It appears you corrected it though. Detection methods can be a bit tricky sometimes. I've got my own scars there...

Let us know how this all goes.

 

[DavidR]

Thanks for gathering up all of that info David, well done.

My first SCCM instructor years ago told me that logs tell you everything. I've not had reason to question that wisdom yet.

Some observations:

• To answer your question regarding the AppEnforceFail.log not showing an install attempt--That log will not have any attempt if the content for the application cannot be found.
• The answer to your issue lies in the LocationServicesFailed.log. Notice the entries stating "Unable to retrieve AD site membership." You'll notice in the LocationServicesGood.log the same line, but it indicating that PC is found in the desired AD site. Those lines tell us SCCM is not able to determine in which AD site the failing computer belongs. Think of the LocationServices.log as UPS trying to determine in which warehouse a computer you ordered resides. Once it locates the appropriate warehouse (AD site) it logs information in the DataTransferService.log regarding the BiTS transferring of that content to the local CCMCACHE dir. (Carrying the analogy further the DataTransferService.log can be thought of as UPS tracking information).
• Based on the information in the point above, verify in Active Directory Sites and Services that the subnet for the failing PC in question is in the desired AD site. Our company has hundreds of locations and I've run into the same issue you have many times. If the failing PC is in an AD site other than the one the good PC is in, you'll need to create a new boundary in SCCM, then associate that boundary to a new boundary group pointing to the proper SCCM site server and distribution point.
• On an unrelated note, I also saw in your AppEnforceGood.log where it appeared there was a detection method issue yesterday with your MobileFrameClient application. (There was a line yesterday after the app installed where SCCM couldn't detect that it was installed). It appears you corrected it though. Detection methods can be a bit tricky sometimes. I've got my own scars there...

Let us know how this all goes.

Thank you VERY much for the insight here. I've learned plenty. After adding the subnet needed to our site in AD, the deployment process is working as it should now. This helps tremendously.

Forgot to mention, I did reach out to the vendor regarding that exe file remote install issue where it grabs the domain in its process but they didn't really have an answer for me. They suggested I just wrap it in an MSI (as I did). I think I'll use that application Orca to edit that domain portion out. Never used Orca before but its worth a shot to see what I could do there for future deployments as we'd rather go the silent exe route.

Thanks everyone for all of the help here. I think I'm good to close this thread out.