Calum
My feedback
-
12 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.
-
71 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.
-
113 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
·
-
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.
-
320 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 votesCalum
shared this idea
·
-
485 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
·
-
8 votesNoted · 2 comments · Ideas » Setup and Server Infrastructure · Flag idea as inappropriate… · Admin →Calum
supported this idea
·
-
112 votesCalum
supported this idea
·
-
98 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
·
-
63 votesstarted ·
AdminAdam Meltzer (ConfigMgr Product Team)
(Software Engineer, Microsoft Endpoint Configuration Manager)
responded
Look for an improvement here in the next TP release.
Calum
supported this idea
·
-
238 votesCalum
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