Option to create custom detection rule/method

With the new possibility of creating custom applications, there will be the need for custom rules. We have lot's of applications, that are far more complicated than a simple .msi or .exe. A rather simple example is TightVNC (Server/Viewer only). We are using TightVNC Server only as a custom App. There is one problem - "TightVNC Viewer only" can't be installed separately because PatchMyPC script thinks it is already installed. Probably because you are checking for product code or something like that. In this case we would additionally have to check for which .exe truly exists.

Our use case is to deploy an application, followed by a post-script that performs a registration task. The post-script generates a registry key to indicate success or failure, and we'd like to ensure that forms part of the detection method. I can think of various other scenarios where checking a value on the device is part of the success criteria, so this would be a really useful feature to have.

I have a use case for this vote as well. We need a detection option thats not version specific, but generic, eg app.exe so only new users/machines get a required app and not existing users. Existing users, I would make additional custom apps available in CP. Use-case is I need to be able to give users different versions of the DisplayLink drivers to install when issues arise for them, but onboarding they get the latest one.

Looking for the same thing with the intune detection rules. My use case is as follows. I want to be able to have PMPC create new deployments for the latest versions and bring over the existing assignments (required and available) but not push it to users. This way new users will always have the latest version available in the company portal and I can manage pushing the update to existing users using the "update" deployment.

Correct me if I am wrong but the way it works now, if I have an app assigned to a group as required and PMPC copies that assignment to the new version of the app, it will get pushed to all the users in that group because the existing detection rule script checks the version.

Creating a custom detection script for the app deployment that simply checks if any version of the app is installed will allow me to keep the apps in the company portal updated and still manage pushing app updates using the update deployment.

To add to this conversation, here's some information about my use-case that I'd like to see. Similar to others, what I'd like is for the PMPC App to only install if the app is not present. Then allow the "updates" version of the app to update the app during my update schedule. For instance, we have Splunk and other security products we want installed ASAP if they aren't already installed. However, we don't want those apps being updated as soon as an update is available. Rather, we want the update workflow to follow our monthly patch schedule.

If there could be a toggle for the detection method to be either "report installed if any version is present" or "report installed only if version is greater than or equal to this release" that would be precisely what I'm looking for. I'm already doing your suggestion of having a required deployment directed towards a collection of devices missing the app, but I'd like to avoid having more collections than necessary so we can optimize the performance of the membership evaluations.

I'd also like to see this implemented. In our case, we have an app we are deploying as a "required" deployment that does a great job of self-updating, but PmPC pulls in updates for this application at least once per week. This results in many prompts to our end users. What we'd like to do is have a mandatory deployment for the application that ONLY installs if there isn't already some version installed (we could manage this ourselves via custom detection methods to ensure proper versions are detected). Only if the app was not detected would the PmPC deployment begin.

Hi,

too bad, I am not sure this will be working for us. With a custom detection rule we would have the possibility to still offer uninstall option. This is not possible if we remove it by a collection scope. Also, a filter by collection would rely on the collection to update and ignores client settings. I understand, that you don't want to change your program for every single customer, but I am confused this was never requested before. Anyways, thank you very much for your time.

Hello,

Appreciate the additional information. It may be best to adjust your collection instead of your detection rule here. If your goal is to "need Adobe Reader to get offered for clients that do not have any version at all" then you can have a collection that excludes all devices which have Adobe Reader 2022. This ensures that your endpoints are only offered Adobe Reader if it is not already installed and you can roll out new versions using the update mechanism instead.

I do think we will still investigate custom detection, but based on what you have provided I would suggest adjusting your collections as it is an immediate solution you can implement and you won't end up with an inaccurate detection method.

You should be able maintain the version of Adobe Reader with software updates on whatever cadence you want, and have your Adobe Reader application available for installation when the software is not already installed. This can be controlled based on the devices you target with your collection rules.

Hello, sorry it took so long, but I wanted to have an example ready to explain my issue. As you can see, I currently have Adobe Reader installed with version 2022.001.20085. Just now a new version (2022.01.20117) has been released and is now avialable over the Software Center. I would like to change the detection rule so this new version does not get offered to my clients for installation. Our clients get updated once a month, so this is not necessary. Since we still need Adobe Reader to get offered for clients that do not have any version at all, the only way to control this is by a custom detection rule that does not offer Adobe Reader for installation if ANY version of 2022 is already installed.

Agreed with Adam, some additional clarification here would be nice. Is this for WSUS updates or Intune Updates, they use different mechanisms for applicability. Our rules also look for version >=, so if an older version of an app/update is deployed, it should not show as applicable anyway.

"so it doesn't install/get offered for self-service after each minor update." - this bit I'm having a hard time understanding. In what scenarios do you not want an update to install (to the point where you want to change its detection logic)? If you changed an update's detection logic to ensure it doesn't install... instead, perhaps don't deploy it?

I'd like to have either the possibility to create custom detection rules, or the option to disable PMPC detection rules.

There are a few scenerious where this is needed. Adobe is an example for an application with frequent updates. I'd like to create a detection rule that includes multiple app versions, so it doesn't install/get offered for self-service after each minor update.

I don't understand your use case, may you elaborate? If I read your request correctly, you would like to modify Adobe detection logic to ensure it doesn't install?