Deploying a MSI through GPO

This tutorial will describe how to deploy a MSI on multiple machines by using Group Policy.

• 1. Methods of deployment
• 2. Create a distribution point
• 3. Create a Group Policy Object
• 4. Assign a MSI package
• 5. Publish a MSI package
• 6. Redeploy a MSI package
• 7. Remove a MSI package
• 8. Troubleshooting Active Directory/GPO deployments

1. Methods of deployment

Group Policy supports two methods of deploying a MSI package:

• Assign software – A program can be assigned per-user or per-machine. If its assigned per-user, it will be installed when the user logs on. However, if its assigned per-machine then the program will be installed for all users when the machine starts.
• Publish software – A program can be published for one or more users. This program will be added to the Add or Remove Programs list and the user will be able to install it from there.

2. Create a distribution point

The first step in deploying a MSI through GPO is to create a distribution point on the publishing server. This can be done by following these steps:

• log on to the server as an Administrator user
• create a shared network folder (this folder will contain the MSI package)
• set permissions on this folder in order to allow access to the distribution package
• copy the MSI in the shared folder

In the shared folder you can also perform an administrative install for a MSI package contained by an EXE bootstrapper.

3. Create a Group Policy Object

A MSI package is deployed (distributed) through GPO as a Group Policy Object. In order to create an object for your package, you can follow these steps:

• click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
• right-click your domain name in the console tree and select the Properties context menu
• select the Group Policy tab and click New
• set the name of the policy (for example MyApplication)
• click Properties and select the Security tab
• check the Apply Group Policy checkbox only for the groups to which the policy will be applied
• click on the OK button

4. Assign a MSI package

A package can be assigned per-user or per-machine. Also, if the package is assigned, it will automatically be installed silently. In order to assign a package you can follow these steps:

• click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
• right-click your domain name in the console tree and select the Properties context menu
• go to the Group Policy tab, select the object you want and click Edit
• expand Software Settings under Computer Configuration
• right-click Software Installation, select the New context menu and then click on Package
• in the Open dialog type the full UNC path of the shared package you want to assign
• click on the Open button
• click on Assigned and then click OK (the package will be added to the right pane of the "Group Policy" window)
• close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in
• when the client computers start, the assigned package will be installed automatically

Do not use the Browse button in the Open dialog to access the UNC location. Make sure that you use the UNC path to the shared package.

5. Publish a MSI package

When using Group Policy, you can publish a package in order to allow the target user to install it by using Add or Remove programs. The steps for publishing a package are:

• click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
• right-click your domain name in the console tree and select the Properties context menu
• go to the Group Policy tab, select the object you want and click Edit
• expand Software Settings under User Configuration
• right-click Software Installation, select the New context menu and then click on Package
• in the Open dialog type the full UNC path of the shared package you want to publish
• click on the Open button
• click on Publish and then click OK (the package will be added to the right pane of the "Group Policy" window)
• close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in
• test the package:
  • log on to the target computer
  • click on the Start button and go to Control Panel
  • double-click the Add or Remove programs applet and select Add New Programs
  • in the Add programs from your network list select the program you published
  • use the Add button to install the package
  • click OK and then Close

Do not use the Browse button in the Open dialog to access the UNC location. Make sure that you use the UNC path to the shared package.

6. Redeploy a MSI package

Sometimes you may need to redeploy a package (for example when doing an upgrade). For redeploying a package you can follow these steps:

• click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
• right-click your domain name in the console tree and select the Properties context menu
• go to the Group Policy tab, select the object you used to deploy the package and click Edit
• expand the Software Settings element (per-user or per-machine) which contains the deployed package
• expand the Software Installation element which contains the deployed package
• right-click the package in the right pane of the Group Policy window
• select the All Tasks menu and click Redeploy application
• click the Yes button for reinstalling the application wherever it is installed
• close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in

7. Remove a MSI package

Group Policy also allows you to remove packages which have been deployed in the past. Here are the steps for removing a package:

• click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
• right-click your domain name in the console tree and select the Properties context menu
• go to the Group Policy tab, select the object you used to deploy the package and click Edit
• expand the Software Settings element (per-user or per-machine) which contains the deployed package
• expand the Software Installation element which contains the deployed package
• right-click the package in the right pane of the Group Policy window
• select the All Tasks menu and click Remove
• select from the following options:
  • Immediately uninstall the software from users and computers
  • Allow users to continue to use the software but prevent new installations
• click the OK button to continue
• close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in

8. Troubleshooting Active Directory/GPO deployments

Here is an article that shows how to troubleshoot an Active Directory/GPO installation: How do I create an installation log?

The End

This concludes our tutorial.

Source: Deploying a MSI through GPO

Registry Based GPO Setting to force displaying small icons in taskbar

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"TaskbarSmallIcons"=dword:00000001

Registry Redirector (Windows)

The registry redirector isolates 32-bit and 64-bit applications by providing separate logical views of certain portions of the registry on WOW64. The registry redirector intercepts 32-bit and 64-bit registry calls to their respective logical registry views and maps them to the corresponding physical registry location. The redirection process is transparent to the application. Therefore, a 32-bit application can access registry data as if it were running on 32-bit Windows even if the data is stored in a different location on 64-bit Windows.

A subset of keys under redirected registry paths are shared. 32-bit registry calls to shared keys are not redirected. Instead, one physical copy of the key is mapped into each logical view of the registry. For a list of redirected keys and shared keys, see Registry Keys Affected by WOW64.

Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: To enable application interoperability through COM and other mechanisms, a subset of redirected registry keys are also reflected. The process of registry reflection copies registry keys and values between two registry views to keep them synchronized. Registry reflection was removed starting with Windows 7 and Windows Server 2008 R2. For more information, see Registry Reflection.

The following scenario illustrates the use of these logical views:

• A 32-bit application checks for the existence of the following registry key: HKEY_LOCAL_MACHINE\Software\Hello. If the key does not exist, the application creates it with a default value of "Hello 32-bit world"; otherwise, it reads and displays the value.
• The same application is modified to write "Hello 64-bit world" instead of "Hello 32-bit world" and recompiled as a 64-bit application.
• When the 32-bit application is run on 64-bit Windows, it displays "Hello 32-bit world". When the 64-bit application is run, it displays "Hello 64-bit world". Both applications call the same registry functions with the same predefined handle and the same key name; the difference is that each application operates on its logical view of registry, and each view is mapped to a separate physical location of the registry, which keeps both versions of the string intact.

Redirected keys are mapped to physical locations under Wow6432Node. For example, HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node. However, the physical location of redirected keys should be considered reserved by the system. Applications should not access a key’s physical location directly, because this location may change. For more information, see Accessing an Alternate Registry View.

To help 32-bit applications that write REG_SZ or REG_EXPAND_SZ data containing %ProgramFiles% or %commonprogramfiles% to the registry, WOW64 intercepts these write operations and replaces them with "%ProgramFiles(x86)%" and "%commonprogramfiles(x86)%". For example, if the Program Files directory is on the C drive, then "%ProgramFiles(x86)%" expands to "C:\Program Files (x86)". The replacement occurs only if the following conditions are met:

• The string must begin with %ProgramFiles% or %commonprogramfiles%. If the string begins with a space or any character other than %, it is not replaced.
• The case of %ProgramFiles% or %commonprogramfiles% must be exactly as shown because the string comparison is case-sensitive. For example, if the string begins with %CommonProgramFiles% instead of %commonprogramfiles%, it is not replaced.
• The string cannot exceed MAX_PATH*2+15 characters. If it exceeds this length, it is not replaced.
• The key cannot be opened with KEY_WOW64_64KEY. This flag specifies that operations on the key should be performed on the 64-bit registry view, so it is not replaced. For more information, see Accessing an Alternate Registry View.

Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: The KEY_WOW_64_64KEY flag does not affect whether a key is replaced. This flag affects replacement starting with Windows 7 and Windows Server 2008 R2.

In addition, REG_SZ or REG_EXPAND_SZ keys containing system32 are replaced with syswow64. The string must begin with the path pointing to or under %windir%\system32. The string comparison is not case-sensitive. Environment variables are expanded before matching the path, so all of the following paths are replaced: %windir%\system32, %SystemRoot%\system32, and C:\windows\system32.

For more information, see the following topics:

• Registry Reflection
• Registry Keys Affected by WOW64
• Accessing an Alternate Registry View
• Example of Registry Redirection on WOW64
• Remote Registry Access in 64-bit Windows

Source: Registry Redirector (Windows)

Registry Virtualization

Registry virtualization is an application compatibility technology that enables registry write operations that have global impact to be redirected to per-user locations. This redirection is transparent to applications reading from or writing to the registry. It is supported starting with Windows Vista.

This form of virtualization is an interim application compatibility technology; Microsoft intends to remove it from future versions of the Windows operating system as more applications are made compatible with Windows Vista and later versions of Windows. Therefore, it is important that your application does not become dependent on the behavior of registry virtualization in the system.

Virtualization is intended only to provide compatibility for existing applications. Applications designed for Windows Vista and later versions of Windows should not write to sensitive system areas, nor should they rely on virtualization to remedy any problems. When updating existing code to run on Windows Vista and later versions of Windows, developers should ensure that applications only store data in per-user locations or in computer locations within %alluserprofile% that properly use an access control list (ACL).

For more information about building UAC-compliant applications, see the UAC Developer Guide.

Virtualization Overview

Prior to Windows Vista, applications were typically run by administrators. As a result, applications could freely access system files and registry keys. If these applications were run by a standard user, they would fail due to insufficient access rights. Windows Vista and later versions of Windows improve application compatibility for these applications by automatically redirecting these operations. For example, registry operations to the global store (HKEY_LOCAL_MACHINE\Software) are redirected to a per-user location within the user’s profile known as the virtual store (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software).

Registry virtualization can be broadly classified into the following types:

Open Registry Virtualization

If the caller does not have write access to a key and attempts to open the key, the key is opened with the maximum allowed access for that caller.

If the REG_KEY_DONT_SILENT_FAIL flag is set for the key, the operation fails and the key is not opened. For more information, see "Controlling Registry Virtualization" later in this topic.

Write Registry Virtualization

If the caller does not have write access to a key and attempts to write a value to it or create a subkey, the value is written to the virtual store.

For example, if a limited user attempts to write a value to the following key: HKEY_LOCAL_MACHINE\Software\AppKey1, virtualization redirects the write operation to HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\AppKey1.

Read Registry Virtualization

If the caller reads from a key that is virtualized, the registry presents a merged view of both the virtualized values (from the virtual store) and the non-virtual values (from the global store) to the caller.

For example, suppose HKEY_LOCAL_MACHINE\Software\AppKey1 contains two values V1 and V2 and that a limited user writes a value V3 to the key. When the user attempts to read values from this key, the merged view includes values V1 and V2 from the global store and value V3 from the virtual store.

Note that virtual values take precedence over global values when present. In the example above, even if the global store had value V3 under this key, the value V3 would still be returned to the caller from the virtual store. If V3 were to be deleted from the virtual store, then V3 would be returned from the global store. In other words, if V3 were to be deleted from HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\AppKey1 but HKEY_LOCAL_MACHINE\Software\AppKey1 had a value V3, then that value would be returned from the global store.

Registry Virtualization Scope

Registry virtualization is enabled only for the following:

• 32-bit interactive processes.
• Keys in HKEY_LOCAL_MACHINE\Software.
• Keys that an administrator can write to. (If an administrator cannot write to a key, then the application would have failed on previous versions of Windows even if it was run by an administrator.)

Registry virtualization is disabled for the following:

• 64-bit processes.
• Processes that are not interactive, such as services.

  Note that using the registry as an inter-process communication (IPC) mechanism between a service (or any other process that does not have virtualization enabled) and an application will not work correctly if the key is virtualized. For instance, if an antivirus service updates its signature files based on a value set by an application, the service will never update its signature files because the service reads from the global store but the application writes to the virtual store.

• Processes that impersonate a user. If a process attempts an operation while impersonating a user, that operation will not be virtualized.
• Kernel-mode processes such as drivers.
• Processes that have requestedExecutionLevel specified in their manifests.
• Keys and subkeys of HKEY_LOCAL_MACHINE\Software\Classes, HKEY_LOCAL_MACHINE\Software\Microsoft\Windows, and HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT.

Controlling Registry Virtualization

In addition to controlling virtualization at an application level by using requestedExecutionLevel in the manifest, an administrator can enable or disable virtualization on a per-key basis for keys in HKEY_LOCAL_MACHINE\Software. To do this, use the Reg.exe command-line utility FLAGS option with the flags listed in the following table.

Flag
Meaning

REG_KEY_DONT_SILENT_FAIL
This flag disables open registry virtualization. If this flag is set and an open operation fails on a key that has virtualization enabled, the registry does not attempt to reopen the key. If this flag is clear, the registry attempts to reopen the key with MAXIMUM_ALLOWED access instead of the requested access.

REG_KEY_DONT_VIRTUALIZE
This flag disables write registry virtualization. If this flag is set and a create key or set value operation fails because the caller does not have sufficient access right to the parent key, the registry fails the operation. If this flag is clear, the registry attempts to write the key or value in the virtual store. The caller must have the KEY_READ right on the parent key.

REG_KEY_RECURSE_FLAG
If this flag is set, registry virtualization flags are propagated from the parent key. If this flag is clear, registry virtualization flags are not propagated. Changing this flag affects only new descendent keys created after the flag is changed. It does not set or clear these flags for existing descendent keys.

The following example shows the use of the Reg.exe command-line utility with the FLAGS option to query the state of the virtualization flags for a key.

Copy

C:\>reg flags HKLM\Software\AppKey1 QUERY

HKEY_LOCAL_MACHINE\Software\AppKey1

        REG_KEY_DONT_VIRTUALIZE: CLEAR
        REG_KEY_DONT_SILENT_FAIL: CLEAR
        REG_KEY_RECURSE_FLAG: CLEAR

The operation completed successfully.

Whenever auditing is enabled on a key that is being virtualized, a new virtualization audit event is generated to indicate that the key is being virtualized (addition to the usual audit events). Administrators can use this information to monitor the status of virtualization on their systems.

Related topics

Getting Started with User Account Control

Understanding and Configuring User Account Control

Developer Best Practices and Guidelines for Applications in a Least Privileged Environment

 

Source: Registry Virtualization

AppShadow: Side-by-side components the other way

Side-by-side components the other way

Important This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry

Abstract

Ever wanted to run some legacy Access 97 application side by side with the latest Microsoft Office suite? Or ever wondered why you cannot install different versions of some applications at the same time on your machine? Then the following will be interesting for you, because in this article I will present a method on how to virtualize the Windows registry on an application (process) basis. You can do it with AppShadow.
By this means you could host multiple versions of otherwise mutual exclusive applications or components on the same machine at the same time. Moreover you can circumvent shortcomings in applications that are normally not meant to be run in a Terminal Server environment.
In order to get the most out of this article some know-how about

• Windows Terminal Server
• Windows DLLs
• Windows API programming

is absolutely recommended. If you do not like changing system settings or are not sure what you are doing please stop reading and do not waste your time reading this article.

Background

When running in a Terminal Server environment, every user receives its own copy of user specific registry settings (where one normally has full access, KEY_ALL_ACCESS). These settings reside in a hive called HKEY_CURRENT_USER (HKCU for short, physically stored in "%USERPROFiLE%\ntuser.dat"). To ease the propagation of changes Windows implements a mechanism called "Shadowing" (from which I borrowed the name AppShadow). The shadow registry is a special registry tree that can be seen as a layer on top of the user’s settings. Each entry in the shadow area corresponds to an entry in HKCU:

Picture: Mapping between shadow area and HKCU
Click to show picture

Every time a user requests a key or value from its HKCU, Windows looks into the "shadow registry" or "shadow area" first if there is a (newer) entry. If available, this entry will be copied to the user’s location – eventually overwriting existing older entries. To determine if entries in the shadow area are newer than those already present in HKCU Windows compares the last write time (a FILETIME structure) of both keys. For some information about editing the access time on registry keys see RegTimeStamp. The shadow area is currently defined at the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install

Machine wide settings are kept in a different area, HKEY_LOCAL_MACHINE (HKLM). Applications can define settings that are global for all users. Normally, only privileged users such as "Administrators" can change entries in this hive. Other users such as "Authenticated Users" have only read permissions, KEY_READ, on these keys. Within HKLM under the key called SOFTWARE (physically stored in "%SYSTEMROOT%\system32\config\software") there is a subkey called Classes that can be referred to as HKEY_CLASSES_ROOT (HKCR).

Picture: Mapping between HKLM\SOFTWARE\Classes and HKCR
Click to show picture

In this area, system-wide registrations of components are kept (CLSIDs, ProgIds, TypeLibs and Interfaces) and among others, file associations for all users. As HKCR is a global instance it means that once, for example, a file association is defined in this place, every user on that machine has the same program that handles this association.

Beginning with Windows 2000 the operating systems tries to ease the implications of one single HKCR branch and introduces user specific software registration. From now on, every user has a private Classes key that maps transparently over HKCR, referred to as HKEY_USER_CLASSES (HKUC).

Picture: Mapping between HKCU\SOFTWARE\Classes and HKUC
Click to show picture

These settings are saved in a file called UsrClass.dat. The file resides in a non-roaming area of your profile: CSIDL_LOCALAPPDATA. So all changes you make are lost after you log off. Everytime a registry call to HKCR is made, the system tries to look in HKUC first. The calling application is normally unaware of this behaviour. By utilizing this feature, every user can have his different file association for documents, for example. Entries in HKUC alyways have precedence over entries in HKCR. But these settings affect all applications throughout the session. Competing applications that defines values in the same area may produce unpredictable results or simply complain that the application is not installed properly.

Though applications can seamlessly read from HKUC when actually opening keys in HKCR, they may still fail when trying to write or register components in HKCR as of insufficient (write) permissions. These requests are not remapped to HKUC! This is a major annoyance as many developers (or maybe just syntactical coders?) still open resources with KEY_ALL_ACCESS permissions while really only read access is allthey really want. (You can use Regmon from Sysinternals to see how applications open registry keys.

If you would like to know more about the registry in a Terminal Server environment, please have a look at Brian Madden’s web site:

• How Applications use the Registry in Terminal Server Environments (Part 1 of 3)
• How Applications use the Registry in Terminal Server Environments (Part 2 of 3)

Or have a look at these documents

• Registry TimeStamps and Shadow Keys
• INFO: Reading and Writing Registry TimeStamps

Registry virtualization

If every process had its private copy of required registry keys and values along with all the permissions it needed to open these resources, world peace would come probably closer – at least for the average administrator or system integrator…
So what we are trying to do is the following: We build a special area of registry keys just like the "shadow area". Every time our application looks up some values, we look in that area first and see if there are values that could be returned to the application. This can be done by redirecting the registry interface of Windows:
From a Win32 programmers perspective, all registry access is implemented via the ADVAPI32 interface. ADVAPI32.DLL is a well known system DLL that is mapped into your program if it makes calls to security and registry functions. In order to virtualize the registry for arbitrary processes, we must somehow replace or redirect calls to the original ADVAPI32.DLL to our library that can redirect calls to our shadow area. So we would supply a DLL with the same name that has the same exports as the original DLL and place it into the programs directory so that our library is called before the original DLL. Unfortunately, Windows treats ADVAPI32 as a special "well known" library and thus prefers loading the real library instead of ours.

DLL redirection to the rescue!

Windows 2003 Luckily there is a feature known as "DLL redirection" within Windows 2003 that instructs the Windows Loader to search libraries in the application directory first. Just as we want it! This works by adding a special folder called APPNAME.EXE.LOCAL into the program directory and copying our library into that folder (if we wanted to redirect Winword we would replace APPNAME.EXE.LOCAL with WINDORD.EXE.LOCAL).

Picture: DLL redirection with Windows 2003
Click to show picture

By doing this our library is called before the original library and has a chance to get loaded.

Note For more information about the load mechanism in Windows, I recommend to read Matt Pietrek‘s articles about PE images (in the MSJ series "Under the Hood") or to have a look at What Goes On Inside Windows 2000: Solving the Mysteries of the Loader.

Windows 2000 Windows 2000 only supports a redirection file (for Winword it would be "WINWORD.EXE.LOCAL"). In that case, the library has to be put into the application directory – possibly affecting other applications as well.

Picture: DLL redirection with Windows 2000
Click to show picture

Apart from that, we have to tell Windows 2000 to treat ADVAPI32 as an ordinary library excluding it from KnownDLLs. So we use RegEdt32.Exe to add a value to the following entry: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ExcludeFromKnownDlls" (REG_MULTI_SZ). You have to reboot until changes take effect.

Picture: ExcludeFromKnownDlls
Click to show picture

The export table

Finally being loaded as ADVAPI32, the only thing left is to check every registry access (function call) and to see if it should get a special "treatment". If we want to redirect the registry access to somewhere else, we do it – otherwise we just leave the call as it is and do what the real library would have done anyway. For this to happen, our library has to export the same function names as the original DLL (as I mentioned earlier). By using DumpBin.Exe with the /EXPORTS switch from the Platform SDK, for example, we can build our own export table.
Warning But be careful: Between different operating systems, the export table changes (specificially the ordinals)! That’s why we need a different version for every operating system we support (Windows 2000, Windows XP, Windows 2003).

NTFS hardlinks come in handy

After having made up what to do, we finally would like to call the original ADVAPI32.DLL from the system’s directory to redirect the registry call made by the application. But there is a problem: We told Windows we wanted a DLL redirection. So when we try to load the original library from the system directory, Windows first tries to load the library from the application directory. As this is our library, we end up in loop loading us again and again until the stack is exhausted and the loader terminates the application. What an unpleasant surprise!

Though one possible solution would be to make a copy of the original DLL and name it to something else. But every time a new update is installed on the system that copy would have to be updated as well (and you know – there are a lot of latest and greatest fixes around these days)…
This is the place where we use an NTFS hardlink, a concept that UNIX knows for a long time: a hardlink is like an alias or pointer to a different file. Every time you open the hardlink, the system opens the real file instead.
Instead of loading ADVAPI32.DLL we load our NTFS hardlink ADVAPI32.DF that we created in "%SYSTEMROOT%\system32". By doing this, we avoid the naming collision and also have only a single copy of the original DLL on the system!
Note As a trade off, the program runs only on NTFS partitions but that should be no real restriction.

Implementation details

Like the shadow area from Windows we need a place where to store the virtual HKLM and HKCU settings for the applications that we want to redirect. The main place where everything starts is:

HKEY_LOCAL_MACHINE\SOFTWARE\d-fens\AppShadow

For every program you want redirection to occur, you define a mapping as seen in the picture. In this example, we define a mapping for Microsoft Access 97 Runtime (MSACCESS.EXE, full path "C:/DATEV/PROGRAMM/QSELZK97/Office/MSACCESS.EXE").

Note All "\" characters have to be replaced with "/" characters!

Within the key is a REG_SZ "Index" pointing to the location where all shadow registry settings should be kept. In this case, it points to the "Access97Runtime" key below "Registry" (see the red arrow). There you have to define 2 keys: "HKLM", and "HKCU". These keys will be the application’s new HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. HKCR and HKUC are consequently defined at "SOFTWARE\Classes" in their respective branches. If no keys are defined, no redirection occurs.

Note You always have to define both entries (HKLM, HKCR and HKCU, HKUC) together to activate redirection. If you omit HKCR (that is the SOFTWARE\Classes branch below our virtual HKLM), for example, HKLM\SOFTWARE\Classes and HKCR would point to different places and unpredictable results could occur. Thanks to Thomas Lehrer for clarifications on this one.

Picture: Redirected HKLM

Click to show picture

Picture: Redirected HKCU

Click to show picture

HKCU remapping

If you want to remap HKCU entries as well, AppShadow will copy all entries below "HKEY_LOCAL_MACHINE\SOFTWARE\d-fens\AppShadow\Registry\Saperion-DMS\HKCU" to "HKEY_CURRENT_USER\Software\d-fens\AppShadow\Registry\Saperion-DMS\HKCU" on application startup , because the user must have write access to these keys.

Role based redirection

Picture: Role based redirection

Click to show picture

When defining access permissions on the Appname registry key, you can control for which users redirection should be active. In the shown example, you can see that only "Saperion-DMSUsers" should get a redirection of registry keys.

Per user HKLM redirection

If redirecting HKLM per process is still not enough for you might consider using the "private HKLM" feature. This is useful if application store user specific settings in HKLM (like Netscape 4 or Cashier4Windows) and you want them to separate. To enable this feature you must create the following registry key (in the same path where you create the "Index" REG_SZ):

PerUserHKLM	REG_DOWRD	0x00000001

Upon start AppShadow checks if HKLM is not already defined in "HKEY_CURRENT_USER\SOFTWARE\d-fens\AppShadow\Registry\’IndexName’" and then copies all keys from "HKEY_LOCAL_MACHINE\SOFTWARE\d-fens\AppShadow\Registry\’IndexName’" to this location with security set to KEY_ALL_ACCESS. If HKLM is already defined in "HKEY_CURRENT_USER\SOFTWARE\d-fens\AppShadow\Registry\’IndexName’" no keys are copied. By this you can deploy a set of individual registry keys per policy to your users.

 

What went wrong?

In case the redirection does not work as expected, AppShadow has built-in logging that you can use to trouble-shoot the error. Every registry call is logged via OutputDebugString(), so all you need is a debug monitor like DebugView from Sysinternals and off you go! This certainly degrades system performance, so make sure you only log when really needed!

Note When trying to log a program from a different Terminal Server session, keep in mind that the kernel objects namespace is separated. Use my OutputDebugString redirector, for example, to redirect the debug stream.

Checklist

Here is a list that you can use for checking in case something does not work as you want it:

• Setup redirection parameters in "HKLM\SOFTWARE\d-fens\AppShadow"
• The correct version of ADVAPI32.DLL for the targeted operating system
• A redirection file APPNAME.EXE.LOCAL when running on Windows 2000
• ADVAPI32.DLL in the same directory of the program you want to redirect when running on Windows 2000
• ADVAPI32.dll put in ExcludeFromKnownDlls when running on Windows 2000 (with reboot)
• A redirection folder APPNAME.EXE.LOCAL when running on Windows 2003 or Windows XP
• ADVAPI32.DLL in a subfolder APPNAME.EXE.LOCAL of the program you want to redirect when running on Windows 2003 or Windows XP
• The correct version of ADVAPI32.DLL for the targeted operating system
• An NTFS hardlink "%SYSTEMROOT%\system32\ADVAPI32.DF" pointing to "%SYSTEMROOT%\system32\ADVAPI32.dll"
• What is logged via OutputDebugString? Does AppShadow tell you whether DLLs and exports could be loaded?

Which registry settings are needed for redirection?

Tough question. It depends on the application you want to redirect. A good thing could be to use an installation monitor that tracks changes in your registry. Import these settings into the AppShadow entry for your application and test it. Sometimes it will suffice to trace with Regmon to see what the application is doing.

 

Some final words

I believe that the features presented in this article should be made available by the operating system! Microsoft talks a lot about server virtualization and scalability. This would really add a benefit to Microsoft Terminal Services!

I know that some people would hesitate to use tools like AppShadow because of support or stability concerns. I do not say that this program is free of bugs but the whole mechanism is implemented in user mode. There is no reason to fear that this could crash your operating system! But, of course, I cannot take any responsibility if something works not as you expect.

When I came up with the idea for AppShadow my customer faced a problem that questioned the success of the whole project. When I first presented the workaround, he was not too pleased. But as it seemed to be the only viable option we had, he gave it a try. In the near future we discovered that we could "integrate" other misbehaving applications as well on our Terminal Servers that would not have been possible otherwise. Test and see for yourself. And of course, leave me a note if you have questions or suggestions (please mail to AppShadow at d-fens dot net).

 

Source: AppShadow

Fix: Microsoft Office 2010 Outlook 2010 Mouse Cursor/Pointer Display Issue in XenApp Session

Scenario:

When you setup Outlook 2010 in Citrix XenApp Server Desktop session and you launch the application for the first time within the session as end user.  You configure the Outlook to use the ‘No email support’ and use the ‘recommended settings’.  You notice that your mouse Cursor/Pointer Display doesn’t appear in Outlook application though it just works fine for other applications in the same server desktop session.

 

Fix:

Have the Outlook launched as the end user at least once in a full desktop (RDP or runas) locally on the server. So that Outlook will have all of the files updated and refreshed on the serve in order for proper rendering. Then launch the same desktop session and you’ll have the Cursor displaying fine for Outlook.

Known Issues with Chrome Automation using Send Keys

Some characters like ‘key’ and ‘keys’ cannot be typed into input field when using Selenium with remote control

SendKeys with long unicode characters cause firefox hung.

Sending ARROW_DOWN to Autocomplete Input Not Working on FF4

Send keys with a large string(~25,000) truncates string

onchange js event fired in WebElement.clear() and WebElement.sendKeys()

javascript onChange not fired when firefox isn’t active window

Java exception at client running grid node

Interactions – KeyPress with Click – Unexpected error

Firefox driver sending incorrect keycodes through for typing

Element is found, first send keys does not send keys Java/Firefox 6.0.2

Command is not allowed as a modifier key

Chrome unable to send keys to div without text field

Check field and submit button not working on Android 2.3.3

:: Failed to send keys because cannot focus element in Chrome ::

"UnhandledWebDriverError: Connection reset" error with Firefox but not IE

 

Source: Issues – selenium – Browser automation framework – Google Project Hosting

Troubleshooting Access Problems to Redirected/Virtualized/Symlinked locations in Windows

 

 

 

Help

You can see that BrokenAppNative is trying to create the file C:\ProgramFiles (x86)\BrokenApp\SomeFile.txt. This file is redirected to the VirtualStore folder, where the actual data file ends up.

Notice the Result column. The line where the result is “REPARSE” is the original operation. The next line with the result “SUCCESS” is the redirected operation.

Managing Folder Redirection using Junctions in Windows

In many cases with x64 bit platforms, administrators requires to redirect a folder location to some another location. This specifically comes in when there is a system wide folder that needs to be customized per user in which case, you require to redirect the default system wide folder location to point to a per user location.

 

Creating and using and deleting the folder junction using linkd:

C:\Test>dir
Volume in drive C has no label.
Volume Serial Number is CC0C-B792

Directory of C:\Test

02/03/2012  10:35 AM    <DIR>          .
02/03/2012  10:35 AM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  81,181,417,472 bytes free

C:\Test>linkd C:\Test\Redirect-to-MyFolder C:\MyFolder
Link created at: C:\Test\Redirect-to-MyFolder

C:\Test>linkd C:\Test\Redirect-to-MyFolder
Source  C:\Test\Redirect-to-MyFolder is linked to C:\MyFolder

C:\Test>dir
Volume in drive C has no label.
Volume Serial Number is CC0C-B792

Directory of C:\Test

02/03/2012  10:38 AM    <DIR>          .
02/03/2012  10:38 AM    <DIR>          ..
02/03/2012  10:38 AM    <JUNCTION>     Redirect-to-MyFolder [C:\MyFolder]
               0 File(s)              0 bytes
               3 Dir(s)  81,143,132,160 bytes free

C:\Test>dir C:\Test\Redirect-to-MyFolder
Volume in drive C has no label.
Volume Serial Number is CC0C-B792

Directory of C:\Test\Redirect-to-MyFolder

01/17/2012  01:10 PM    <DIR>          .
01/17/2012  01:10 PM    <DIR>          ..
01/17/2012  01:09 PM                 7 Test1.txt
01/17/2012  01:09 PM                 7 Test2.txt
01/17/2012  01:10 PM                15 Test3.txt
               3 File(s)             29 bytes
               2 Dir(s)  81,143,132,160 bytes free

C:\Test>dir C:\MyFolder
Volume in drive C has no label.
Volume Serial Number is CC0C-B792

Directory of C:\MyFolder

01/17/2012  01:10 PM    <DIR>          .
01/17/2012  01:10 PM    <DIR>          ..
01/17/2012  01:09 PM                 7 Test1.txt
01/17/2012  01:09 PM                 7 Test2.txt
01/17/2012  01:10 PM                15 Test3.txt
               3 File(s)             29 bytes
               2 Dir(s)  81,143,132,160 bytes free

C:\Test>linkd C:\Test\Redirect-to-MyFolder /d
The delete operation succeeded.

C:\Test>dir
Volume in drive C has no label.
Volume Serial Number is CC0C-B792

Directory of C:\Test

02/03/2012  10:45 AM    <DIR>          .
02/03/2012  10:45 AM    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  81,143,078,912 bytes free

C:\Test>dir C:\MyFolder
Volume in drive C has no label.
Volume Serial Number is CC0C-B792

Directory of C:\MyFolder

01/17/2012 01:10 PM <DIR> .
01/17/2012 01:10 PM <DIR> ..
01/17/2012 01:09 PM 7 Test1.txt
01/17/2012 01:09 PM 7 Test2.txt
01/17/2012 01:10 PM 15 Test3.txt
3 File(s) 29 bytes
2 Dir(s) 81,143,132,160 bytes free

C:\Test>

Modifying existing junction to connect to the different folder:

C:\Test>linkd C:\Test\Folder-Junction "C:\Program Files"
Link created at: C:\Test\Folder-Junction

C:\Test>dir C:\Test\Folder-Junction\mozilla*
Volume in drive C has no label.
Volume Serial Number is CC0C-B792

Directory of C:\Test\Folder-Junction

File Not Found

C:\Test>linkd C:\Test\Folder-Junction "C:\Program Files (x86)"
Link created at: C:\Test\Folder-Junction

C:\Test>dir C:\Test\Folder-Junction\mozilla*
Volume in drive C has no label.
Volume Serial Number is CC0C-B792

Directory of C:\Test\Folder-Junction

12/20/2011  08:54 AM    <DIR>          Mozilla Firefox
               0 File(s)              0 bytes
               1 Dir(s)  81,147,301,888 bytes free

C:\Test>

 

 

Junctions Work Across Users:

User1: Modifies the junction to point to a different folder:

C:\>linkd C:\Test\Folder-Junction
Source  C:\Test\Folder-Junction is linked to
C:\Program Files (x86)

C:\>linkd C:\Test\Folder-Junction "C:\Program Files"
Link created at: C:\Test\Folder-Junction

C:\>

User2: Junction point for user2 as well redirects to the newly redirected folder by user1

C:\Test>linkd C:\Test\Folder-Junction
Source  C:\Test\Folder-Junction is linked to
C:\Program Files (x86)

C:\Test>linkd C:\Test\Folder-Junction
Source  C:\Test\Folder-Junction is linked to
C:\Program Files

C:\Test>

Making Junctions Redirect to User Specific Location Per User:

 

Say you want to redirect a junction to user temp folder, junctions don’t help redirecting locations per user rather they operate across all users that is system wide.  In order to make junctions redirect to user specific locations, one has to map a user specific location to a static path something link subst. Such that the drive redirect to user specific locations.

User: TestUser1

C:\>whoami
TestUser1

C:\>echo %USERPROFILE%
C:\Users\TestUser1

C:\>subst R: %USERPROFILE%

C:\>dir R: | wc -l
18

C:\>linkd C:\Test\Folder-Junction R:
Link created at: C:\Test\Folder-Junction

 

C:\>dir C:\Test\Folder-Junction  | wc -l
18

C:\>

User: TestUser1

C:\>whoami
TestUser2

C:\>echo %USERPROFILE%
C:\Users\TestUser2

C:\>subst R: %USERPROFILE%

C:\>dir R: | wc -l
26

C:\>linkd C:\Test\Folder-Junction
Source C:\Test\Folder-Junction is linked to
R:\

C:\>dir C:\Test\Folder-Junction  | wc -l
26

C:\>

Configure Http(s) URL default launch program

Scenario: Sometimes even when you keep your default browser to IE, you notice that clicking on hyperlinks/URLs in applications like Outlook/Word launch them in a different browser say Firefox.

 

Cause: This happens because though you have IE as your default browser, the default programs for HTTP(s) are set to launch from other browser program say Firefox as shown below.

 

Fix: One has to explicitly set the default programs for HTTP(s) application types via Default Programs Control Panel applet as shown below: