Allow Nesting Distribution Point Groups.

We have an issue with not always wanting to replicate all content to all locations due to content size and applicability, but to specific locations determined by function.

Examples:
Site A - Imaging DP Group. (Server DataCenter Environments)
Site B - Imaging DP Group. (Desktop Environments)
Site C - Imaging DP Group. (A mix of Environments and business units)

These three sites have different business functions. So while not all imaging content would be the same across the board. It would be nice to have if you could nest those three Distribution Point Groups into one Group, e.g. All Imaging DP Groups.

This would allow the ability to distribute what is common in one click, but the one-offs (which are usually huge in size) do not get sent to locations that do not need those files.

There are times when the drain and resume scripts may need to run as an account other than the local system account of the server. We often support "clustered" servers that rely on a clustering method or data outside of Windows fail-over clustering (Exchange being a good example, but not the only use-case).
It would be nice to specify a run-as account for these scripts in order to reach out to external systems using a service account in order to authenticate to those systems for any required health checks prior to patching (drain script) or after patching (resume script). We could give the SamAccountName of each cluster member server the appropriate rights, but there are major security concerns with doing so. We can also embed credentials in the scripts, but even if we hash them first, this is still not a very secure option. There also isn't room to include credentials given the character limit of the scripts.

I would like to be able to view the device model information within a collection from the admin console\device collections. This currently does not seem to be available from the menu when I right click on a collections column headings to add more columns.

I believe this may be useful as an additional way to ensure that mistakes have not been made when creating queries to populate collections with specific models\manufacturers.

As an example, I created a collection for a specific manufacturer that the computer object also had membership of a specific Active Directory OU. This resulted in the collection populating with different manufacturers so the query was not setup correctly.

The drain and resume scripts are currently limited to 512 characters each. I know there is currently a request to add native cluster aware patching support, but it would be a great start to simply increase the size limit of the scripts. It doesn't seem like there is a safe way to "drain" a server from a cluster to prep it for patching in a mere 512 characters, especially considering that we have to use up some of those characters to return the correct exit code.

We can run some pretty complex and lengthy scripts in configuration items and baselines, so this seems like it should be a pretty simple enhancement.

In our organization, we really like what we've seen for the Scripts Approval Workflow, where we are able to select 'Approvers' to authorize changes to a Script before deployment.

This is a powerful mechanism, we'd love to trigger the workflow mechanism in two other situations:

1.) We want to require Approval when a new deployment is created, and especially when a new OSD Task Sequence is deployed to a collection.

2.) What if we have an existing Deployment that targets a collection? Someone could edit the collection and then add an Include rule for 'All of Our Super Prod Servers - Don't target deployments here' collection? Sure, it might limit their future employment prospects with our company, but they could use that approach to side-step the protections given in request #1. To protect against that, we'd want to trigger the Approval workflow when collection counts change by a configurable threshold.

We imagine this workflow presenting a new node under Applications called 'Pending Change Approvals' or something similar. Ideally, we would be able to add a new role called 'Change Approvers' to certain well trusted users, and additionally it would be a bonus if it were obvious when the Approval was triggered, so that we could build automation around that event to send a message or e-mail.

Incremental collections are an invaluable component of Configuration Manager 2012 that is unfortunately held back by the performance implications of having too many (based on the best practice limit of 200). While the -need- for frequent updating collections was reduced based on an applications conditions, there is still an industry preference to manage application availability using Active Directory groups. As a result, the number of collections potentially benefiting from incremental collection updates is high. I work around this by parsing collections that reference AD groups, checking if they've been updated recently and then requesting collections updates of relevant collections. This works, but simply being able to tick incremental collections would be way better and more discoverable for most Configuration Manager users.