Virtualising Office 2010

Posted: May 2, 2011 in Uncategorized

The following is a guest post from my colleague Owen de Mooy, Systems Consultant at Dimension Data NZ on the pro’s and con’s for virtualising Office 2010 with Microsoft App-V.

The virtualisation of standard/core version of Microsoft Office (in this case Office 2010) requires careful consideration as Office is unlike most other applications. To start with Office functionality can be extended with a large number of third party plugins (such as CommVault, PIE), or leveraged by many other applications (such as SAP). Office also ties in with many underlying operating system components (such as additional control panel’s, API calls etc.).

To effectively virtualise the standard/core version of Office customers need to look at these plugins, applications and OS integrations pieces, and evaluate how virtualising Office affects them. There are many published articles on how to virtualise Office and the benefits it delivers. But many of these articles fail to address or provide guidance on how to handle any short comings, or even what short comings there are.

Based on feedback from existing customers and anecdotal evidence from the Internet we know the following areas are affected by virtualising the standard/core Office suite:

Third Party plugins such as CommVault or PIE interact with Office in different ways some are launched from a special icon, whilst others are automatically loaded by an Office application on launch. Virtualising Office removes the plugins ability to interact with Office (as by design virtualised applications are isolated from the rest of the system). To elevate this issue Microsoft provide a solution to link APP-V packages together (called the Dynamic Suite Composition (DSC) tool) allowing two separate APP-V packages to interact and see each other.

This approach has the following pro’s:

  • Allows the creation of separate APP-V packages for each plugin, that can still communicate with Office
  • Plugins can be easily upgraded

 
 

This approach also has the following con’s:

  • New/changed plugins need to be registered against the APP-V package, this means a minor update to the Office APP-V package which then needs to be redeployed to all workstations
  • All plugins need to be virtualised using APP-V to ensure they can be linked and interact with the Office APP-V package

 
 

For more details on how the linking of APP-V packages work please review the following link: http://technet.microsoft.com/en-us/library/cc843662.aspx

Applications that use Office as middleware,
such as SAP, leverage components within Office. These are similar in nature to a plugin but typically launch Office from within the application (instead of plugins which are launched by Office). As with plugins when Office is virtualised it removes the ability for the application to interact with Office. But in this case the DSC tool provided by Microsoft to link APP-V packages cannot be used, as they specifically mention the following:

“A primary package can have more than one secondary package. However, only one level of dependency is supported, so you cannot define a secondary package as dependent on another secondary package. Also the secondary application can only be middleware or a plug-in and cannot be another full software product.” 

To work around this issue most organisations are sequencing applications that interact with Office with a copy of the Office applications within the APP-V package (e.g. SAP with Microsoft Office Excel).

This approach has the following pro’s:

  • Applications dependent on specific Office product versions can still be sequenced within the same APP-V package
  • The standard/core version of Office can easily be changed without affecting applications that rely on Office, as the specific version of the Office application is/can be included in the respective APP-V packages

 
 

This approach also has the following con’s:

  • Management of the APP-V packages become more complex as some APP-V packages will contain both the specific application and its associated Office application. Changes to either the application or office application will result in the whole APP-V package needing to be re-sequenced

 
 

Microsoft have also published a knowledge base article about the known limitations of virtualising Office. These mostly relate to the inability of applications to interact with a virtualised Office install. This mostly relates to Microsoft products, but still provides a useful insight into some of the pitfalls of virtualising Office: http://support.microsoft.com/default.aspx?scid=kb;EN-US;2481474

Patch Management using existing tools such as SCCM or Windows Update is not possible as the APP-V package is isolated from the operating system. The only way to update or Service Pack Office would be to re-sequence Office with the new updates or service packs.

There are no real pro’s to this situation, as the process to patch Office would become totally manual and require re-sequencing and deployment of the APP-V package to all workstations. Although the auto-update and streaming capabilities of APP-V do alleviate that situation.

By not virtualising Office customers are able to experience the full Office 2010 experience without any limitations, whilst still benefiting from the use of APP-V to:

  • Virtualise applications, even those that rely on the locally installed Office as by default if an application looks for components or software not included in the virtualised package they can fall back to the locally installed components. For example a virtualised package of SAP GUI 7.20 could still leverage the local install of Office 2010

     

  • Virtualise applications which require older versions of Office, by including the older version of Office within the virtualised package. Applications such as SAP GUI 7.10 which do not support Office 2010 could be virtualised with an older version of Office (e.g. 2007) without impacting/conflicting with the locally installed copy of Office 2010

     
     

This approach has the following pro’s:

  • APP-V can still be used to virtualise any application, even those that interact with Office 2010
  • Applications that rely on older versions of Office can be sequenced with APP-V with the older version of Office included without conflicting with Office 2010
  • The locally installed copy of Office 2010 can be patched and updated using existing tools such as SCCM or Windows Update

 
 

This approach also has the following con’s:

  • Office plugins cannot easily be virtualised, as they are typically launched by an Office application on launch, and virtualised plugins would not be visible to the Office application to launch it
  • Upgrades to a new standard/core version of Office would require an uninstall and install of the new version. This would potentially not be as clean as the removal of a virtualised instance of Office

     
     

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s