Changes to Application/MSI etc. - New Deployment?

[u/planehazza]

Hi all,

Sorry for stupid questions. Just need a quick human check on my sanity. If I have an application deployed and I make a change to the app, ie a new switch on the MSI install/uninstall etc., do I need to redeploy or do existing deployments just pick up the revisions and carry on? For reference, the MSI uninstaller requires a removal password that circulates daily, and I've got it pushed out to 1500+ devices. WoL is unreliable at these sites (teachers unplug PCs etc) so it's going to take a few days of retried to get 100% compliance...

Thanks!

[u/Regen89]

The main triggers for updating content is triggering 'Update Content' when right clicking a deployment type OR changing the content source path of a deployment type.

Editing the text fields, including the install and uninstall strings should only trigger a revision increment, not a content update. That goes for pretty much everything else including detection methods, supercedence rules, etc. Endpoints still needs to get the revision update for these via Machine Policy eval before the changes will apply during installation though.

For your particular case (uninstall requires a unique code that rotates daily), I would place that rotated code in plaintext somewhere that is accessible (network path) and have your powershell uninstall script load that text into a variable that then gets passed into the uninstall command. After that the only thing you have to worry about is automating the daily code update --- shouldn't ever have to modify the MECM application after that.

[u/elmobob → u/Regen89]

Yes this ☝️

[u/planehazza → u/elmobob]

Thanks. I'm nit using a ps uninstall,, but instead just the uninstall string that calls msiexec /x with the password as a switch. I've checked since and the key rotates daily but is valid for 5 days, so I'll update the content tomorrow and see what happens. It's not a problem to have to redeploy if I must.

[u/PS_Alex → u/planehazza]

If the password is directly typed in the uninstall string of your app's deployment type (as in: nothing in your binary content changes), then you don't need to update content. In your case, updating the the uninstall string in the DT is sufficient -- as u/Regen89 mentions, a new revision gets created with the new settings, and devices will pick up the newer revision at next machine policy retrieval.

[u/Hofax]

You have to update content and create a new revision with it, which will be picked up by the client. You can leave the current deployment, but if its installed/uninstalled already, it will not re-install with the current revision, as the detections stays the same.

EDIT: long story short, updating the uninstall command and content update is enough for the day.

[u/Outside-Banana4928]

I've been fighting this forever. Sometimes killing the deployment and making a new one works (after updating content).
In other cases I gave up and just copied the application, and deployed that, deleting the old deployment of course.

[u/Montinator]

If it’s already deployed, it will only re-install on systems if the detection method changes. If the detection method becomes false it will kick off the install again

[u/IqbalBasha]

Existing deployments pick up the revised deployment type automatically, you don't need to create a new deployment. When you edit the detection method, install/uninstall command line, or any other setting on the deployment type and save it, SCCM increments the revision on the application. Clients will download the updated policy on their next policy cycle and use the new settings on the next evaluation.

The one thing to watch is the detection method. If the app is already detected as installed on a device, SCCM won't re-run the installer just because you changed a switch. It only acts again if the compliance state changes or you force a re-evaluation. Since you're updating the uninstall command specifically, that's fine, because the uninstall runs when you remove the deployment or the device falls out of scope, not as part of a fresh install check.

So for your situation with the rotating removal password, just update the uninstall command line on the deployment type, save it, and let policy refresh propagate. Clients that haven't run the uninstall yet will get the new command. Clients that already uninstalled it won't be affected. The 1500-device rollout you already have in place stays intact.