Udostępnij za pośrednictwem

Using SCCM Local Policy to Selectively Restrict App-V Integration

  • Artykuł

I got chatting over a month ago with Rob York who is one of my colleges in Microsoft about the SCCM and App-V Integration. He was working with a customer that had already deployed App-V Full Infrastructure and wanted a graceful way around moving them to SCCM. One of the tail conversations I had with him was how MSIT have created a method to allow an exception policy to prevent users from receiving the SCCM and App-V Integration policy. Rob then tunnelled away in code and the config manager SDK to come up with a very elegant solution to the problem.

Now over to my guest post from Rob on the solution.

------------------

I am sure my customer are not alone in their desire to control the way in which Configuration Manager takes ownership of Virtual Application delivery to clients on a network. I hope this entry is able to help a few more of you:

Because the change to enable virtual application delivery in ConfigMgr is a site setting, all machines under a single primary site will get the policy to take ownership of the App-V Client if it is installed on the machine.

The two main issues with this that spring to mind are:

1. If you wish, for whatever reason, to concurrently run an App-V infrastructure alongside virtual application delivery in ConfigMgr.

2. Because ConfigMgr only advertises user targeted advertisements to users logged on to console 0, it is not possible to target at users that log on as to terminal services session.

One way around the problem is to deploy another Primary Site in which you can disable the delivery of virtual applications and thus you are able to split the clients in your environment into those you want to advertise virtual applications with ConfigMgr and those that you want to deliver via a standard App-V infrastructure. Problem solved right? Well not necessarily; not only do you have all the extra software licencing and hardware costs you've got all the additional administration and management and not many people are willing to re-write their ConfigMgr design to accommodate this one setting.

This relatively simple method allows you to select on a per client basis the virtual application delivery.

At this stage it is worth noting that the local policy can be applied after virtual application delivery has been turned on at the site. However you will need to repair the Client's connection to the App-V Management Server and refresh all the virtual application. For the purposes of this guide it is assumed that the "Allow virtual application package advertisement" check box on the "Advertised Programs Client Agent" in the ConfigMgr Console is set to cleared:

clip_image001

Before I begin I feel it may be pertinent to give a quick overview of how policy works in ConfigMgr. ConfigMgr has three versions of Policy on a client machine. The two we are interested in here are Requested and Actual. Requested policy is that which has been provided to the client for evaluation. During normal client operation this is downloaded from the site's management point. Actual Policy has been evaluated by the client and it is this policy that determines the settings in place on the client. Each version of policy is stored in within its own namespace in WMI. As well as the policy a client receives from the site it is possible to inject our own, "Local Policy" Furthermore, in ConfigMgr, unlike Group Policy, local policy overrides site policy by default. Using a MOF file and MOFCOMP.EXE on the client, we can apply local policy into the RequestedConfig namespace of the client. Once the client evaluates its policy; the local policy will take effect in the ActualConfig policy namespace. Using the tool "PolicySpy" from the "SCCM 2007 Toolkit". It is possible to see the different versions of policy:

clip_image002

 clip_image003

As you can see: the policy in Requested and Actual mirror one another!

The first step is to create the MOF file to contain the local policy we wish to apply to the machine.

The part of the policy we wish to change is:

Reserved1 = "<?xml version='1.0' ?>
<SWD_ClientConfigExtensions>
<DownloadRetryInterval>3600</DownloadRetryInterval>
<DownloadModificationInterval>28800</DownloadModificationInterval>
<VirtualAppsEnabled>FALSE</VirtualAppsEnabled>
</SWD_ClientConfigExtensions>";

The MOF file I used is described below:

#pragma namespace("\\\\.\\root\\ccm\\policy\\machine\\requestedconfig") //defines the namespace to which the MOF file amends
[CCM_Policy_PartialPolicy(true)]  //allows the local policy to be incomplete and to be merged with the policy received from the Management Point. Any settings not specified below but received from the management point will still be evaluated for actual policy
instance of CCM_SoftwareDistributionClientConfig //identifies the instance to which the settings apply
{
    // Header properties - The header is used to identify the local policy and is necessary in order to apply it to a machine
        PolicyID = "RYAPPVDISABLE"; //also used for identification and removal purposes. Must be unique
        PolicySource = "local"; //identifies the policy as local. must be set in order for policy to override that from the MP
        PolicyVersion = "1";
        PolicyRuleID = "1";
        PolicyInstanceID = "1";
    SiteSettingsKey = 1;
    [ccm_policy_override(TRUE)] //Sets the Local Policy to override Site Policy (Default behaviour)

//the setting we wish to override. a value of false prevents ConfigMgr from "owning" the app-v client if installed on the machine

Reserved1 = "<?xml version='1.0' ?>
<SWD_ClientConfigExtensions>
<DownloadRetryInterval>3600</DownloadRetryInterval>
<DownloadModificationInterval>28800</DownloadModificationInterval>
<VirtualAppsEnabled>FALSE</VirtualAppsEnabled>
</SWD_ClientConfigExtensions>";
};

Secondly, and in order to control the integration, we need to identify the machines on which App-V integration is to be disabled. In my opinion (bearing in mind I am a ConfigMgr engineer) the most convenient method is to use a query based collection in ConfigMgr to contain all clients with the App-V Client installed. Once you have done this; you can apply the local policy. Again, being a ConfigMgr engineer, my delivery method of choice is naturally ConfigMgr Software Distribution. But this could equally be Group Policy or even manually at each client.

Whatever method you choose; there are the two steps to applying the local policy. The first is to apply the MOF file to WMI using MOFCOMP.exe; a compiler that parses a file containing MOF statements and adds the classes and class instances defined in the file to the WMI repository and will be present on any WMI enabled machine.

To execute MOFCOMP call it from the command line with the parameter of the MOF file above:

MOFCOMP.EXE <path_to_file>\<mof_file.mof>

The second step is to force the client to evaluate its machine policy. This can be done is a number of different ways. From the Client Applet in Control Panel, From Policy Spy or from the command line (perhaps the topic for another, shorter, blog entry).

Once the MOF file has been parsed you should see the following entry in RequestedConfig:

clip_image004

Now when you check the "Allow virtual application package advertisement" check box on the "Advertised Programs Client Agent" in the ConfigMgr Console and the client downloads and evaluates the updated policy, App-V integration will remain disabled wherever this policy has been applied.

If, at any point you wish to return the client to the setting from the site policy, you can simply disable the entry in RequestedConfig created by the MOF file and re-evaluate the policy. Again, this can be scripted. The necessary code snippet is below:

   Set ObjSvc = GetObject("WinMgmts:root\ccm\policy\machine\requestedconfig")
   Set objSet = objSvc.ExecQuery("Select * from CCM_SoftwareDistributionClientConfig where PolicyID = 'RYAPPVDISABLE'")
   If objSet.count <> 0 Then
   For Each obj in objSet
   obj.Delete_
   Next
   Else
   End If

By specifying a PolicyID within the local policy MOF file; we can identify the item of policy we wish to remove. Once the local policy has been removed the site policy settings will take effect.

Thanks to Andy from Premier support for a few bits!

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

This post was contributed by Rob York, a Premier Field Engineer with Microsoft Premier Field Engineering, UK.

Comments