bdam
My feedback
-
36 votes
An error occurred while saving the comment bdam
supported this idea
·
-
491 votesunder review · 26 comments · Ideas » Client deployment and discovery · Flag idea as inappropriate… · Admin →
An error occurred while saving the comment bdam
commented
Yes please. It's pretty common to have a non-repeating maintenance window to prevent anything happening on certain devices. At least, any deployment that doesn't explicitly override the window. Any devices in such a window will never apply the automatic upgrade. Further, you cannot add custom deployments to the client packages so the only recourse is to create your own.
-
8 votesbdam
supported this idea
·
An error occurred while saving the comment bdam
commented
Of particular concern to us, the deferred channel has multiple tracks/releases and experience has shown us that you do not want to deploy more than one. So picking a channel isn't enough, we need some automated way to pick the track/release within a channel as well. If memory serves there should only ever be two in the deferred channel so even a earliest vs. latest option should suffice.
-
839 votes
Updated to Noted. We’ve been discussing the same in our planning meetings.
Thanks,
BobMN on behalf of SangeeV for SCCM OS DeploymentAn error occurred while saving the comment bdam
commented
As an addendum, the ability to update (regenerate) customized bootdisks (including MDT bootdisks) from the console. Currently you have to rebuild the bootdisks from scratch when the ADK changes. With the release of 1702 only bootdisks based on the 1607 ADK can be customized. However, it's not just that, you can't even see the customizations you had on your old bootdisks so you have no way to directly replicate them.
-
17 votesbdam
supported this idea
·
An error occurred while saving the comment bdam
commented
Yes, please! Another application model gotcha that should be easy to resolve.
An alternative solution would be to bypass this by for all PowerShell application detection. There's no option to sign the code so the only configuration that works is to ignore the execution policy.
-
81 votesbdam
shared this idea
·
-
3 votes
An error occurred while saving the comment bdam
commented
The difficulty I see is that those dependencies would become highly OS specific. Updates sometimes apply to specific OS's and then get superseded. So you'd need to constantly monitor and understand the changing landscape. With MS's changes to update rollups I think this becomes even worse.
Your example of .NET 4.6.1 show another issue. Only Windows 7 and Server 2012 R2 have updates that install .NET 4.6.1. There is no update for other OSs and in some cases (Win 10 1511+) the update is part of the OS. The .Net updates are now rollups and are superseding the previous month's. So you're going to have to create some pretty convoluted dependencies to cover .NET in terms of what updates are installed.
Dependency groups are satisfied when any single item is detected so they can't be used to verify that multiple depend apps are installed. You can't order the groups so you have to use dependencies to enforce a particular order. You can't have a dependency chain longer than 5 apps long so if order matters the application model can't handle more than 5 apps. That means Task Sequences. Implementing group ordering would eliminate this bottleneck and the need for task sequences.