Calum
My feedback
-
9 votes
An error occurred while saving the comment -
5 votes
An error occurred while saving the comment Calum commented
I would give you my vote, if I had any left. It's quite jarring that almost every other dashboard has clickable views except the ATP dashboard.
-
69 votes
An error occurred while saving the comment Calum commented
Very much agreed with this, I was surprised by the lack of this feature this morning.
-
34 votes
An error occurred while saving the comment Calum commented
Agree with this request, the wording is confusing. To go further. whilst changing the wording would be easier I would personally love if there was also an option to allow no action (current behaviour if checkbox isn't checked), discovery, or discovery & remediation (current behaviour if box is checked) outside the maintenance window. That would allow the ConfigMgr admin full control over what actions can and cannot be taken by compliance evaluation outside of maintenance windows.
-
107 votes
An error occurred while saving the comment Calum commented
As Zack says, checking the type of registry value would be incredibly helpful. If I want a value to be 1 and type REG_DWORD, I don't want this to report compliant if it's actually a REG_SZ - even if it's still set to 1. I would also love if the CI would change the type of value to match what is specified.
-
1 vote
Calum shared this idea ·
-
13 votesplanned ·
AdminBob Mac Neill (Software Engineer, Microsoft Endpoint Configuration Manager) responded
Updating status to planned – see https://docs.microsoft.com/en-us/mem/configmgr/core/understand/find-help#send-a-suggestion for an explanation of each value.
An error occurred while saving the comment Calum commented
Expanding the accepted wildcards in task sequence conditions would be a big help. Being unable to use operators such as [0-9] is problematic and it's confusing to use % and _ in one area vs * and ? in another to represent the same thing. At the very least this should be documented.
-
36 votes
An error occurred while saving the comment Calum commented
This would be a great improvement to the product. As bdam mentions, the only alternatives right now are task sequences or chaining dependencies, and chaining dependencies only gets you so far.
-
314 votes
An error occurred while saving the comment Calum commented
No votes to add to this but I 100% agree. Functionality to remove items with a CI where they can be added by a CI, as well as remediate only if the item exists, would be a huge help.
-
2 votes
-
0 votes
Calum shared this idea ·
-
479 votes
Calum supported this idea ·
-
19 votes
An error occurred while saving the comment Calum commented
This request seems a bit dead compared to this one:https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/15032517-allow-the-client-upgrade-to-be-performed-outside-mNot sure if this could be a candidate to merge but I wanted to add my 2p worth here as well. Being able to define when the client will be upgraded more exactly than we can now would be of immense help, particularly when the current method means the client may a) take a long time to be upgraded if the client has fairly restrictive maintenance windows and b) may be upgraded during a maintenance window when the client is already handling software installations, Windows patches etc which disrupts the process. More control over the client upgrade timings would mean we can avoid these issues.
-
2 votes
Calum supported this idea ·
-
8 votesNoted · 2 comments · Ideas » Setup and Server Infrastructure · Flag idea as inappropriate… · Admin →
Calum supported this idea ·
-
104 votes
Calum supported this idea ·
-
81 votes
An error occurred while saving the comment Calum commented
Also no votes left but fully agree! It would also be great to have the ability to run this on DPs in untrusted forests.
-
15 votes
Calum supported this idea ·
-
66 votesNoted ·
AdminMark Silvey - ConfigMgr Product Team (Engineering Manager, ConfigMgr, Microsoft Endpoint Configuration Manager) responded
This bothers me too! Looking forward to addressing this.
Calum supported this idea ·
-
216 votes
Calum supported this idea ·
"When the MSI exit code returns reboot pending, it could also automatically retry on the next reboot."
This would be fantastically useful, or at least, run the application deployment evaluation cycle when the agent next starts. This would allow a lot of folk who use task sequences to handle a situation where an app install or uninstall needs a reboot to move to simpler applications instead.
A scenario I'm facing at the minute when deploying a new version of an app, let's call them OldVer and NewVer.
NewVer cannot be installed over the top of OldVer, and won't upgrade it - OldVer must be removed first.
Removing OldVer requires a reboot before NewVer can be installed.
Right now I have to use a script which, if OldVer is installed, uninstalls OldVer and returns 3010 - but then NewVer may not be installed in the same maintenance window.
Edit: also related item - https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/20425228-application-deployment-evaluation-cycle-automatic