Many customers are still configuring collection structures similar to 2007 and using collections to control the validity of who should receive which applications.

Where possible we should be changing how we now manage application deployments and move the validity processing of the application back to the client by using our Global Conditions (state based) to manage Requirement Rules. This works well for many Off The Shelf (OTS) applications that do not have specific procurement constraints as we can safely deploy this category of applications to ALL USERS and if needed implement an Application Approval workflow. Where I am increasingly seeing customers still reverting back to specific targeted of applications, normally based of an AD Security Group, is for APP-V application deployments.

I continue to see a large uptake of APP-V in many customer sites as we move towards a user-centric mobile environment, which is great, however I am seeing a lot of customers experiencing poor publishing times of virtual applications which is often a result of poor administrative processes.

In SCCM 2007 we had the option to instruct the virtual application advertisement to auto remove the virtual application when the advertisement was no longer available to a client. Unfortunately this option is no longer available in 2012 and as a result many customers have gone searching for a solution by looking to the ConfigMgr Community forums. Unfortunately a lot of members of the community are simply recommending to use the general deployment rule that an INSTALL deployment takes precedence over an UNINSTALL deployment.  As a result many of the community forums have been instructing customers to simply create an UNINSTALL deployment for each virtual application and target this to the ALL USERS or ALL SYSTEMS collections. Please DO NOT DO THIS as you will continue to experience slow publishing times for APP-V applications.

If you are already doing this approach, I strongly recommend you read this blog to understand why this is a BAD idea and be VERY CAUTIOUS in your approach to undo this setup. DO NOT do a BIG BANG approach and remove all of the current UNINSTALL deployments in one hit and create the new recommended workflow as this will cause a huge amount of deployment policy objects potentially causing significant issues in your environment. It would be very advisable that you slowly stage the changes in your environment over a few days to prevent a mass number of policy changes in one hit.

When to use explicit collections for Tier 2 applications?

Only when you have specific LOB applications that require a REQUIRED Deployment.

• Valid Reason: APP-V Deployments where an automatic unpublished workflow is required

AGAIN DO NOT Target APP-V Uninstall deployments to the ALL USERS / ALL SYSTEMS collection as mentioned in many other forums. This will only delay your application publishing times and add unnecessary load on your ConfigMgr environment.

Understanding WHY this is BAD practice

When a client polls for new policy changes, a SPROC is run by the Management Point consuming SQL resources.

The more records in ResPolicyMap and DepPolicyAssignment, the more CPU time required to process the “GET” SPROC like

MP_GetMachinePolicyAssignments – Machine Targeted Deployments

MP_GetUserAndUserGroupPolicyAssignments – User Targeted Deployments

ResPolicyMap maps the resource ID and PADBID, (unique identifier for the policy). You can Query the count of ResPolicyMap objects to determine the number of policies being targeted to each user / system that must be processed.

DepPolicyAssignment links a policy object with its dependency polices and are provided to both users &/or machines when a policy request is initiated.

Examples:

• Application Requirement Rules defined
• Multiple Deployment Types per application

How you should mange APP-V Deployments in your environment

• Minimise the number of Required Deployments to the ALL USERS / ALL SYSTEMS Collections.
• Prevent making any large policy changes that target the ALL USERS / ALL SYSTEMS collections, or any large number of objects in one hit.
• Create an explicit UNINSTALL Collection for each REQUIRED Install Deployment.
• Base the Collection membership on the compliance state of the application = true and exclude the INSTALL collection.

Below are examples of the Collection Queries you can use to manage an auto un-publish workflow for App-V deployments based off an AD Security Group.

USER Centric Deployments.

1. Create an AD Security group for the application you are deploying.

2. Create an INSTALL Collection for each Virtual Application with a dynamic query linked to the AD Security Group. Target the INSTALL Deployment for each APP-V Application to this Collection.

2. Create a specific UNINSTALL Collection for each Virtual Application with a dynamic query using the syntax below. Also add an explicit EXCLUDE Collection membership rule that excludes the INSTALL Collection for that application. Ensure the application name matches that listed in the ConfigMgr database.

select SMS_R_USER.ResourceID,SMS_R_USER.ResourceType,SMS_R_USER.Name,SMS_R_USER.UniqueUserName,SMS_R_USER.WindowsNTDomain
from SMS_R_User inner join SMS_G_System_AppClientState on SMS_R_USER.UniqueUserName = SMS_G_System_AppClientState.UserName
where SMS_G_System_AppClientState.AppName = "APPLICATIONNAME"
and G_System_AppClientState.ComplianceState = 1

Example

Create and Target the UNINSTALL deployment policy to the UNINSTALL Collection.

The result will be…. When a User is added to the AD Security Group the virtual application will be made available to the end user and install silently. When the user is removed from the AD Security group that has previously successfully published the APP-V application, they will be added to the UNINSTALL collection resulting in the virtual application being automatically removed from the client only then. This approach will minimise the ongoing policy objects that every user in the organisation will have to process.

Disclaimer: The queries and examples provided in this post are offered “AS IS” and should be used at your own discretion. Please ensure extensive testing be done before implementing this solution into any production environment. While this solution has been tested and confirmed, the ConfigMgrDogs team takes no responsibility for any unexpected results this may have in your ConfigMgr 2012 environment.…