Currently if you run an MSI using a wrapper, and the MSI is located in a subfolder, the source list reg keys get set differently.

The path in HKEYCLASSESROOT\Installer\Products<product code>\SourceList\Net gets set to the relative path of the MSI at run time.

The path in HKEYCLASSESROOT\Installer\Products<product code>\SourceList\URL gets set to the root content URL on the DP.

This causes issues if the local cache has been removed or purged. The user can no longer perform a repair as the source path is invalid.

Normally I'd say just uninstall and reinstall, but in the case of some CAD systems that can be a pure nightmare for the user or tech.

I always have three version of Flash to import. Flash for Active-X, Firefox, and Chrome. I'm just using Flash as an example.

All of the installers are .msi I'd like to create a folder called "sources" place all of my .msi files in the "sources" folder then click import. The import wizard would import all of the .msi applications and place the source .msi in a target folder automatically for deployment. Maybe include a template in the import wizard. The template would be the same for all imported .msi applications. Example install for Device, Only Show notifications for restarts, Silent/Hidden install etc.

Please put in Event based deployment versus Time based deployment based on file/registry/Event log change. The deployment date should be used as the absolute earliest the event could take place. The expiration date should still hold true.

The action could possibly happen on a single device, but need to occur to devices within a boundary/collection.

The usage scenario is when a computer device is being used in a 24 hour retail setting, and the maintenance window is dependent on when the retail location determines a time in which it can take such action. The retail store may only have a single device that's given the signal that such action should take place on all of its devices.

Enable/Disable Feature for Application Deployments
When a Deployment is created, it is Enabled by default and there is no way to Disable it. In the current state, a Deployment could get created incorrectly, resulting in a large number of computers in the company getting rebooted, unwanted software or blue screens (if its something incompatible for that platform). In SCCM 2007 we got around this by creating a "Disabled" program for each Package, then after an Advertisement was QA'd, we would associate the "Enable" Program with the Advertisement. This option is not available in 2012. Seems like a pretty simple feature to introduce, but I haven't gotten very far with Microsoft.

1. When deploying an application as available, it will by default be set to UTC time in the scheduling section without the ability to change it to "Client Local Time"


2. When deploying an application as required, it will by default be set to UTC time, unless I check the "installation deadline" then I get the abillity to choose "Client Local Time"

Here in Denmark and other places in Europe UTC is a bit confusing, we always have to be aware of this when deploying applications eg. I want to deploy an application for the end users at 08:00AM then I have to set the deployment time to 10:00AM because of UTC, make no sense for us here in Europe...

I would like to be able to choose "Client Local Time" on all deployment types.

Look at Software Updates deployments, here I can choose "Client Local Time" on both Available and Required, actually it's set by default in our environment.

Dear All,

we are using more than one detection rule for all our applications(script installer) that are created in our environment.

During installation, the detection rule (AND condition) works fine and we face no issues.

But there are cases when the uninstallation fails in the middle of the script, we get the message as REMOVAL FAILED in the software center, and out of 3 detection rule one or two get removed (partly uninstalled) , but not the whole application is uninstalled from the machine. And when we run the RETRY for removing the application, SCCM check for installation status based on the detection rules and the detection rule returns false, which makes SCCM to believe the application is no more installed in the machine and vanishes from the software center without even executing the uninstallation again.

This brings inconsistency in the application uninstallation, and few application are partly uninstalled and broken. And when we try to reinstall the application on the same machine, it even fails to install the application, since it has a broken application because of this partial Uninstall.

And this can be rectified only when the detection rule work vice versa for Uninstallation, i.e all the detection rule values must be removed from the machine , only then sccm should declare the application is removed from the machine or by creating custom scripts for detection rule (which we don’t want to). But sccm doesn’t work that way.

So the detection logic can be changed to make it work the other way during uninstallation.

In the Microsoft portfolio a complete User Environment Management (UEM) solution is missing. Yes, there is Group Policy + Preferences and User Environment Virtualization (UE-V), but a solution like RES One Workspace or AppSense is missing. Why's that? Lot's off customers like to have a Microsoft-only or Microsoft-unless policy, which can't be using Microsoft solutions alone.

Think about a solution which combining user settings like start menu, desktop, folder redirection, taskbar, application control, application security, license management, drive mappings and printer offering. Where delegating of control is possible. With integration in Configuration Manager, and what else you can think of. How's everyone in the world doing this without using a 3rd party solution?

Hope that Microsoft will come some day with a solution like this. On-premises isn't dead. Hybrid is the future, and local systems still needs to be managed.

/Henk

Please incorporate the option to execute a Program without elevation (least amount of privileges).

Background:
We sometimes receive requests to automate some process via Configuration Manager. This is frequently done by creating a Package with a Program that executes a script.

Use case:
When automating the OneDrive sync client (or various other commands / programs), a simple script works well.

Problem:
When the same script is executed with elevation, it doesn't work as expected.
Configuration Manager elevates the session when the currently logged on user has admin privileges on the machine.
Some troubleshooting is required to find the root cause. After that, additional scripting, testing and verification is needed to make the script work as expected.

Workaround:
Additional scripting.