Tag Archives: AppVFAQ

App-V FAQ: What are Providers Policies?

This is a guest post from Jurjen van Leeuwen, an App-V MVP (new for 2011) and independent consultant based in Norway. You can read more from Jurjen at his web site.

Provider Policies are ‘rules’ that apply when users launch virtual applications from a Microsoft App-V Management Server using RTSP(s). Other App-V infrastructure scenarios or the use of the HTTP(s) protocol don’t support the use of Provider Policies.

The ‘rules’ allow App-V administrators to control the following settings:

  • Server access – The Active Directory group that can connect to the server through the Provider Policy.
  • Authentication – If authentication is required to connect to the server or the use of applications.
  • Logging – Record application usage data in the App-V data store.
  • Licensing – Whether or not to audit or enforce application licenses.
  • Client refresh behaviour – At which interval and events the client checks with the server for application changes. For example new applications and shortcuts, removed or disabled applications. At a refresh, the client will also communicate the application usage logging with the server if configured.

Why would I use them?

Besides the Provider Policy created by the installation process of the App-V Management Server, called the Default Provider, you would basically need multiple Provider Policies if you require maintaining different configurations of the settings mentioned in the previous paragraph. For example different Provider Policies are required for auditing AND enforcing licensing: If you have one or more applications where you want to enforce licensing and monitor license usage for some other applications you will need two different Provider Policies. Another example would be a separate Provider Policy which doesn’t require authentication for specific applications for contractors.

How do I use them?

Only the App-V Management Server offers the use of Provider Policies which itself requires Active Directory and Microsoft SQL to hold the App-V data store.

When installing the App-V Management Server one Provider Policy is created by default, called Default Provider. This Provider Policy is tied to the default created server group which is named Default Server Group, if no other name was specified during the App-V Management Server setup.

To create a new Provider Policy right click the Provider Policies node in the App-V Management Console and choose: New Provider Policy. The Properties screen allows for naming the new Provider Policy and the configuration of the client refresh behaviour. The minimum interval for a scheduled refresh is 30 minutes.


In the Group Assignment screen select the Active Directory groups that have access to the App-V server through this Provider Policy. A minimum of one group is required. The user has to be a member of this group when the Authentication checkbox is set on the Provider Pipeline screen.


The Provider Pipeline screen allows the following options to be set:


Authentication: This checkbox forces authentication in the session. If the App-V client can’t use the current user’s credentials, a login box is shown to the user to provide them. Disabling this checkbox allows any user to launch applications from the App-V server through this Provider Policy. The Authentication dropdown box only has one option: Windows Authentication.

With the Enforce Access Permission Settings checkbox enabled the user can only launch an application if he is a member of an Active Directory group specified on the Access Permissions tab under the Properties of an Application.

Log Usage Information: With this checkbox selected, application usage data is stored in the App-V data store. This allows administrators to generate a basic report from the Management Console or extract this information by other means.

Licensing: When enabled this setting allows for monitoring (auditing) or enforcing application licenses. Auditing still allows the use of applications even when the license count would exceed. Licenses are created in the Application Licenses node of the Management Console and an application is assigned to a license.

After creating the Provider Policy, the Provider Pipeline tab under Properties shows an Advanced button. Under this button the corresponding modules (.dll files) to the checkboxes are shown.

There are two ways to control which Provider Policy applies in a session between the client and the server:

1. The default Provider Policy configured for the Server Group: On the General tab of the Server Group properties specify the default Provider Policy to use:


In this case the Provider Policy applies when users connect to a server from this Server Group.

2. With the Policy specified in the Application’s OSD file: In the CODEBASE tag add the Provider Policy to the HREF value by appending .SFT file name with the following text: ?Customer=ProviderPolicyName. For example:


Any Provider Policy specifically assigned in an OSD file will overrule the Provider Policy configured at on the Server Group.

Additional Resources

For more information on streaming, publishing and client configuration when using HTTP take a look at these links:

App-V FAQ: Can I virtualize the .NET Framework or Visual C++ Redistributables?

This is a guest post from Nicke Källén, an App-V MVP from Sweden. He posts as Znack on the TechNet Forums, and you can read more articles from Nicke at his blog here.

The .NET Framework and Visual C++ Redistributables are components or application dependencies that have started to be considered as operating system components and the question of whether to include the .NET Framework and/or the Visual C++ Redistributables has been revisited quite a few times by Microsoft.

Since the release of App-V 4.5 it has been recommended that all versions of the .NET Framework are installed natively, however since the release of App-V 4.5 Cumulative Update 1 this was subsequently revised for Windows XP and this allowed versions earlier than the .NET Framework 3.5 Service Pack 1 to be part the package.

As a good practice any sequencing machine should be setup in a similar way as the client and therefore its key to synchronize the levels of the .NET Framework and Visual C++ Redistributables on both the sequencer and client computers. Visual C++ Redistributable are prerequisites for both the client and the Sequencer, however the current level is different depending on which version you are installing.

Microsoft have not explicitly stated that it is not possible to include the Visual C++ Redistributables within a virtualized application; however an older Knowledgebase article (939084) states that they should be available locally on a client computer.

As illustrated on the official .NET Framework support statement, the .NET Frameworks are included in all newer operating systems (Windows 7 includes .NET Framework 3.5 Service Pack 1 and below). Windows XP Service Pack 2 (and thereby we can also presume Windows Server 2003) is the only platform that would successfully execute a virtualized package containing .NET Framework while not having it available natively. The Application Virtualization 4.5 Cumulative Update 1 client would allow this due to a new mini-filter driver introduced in the update.

Regardless of whether it is possible to virtualize certain versions of .NET Framework on older platforms – it seems to be an more scalable and future-proof strategy to ensure that .NET Framework and Visual C++ Redistributables are available on any target machines for any virtualized application to use.

Normally the following can be recommended to be setup both on the sequencer and the client; (32-bit versions only linked below. 64-bit versions in case of availability are recommended also in case of having a 64-bit target environment)

Visual C++ 2005 SP1

Visual C++ 2008 SP1

Visual C++ 2010

.NET Framework 1.1 / 2.0 / 3.0 / 3.5 / 4.0

The Application Virtualization Client requires Visual C++ 2005 SP1 along with the ATL security update and the Visual C++ 2008 SP1 along with its ATL security update; however the Sequencer only installs Visual C++ 2005 SP1 along with its ATL security update.  This of course requires the manual tasks of assuring that both are aligned on the same level in prerequisites.

Reading section 3.2 from the 4.6 sequencing whitepaper gives some specific examples how to resolve possible SxS issues when sequencing on a 64-bit sequencer – something which can be avoided if being prepared and already natively offering both 32-bit and 64-bit redistributables on both sequencer and client machine.

Not documented anywhere and purely untested, normally these following redistributables can also be recommended in maintaining natively;

Visual J#

Visual Studio 2010 F# Runtime 2.0

Further reading and resources