ADR Available Deployments
I would like to see ADR's support the creation of Available deployments in addition to Required deployments. We have some business cases where a certain subset of servers are aren't allowed to "push" software updates to until the server/app owners have verified the patches.
The issue is that these servers don't have connectivity to the internet so we have to deliver them via ConfigMgr. By creating an Available update using an ADR, it streamlines our ability to "deliver" the updates to all systems, and allow the Patching Team, or App/Server owner to patch according to their own business schedules.
Dustin Hedges
shared this idea
Admindjam
(Product Director, or Executive, Microsoft Endpoint Configuration Manager)
responded
on our short term radar.
48 comments
-
Ryan Hathaway
commented
Can we move this from the short term radar, to the REALLY REALLY REALLY short term radar???
-
Paco
commented
While MS do not complete the Orchestration Group functionality ( e.g decide what SU groups need orchestration and which not, THIS IS A MUST
-
Anonymous
commented
+1 still waiting and this feature would make our lives much easier!
-
jan-the-man
commented
WE NEED THIS!
:) honestly ... the whole wide world need it... please let us know!
-
Schubbi
commented
@djam
this is on the short term radar for allmost 3 years.
will it be in the next release ?we desire this option :)
-
Jon Fetherston
commented
We would very much like this feature also?
-
Nikola Bozov
commented
We require this feature more and more. In our infrastructure we support primaraly server which we do not want ot have required updates or apps deployed. ADR's will make our jobs very easy for deploying O365, security updates, apps etc with available deployments.
-
Sandro Jäger
commented
Would be very helpful to automate update deployments for critical systems where a required update deployment is not feasible.
-
Anonymous
commented
"on our short term radar." from 2018 - I really hope they implement this!
In the meantime, this might be a workaround: Have an ADR required deployment to a collection with a non-recurring maintenance window in the past. Show notifications in Software Center. I think this will work. Got the idea from Bryan Dam's blog.
-
Rebecca Haas
commented
We would also like this feature! :-D
-
Grant D
commented
Marked as Planned 2 years ago. Can we get some movement on this? I want to automate my job even if the Apps/DB team can't / don't want to automate theirs. I just want to give them their patches and they can do what they like with their servers.
-
Tim De Keukelaere
commented
Recycled a vote to +1 this - would be very helpful for many of the environments I work in.
-
Thomas Kurth
commented
Hmm would be really helpful
-
Tristan Dawson
commented
I'd really still like to see this, though seeing as it's been on the 'short term radar' for the last two years, I haven't got high hopes :(
-
Anonymous
commented
This is a huge concern where I work too. What's the point of ADR's if we can't also create an ADR to only make Windows updates show up Available in Software Center? We have a couple hundred specialized devices that absolutely cannot be patched at all automatically and need to be patched manually. Not allowing the type of deployment to be changed to Available until after the rule runs and downloads the updates is ridiculous. Now, I will have to revert back to the old way of deploying the SUG every month that just makes the updates show up in Software Center as Available.
-
Alessandro
commented
+1 would help automating my server patch management.
-
Germier Mela
commented
Please, how long we need to wait for this? it is slowly time......
-
Bradley Fox
commented
This has been on "short term radar" for almost 2 years now. I can't believe this is a heavy lift as it would just require on additional option in the deployment. Please implement this.
Currently, I let the ADR create the required deployment as disabled then I have to come in every month and change the deployment to Available then enable it.
-
Jeff
commented
There's really two issues to address here, if Microsoft is indeed a newer, better Microsoft under Satya.
1. Yes please stop artificially limiting this feature. And that's really what needs to be done here. No one is asking for you for new code - this feature is available in other areas of the same product. It was simply a choice by MS to not allow for the use of this feature here.
2. Which leads to the second issue. A 'Better Microsoft' is a Microsoft that gets off its ego driven high horse, and stops forcing certain options, or enforcing the limitation or removal of options, based on someone at Microsoft deciding how things should be done in some environment they do not understand. And environments outside of Microsoft offices are CLEARLY environments Microsoft does not understand. Stop trying to ENFORCE your idea of how work should be done, because it just harms your reputation every single time you do that. Make your products feature - rich, not feature - poor. Make them FLEXIBLE, not rigid. If you have a feature, make it widely available - instead of using it as a medium to tell people how things ought to work in some environment you clearly do not understand. -
Waingro
commented
We need this terribly. I can't even believe it isn't an option. We deploy updates as available to unknown systems and specific groups who get white-glove update installation service. With the current setup this is a manual process or I have to spend cycles to script it out. Either effort is pointless when the tool is capable and should be doing it already.