Forums on Intune, SCCM, and Windows 11

Welcome to the forums. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your topics and posts, as well as connect with other members through your own private inbox!

PENDING Application vs Package (In-depth)

  • Thread starter Thread starter CMMaster
  • Start date Start date
  • Replies Replies 4
  • Views Views 5K

CMMaster

New Member
Messages
4
Solutions
2
Reaction score
0
Points
1
I have a general question the community may know. I have an application I'm attempting to deploy to some systems that keeps failing during the install. If I take the command line specified in Installation Program and run it manually, the software installs as expected. So I know the command line works, but whenever I deploy it as an application it always seems to fail abruptly.

After trying different things for a few hours, on a whim I tried the same application as a package. It worked.

So my question is, does the ConfigMgr client treat package installations differently than Applications? I suppose I'm wondering this particular application works as a package and not an application.

Thanks!
 
Solution
Don't look at the CM logs, Look at your custom app's log. It will tell you why it is failing.
There is no difference between app and program for a system content but you can run a app as a x64 app.
That error I described was from the appp’s log. That’s what makes the behavior odd, it doesn’t show any errors, it just abruptly terminates. But again only as an application, as a package it completes successfully.

That said, you gave me something to look at when you said the difference is an application can run as a x64 app. I changed the deployment type to use 32-bit on 64-bit systems, and it worked!

I can't explain why the installer works as a 64-bit process when someone is logged in, but at least now I have a workaround.

Thanks...
So my question is, does the ConfigMgr client treat package installations differently than Applications? I suppose I'm wondering this particular application works as a package and not an application.
No but yes... there do thing slight differently. For your app, review the log file that it creates to see exactly what is happening.
 
No but yes... there do thing slight differently. For your app, review the log file that it creates to see exactly what is happening.
According to the application log, it gets to the point of "updating file associations" and then abruptly stops. I can also tell it's not a clean install because the log file has a .lck extension that is usually removed when the install completes successfully.

One key thing I forgot to mention is this issue only occurs when no one is logged into the system. If someone is logged in, the installation (as an application) completes successfully. When deployed as a package, it works regardless of whether a user is logged in or not.

You mentioned they do things slightly differently, can you elaborate on the slight differences? I know ConfigMgr installs applications in the SYSTM context, and I know applications can sometimes exhibit odd behavior when installed as SYSTEM. Now I'm wondering if there is a connection between these differences and when the installation is failing.
 
Don't look at the CM logs, Look at your custom app's log. It will tell you why it is failing.
There is no difference between app and program for a system content but you can run a app as a x64 app.
 
Don't look at the CM logs, Look at your custom app's log. It will tell you why it is failing.
There is no difference between app and program for a system content but you can run a app as a x64 app.
That error I described was from the appp’s log. That’s what makes the behavior odd, it doesn’t show any errors, it just abruptly terminates. But again only as an application, as a package it completes successfully.

That said, you gave me something to look at when you said the difference is an application can run as a x64 app. I changed the deployment type to use 32-bit on 64-bit systems, and it worked!

I can't explain why the installer works as a 64-bit process when someone is logged in, but at least now I have a workaround.

Thanks for the help Garth!
 
Solution

Forum statistics

Threads
7,170
Messages
27,984
Members
18,286
Latest member
SteveL

Trending content

Back
Top