File and Registry Virtualization in Visual Studio .NET

Creator Code 39 Full ASCII in Visual Studio .NET File and Registry Virtualization

Prior to Windows Vista, many applications even those run by standard users were run with administrator privileges. These elevated privileges were necessary because many applications write to system files and registry keys during the installation and running of the program. Often, in fact, if applications in Windows XP were configured to run with standard user privileges, they would fail to run properly because of insufficient access rights. Running programs with administrator privileges nonetheless introduced a persistent and serious security hole in Windows installations. Malware such as worms and viruses could leverage the privileges of such a program to damage the system or install other undesirable features.

To fix this problem, Windows Vista introduced a background feature called file and registry virtualization. In Windows Vista, all applications by default run with standard user privileges. When a program attempts to write to a privileged area of the registry, the operation is redirected to a safe location reserved for each user. For example, registry operations to the global store (HKEY_LOCAL_MACHINE\Software) are redirected to a peruser location within the user s profile known as the virtual store (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software). In addition to this security improvement, other Windows Vista features that might affect application compatibility include:

16-bit applications and 32-bit drivers are not supported on 64-bit versions of Windows Vista. Automatic registry and system file redirection is not supported in the 64-bit environment. These changes require that 64-bit applications must adhere to a stronger set of Windows Vista application standards.

Applications may check for a specific version of operating system, such as Microsoft Windows 98 Second Edition, Windows 2000, or Windows XP. Although the application might run correctly on Windows Vista, logic in the application might prevent the application from installing if a specific operating system version is not discovered.

The Application Compatibility Toolkit (ACT) 5.0 is a set of tools that collects information about the applications installed on your network. After compiling a list of these installed applications, the ACT helps you understand application compatibility challenges by identifying which of these applications are compatible with Windows Vista and which require further testing. When preparing for deployment-related application compatibility challenges, you can also use the ACT to achieve the following:

Analyze your network s portfolio of applications, websites, and computers. Evaluate operating system deployments, the impact of operating system updates, and your compatibility with specific websites. Centrally manage compatibility evaluators and configuration settings. Prioritize application compatibility efforts with filtered reporting. Deploy automated mitigations to known compatibility issues.

1

ACT 5.0 is included on the companion CD in the Software\ACT folder. You can also download ACT from the Microsoft Download Center. To locate the ACT download page, go to http://download.microsoft.com and search for Application Compatibility Toolkit. If you want to learn more about how to use the ACT, you can perform the ACT virtual lab in the Suggested Practices section at the end of this chapter.

Although you don t need to know how to use the ACT for the 70-622 exam, you do need to know what it is and what it is used for.

Besides planning for the migration of applications, you also need to plan for the migration of data before you deploy Windows Vista. Typically, data that is migrated is first backed up from the source systems and then restored to the target systems during the deployment process. In general, the data that needs to be backed up includes user data, operating system data, and application data.

When planning for your migration, you should identify the file types, files, folders, and settings that you want to migrate. First, determine the standard file locations on each computer, such as My Documents, C:\Data, and company-specified locations, such as \EngineeringDrafts. Next, you should determine the nonstandard locations. For nonstandard locations, consider the following:

File types Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your organization. For example, Microsoft Word primarily uses .doc (and under Word 2007, the .docx) file name extension. However, it also uses other file types, such as templates (.dot files), less frequently. n Excluded locations Consider the locations on the computer that should be excluded from the migration (for example, %windir% and Program Files). n New locations Decide where files should be migrated to on the destination computer (for example, My Documents, a designated folder, or the original location).

After you catalog the files and folders that you want to back up, you should identify which system settings you want to migrate. These system settings might include desktop appearance and wallpaper, key repeat rates, Web browser home page, and e-mail account settings.