Calum
My feedback
-
34 votes
An error occurred while saving the comment -
63 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 voteCalum
shared this idea
·
-
7 votes
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.
-
33 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.
-
239 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.
-
4 votes
-
0 votesCalum
shared this idea
·
-
384 votesCalum
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 votesCalum
supported this idea
·
-
7 votesNoted · 2 comments · Ideas » Setup and Server Infrastructure · Flag idea as inappropriate… · Admin →Calum
supported this idea
·
-
77 votesCalum
supported this idea
·
-
50 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 votesCalum
supported this idea
·
-
57 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
·
-
176 votesCalum
supported this idea
·
-
4 votes
An error occurred while saving the comment Calum
commented
You got my votes. ConfigMgr should definitely reflect the state of ATP onboarding for all supported OSes.
Calum
supported this idea
·
-
66 votesCalum
supported this idea
·
-
22 votes
An error occurred while saving the comment Calum
commented
To be useful, this would really also need to include checks for include/exclude membership rules - collections don't always directly have something deployed to them but a collection they're included in may well do.
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.