AppV Client Logging

The App-V client logs information to both the Windows Event log and to a local log file.   Both of these logging options can be adjusted to change the type of information that is captured.   The local file based log can only be accessed by a local administrator of the machine or the SYSTEM account on the machine.

File Log

The local cache is located in profiles \All Users(Public on Vista)\Application Data\Microsoft\Application Virtualization Client\sftlog.txt.  The settings for this file can be modified using the registry at the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Configuration

Value	Default	Description
LogFileName	CSIDL_COMMON_APPDATA\Microsoft\Application Virtualization Client\	Client log file. Can be modified to change the log file location. You must restart the sftlist service after changing this value.
LogMinSeverity	4, Informational	Controls which messages are written to the log.  The value indicates a threshold of what is logged – everything at and below that value is logged. For example, a value of 0x3 (Warning) indicates that Warnings (0x3), Errors (0x2), and Critical Errors (0x1) are logged. Value Range: 0x0 == None, 0x1 == Critical, 0x2 == Error, 0x3 == Warning, 0x4 == Information (Default), 0x5 == Verbose
LogRolloverCount	4	Defines the number of backup copies that are kept of the log file, sftlog.txt when it is reset.  The valid range is 0-9999.  The default is 4.  A value of 0 means no copies will be kept.
LogMaxSize	256	Defines the size in megabytes that the log file can reach before being reset.  The default size is 256 MB.  When this size is reached, a log reset will be forced on the next write attempt.

System Event Log Level

The system event logging level can be configured using the App-V Client Management Console by right clicking the root node and going to properties.

Managing the event logging that will be recorded can also be modified by using the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\Client\CurrentVersion\Configuration\

This registry value indicates the logging level at which App-V log messages will get written to the NT event log. The value indicates a threshold of what is logged – everything at and below that value is logged. For example, a value of 0x3 (Warning) indicates that Warnings (0x3), Errors (0x2), and Critical Errors (0x1) are logged.

Value	Default	Recommend Management Server Configuration
SystemEventLogLevel	4 (Information)	·         0 == None ·         1 == Critical ·         2 == Error ·         3 == Warning ·         4 == Information ·         5 == Verbose

AppV Per-Package File System Container Volumes

The per-package file system container volumes store changes that are made to packages made by users or system processes.  These changes allow for users and the machine to make setting and configuration changes to the base package, without affecting it.  These changes are stored in several PKG files that are described below.  The files are individual for each package and stored in unique directories that are created by combining the Package Root directory name where the package was installed on the sequencer and the first portion of the package GUID.  An example for Microsoft Office 2007 where the Package Root is OFF2K7.V1 and the package GUID for office is 5C99B562-F61F-4009-AB16-B38E16093AE4 the resulting directory would be OFF2K7.V1-5C99B562-F61F-4009.  Two directories for each package will be created, one for the user’s profile and one for the machine at the following locations:

Windows XP

·         Per-user at:  %USERPROFILE%\Application Data\SoftGrid Client

·         Per-machine at:  All Users\Documents\SoftGrid Client\AppFS Storage

Windows Vista

·         Per-user at: %USERPROFILE%\AppData\Roaming\SoftGrid Client\ and %userprofile%\AppData\Local\SoftGrid Client\

·         Per-machine at:  Public\Documents\SoftGrid Client\AppFS Storage

NOTE:  Due to changes in profiles in Windows Vista a third directory is created for the temporary version of the PKG file while the application is in use.

The following description of the files describes how data is populated into these files and will be covered in further detail in a Package and Data Management section of this document.

User Location

The usrvol_sftfs_v1.pkg file contains user-specific files that are modified or new files that are created by any user process in the virtual environment.  This volume also contains the virtual environment configuration as modified by the user.

System Locations

UsrVol_sftfs_v1.pkg contains new or modified user-specific data from a system process that is not associated with a specific user context but is associated with a specific package.

GlblVol_sftfs_v1_<SID>.pkgcontains application-specific files that are modified by any user process in the virtual environment.  The SID of the user is appended to the volume name to uniquely identify it.

GlblVol_sftfs_v1_S-1-5-20.pkg contains any application-specific data that is modified by a system process.  The well-known SID for system is appended to the volume.  In SoftGrid 4.0 and 4.1, this volume was used for all modified application data; in 4.2 and 4.5 modifications are separated into those made by system processes such as the Listener, and those made by user application processes.  User modifications go instead to the Application Data Isolation Volume.  The global package volume also contains the virtual environment configuration for system processes.

Will packages created in App-V 4.x work on App-V 5.0?

No. Packages have to be converted into the new format.

Disadvantages of PerUser installation

There are several common scenarios that an arise when the choice of “Per-User” versus “Per-Machine” is given to the user:

1. Major Upgrades can Fail
   If you use the Upgrade code feature of Windows Installer to perform a major upgrade the detection of the existing software will fail if: (a) the original software was installed with ALLUSERS=”" and the new software has ALLUSERS=1 in its Property table or passed on the command line or (b) the original software was installed with ALLUSERS=1 and the new software has ALLUSERS=”" or ALLUSERS is not defined in the Property table or on the command line.
2. Uninstall Problems
   If two different users on the system install the software with ALLUSERS=”" they will both have their own shortcuts and Add/Remove Programs entries made (which is fine and is by design). However, if some of the files are installed to a shared location (such as ProgramFilesFolder) and one of the users uninstalls the software, the other user will not be able to use the software even though their shortcuts and Add/Remove Programs entries are still intact. In other words, the two installed instances of the software will not “know” about each other.
3. Support Issues

• Installing to locations the user has the ability to alter might reduce the confidence the package producer has for the integrity of the install. This can affect support costs as well as computational correctness under a regulatory environment (lawyers, accounts, food and drug companies, government agencies, etc)
• Multiple instances of an install means there is duplicate copies of binaries on the machine which wastes disk space. A “Per-Machine” install creates a single copy of common binaries for all users thus saving space.
• Software is less secure because updating behavior has to be done for each user on the machine. In other words, the occasional user on the machine can made the machine vulnerable because they are not on the machine often enough to keep the software they use up to date.
• IT departments want programs in locations users can’t tamper with. User tampering is a major source of support costs.
• Centralized install, servicing, and uninstall from a central IT department are all more challenging when the apps are just in the users profile. There are numerous conditions where it is known not to work at all

PerUser vs PerMachine Installation

There is a MSI property that can be placed within the application package that allows the application setup to announce to Windows Installer that it wants to be installed “Per-User”.

Windows XP

The ALLUSERS MSI property can be set so that the application package will be run in the “Per-User” context. Both by the absence of the ALLUSERS property or the property is present but the value is set to NULL (ALLUSERS=”") will force the installation package to be run in the “Per-User” context.

Vista

On Vista, you could still force the installation package to be run as “Per-User” as we have discussed. Note that the user’s privileges are immaterial when running in the “Per-User” context – but once the decision is made that the install will be run in the “Per-User” context (By setting the ALLUSERS=”" or not having the property), the User rights issue makes no difference. But remember, the install starts but it WILL FAILif the user doesn’t have Admin rights and the install tries to write to any machine-wide resources.

If a user has Admin rights, but the install is run in the “Per-User” context, with the Admin rights, any accidental writing to machine-wide resources will be allowed.

Windows 7

On Windows 7, the ability to run as “Per-User” is constrained by the specifics of the package. Essentially these points are important for an application setup to be eligible for a “Per-User” installation context:

• All files are installed to Per-User folders, such as
  • “C:\Documents and Settings\$User\Local Settings\Application Data” on WinXP
  • “C:\Users\$User\AppData\Roaming” on Windows 7
• All Shortcuts and the Add/Remove Control Panel entry are only seen by that user
• All registry entries (Application data and registration) are made to HKEY_CURRENT_USER hive.
• No registry entries are made to machine-wide registry keys, such as HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT hives
• The installation package cannot allow the user performing the installation package to select destination directories that are machine-wide, such as “c:\Program Files”
• All application binary file (EXE, DLL) need to be digitally signed to be allowed to be installed by “Per-User” for Windows 7.

On Windows 7, if any of the above constraints are not met, the package will be installed “Per-Machine” – this means that a “Per-User” will not be allowed!

Self Healing Explanation

XCACLS Command line syntax

Xcacls.exe syntax


xcacls file name [/T] [/E] [/C] [/G user:perm;spec] [/R user] [/P user:perm;spec [...]] [/D user [...]] [/Y]
where file name indicates the name of the file or folder to which the ACL or access control entry (ACE) is typically applied. All standard wildcard characters can be used.

/T recursively walks through the current folder and all of its subfolders, applying the chosen access rights to the matching files or folders.

/E edits the ACL instead of replacing it. For example, only the administrator will have access to the Test.dat file if you run the XCACLS test.dat /G Administrator:F command. All ACEs applied earlier are lost.

/C causes Xcacls.exe to continue if an "access denied" error message occurs. If /C is not specified, Xcacls.exe stops on this error.

/G user:perm;spec grants a user access to the matching file or folder.
·       The perm (permission) variable applies the specified access right to files and represents the special file-access-right mask for folders. The perm variable accepts the following values:
o       R Read
o       C Change (write)
o       F Full Control
o       P Change Permissions (special access)
o       O Take Ownership (special access)
o       X EXecute (special access)
o       E REad (Special access)
o       W Write (Special access)
o       D Delete (Special access)
·       The spec (special access) variable applies only to folders and accepts the same values as perm, with the addition of the following special value:
o       T Not Specified. Sets an ACE for the directory itself without specifying an ACE that is applied to new files created in that directory. At least one access right has to follow. Entries between a semicolon (;) and T are ignored.

Notes
§       The access options for files (for folders, special file and folder access) are identical. For detailed explanations of these options, see the Windows 2000 operating system documentation.
§       All other options, which can also be set in Windows Explorer, are subsets of all possible combinations of the basic access rights. Because of this, there are no special options for folder access rights, such as LIST or READ.

/R user revokes all access rights for the specified user.

/P user:perm;spec replaces access rights for user. The rules for specifying perm and spec are the same as for the /G option. See the "Xcacls.exe examples" section.

/D user denies user access to the file or directory.

/Y disables confirmation when replacing user access rights. By default, CACLS asks for confirmation. Because of this feature, when CACLS is used in a batch routine, the routine stops responding until the right answer is entered. The /Y option was introduced to avoid this confirmation, so that Xcacls.exe can be used in batch mode.