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.

Setup.exe Silent Switches

Perhaps there is some undocumented process you can uncover. Below are some command lines found to work, try "setup.exe /?" first then go through the list below- you may get lucky!

• setup.exe /q
• setup.exe /qn
• setup.exe /silent
• setup.exe /s
• setup.exe /NoUserInput
• setup.exe /unattended
• setup.exe /CreateAnswerFile
• setup.exe /quiet
• setup.exe /passive
• setup.exe /NoUI
• setup.exe -s
• setup.exe -silent
• setup.exe /VerySilent
• setup.exe -r      (Creates response file in Windows directory with name setup.iss)

What is SystemGuard

SystemGuard tracks and analyses configuration repositories and resources used by the application and intercepts the use of these resources, redirecting them to the virtualized instances of the resources.


The Microsoft App-V Application Virtualization Platform‘s heart is SystemGuard, a patented technology which enables applications to run without installing them locally—and without altering the client‘s operating system.


SystemGuard eliminates common application deployment and management problems:


Application Conflicts: Almost any application will run on any client at any time.


Version Incompatibilities: Different versions of the same application will run simultaneously on the same computer.


Multi-User Access: Applications that were previously unable to run in multi-user mode and therefore could not run within Citrix MetaFrame or Windows Terminal Services, will now do so and function correctly for multiple users.


Multi-Tenancy Issues: Instances of the same application using different database paths will run on the same computer at the same time.


Server Siloing and N-Way Regression Testing: The need for many separate server farms and time-intensive regression testing for application conflicts is eliminated.

Check if Registry hive exists

Following script checks if HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft hive exists


const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."


Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_ 
strComputer & "\root\default:StdRegProv")


strKeyPath = "SOFTWARE"
oReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys


For Each subkey In arrSubKeys


    If subkey = "Microsoft" Then
   Exit For
     End If
Next


    MSGBOX subkey