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.

When OSD Script Runs

When the script runs

You can use the .osd file to run scripts at various times during the startup of App-V (SoftGrid)-enabled programs. The "SCRIPT TIMING and EVENT" setting in the script comes first. Under this setting, the following attributes determine when the script runs:

• PRE STREAM
  This attribute runs the script before the program starts streaming. For example, use this attribute when you have to open a virtual private network (VPN) connection to the App-V (SoftGrid) server before you run the program.
• POST STREAM
  This attribute runs the script after authorization and after the program starts streaming but before the Virtual Environment is set up.
• PRE LAUNCH
  This attribute runs the script inside the virtual environment before the program runs.
• POST LAUNCH
  This attribute runs the script after the program is started.
• POST SHUTDOWN
  This attribute runs the script after the program is shut down. For example, use this attribute to clean up configuration settings or to delete configuration files.

How OSD script runs

How the script runs

The new TIMEOUT attribute determines the following:

• Whether the App-V (SoftGrid) client waits for the script to finish
• The period that the App-V (SoftGrid) client will wait for the script to finish

For backward compatibility, the WAIT attribute is still supported in Microsoft App-V 4.x and in Microsoft SoftGrid 4.x. 

Set these attributes as follows:

TIMEOUT
• TIMEOUT=x
  The client will wait x seconds for the script to finish before the client returns an error.
• TIMEOUT=0
  The client will wait indefinitely for the script to finish.

WAIT
• Wait=False
  The client will continue without waiting for the script to finish.
• Wait=True
  The client will not start the next step until the script finishes.

Notes

• The client does not support a pre-shutdown event. You cannot determine the exact moment at which a user will perform a shutdown. For example, you cannot predict when the user will clickClose or when the user will press ALT+F4.
• You can use scripts in any language. However, the language must be installed locally on the client computer.