Udostępnij za pośrednictwem

About App-V dynamic configuration

  • Artykuł

Applies to:

  • Windows 10
  • Windows 11

You can use dynamic configuration to customize an App-V package for a user. This article will tell you how to create or edit an existing dynamic configuration file.

When you edit the Dynamic Configuration file, it customizes how an App-V package will run for a user or group. Therefore, package customization is made more convenient by removing the need to resequence packages using the desired settings and provides a way to keep package content and custom settings independent.

Advanced: dynamic configuration

Virtual application packages contain a manifest that provides all the core information for the package. This information includes the defaults for the package settings and determines settings in the most basic form (with no further customization). If you want to adjust these defaults for a particular user or group, you can create and edit the following files:

  • User Configuration file
  • Deployment Configuration file

These .xml files specify package settings let you customize packages without directly affecting the packages. When a package is created, the sequencer automatically generates default deployment and user configuration .xml files using the package manifest data. These automatically generated configuration files reflect the package's default settings that were configured during sequencing. If you apply these configuration files to a package in the form generated by the sequencer, the packages will have the same default settings that came from their manifest. This result provides you with a package-specific template to get started if any of the defaults must be changed.

Note

The following information can only be used to modify sequencer generated configuration files to customize packages to meet specific user or group requirements.

Dynamic Configuration file contents

All of the additions, deletions, and updates in the configuration files need to be made in relation to the default values specified by the package's manifest information. The following list represents the relationship between these files in how they'll be read, from most to least precedence:

  • User Configuration .xml file
  • Deployment Configuration .xml file
  • Package Manifest

The first item represents what will be read last. Therefore, its content takes precedence. All packages inherently contain and provide default settings from the Package Manifest, but it also has the least precedence. If you apply a Deployment Configuration .xml file with customized settings, it will override the Package Manifest's defaults. If you apply a User Configuration .xml file with customized settings prior to the override of the Package Manifest's defaults, it will override both the deployment configuration and the Package Manifest's defaults.

There are two types of configuration files:

  • User Configuration file (UserConfig): Allows you to specify or modify custom settings for a package. These settings will be applied for a specific user when the package is deployed to a computer running the App-V client.
  • Deployment Configuration file (DeploymentConfig): Allows you to specify or modify the default settings for a package. These settings will be applied for all users when a package is deployed to a computer running the App-V client.

You can use the UserConfig file to customize the settings for a package for a specific set of users on a computer or make changes that will be applied to local user locations such as HKCU. You can use the DeploymentConfig file to modify the default settings of a package for all users on a machine or make changes that will be applied to global locations such as HKEY_LOCAL_MACHINE and the All Users folder.

The UserConfig file provides configuration settings that you can apply to a single user without affecting any other users on a client:

  • Extensions that will be integrated into the native system per user: shortcuts, File-Type associations, URL Protocols, AppPaths, Software Clients, and COM.
  • Virtual Subsystems: Application Objects, Environment variables, Registry modifications, Services, and Fonts.
  • Scripts (user context only).

The DeploymentConfig file provides configuration settings in two sections, one relative to the machine context and one relative to the user context providing the same capabilities listed in the preceding UserConfig list:

  • All UserConfig settings from the preceding section in this topic
  • Extensions that can only be applied globally for all users
  • Virtual Subsystems that can be configured for global machine locations, such as the registry
  • Product Source URL
  • Scripts (Machine context only)
  • Controls to terminate child processes

File structure

The structure of the App-V Dynamic Configuration file is explained in the following section.

Dynamic User Configuration file

An example of a Dynamic User Configuration file's header is:

<?xml version="1.0" encoding="utf-8"?>
<UserConfiguration PackageId="1f8488bf-2257-46b4-b27f-09c9dbaae707" DisplayName="Reserved" xmlns="http://schemas.microsoft.com/appv/2010/userconfiguration">

The PackageId is the same value that exists in the Manifest file.

Dynamic User Configuration file body

The Dynamic User Configuration file's body can include all app extension points defined in the Manifest file, and the information to configure virtual applications. There are four subsections allowed in the body:

Applications: All app-extensions contained in the Manifest file within a package are assigned with an Application ID, which is also defined in the manifest file. This allows you to enable or disable all the extensions for a given application within a package. The Application ID must exist in the Manifest file or it will be ignored.

    <UserConfiguration PackageId="1f8488bf-2257-46b4-b27f-09c9dbaae707" DisplayName="Reserved" xmlns="http://schemas.microsoft.com/appv/2010/userconfiguration">
    <Applications>
    <!-- No new application can be defined in policy. AppV Client will ignore any application ID that is not also in the Manifest file -->
    <Application Id="{a56fa627-c35f-4a01-9e79-7d36aed8225a}" Enabled="false">
    </Application>
    </Applications>
    …
    </UserConfiguration>

Subsystems: AppExtensions and other subsystems are arranged as subnodes under <Subsystems>, as shown in the following example.

    <UserConfiguration **PackageId**="1f8488bf-2257-46b4-b27f-09c9dbaae707" DisplayName="Reserved" xmlns="http://schemas.microsoft.com/appv/2010/userconfiguration">
    <Subsystems>
    ..
    </Subsystems>
    ..
    </UserConfiguration>

Each subsystem can be enabled/disabled using the Enabled attribute. The following sections describe the various subsystems and usage samples.

Dynamic User Configuration file extensions

Extension Subsystems control extensions. These subsystems are Shortcuts, File-Type associations, URL Protocols, AppPaths, Software Clients, and COM.

Extension Subsystems can be enabled and disabled independently of the content.  Therefore, if Shortcuts are enabled, the client will use the shortcuts contained within the manifest by default. Each Extension Subsystem can contain an <Extensions> node. If this child element is present, the client will ignore the content in the Manifest file for that subsystem and only use the content in the configuration file.

Examples of the shortcuts subsystem

Example 1

Content will be ignored if the user defined the following syntaxes in either the dynamic or deployment config file:

                                     <Shortcuts  Enabled="true">
                                                 <Extensions
                                                  ...
                                                 </Extensions>
                                     </Shortcuts>

Example 2

Content in the manifest will be integrated during publishing if the user defined only the following syntax:


                                    `<Shortcuts  Enabled="true"/>`

Example 3

All shortcuts in the manifest will be ignored and no shortcuts will be integrated if the user defines the following syntaxes:

                           <Shortcuts  Enabled="true">
                                                 <Extensions/>
                                     </Shortcuts>

Supported Extension Subsystems

Shortcuts: This subsystem controls shortcuts that will be integrated into the local system. The following example has two shortcuts:

    <Subsystems>
    <Shortcuts Enabled="true">
      <Extensions>
        <Extension Category="AppV.Shortcut">
          <Shortcut>
            <File>\[{Common Programs}\]\\Microsoft Contoso\\Microsoft ContosoApp Filler 2010.lnk</File>
            <Target>\[{PackageRoot}\]\\Contoso\\ContosoApp.EXE</Target>
            <Icon>\[{Windows}\]\\Installer\\{90140000-0011-0000-0000-0000000FF1CE}\\inficon.exe</Icon>
            <Arguments />
            <WorkingDirectory />
            <AppUserModelId>ContosoApp.Filler.3</AppUserModelId>
            <Description>Fill out dynamic forms to gather and reuse information throughout the organization using Microsoft ContosoApp.</Description>
            <Hotkey>0</Hotkey>
            <ShowCommand>1</ShowCommand>
            <ApplicationId>\[{PackageRoot}\]\\Contoso\\ContosoApp.EXE</ApplicationId>
          </Shortcut>
      </Extension>
      <Extension Category="AppV.Shortcut">
        <Shortcut>
          <File>\[{AppData}\]\\Microsoft\\Contoso\\Recent\\Templates.LNK</File>
          <Target>\[{AppData}\]\\Microsoft\\Templates</Target>
          <Icon />
          <Arguments />
          <WorkingDirectory />
          <AppUserModelId />
          <Description />
          <Hotkey>0</Hotkey>
          <ShowCommand>1</ShowCommand>
          <!-- Note the ApplicationId is optional -->
        </Shortcut>
      </Extension>
     </Extensions>
    </Shortcuts>

File Type Associations: Associates file types with programs to open by default and to set up the context menu. (MIME types can also be set up with this subsystem.) An example of a FileType association is:

    <FileTypeAssociations Enabled="true">
    <Extensions>
      <Extension Category="AppV.FileTypeAssociation">
        <FileTypeAssociation>
          <FileExtension MimeAssociation="true">
          <Name>.docm</Name>
          <ProgId>contosowordpad.DocumentMacroEnabled.12</ProgId>
          <PerceivedType>document</PerceivedType>
          <ContentType>application/vnd.ms-contosowordpad.document.macroEnabled.12</ContentType>
          <OpenWithList>
            <ApplicationName>wincontosowordpad.exe</ApplicationName>
          </OpenWithList>
         <OpenWithProgIds>
            <ProgId>contosowordpad.8</ProgId>
          </OpenWithProgIds>
          <ShellNew>
            <Command />
            <DataBinary />
            <DataText />
            <FileName />
            <NullFile>true</NullFile>
            <ItemName />
            <IconPath />
            <MenuText />
            <Handler />
          </ShellNew>
        </FileExtension>
        <ProgId>
           <Name>contosowordpad.DocumentMacroEnabled.12</Name>
            <DefaultIcon>\[{Windows}\]\\Installer\\{90140000-0011-0000-0000-0000000FF1CE}\\contosowordpadicon.exe,15</DefaultIcon>
            <Description>Blah Blah Blah</Description>
            <FriendlyTypeName>\[{FOLDERID\_ProgramFilesX86}\]\\Microsoft Contoso 14\\res.dll,9182</FriendlyTypeName>
            <InfoTip>\[{FOLDERID\_ProgramFilesX86}\]\\Microsoft Contoso 14\\res.dll,1424</InfoTip>
            <EditFlags>0</EditFlags>
            <ShellCommands>
              <DefaultCommand>Open</DefaultCommand>
              <ShellCommand>
                 <ApplicationId>{e56fa627-c35f-4a01-9e79-7d36aed8225a}</ApplicationId>
                 <Name>Edit</Name>
                 <FriendlyName>&Edit</FriendlyName>
                 <CommandLine>"\[{PackageRoot}\]\\Contoso\\WINcontosowordpad.EXE" /vu "%1"</CommandLine>
              </ShellCommand>
              </ShellCommand>
                <ApplicationId>{e56fa627-c35f-4a01-9e79-7d36aed8225a}</ApplicationId>
                <Name>Open</Name>
                <FriendlyName>&Open</FriendlyName>
                <CommandLine>"\[{PackageRoot}\]\\Contoso\\WINcontosowordpad.EXE" /n "%1"</CommandLine>
                <DropTargetClassId />
                <DdeExec>
                  <Application>mscontosowordpad</Application>
                  <Topic>ShellSystem</Topic>
                  <IfExec>\[SHELLNOOP\]</IfExec>
                  <DdeCommand>\[SetForeground\]\[ShellNewDatabase "%1"\]</DdeCommand>
                </DdeExec>
              </ShellCommand>
            </ShellCommands>
          </ProgId>
         </FileTypeAssociation>
       </Extension>
      </Extensions>
      </FileTypeAssociations>

URL Protocols: This subsystem controls the URL Protocols integrated into the local registry of the client machine. The following example illustrates the “mailto:” protocol.

    <URLProtocols Enabled="true">
    <Extensions>
    <Extension Category="AppV.URLProtocol">
    <URLProtocol>
      <Name>mailto</Name>
      <ApplicationURLProtocol>
      <DefaultIcon>\[{ProgramFilesX86}\]\\Microsoft Contoso\\Contoso\\contosomail.EXE,-9403</DefaultIcon>
      <EditFlags>2</EditFlags>
      <Description />
      <AppUserModelId />
      <FriendlyTypeName />
      <InfoTip />
    <SourceFilter />
      <ShellFolder />
      <WebNavigableCLSID />
      <ExplorerFlags>2</ExplorerFlags>
      <CLSID />
      <ShellCommands>
      <DefaultCommand>open</DefaultCommand>
      <ShellCommand>
      <ApplicationId>\[{ProgramFilesX86}\]\\Microsoft Contoso\\Contoso\\contosomail.EXE</ApplicationId>
      <Name>open</Name>
      <CommandLine>\[{ProgramFilesX86}\\Microsoft Contoso\\Contoso\\contosomail.EXE" -c OEP.Note /m "%1"</CommandLine>
      <DropTargetClassId />
      <FriendlyName />
      <Extended>0</Extended>
      <LegacyDisable>0</LegacyDisable>
      <SuppressionPolicy>2</SuppressionPolicy>
       <DdeExec>
      <NoActivateHandler />
      <Application>contosomail</Application>
      <Topic>ShellSystem</Topic>
      <IfExec>\[SHELLNOOP\]</IfExec>
      <DdeCommand>\[SetForeground\]\[ShellNewDatabase "%1"\]</DdeCommand>
      </DdeExec>
      </ShellCommand>
      </ShellCommands>
      </ApplicationURLProtocol>
      </URLProtocol>
      </Extension>
      </Extension>
      </URLProtocols>

Software Clients: Allows the app to register as an email client, news reader, or media player and makes the app visible in the Set Program Access and Computer Defaults UI. In most cases, you only need to enable and disable it. There's also a control that lets you enable or disable the email client only in case you want all the other clients to remain as they are.

    <SoftwareClients Enabled="true">
      <ClientConfiguration EmailEnabled="false" />
    </SoftwareClients>

AppPaths: If an application, such as contoso.exe, is registered with an apppath name of “myapp”, this subsystem lets you open the app by entering “myapp” into the run menu.

    <AppPaths Enabled="true">
    <Extensions>
    <Extension Category="AppV.AppPath">
    <AppPath>
      <ApplicationId>\[{ProgramFilesX86}\]\\Microsoft Contoso\\Contoso\\contosomail.EXE</ApplicationId>
      <Name>contosomail.exe</Name>
      <ApplicationPath>\[{ProgramFilesX86}\]\\Microsoft Contoso\\Contoso\\contosomail.EXE</ApplicationPath>
      <PATHEnvironmentVariablePrefix />
      <CanAcceptUrl>false</CanAcceptUrl>
      <SaveUrl />
    </AppPath>
    </Extension>
    </Extensions>
    </AppPaths>

COM: Allows an Application to register Local COM servers. Mode can be Integration, Isolated or Off. When Isol.

    <COM Mode="Isolated"/>

Other settings for Dynamic User Configuration file

In addition to Extensions, the following other subsystems can be enabled/disabled and edited.

Virtual Kernel Objects

    <Objects Enabled="false" />
```xml

**Virtual Registry**: use this if you want to set a registry in the Virtual Registry within HKCU.

```xml
    <Registry Enabled="true">
    <Include>
    <Key Path="\\REGISTRY\\USER\\\[{AppVCurrentUserSID}\]\\Software\\ABC">
    <Value Type="REG\_SZ" Name="Bar" Data="NewValue" />
     </Key>
      <Key Path="\\REGISTRY\\USER\\\[{AppVCurrentUserSID}\]\\Software\\EmptyKey" />
     </Include>
    <Delete>
      </Registry>

Virtual File System

          <FileSystem Enabled="true" />

Virtual Fonts

          <Fonts Enabled="false" />

Virtual Environment Variables

    <EnvironmentVariables Enabled="true">
    <Include>
           <Variable Name="UserPath" Value="%path%;%UserProfile%" />
           <Variable Name="UserLib" Value="%UserProfile%\\ABC" />
           </Include>
          <Delete>
           <Variable Name="lib" />
            </Delete>
            </EnvironmentVariables>

Virtual services

          <Services Enabled="false" />

UserScripts

Scripts can be used to set up or alter the virtual environment and execute scripts on deployment or removal, before an application executes, or they can clean up the environment after the application terminates. Refer to a sample User Configuration file output by the sequencer to see a sample script. For more information about the various triggers you can use to set up scripts, see the Scripts section.

Dynamic Deployment Configuration file

Dynamic Deployment Configuration file header

The header of a Deployment Configuration file should look something like this:

<?xml version="1.0" encoding="utf-8"?><DeploymentConfiguration PackageId="1f8488bf-2257-46b4-b27f-09c9dbaae707" DisplayName="Reserved" xmlns="http://schemas.microsoft.com/appv/2010/deploymentconfiguration">

The PackageId is the same value as the one that exists in the Manifest file.

Dynamic Deployment Configuration file body

The body of the deployment configuration file includes two sections:

  • The User Configuration section allows the same content as the User Configuration file described in the previous section. When the package is published to a user, any appextensions configuration settings in this section will override corresponding settings in the Manifest within the package unless a user configuration file is also provided. If a UserConfig file is also provided, it will be used instead of the User settings in the deployment configuration file. If the package is published globally, then only the contents of the deployment configuration file will be used in combination with the manifest.
  • The Machine Configuration section contains information that can only be configured for an entire machine, not for a specific user on the machine. For example, HKEY_LOCAL_MACHINE registry keys in the VFS.
<DeploymentConfiguration PackageId="1f8488bf-2257-46b4-b27f-09c9dbaae707" DisplayName="Reserved" xmlns="http://schemas.microsoft.com/appv/2010/deploymentconfiguration">
<UserConfiguration>
..
</UserConfiguration>
<MachineConfiguration>
..
</MachineConfiguration>
..
</MachineConfiguration>
</DeploymentConfiguration>

User Configuration: For more information about this section, see Dynamic User Configuration.

Machine Configuration: The Machine Configuration section of the Deployment Configuration File configures information that can only be set for an entire machine, not a specific user on the computer, like the HKEY_LOCAL_MACHINE registry keys in the Virtual Registry. This element can have the following four subsections.

Subsystems

AppExtensions and other subsystems are arranged as subnodes under <Subsystems>:

    <MachineConfiguration>
      <Subsystems>
      ..
      </Subsystems>
    ..
    </MachineConfiguration>

The following section describes the various subsystems and usage samples.

Extensions

Some subsystems (Extension Subsystems) control extensions that can only apply to all users. The subsystem is application capabilities. Because this subsystem can only apply to all users, the package must be published globally in order for this type of extension to be integrated into the local system. The rules for User Configuration extension controls and settings also apply to the ones in Machine Configuration.

Application Capabilities

Application Capabilities extension is used by default programs in the Windows OS interface; it allows an application to register itself as capable of opening certain file extensions, as a contender for the Start menu's internet browser slot, and as capable of opening certain Windows MIME types. This extension also makes the virtual application visible in the Set Default Programs UI.

    <ApplicationCapabilities Enabled="true">
      <Extensions>
       <Extension Category="AppV.ApplicationCapabilities">
        <ApplicationCapabilities>
         <ApplicationId>\[{PackageRoot}\]\\LitView\\LitViewBrowser.exe</ApplicationId>
         <Reference>
          <Name>LitView Browser</Name>
          <Path>SOFTWARE\\LitView\\Browser\\Capabilities</Path>
         </Reference>
       <CapabilityGroup>
        <Capabilities>
         <Name>@\[{ProgramFilesX86}\]\\LitView\\LitViewBrowser.exe,-12345</Name>
         <Description>@\[{ProgramFilesX86}\]\\LitView\\LitViewBrowser.exe,-12346</Description>
         <Hidden>0</Hidden>
         <EMailSoftwareClient>Lit View E-Mail Client</EMailSoftwareClient>
         <FileAssociationList>
          <FileAssociation Extension=".htm" ProgID="LitViewHTML" />
          <FileAssociation Extension=".html" ProgID="LitViewHTML" />
          <FileAssociation Extension=".shtml" ProgID="LitViewHTML" />
         </FileAssociationList>
         <MIMEAssociationList>
          <MIMEAssociation Type="audio/mp3" ProgID="LitViewHTML" />
          <MIMEAssociation Type="audio/mpeg" ProgID="LitViewHTML" />
         </MIMEAssociationList>
        <URLAssociationList>
          <URLAssociation Scheme="http" ProgID="LitViewHTML.URL.http" />
         </URLAssociationList>
         </Capabilities>
      </CapabilityGroup>
       </ApplicationCapabilities>
      </Extension>
    </Extensions>
    </ApplicationCapabilities>

Other settings for Dynamic Deployment Configuration file

You can edit other subsystems in addition to extensions:

  • Machine-wide Virtual Registry: Use this subsystem when you want to set a registry key in the virtual registry within HKEY_Local_Machine.
    <Registry>
    <Include>
      <Key Path="\\REGISTRY\\Machine\\Software\\ABC">
        <Value Type="REG\_SZ" Name="Bar" Data="Baz" />
       </Key>
      <Key Path="\\REGISTRY\\Machine\\Software\\EmptyKey" />
     </Include>
    <Delete>
    </Registry>
  • Machine-wide Virtual Kernel Objects
    <Objects>
    <NotIsolate>
       <Object Name="testObject" />
     </NotIsolate>
    </Objects>
  • ProductSourceURLOptOut: Indicates whether the URL for the package can be modified globally through PackageSourceRoot to support branch office scenarios. It's set to False by default. Changes to the value take effect on the next launch.
    <MachineConfiguration>
      ..
      <ProductSourceURLOptOut Enabled="true" />
      ..
    </MachineConfiguration>

  • MachineScripts: The package can be configured to execute scripts upon deployment, publishing, or removal. To see an example script, see a sample deployment configuration file generated by the sequencer. The following section provides more information about the various triggers you can use to set up scripts.

  • TerminateChildProcess: You can use this subsystem to specify that an application executable's child processes will be terminated when the application.exe process is terminated.

    <MachineConfiguration>
      ..
      <TerminateChildProcesses>
        <Application Path="\[{PackageRoot}\]\\Contoso\\ContosoApp.EXE" />
        <Application Path="\[{PackageRoot}\]\\LitView\\LitViewBrowser.exe" />
        <Application Path="\[{ProgramFilesX86}\]\\Microsoft Contoso\\Contoso\\contosomail.EXE" />
      </TerminateChildProcesses>
      ..
    </MachineConfiguration>

Scripts

The following table describes the various script events and the context under which they can be run.

Script execution time Can be specified in Deployment Configuration Can be specified in User Configuration Can run in the package's virtual environment Can be run in the context of a specific application Runs in system/user context: (Deployment Configuration, User Configuration)
AddPackage X (SYSTEM, N/A)
PublishPackage X X (SYSTEM, User)
UnpublishPackage X X (SYSTEM, User)
RemovePackage X (SYSTEM, N/A)
StartProcess X X X X (User, User)
ExitProcess X X X (User, User)
StartVirtualEnvironment X X X (User, User)
TerminateVirtualEnvironment X X (User, User)

Using multiple scripts on a single event trigger

App-V supports the use of multiple scripts on a single event trigger for App-V packages, including packages that you convert from App-V 4.6 to App-V for Windows client. To enable the use of multiple scripts, App-V uses a script launcher application, named ScriptRunner.exe, which is included in the App-V client.

How to use multiple scripts on a single event trigger

For each script that you want to run, pass that script as an argument to the ScriptRunner.exe application. The application will run each script separately, along with the arguments that you specify for each script. Use only one script (ScriptRunner.exe) per trigger.

Note

We recommended you first run the multi-script line from a command prompt to make sure all arguments are built correctly before adding them to the deployment configuration file.

Example script and parameter descriptions

Using the following example file and table, modify the deployment or user configuration file to add the scripts that you want to run.

<MachineScripts>
 <AddPackage>
   <Path>ScriptRunner.exe</Path>
   <Arguments>
   -appvscript script1.exe arg1 arg2 –appvscriptrunnerparameters –wait –timeout=10
   -appvscript script2.vbs arg1 arg2
   -appvscript script3.bat arg1 arg2 –appvscriptrunnerparameters –wait –timeout=30 –rollbackonerror
   </Arguments>
   <Wait timeout=”40” RollbackOnError=”true”/>
 </AddPackage>
</MachineScripts>
Parameter in the example file Description
<AddPackage> Name of the event trigger you're running a script for, such as when adding or publishing a package.
ScriptRunner.exe The script launcher application included in the App-V client.

Although ScriptRunner.exe is included in the App-V client, the App-V client's location must be in %path% or ScriptRunner won't run. ScriptRunner.exe is typically located in the C:\Program Files\Microsoft Application Virtualization\Client folder.
-appvscript script1.exe arg1 arg2 –appvscriptrunnerparameters –wait –timeout=10

-appvscript script2.vbs arg1 arg2

-appvscript script3.bat arg1 arg2 –appvscriptrunnerparameters –wait –timeout=30 -rollbackonerror		 -appvscript—token that represents the actual script you want to run.
script1.exe—name of the script you want to run.
arg1 arg2—arguments for the script you want to run.
-appvscriptrunnerparameters—token that represents the execution options for script1.exe.
-wait—token that tells ScriptRunner to wait for execution of script1.exe to finish before proceeding to the next script.
-timeout=x—token that informs ScriptRunner to stop running the current script after x number of seconds. All other specified scripts will still run.
-rollbackonerror—token that tells ScriptRunner to stop running all scripts that haven't yet run and roll back an error to the App-V client.
<Wait timeout=”40” RollbackOnError=”true”/> Waits for overall completion of ScriptRunner.exe.

Set the timeout value for the overall runner to be greater than or equal to the sum of the timeout values on the individual scripts.

If any individual script reported an error and rollbackonerror was set to True, then ScriptRunner should report the error to App-V client.

ScriptRunner will run any script whose file type is associated with an application installed on the computer. If the associated application is missing, or the script’s file type isn't associated with any of the computer's applications, the script won't run.

Create a Dynamic Configuration file using an App-V Manifest file

You can create the Dynamic Configuration file using one of three methods: manually, using the App-V Management Console, or by sequencing a package, which will generate a package with two sample files.

For more information about how to create the file using the App-V Management Console, see How to create a Custom Configuration file by using the App-V Management Console.

To create the file manually, you can combine the components listed in the previous sections into a single file. However, we recommend you use files generated by the sequencer instead of manually created ones.