It can be achieved, but why?

if the user do the install it would be done in the context of the user and affected by EPM Policy.
Block the installer from executing using more matching criteria. This will prevent from matching when the app is installed. Then from intune company portal do the install of Notepad++ in the context of system, as it will not be affected by EPM Policy and there for not blocked. There are multiple options for accomplishing this.

Personally this is one of those software you do not want to deal with, having to package and support. So I would configure rules to allow this to auto-update and allow plugin installation for the majority of users.

Hi, we are not focusing on a single application but on all applications that are externally downloaded, while ensuring that only applications installed via Intune or the Company Portal are allowed.

The reasons for this policy are:

To prevent the installation of unauthorized external applications on company devices.
To ensure compliance with corporate application policies and avoid unauthorized software usage on endpoints.
To streamline the licensing and procurement of applications required by the organization.

@SureshM - do you want to restrict all applications from being installed/run by end users, unless they come from Intune?

If so, the best approach would likely be in two parts: 

The first would be to use default-deny allowlisting - which will prevent users from running any unprivileged applications they have introduced.  This is part of the QuickStart template and combines an allowlist with an ‘Any Application’ catch all rule which is where you apply a block or exception message.  If you have deployed QuickStart, you may just be able to adjust your rules to enforce this - or you may wish to use the configuration as a reference to implement the same settings if you are using a custom policy. 

If you have any privilege exception rules, you can adjust the criteria of the definitions so that they only apply when the application has ‘Trusted Ownership”. Again we have some examples in the QuickStart template with the ‘Trusted and Signed UAC’ group/rule, and it would be trivial to adjust the other UAC rules to trap Trusted and ‘Untrusted’ UAC requests. 

Hope that helps!
 

Hey @SureshM  , This whole environment you want to implement we also have implemented , so in order to enforce this we use Block rule on whenever user tries to execute the installer of any application which is present over company portal .  So the block rule has a link in the bottom end by clicking on that the users are redirected to company portal from where they will be able to install that application instead from external sources.

Hope this helps.

Thank you for all your responses. I have implemented a solution that appears to be working, though it requires ongoing monitoring to ensure it doesn’t cause any unintended issues.

I added a default rule in the regular rules to block anything using a wildcard, without any rules to support elevation.
In the On-Demand Rules, I added a "Trusted Ownership" rule with a wildcard, followed by a "block all" rule.
This setup allows me to block any executions while still permitting the elevation and execution of apps installed via Intune.

Thank you for closing the loop on this @SureshM, and I’m glad you’ve found a configuration which is working for you. As noted above, if you are concerned about blocking something which is required, I would always suggest using an end-user message which requires some form of approval (e.g., Challenge/Response or a JIT request) as it gives you the option to break the glass on a case-by-case basis without having to push out a revised policy.