It is only when you use the wizard to import a MSI.
Manual creation or after the wizard is done, you can set the source path and command line independently.
Both the client and console require local admin rights to install.
When the client is updated, it is a service the is run in SYSTEM context.
The console is a regular program that run in the current users context, which is not necessary have admin rights.
Great idea. But please make it an option, not a requirement.
I would venture a guess that this wouldn't test the deployment scenario completely.
I guess it only will work when the server sees the clients as online. And I often see that a client is actually online, but the console says it is offline.
Immediate tasks don't run when clients is thought to be offline.
This seems like an easy implementation, but it is still not a thing after two years.
It really would help a lot, when testing a deployment where you make many small changes to get it working.
Is there any plan to implement it?
19 votesNoted · AdminAdam Meltzer (ConfigMgr Product Team) (Software Engineer, System Center Configuration Manager) responded
This is an interesting suggestion. I’ll note this and see if this is functionality we can add into our console or Support Center in the future.
It is already available in Support Center.
Under the Content tab, make sure the Content button is marked, then click Load.
The loaded list is Applications, packages and updates available on the connected machine.
You can use a custom requirement with a WQL query or a script. Powershell, VBscript og Jscript.
With any of these you can query WMI for any information you want.
As such you can deploy an application to a user collection, with your IT guys, with both a requirement of primary device and some WMI query.
Updated by bobmn for sangeev/OSD
Maybe an option to choose architecture to sync for specific products.
At my work we use 64 bit Windows, but 32 bit Office.
It is unfruitful work to separate unwanted updates from those we want.
And with update without architecture in the title, what then? For both? Only for 32 bit?
Syncing only the needed updates would help a lot.
I am now working on a deployment for a Wise Installer with an answer file, .ini.
This installer is old and not very smart.
It needs the full path for the .ini file, so it is would be nice to just put in a variable for the cache folder.
It the case of this deployment the install command is "setup.exe" -u="Very\long\path\to\source\folder\setup.ini"
It could be "setup.exe" -u="%cachepath%\setup.ini" resulting in "Setup.exe -u="C:\Windows\ccmcache\2n\setup.ini"
With deployment points spread out over the world, having one deployment that point to the source folder is just not a good thing. Though it is just a small text file.
10 votesplanned · AdminAdam Meltzer (ConfigMgr Product Team) (Software Engineer, System Center Configuration Manager) responded
We are investigating adding more troubleshooting capabilities from our existing toolset (including Support Center) into the console.Carsten supported this idea ·
Features like monitoring running deployments, starting a deployment and clearing cache is what I'd like to see added to the console.
Check out the new uninstall behavior in 1804 tp.
To clarify a little, if there is no need for license management for a given application, there is no need to uninstall it if it falls out of scope.
E.g. I work in a municipality with a lot of apps licensed based on number of citizens. So there is no need to uninstall these apps when they fall out of scope, because license costs aren't affected.
I think the software should only be uninstalled when the affinity for the user, which it is deployed to, changes.
E.g. the application is deployed to User1 who has Computer1 as primary device.
User1 then moves to a different department and starts working on Computer 2. When affinity is changed, by usage agent or user/admin choice, and Computer1 is no longer User1's primary device, the application is uninstalled.
So it would require that each computer checks not only what is deployed to it, but also any software deployed to any user who has said computer as primary device.
The user who has been assigned the application will not get the application installed if the affinity isn't changed.
That way we can use it for license management.
Most software licensing models are computer based. E.g. one license grants one installation on one computer.
But most purchases are user based. E.g. software is bought for the user and not the computer.
If you are already making a script for uninstalling, just make your check in the script, so you can run the required uninstall.
I think it would be better to have a collection check in requirements for the Deployment Type.
This way the Application model won't require more work for each, but only the DT you want this check on.
If the link idea is made, every DT would need to be linked to a Deployment thereby requiring more work on every DT.
With package/program you can have it rerun on a schedule without the detection logic.
This seems to be what you need.