Managing APP-V Deployments in ConfigMgr 2012

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.…

Comments

• Anonymous
  January 01, 2003
  Hi Alan, This guide provides the solution for a system centric deployment. If you review page 31 you will see the "Note: The uninstall collection query listed only works for systems. The query must be modified when the install collection contains user objects." This solution is based around the same concepts however for a user deployment model. Hope that answers your query.
• Anonymous
  January 01, 2003
  Hey @Ron and @Ian
  
  This behaviour is by design, as the SMS_G_System_AppClientState attribute class is not exposed through the UI. As it's not exposed, entering it via the WQL Query editor will work, however when you switch to design view it relies on the classes exposed via the UI.
  
  Matt
• Anonymous
  January 01, 2003
  Hi Ron, The last image simply shows the query with the syntax to explicitly exclude the AD Security Group, As The Install Collection is based of this AD Security Group we can simply use the Exclude Membership Rule to achieve the same result, which is what I recommend. I will update the image when I get a chance. On your second point, Check the quotation marks in your query as the sometimes cause issues when copying directly from a browser, you can try copying to notepad first, then into your ConfigMgr Console.
• Anonymous
  November 05, 2014
  OK things to note with this setup (that i have tested):
  
  - When the user is removed from the AD group you have to wait for the AD Group Discovery to kick in for the query to run. If the discovery is set for Delta updates it should happen quite frequently.
  
  - The user gets added into the Uninstall collection and stays there until the collection is cleaned out (manual task).
  
  - The application gets completely deleted from the App-V cache and their start menu. HOWEVER, if they have pinned the shortcut to their start menu or taskbar these will remain!
  
  - If another user of the same application logs into their machine the app gets pulled down again. When the original user logs back in the app will be in the cache..... though they will not have any capability to launch it (no icons present).
  
  - Adding a user back into the relevant AD group re-publishes the application to them.
  
  Cheers
  
• Anonymous
  November 27, 2014
  Hello,
  
  Is your best practices are the same like this Microsoft Official Guide ?
  http://www.microsoft.com/en-us/download/confirmation.aspx?id=38177
  
  Best regards,
  
  
• Anonymous
  December 24, 2014
  Thanks for this blog but I have a question. Why is the example of the query different than the query in the last image of your blog.
  I also have a problem when I copy the example query into our SCCM 2012 R2 environment I get a error message: This query either has a syntax error or is using features of the language not supported in design view" any idea what is causing this error.
  
  Best Regards,
  
• Anonymous
  January 06, 2015
  Hi Ian, Thanks for the explination. I also did copy the query to notepad and from here I copied it to SCCM. But I still have te same error message. I don't have any idea what I'm doing wrong. So I tried to make the query myself within the query editor. I don't get any erro message until I add the part of the join. In the join you refer to SYSTEM_AppClientState and when I create this join manully I can't select SYSTEM_AppClientState. It seems that something is missing,
  Hopefully you understand the way I describe the problem.
• Anonymous
  January 07, 2015
  Hello Ian. forget my last remark. The error message still appears when I click "Show Query Design". But when I click OK and save the collection there is no error. Also the collection is filled up with the correct members.
  So I think this error message is a SCCM bug/feature.
  I tested this a couple of times and it does exactly as expected.
  Thanks for this blog.
  
  Cheers
• Anonymous
  January 12, 2015
  Thanks Matt for clearing this up.
• Anonymous
  June 08, 2015
  Here is an interesting issue I worked with Umair Khan on a support case. This will help in analyzing
• Anonymous
  June 30, 2015
  ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like