Allow deployments using application model to be installed from DP rather than downloaded to ccmcache folder
I have to create several very large (10GB and up) software deployments each year and install them for two thirds of the user base. Preferred method of delivery is install directly from the DP rather than download the installation files to C:\windows\ccmcache. It would be nice to do this using the application model so I can make use of the extended feature set it provides over the package model. I have to work around the limitations using convoluted wrapper scripts to get everything working properly.
How did you make this work? It works for Packages but I still don't have the option for applications.
This already works, it has for years. So I am not sure why this request is here?
Detection of an Application should be possible without DL the content Application can already be installed. No need for Contend DL
Bryan Dam commented
As an alternative, download the app but don't cache it or count it towards the cache limit and once installed, get rid of it.
I might dedicate 10 or even 20 GB to ConfigMgr's cache and in 99% of situations that perfectly fine. It's the outliers though, the CAD applications, that we need some kind of exception for instead of be ruled by their needs.
With our organisation moving towards branchcache, the issue becomes not only about the installing PC's cache, but also about consuming space on adjacent PCs' caches (which already consume much of those small SSD's). But we also lose our DPs. Getting difficult.
I asked DJAM at MMS about why this hasn't been done. It comes down to security. They are rolling out some new cache features soon that will hopefully help some of the scenarios people are facing, but it will never do all of them. This UV should have been closed probably as its never going to happen.
This need is due to some vendors license limitations regarding installing their software
Please implement ASAP. The option in Packages kind of then defeats the use of the Application model. Sometimes being able to run from DP would save having to sent content out to 1325+ distribution points (and troubleshooting)..... Would help lots.
I know this may be strange, but in our university, all users run with local administrator rights. My concern is that they can access ccmcache folder and grab my applications with the licence in it and publish it to the world after if they want to. The workarround is to use package program deployment to run directly from DP. It would be nice to be able to use application deployment instead, with the option to run directly from DP. Application deployment provide detection method, wich is a lack with package program deployment.
Lee Speers commented
Any update on this feature?
Phil Brandvold commented
This feature's unavailability is killing us right now. It's not about network speed, it's about hard drive space. Solidworks requires 15-20GB of free space to install already, and now you want me to free up 18GB for the install package itself? What's the point of that? We need to be able to install from a network location, and we need it yesterday.
@sccmteam What are you waiting for to implement this feature ? You cannot push the application model without providing this feature ! It's been more than 3 years now that this feature proposal has been asked. Can you at least tell us if it is in the roadmap ?
So let me get this straight. We are going to take an installer and all its resources and replicate it hundreds and hundreds of times. Efficient!
Oh, and we will not be able to target any files local to the workstation to accomplish application removal. Also, efficient!
With applications getting larger (many CAD apps are 20GB+) and drives are now smaller than they were 5+ years ago due to SSDs being common and more costly, this feature is needed ASAP.
yes please do it !
I have really tried - have application run a helper package to get its location (saved in a file) and use the source from there to install huge Application - but it turns out that WMI that has the programs is not accessible to SYSTEM account - so script fails to find the helper package. Lot of work to find out that the guts are just missing in SCCM client infrastructure.
We don't want to have to expand the cache size on our clients' small SSDs just to allow one or two unreasonably large packages to download before they install - costly in many ways. We have to use the package/program model for these applications that would otherwise work fine in the application model.
We can't use a single common share because our network is so widely distributed - we rely on SCCM distribution points replication to get the software close to the clients that will install it, and not willing to stand up alternative replication infrastructure that would only compete with it over our WAN.
At least could you let us distribute content as a Package to DPs, and give us a simple, reliable way to dynamically find the correct _local_ distribution point package contents with a script run on each client (eg powershell and/or WMI api), until a full solution can be implemented?
Having Application model able to install from distribution point share - would hit the mark so much better.
I seriusly needed this yesterday. A real world example. Avid Sibelius Sounds 7 is huge at 35gb approx. and we had to script it (deploy the PowerShell scripts only as an Application) to get it to do the work.
Rich Mawdsley commented
There is a simple enough workaround for this, for anyone who does not know:
Create an Application, but leave the Content Location blank, and set the Installation Program line to a network location, i.e \\Server\Share\MyInstall.bat
SCCM will run this directly from the client, without downloading content.
I would stress this should only really be necessary for situations like Daniel Ratliff has said, if you want this because you don't want to fill up storage space on the client, like I often hear people say, then you need to better control the cache as a pose to this workaround.
Daniel Ratliff commented
In our VDI environment, we use shared flash based storage. This means whenever software is pushed to a large number of VMs at once, there is a potential for disk I/O impact because of de-duplication on the fly from the shared storage solution.
Because of this scenario, we are stuck using packages in our environment because we cannot use Application model on our VDI environment.