UPDATE: I have sent my feedback to Microsoft - if you agree with me would you be willing to send a vote or three my way? https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/12873717-add-options-to-deployment-type-application-model

Let me paint a picture for you. You have a mixed environment in SCCM 2012 of server and desktop operating systems. You also choose to utilize user security groups as a way to manage applications that are only deployed to certain users (from now on we will call these Level 2 applications).  You initially set the requirements of those Level 2 applications to only deploy to desktop operating systems because you don’t want them on servers in the environment.

Now as the desktop team you have been tasked with managing your remote access infrastructure (RDS, XenApp/XenDesktop, etc.), and you’ve decided that you want to deploy certain Level 2 applications to all these machines (via TS or via Deployment) but not to the other servers in the environment.

Well you could remove the requirements on the app altogether to ensure that they are deployable via OSD TS, and then make sure you’re not deploying them to the collections containing the servers you don’t want the software on.  ConfigMgr, it doesn’t solve the user deployment issues - you deploy the app to a security group containing User X and then User X logs on to one of these servers - BAM! You have software you didn’t want on these servers.

So I’m throwing this question out to my readers. How would you propose that we manage this solution? The goal is to deploy the application to some systems that meet the requirements, but not to others - ConfigMgr, the deployment is based on USER not COMPUTER. Comment below to let me know your thoughts. Read on for two of my proposed solutions that I want to submit to Microsoft for consideration into the next major release of SCCM.

Proposed Solution 1
Create a requirements or filter for deployments similar to how filters work on group policy objects.  Essentially you would be given the option during a deployment to filter the installation - so if those requirements aren’t met the deployment doesn’t take place.

“BUT Z-Nerd, that’s the point of the application model ‘requirements’ section!” I agree to a degree - but in our scenario from earlier in the post, even if you make separate deployment types and set the requirements to different OSes, you don’t get to choose which deployment types are ‘allowed’ by the deployment.  In the case of application requirements you would actually have to create two separate applications models for the same application to make this work.

The real downside I see to this solution is additional strain on the workstation for whatever query language is used to determine applicability.  This could somewhat be mitigated to limiting requirement/filter scanning to only deployments that utilize a filter.

Proposed Solution 2
Create a flag for application deployment types that either:

Thanks for reading, and as always - Happy Admining!