Hi,

I am using Application catalog for making the applications available for the users to install as and when they are in need of. By default, user can set more than one device as his primary device and any approved application can be installed on any/all of those machines.

While checking the available option to automatically install an app to users primary device (In case of OS reinstallation or Hardware refresh) using appcatalog, it gets installed on all primary devices.

It becomes difficult to manage this scenario since there are many licensed applications which will get installed on multiple machines.

Is there any possibilities wherein we would get an option to restrict the users to set only one device as his primary device?

Regards
Nikhil S

Today the only deployment type for Mac is to use the ".cmmac" packages.
These packages are far from on par with what is available for Windows.
The most basic option to uninstall the app is not present.

It would be very usfull to have the "Mac Script Installer" deployment type where we can simply add a .pkg file or bash script with media and execute install and uninstall with custom commands. Some of the packages require more then just the .pkg file and will therefor be incomplete.
Having a uninstall command will also allow for propper supersedence where now application would trigger uninstall of old.

also to this deployment type there should be more options for detection like File, Directory

Web Application deployment types in their current incarnation are not very usable. The main issues with using them are that:

1. There is no control over where the shortcut to the Web App gets placed; they always go to the start menu. We would like the option to put the shortcut on the desktop or in the user's favorites menu. To do this currently we have to write a script and cannot use this deployment type.

2. The icon for the Web Application should use the icon imported into the software center. Nondescript icons make finding the application you want to launch much more difficult that it needs to be.

Consider an app with multiple deployment types using different requirement rules filtering on items such as platform (x86, x64, APP-V, etc). When the app is configured the requirement logic is evaluated and the proper deployment type executed.

Suppose that the deployment type selected was specific for x64 systems and also that the deployment type is the third deployment type in the list. Assume also that each of the three deployment types supports an uninstall command.

If the user goes into software center and manually selects to uninstall everything works as expected and the specific deployment type is removed. If, instead, it is a business requirement to force the uninstall the requirements are NOT evaluated (see the link below) and the uninstall command line on the first deployment type is executed. If the install was based on a different deployment type then the content will need to be downloaded again for the first deployment type and the uninstall will likely fail.

If the application uninstall adhered to the requirement rule logic then the correct uninstall option would always be selected and no additional content would be downloaded.

To improve HA options - this was previously filed on Connect (https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/1413501/keep-app-catalog-running-with-site-database-server-down-replica-mps-in-place)

When running replica MP's policy is available on the replica MP's DB and Software Center is available and applications are able to installed even if the site server and DB is down. Great for device targeted deployments.

However for user centric deployments that are available via the App Catalog, the users ability to install these is none existent since when the site database is down the App Catalog cannot load as it tries to connect to it and fails.

It might be handy if the database elements that are needed to load the App Catalog are replicated over to the replicated DB's on the replica MP's and if the administrator is able to change from the site DB to a replica DB to keep the functionality of the App Catalog available during an outage.

Or even, if App Catalogs are offloaded from the site server then during their install the administrator is given the option to use a replica DB rather than the site database so no switching is needed during a site DB outage.

With CM1606, we get a great new feature on Deployments of Software Update Group that can trigger a software update scan after the reboot. This makes it quicker to fully patch machines since Update A might get installed and now Update B becomes applicable. Previously, you'd have to wait for the next update scan (which at shortest is 24 hours, even if you schedule it for more often) before Update B would show up as required.

Well, this functionality would be incredibly useful on Deployments of Applications. If I deploy Office 2016, I'd want the device to do a software update scan after the enforcement is complete (after reboot if required, or right away if no reboot required).

Because so many applications require updates themselves, or have dependencies/prereqs for things like .NET Framework versions or C++ Redistributables, this feature addition would make it a better user experience and secure devices faster.