Archive for September, 2013

Oracle Preview Virtual Machines on Windows Azure are now Available!

September 30, 2013 1 comment

Virtual Machines for Oracle are now available in preview. Microsoft and Oracle have combined to provide end-to-end support for customers running business-critical Oracle software on Windows Azure. Brad Anderson announced it at Oracle OpenWorld! View the video here:

This means the Oracle Database, Oracle WebLogic Server, and the Java development environment are now available, in preview, in the Windows Azure Virtual Machines Image Gallery. These images include licenses for the Oracle software that they contain.

During the preview period, there is no charge for the included Oracle licenses. You will pay only for the Windows Azure compute and storage resources that your Virtual Machine consumes. If you would prefer to use an Oracle software license that you already own, you can do that too. Just choose a Windows Server image from the Image Gallery and install the Oracle software yourself.

Whether you bring your own Oracle license or use one of the license-included images, you now have increased flexibility and choice in where to deploy your applications and the peace of mind that comes from knowing you will be fully supported by Oracle.

To get started, sign in to the Windows Azure Management Portal ( and add a new Virtual Machine from the Image Gallery. For more information, visit the Oracle information page ( on the Windows Azure website.
If you are new to Azure and an Oracle user looking to migrate to a cloud solution, check out this:

if you are looking for more technical guidance, i would recommend these links as a first start:

Deploy Pre-configured Oracle VMs on Windows Azure

For specific configuration and version information, use this MSDN reference:

Categories: Uncategorized Tags: , , , ,

App-V: On Registry Staging and how it can affect VDI Environments

September 25, 2013 15 comments


The App-V 5.0 Virtual Registry is isolated for each application (or virtual environment when using Connection Groups.) With this release, there is a better view into the Virtual Registry subsystem. In fact, the App-V 5 virtual registry is divided into two main parts: The Virtual Registry itself (VREG) and the registry staging subsystem.

The APPV package file is a human-readable set of assets. As many of you may have already figured out, you can simply rename the file to a ZIP extension and browse it from within Explorer. Some of you have discovered the hard ay that you destroy the package once you try to modify it this way. Yes – it is a mechanism for VIEWING ONLY.  If you have had a chance to do this, you have probably noticed that each APPV package contains its own registry hive file (.DAT)

This is where all of the registry assets captured during sequencing reside. When a package is being published, part of the overall package publishing includes the staging of the registry. Both registry machine data and user data will occur. The staging allows the virtual registry not just to be made available, but to also set up the opacity configuration and other important relationships with the native registry. This is to ensure that the applications have a consistent view of both. If you launch REGEDIT.EXE inside one of the App-V bubbles, you will see this converged registry.

If you are using a traditional App-V 5 server-based infrastructure, you might find yourself in an interesting situation. When synchronizing with a publishing server for the first time, all of the publishing blocks for all of the applications targeted to that machine or user will be passed down and each application will be published on the App-V client either to the user or globally depending on the target methodology. In addition to shortcuts, file type associations, and other extension point registrations, there will also be the staging of the virtual registry occurring in the background. This staging can produce some significant overhead during these sync and on first launch – and when many applications are being used (as well as applications with thick registries) this overhead can delay availability of those applications. This can be especially critical when using pooled VDI scenarios incorporating SCS (Shared Content Store) because you also have the additional overhead of sparse file creation.

Registry staging occurs upon the initial launching of a package if it has not been completed. It extracts the .DAT file from the APPV Package Root (which was copied from the APPV file) and then copies it again over to %PROGRAMDATA%MicrosoftAppVClientVREG. It will then mount the hive file through a background thread and recreate it in the package registry location inside the native registry. Registry staging will occur for both individual packages and connection groups. The time it takes depends on several factors including the size of the hive.

The native registry locations where these are stored are:


Package Registry Staging: HKLMSoftwareMicrosoftAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>

Connection Group Registry Staging: HKLMSoftwareMicrosoftAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>



Package Registry Staging: HKCUSoftwareClassesAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>

Connection Group Registry Staging: HKCUSoftwareClassesAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>

You will also be able to tell if the registry staging for a specific application has been completed as there will be an additional key called RegistryStagingFinished (beneath the <VERSION_GUID> entry.)  Registry staging can occur in the background or on-demand. In VDI environments, we are seeing heavy CPU utilization with background staging in some circumstances. You can gain significant improvement by switching to on-demand staging. You can do this by adding the following registry value in the HKEY_LOCAL_MACHINESoftwareMicrosoftAppVSubsystem key


Value: NoBackgroundRegistryStaging

Data Type: DWORD

Data: 1

This is showing to improve first launch experiences in App-V 5 VDI environments.


App-V 5: To Virtualize or not to Virtualize! How App-V 5 Answers that Question when you Launch a Shortcut

September 12, 2013 4 comments

Wow, that blog post title sounds like every formulaic business book title from the last twenty years. I should probably change it. I’ll worry about that later. For a change of pace, I am not going to write much on this subject because this is one subject that needs to be explained visually. So for the most part this blog post will be very little in the realm of text but hopefully a very ugly, yet hopefully very helpful picture.


In essence, AppV remains behinds the scenes. When the EXE is launched, the App-V virtualization manager receives a blocking callback function and triggers a series of verifications to determine if a process should be virtualized or not. This makes it very flexible especially considering you may be dealing with native EXE’s, EXE within the App-V VFS, potential co-existence with the 4.6 client. Hope this flowcharts helps to explain the process!

App-V: On COM Isolation and Interaction

September 11, 2013 8 comments


Through the history of Windows, the COM (Component Object Model) has been integral to application development the as an interprocess communication mechanism. The roadmap from DDE (Dynamic Data Exchange,) to OLE (Object Linking and Embedding,) to OCX (OLE Custom Controls,) to ActiveX – and so on – allowed and continues to allow multiple languages and development environments to develop applications on this language-agnostic platform.

Because COM facilitates communication channels and data exchanges between applications, it requires both significant consideration and planning when determining the feasibility of application virtualization. App-V has its own virtual COM subsystem which is designed to isolate the COM interactions from the local operating system. The primary way it does this is through GUID spoofing.

COM uses CLSIDs (Class Library Shell Identifiers) to identify all of its components and interfaces. These are labeled using GUIDs just as many other things are in Windows  Different component types are identified by class IDs (CLSIDs), which are Globally Unique Identifiers (GUIDs). Each COM component exposes its functionality through one or more interfaces ({7312498D-E87A-11d1-81E0-0000F87557DB} is my favorite because it is “blur.”) The different interfaces supported by a component are distinguished from each other using these identifiers. One of the strengths of App-V is that it prevents COM conflicts among native and virtual applications and among applications running in different virtual environments. App-V is also able to isolate native and virtual COM servers within a virtual environment.

When App-V hooks into a process, the virtual COM subsystem is able to intercept and virtualize COM object instantiations by dynamically cloning COM registration within the virtual environment using auto-generated CLSIDs and start instances of the cloned COM server. The GUID mappings will be maintained throughout the life of the process. While the hook model is different between App-V 4.x and 5.x, the overall process is very similar. When you combine applications into multiple virtual environments (DSC, Connection Groups) or package multiple applications together into a single package, all of these applications will still be able to communicate with each other at the application level through COM.

Basic Planning

For the majority of applications, you will likely only need to consider COM at a high level when planning. I like to use scenarios and I often do when I am explaining this to customers.


In the example above, we have a simple scenario. We have Application A (Word) and there is an embedded object type of Application B that can be inserted and modified leveraging the controls of Application B. Oldest and most known method as it goes all the way back to OLE. In the world of App-V this may still be needed with virtual applications. How do we facilitate this?

1.)    If your plan is that Application A is virtual and Application B is virtual – then you will have to either:

          Package Application A and B together in a single sequenced virtual application package

          Package Application A and B separately but join them via a unified virtual environment (using DSC with 4.6 or Connection Groups with 5.x.)

2.)    If your plan is that Application A is virtual and Application B will be locally installed – then you will need to:

          Configure COM integration/interaction with the local operating system. The method varies depending on the version of App-V you are using.

3.)    If your plan is that Application A will be local and that Application B will be virtual – then you will have to do one of the following:

          Create an extension point (shortcut) to the local application (A) within the configuration of the virtual application (B) and will have to launch the local application using that extension point so it will be hooked.

          Create an extension point (shortcut) to the local application (A) within the configuration of an otherwise empty virtual package. Bring that package and the virtual application (B) into the same virtual environment using DSC or a Connection Group (depending on what version you are using.)

          Use the “RunVirtual” registry key if you are using App-V 5.0 to allow the local process (A) to operate inside the virtual environment of the virtual application (B.)


Because some applications may still need to communicate with the local operating system, there may be the need to adjust and fine-tune COM behavior for certain applications (as in the case of #2 above.) App-V historically has had ways of doing this.



This is a tag in the XML configuration (OSD file) of an App-V 4.x application. Whehn this tage exists and is set to TRUE, this means that BOTH object/eventing virtualization (spoofing) and COM GUID virtualization (also spoofing) are turned off. This DOES NOT mean the virtual COM or the virtual object subsystems are turned off. The objects will still be looked up in the virtual environment, but if not found, App-V will revert to the native OS and look there as well. This is why it is usualy a fairly safe thing to implement. The primary App-V 4.x hook DLL (SFTLDR.DLL) is still injected with all of its subsystems.

To enable local interaction, the OSD VIRTUALENV element is configured as follows:




Objects/Eventing will be discussed more in detail and in a forthcoming post.


App-V 4.x: Disabling and/or Micromanaging Virtual COM

You can manage COM in more detail within App-V 4.6 by configuring the client registry. This is generally not preferred as it globally affects the App-V Client where LOCAL_INTERACTION_ALLOWED applies only to the application package. If you want to disable the Virtual COM subsystem, you can navigate to the following registry key and set the following value:


Value: DisableGuidMapping

Data Type: REG_DWORD

Value: 1

Outside of troubleshooting, I find it illogical and dangerous to disable this as a solution to any virtualization problem. I would only advise doing this as a troubleshooting step. Once you realize what may be happening you can simply apply a more granular approach to permanently fixing the solution by excluding COM GUID spoofing for the troublesome application. You do this through COM exclusions. First create a subkey called ComExclusions beneath:


Then create a value called “Exclusions” with a data type of REG_MULTI_SZ and then you will list all of the CLSID GUIDs that you want excluded on each line.

The App-V 5.0 Virtual COM Subsystem

COM integration in App-V 5 does out-of-process (its own process) and in certain cases – in-process (within a process) COM registration (Office 2013 Click2Run.) COM is also handled a little more granularly in the dynamic configuration files in App-V 5.0. This is to encourage more handling of COM through configuration policy on a per-package or per-connection group basis. Within this policy, you can set one of three modes:

  • Off
  • Isolated (Virtualized)
  • Integrated (through in-process or out-of-process registration.)

The overall effects are outlined in the following boring chart:


 COM Mode in XML

 OS Integration

 COM Virtualization

     <COM Mode=“Off”>


 No integration


     <COM Mode=“Isolated”>


 No integration

 On – w/ GUID Spoofing

     <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”false” InProcessEnabled=”false” />


 No integration

 On – no GUID Spoofing

     <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”true” InProcessEnabled=”false” />


 Integrate out-of-process

 On – No GUID Spoofing

     <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”false” InProcessEnabled=”true” />


 Integrate in-process

 On – No GUID Spoofing

     <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”true” InProcessEnabled=”true” />


 Integrate both

 On – No GUID Spoofing


I felt it important that you get a sense of all of the possible permutations of COM policy configuration. Especially if you are toggling the sequencer defaults in the “Advanced” tab. All this does is set the default policy in the dynamic configuration file (deployment_config.xml) generated by the sequencer.


When “Allow all COM Objects to interact with the local system” is turned off, the COM policy will default to:

    <COM Mode=”Isolated”>


When turned on (checked) it sets it to:

    <COM Mode=“Integrated”>

      <IntegratedCOMAttributes OutOfProcessEnabled=”false” InProcessEnabled=”false” />



COM Mappings and Exclusions in App-V 5.0

COM GUID Mappings are stored in a COM Class Maps located in the following registry locations:

Per User:


Per Machine:


These are helpful when troubleshooting COM. Like 4.6, you can also add individual exclusions within the registry by adding the GUID as a REG_SZ value in


Use the value itself to give a description for humans to read 🙂 For example:

   Value: HKEY_CLASSES_ROOTCLSID{7312498D-E87A-11d1-81E0-0000F87557DB}
   Data Type: REG_SZ
Data: Blur

Categories: Uncategorized Tags: , ,

App-V: On Virtualizing Multiple Excel Add-ins

September 4, 2013 11 comments

Yes, I’m still obsessed with the subject of add-in virtualization. I felt it also necessary to ensure that there was a discussion of add-in types and multiple Office add-ins (particularly Excel) before I finally leave this topic of discussion. Have you ever noticed that when you are managingloading add-ins in Excel that you have multiple distinct types of add-ins. The two most common types are COM add-ins (common format for 3rd-party applications) and Excel Add-ins or what we refer to technically as Automation Add-ins (VSTO, XLAM add-ins.)


COM Add-Ins

COM add-ins act as in-process COM servers (like an ActiveX DLL) that is built off the IDTExtensibility interface. These are pretty much event-driven and present themselves to the user in the form of custom menus, commands, etc. When a COM Add-in is installed on a user’s system, registry entries are created for the Add-in. In addition to normal COM registration, a COM Add-in is registered for each Office application in which it runs. COM Add-ins used by Excel are registered in the following registry key:


For example, if I have an Add-in called “Data Transfer Excel Add-in.” it would register in a key similar to the image below:


NOTE: Do not get confused. This registration may be used with the other add-in registrations that Office applications may use (in the HKLM or the HKCUSoftwareMicrosoftOffice<VERSION><App>Addins key.) That can also be a source of troubleshooting sometimes.

Dynamic Configuration is important when leveraging an add-in when it comes to COM settings. If the Add-in will be packaged with the application, it should remain isolated – which is the default. If the add-in is virtualized but Office is locally installed, then the COM add-in must have its COM mode configured as “Integrated” with in-process registration. If you are linking the add-ins with a virtual instance of Office via a connection group, this is also recommended (using the element “<COM Mode=”Integrated”>”)

NOTE: LOCAL_INTERACTION_ENABLED set to TRUE in the 4.6 OSD file achieves this same result.

Automation Add-Ins

Automation Add-ins build on COM Add-ins in that functions in Automation Add-ins can be called from formulas in Excel worksheets. While COM Add-ins must be in-process COM servers that support the IDTExtensibility2 interface; however, Automation Add-ins can be in-process or out-of-process COM servers and implementation of IDTExtensibility2 is optional. Understanding what type of COM server will determine how the add-ins COM configuration may need to be configured in the applications dynamic configuration file.

Order of Add-Ins

When you make additions to the list in the Add-Ins dialog box or when you select and clear Add-ins in the list, Excel stores your changes in the registry. First, Excel uses the following registry setting to determine whether or not an Automation Add-in in the Add-in list is loaded:

Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice<VERSION>ExcelOptions

String OPENx (where x is the numerical order.)

Sample Value: /A “ServerName.Classname”


Note: The /A switch denotes it is loading an automation add-in *AND* unlike COM Add-ins, automation add-ins are loaded on demand so the LoadBehavior registry key is not necessary for these types of add-ins.



When an Automation Add-in that is listed in the Add-Ins dialog box is cleared, a subkey with a name equal to the Add-in’s Program ID is created in the following registry key:

HKEY_CURRENT_USERSoftwareMicrosoft<VERSION>ExcelAdd-in Manager

This registry setting ensures that Automation Add-ins that you have added to the Add-ins list are retained in the list even when you have chosen not to load them. Both the Add-in Manager and OPENx registry settings need to be managed properly when virtualizing add-ins.

Caveats when Virtualizing Multiple Add-ins with App-V

When Excel loads these automation add-ins it will expect to see a ordinal series of OPEN entries in the registry (OPEN, OPEN1, OPEN2, OPEN3, etc.) If it is the first add-in to be installed, the registry value created will be “OPEN.” When the second add-in is installed, it will register “OPEN1.” The third add-in installed will then register “OPEN2” and . . . well, you get the idea.

So here is the problem that often arises: Let’s say you are virtualizing three Excel Add-ins separately and you want to link them with a virtualized Office package (or even linking local Office by pulling into an empty package and linking that with these three add-ins.) Chances are the first time you do this, you will fail – as the case with many of us.




If I sequence all of these add-ins separately and link them all with Office through a connection group, I have the following factors to consider with regards to these overlapping OPEN values:

  • Registry opacity within the add-in package
  • Resultant registry opacity upon Connection Group deployment

During sequencing, the normal behavior to determine default registry opacity goes as follows:



This of course, can be adjusted using the virtual registry tab within the sequencer. If you virtualize each add-in separately (which is normal) and add the add-ins into Excel with each sequence, you will find that each one appears as an OPEN registration. When you combine the add-ins together, you will likely find only one of the add-ins working upon first launch.




Another problem to avoid but one that is less likely to occur is to ensure that your OPEN registrations are in a direct sequence (OPEN, OPEN1, OPEN2, etc.) They have to be consecutive. If you have OPEN, OPEN3, OPEN5, etc. configured then you find Excel stops loading after the first one because OPEN2 is missing.

What I am Currently Doing

I take advantage of the knowledge of knowing that when you use Connection Groups, the number one entry in <appv:packages> section of the Connection Group XML descriptor document takes precedence. So if I were to employ a connection group that contained a local instance of Office, I would simply import a custom REG file containing the OPEN registrations in the correct order into an empty package (during sequencing) that also contains the shortcut extension points to the local Office applications. I then ensure that the empty package is at the top of the order within the Connection Group.


  <appv:Package DisplayName=”Local Office” PackageId=”<GUID>” VersionID=”<GUID>”/>

  <appv:Package DisplayName=”Add-in #1” PackageId=”<GUID>” VersionID=”<GUID>”/>

  <appv:Package DisplayName=”Add-in #2” PackageId=”<GUID>” VersionID=”<GUID>”/>

  <appv:Package DisplayName=”Add-in #3” PackageId=”<GUID>” VersionID=”<GUID>”/>




You have to ensure that the resultant virtual registry used by the parent Excel application has a correct OPEN sequence of registrations. You also have to ensure that the opacity will not conflict with any local registrations. Keeping these things in mind, I have the following recommendations when I am devising a add-in strategy for my customers.

Virtualize NO Excel automation add-ins.


Virtualize ALL Excel automation add-ins. Use Connection Groups to bridge a local or virtual Excel instance or package everything together if necessary,