logo
2
Considering

Option to preserve original configuration policy name when cloning or restoring policy from backup

Option to preserve original configuration policy name when cloning or restoring policy from backup Currently when cloning a policy from one tenant to another, it sets the policy name to "[Name] (CLONED Date Time)", I can understand why this is the case, but could we have the option to copy the with the original name to save having to go back into Intune and update them all manually to remove the extra brackets and (CLONED Date Time)? If its a case of not overwriting the existing policy if there is one of the same name, maybe add a toggle option to allow overrwite?

2
In progress

Tickboxes to allow mutiple selections in the Policy Manager

Tickboxes to allow mutiple selections in the Policy Manager Being able to select multiple configuration profiles/policies and take Clone/Save/Backup/Delete action on them all at the same time rather than having to do the same action for each one individually

2
Considering

Addtional column in Security Dashboard for CVSS v3.1 base score for the pending app update

Addtional column in Security Dashboard for CVSS v3.1 base score for the pending app update Would it be possible in a future update to include a column before/after Risk Score, maybe called "CVSS" and have it show the highest outstanding CVSS v3.1 base score for the app that needs updating? That way we can prioritise updating those apps that are 7.0 or above. I know the Risk Score is similar and obviously we should treat highest first, just think it might be a useful/nice addition if it was possible?

2
Considering

It doesn't appear there is a way to modify a currently deployed (Status = Success) application and redeploy with the new settings. Delete and rebuild seems a bit awkward.

It doesn't appear there is a way to modify a currently deployed (Status = Success) application and redeploy with the new settings. Delete and rebuild seems a bit awkward.

1
Considering

Change “Installation Behavior” retroactively. For example, we have the problem that another piece of software (which was not previously installed on the client) must be excluded for an “Update Only” package. Currently, this requires regenerating the entire application package. The “Installation Behavior” field is grayed out.

Change “Installation Behavior” retroactively. For example, we have the problem that another piece of software (which was not previously installed on the client) must be excluded for an “Update Only” package. Currently, this requires regenerating the entire application package. The “Installation Behavior” field is grayed out.

1
Planned

Ability from Pkgr to append an organizational description to all apps deployed to include "Any problems with installations please contact IT at XXX-XXX-XXXX or [email protected]."

Ability from Pkgr to append an organizational description to all apps deployed to include "Any problems with installations please contact IT at XXX-XXX-XXXX or [email protected]." This append would be nice if it was organizational so that every deployment gets the same thing appended to the description of the app so an end user can see it to remind them where to contact if any issues arrise. Or to know who is responsible for application updates to contact the correct department and so on.

1
In progress

Allow use of authenticator apps such as Microsoft Authenticator to protect "break glass" account

Allow use of authenticator apps such as Microsoft Authenticator to protect "break glass" account

0
Considering

Can you set it to automatically link the policy when cloning them? Or atleast give a tick box when deploying to link them

Can you set it to automatically link the policy when cloning them? Or atleast give a tick box when deploying to link them

0
Planned

Policy to limit when packages get updated for org, so that if a newly-released package has vulnerabilities or malware, you're not instantly hit with it. Let's say you can set a 7 day package age minimum before it gets promoted for your org as available

Policy to limit when packages get updated for org, so that if a newly-released package has vulnerabilities or malware, you're not instantly hit with it. Let's say you can set a 7 day package age minimum before it gets promoted for your org as available This is available in package managers (for software developers) like npm.

0
Considering

TOTP for MFA on accounts

TOTP for MFA on accounts instead of using mobile numbers, please implement TOTP - this is a lot more viable for MSPs.