Can ThinApp MSIs be installed by Regular Users

Of course!

Simply put, the MSI settings are straight form Microsoft Installer requirements, and the PACKAGE.INI file only shows those specific settings pertaining to a virtualized application. Remembering the four things which occur during a ThinApp package registration (either through the SDK, THINREG, or a ThinApp MSI), they are...

1. Shortcut Creation on the desktop, start menu, or elsewhere (taskbar or quick launch bar).
2. File Type Association so when a user double-clicks on a file associated to the virtualized app, the virtualized application starts and opens the file.
3. Protocol Association, so when a user clicks on a link with an associated protocol (i.e. HTTP, HTTPS, FTP, MAILTO, NOTES, etc.) the appropriate virtualized application opens and conducts the associated action with that protocol.
4. COM Object Association, so when a user initiates an action with an associated object the appropriate virtualized application opens and conducts the associated action with the object.

The registration process just assigns these items to the user or system based upon the commands within the registration process. For THINREG, using a "/A" switch tells ThinApp to assign the aforementioned four items within the application to the entire system (by default, THINREG only registers these for the user).

The same goes for MSI settings, however, it's default is to register the virtualized app to the entire system due to the default settings below:

• MSIDefaultInstallAllUsers=1
• MSIRequireElevatedPrivileges=1

Changing the above settings to "0" will allow the MSI to be installed by a regular user and only register the components to the user executing the MSI.

• MSIDefaultInstallAllUsers=0
• MSIRequireElevatedPrivileges=0

NOTE: Don't forget to save the PACKAGE.INI and rebuild with BUILD.BAT.

So now, not only will your apps run under regular user permissions, but they can also be installed and uninstalled by regular users! This means, you can remove Local Admin permissions and reduce your overall desktop security risks!

VMWare ThinApp Factory Released

ThinApp Factory is a virtual appliance which can be used to automate the packaging of legacy Windows applications with VMware ThinApp.

The virtual appliance is a Debian Linux vApp which can be installed on VMware vSphere 4.1 or higher or VMware Workstation 8.x and higher. It has a TomCat web based interface and built into it is an enhanced ThinApp package editor and basic web based store for users to install their own applications.

It can pull from manually uploaded installers, regular file share repositories (something very common amongst IT shops), as well as RSS-style app-installer feeds using the JSON format.

For more information on ThinApp Factory, please visit vmware blog 

http://blogs.vmware.com/thinapp/2012/06/thinapp-factory-released.html

Migration from SCCM 2007 to SCCM 2012

Please check following video on Microsoft Technet

http://technet.microsoft.com/en-us/video/Video/hh304354

MountPoint vs VFS Sequencing

There are two ways you can sequence an application. They are Mount point sequencing and VFS  sequencing .
                                                                  

Mount Point Installation

                Installing an application to a folder in Mount point is considered to be an efficient way of sequencing application. A deeper look at the scanning operation performed during the sequencing operation would help us better comprehend the advantages of mount point installation.

·      
As the application is installed to a mount point (Q:\), only required files are monitored by the sequencer. The tax on the sequencer to scan the entire C:\ is hugely removed in this case there by making it easily the efficient way to sequence an application.

VFS Installation

            Nonetheless, there are applications which refuse to install to a location other than C:\ (Virtual File System). Under these circumstances, the entire hard disk is scanned for system changes, making it much slower than mount point installation. Also, scanning the entire hard disk for changes would result in capturing files that are not actually used by the application.

From the above points, it is evidently visible that Mount point installation is the preferred method to sequence an application compared to VFS installation

AppV Security Descriptor

By enabling Security Descriptors during sequencing an application, permissions on the windows file system are “pulled into the bubble”. The sequencer always captures security descriptors during sequencing, but only with the Enforce Security Descriptors setting checked, the client enforces them on the file system drive at runtime.

So if a users group on the Sequencer had read rights on the T:\APP-X folder, these rights are stored in the Virtual Environment. Once streamed and run on the client, the user cannot edit in this specific folder. In this manner you can set permissions on parts of the Virtual Environment and secure parts of being modified by a user

   

On the contrary, I would check this option ONLY when it is absolutely essential. Meaning, only for badly written software which expects specific security settings for proper functionality would precisely be the circumstances under which I would keep the option checked. When the security descriptors are turned off, the user is considered to have full rights on the asset directory which would be the ideal case.

    

USEFUL TIP you can turn off “Enforce Security Descriptor” by default by editing the “Default.sprj” file.

Open the “Default.sprj” file with notepad, search for “UseSecurityDescriptors” and set the value to “NO” and save the file.

Roaming, Local, LocalLow

Windows Vista and Windows 7 comes with three new folders namely “Local”, “LocalLow” and “Roaming” which has been created by Microsoft intentionally for the following reasons

• Better performance during logon

• Segregation of application’s data based on the usage level

Roaming

The folder “Roaming” by design ensures that ONLY absolutely essential data like “Favorites” “Desktop” and “Documents” travel with the user thereby making it as a roaming profile. Data stored inside this folder would be user’s preference for a particular application. For instance, Adobe products stores user’s settings in this folder. It is worth to remember that “Roaming” folder is synchronized with the server meaning bigger the size of roaming folder longer the time required to logon to a PC.

Local

The folder “Local” is designed to store any machine specific information which wouldn’t be synchronized with the server at logon time. Usually, this data is machine specific. This folder is equivalent to C:\Documents and Settings\Local Settings\Application Data on Windows XP.

LocalLow

This folder stores what Microsoft calls as “Low Integrity” data. IE8, for example, can only write to the locallow folder (when protected mode is on).

Where OSD Script Runs

Where the script runs

The script can run in the following two locations:

• Inside the Virtual Environment
• Outside the Virtual Environment

Set the PROTECT attribute as follows:

• PROTECT=True
  This setting configures the script to run in the Virtual Environment. You can use this setting to run scripts that are used to troubleshoot issues.
• PROTECT=False
  This attribute configures the script to run outside the Virtual Environment. For example, you can use this setting to run scripts that copy files locally to the client.