Calum
My feedback
-
274 votesCalum
supported this idea
·
-
19 votes
-
32 votes
-
101 votesCalum
supported this idea
·
-
2 votesCalum
supported this idea
·
-
11 votesNoted · 2 comments · Ideas » Setup and Server Infrastructure · Flag idea as inappropriate… · Admin →Calum
supported this idea
·
-
45 votesCalum
supported this idea
·
-
32 votesCalum
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
·
-
38 votesNoted ·
AdminMark Silvey - ConfigMgr Product Team
(Engineering Manager, ConfigMgr, System Center Configuration Manager)
responded
This bothers me too! Looking forward to addressing this.
Calum
supported this idea
·
-
95 votesCalum
supported this idea
·
-
4 votesCalum
commented
You got my votes. ConfigMgr should definitely reflect the state of ATP onboarding for all supported OSes.
Calum
supported this idea
·
-
59 votesCalum
supported this idea
·
-
22 votesCalum
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.
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.