With enterprise IT modernization projects on the rise, companies are faced with the dilemma that presents itself when older versions of Microsoft Office applications are required to run add-in components for software programs which are critical to the continuity of business operations.
Many corporations have begun the process of modernizing operating systems from Windows® 7 to Windows 10 and upgrading their software from Office 2010 or Office 2013 to the latest version available from Office 365. These upgrades typically break the functionality of outdated Office add-ins. Furthermore, these legacy add-in components are often tied to a specific version of Office software, and they are mission-critical to the company’s line of business. This applies to older versions of Office (Word, Excel, and Access), including Office 2007, Office 2003, and even Office XP, creating a difficult challenge during migration projects requiring the support of these older addins. Supporting these add-ins is a significant reason for companies to continue running older versions of Office.
Problems Installing Legacy and Current Versions of Office Simultaneously
Considering how deeply Office integrates into Windows, running multiple versions simultaneously with success is difficult to achieve. The problem begins with having to install Office in a very specific sequence to allow the installation of multiple versions by the installer1. Additionally, Microsoft does not permit the installation of Office 32-bit and 64-bit on the same system2. This is because shared files, file associations, and other integration features may fail when legacy Office versions are physically installed. In other words, Microsoft is preventing installations that may result in issues with Office functionality.
Managing Multiple Installs of Different Office Versions
Companies will often have a current, supported version of Office (such as 2016) deployed throughout the enterprise, meaning that all users will have a current, updated version of Office when they receive their computer. Although Office components utilize Windows side-by-side (WinSxS) that allows multiple versions of Office to run on the same system, WinSxS does not help making multiple Office installations any easier to deploy and use. In order to install an older version of Office, an administrator must follow a series of time-consuming steps. Take, for example, the installation of Office 2010 on a system running Office 2016. In this scenario, the administrator must first uninstall Office 2016, then install Office 2010, and finally reinstall Office 2016. This wastes time for not only the administrator, but also the end user who will not be able to use either version of Office during this tedious and time-consuming process.
Additional challenges present themselves in the above scenario, including the need to train the end user on how to choose the correct version of Office required for their given task. Because the installation of Office creates, by default, all of its associated shortcuts in the Start Menu, a user may inadvertently click the wrong version of Office required to access a specific document. It is possible that the Office 2010 application could corrupt a newer file or that a newer version of Office could corrupt a file requiring Office 2010.
Office 2010 will reach its end-of-life (EOL) in 2020,3 joining older versions that have already reached the point of no longer being supported by Microsoft. When software reaches end-of-life, not only does it stop receiving feature updates and fixes, but it also stops receiving security updates. Due to security risks, most enterprises will elect to discontinue the delivery of EOL software to endpoints, avoiding any potential vulnerabilities that could arise. This decision can present a problem for enterprises with critical, line-of-business add-ins which require an older version of Office to function.
One of the solutions to this problem includes creating a virtual machine for the sole purpose of running the legacy software. This, too, has its own set of issues due to the difficulty of working with and sharing multiple versions of Office documents. Other solutions include upgrading the legacy software applications requiring older Office add-ins. This can be a very expensive and time-consuming process as it may involve updating other tangential applications and requiring a great deal of financial and human capital.
The Cloudpaging Solution
As the flagship technology of granular-level control over isolating components within a container, Cloudpaging allows the concurrent use of legacy and modern versions of Microsoft Office within a modern Windows operating system. Better yet, it enables the running of legacy 32-bit Office component with add-ins alongside a modern 64-bit Office suite. This is possible because Cloudpaging technology addresses and manages both integrated and isolated elements of an application package. Cloudpaging has the unique ability to hide elements from Windows including, but not limited to, file extension associations, shortcuts from the Start Menu, or desktop icons.
Similarly, Cloudpaging makes it possible for legacy Office add-ins to print to PDF, integrate with SharePoint, and more. The granularity of control over the application packaging process allows the packager to provide a user experience that reduces confusion, thereby eliminating the need for additional user training and bypassing the time-consuming uninstall, install, re-install process.
The advanced container features of Cloudpaging technology also allow for these legacy add-ins to be hidden from the modern Office version. This allows the modern version of Office to run without complications stemming from legacy add-ins being available for installation. Because add-ins are also designed to interface with the operating system, certain legacy versions may lack compatibility with newer operating systems. By using Cloudpaging to intercept and remediate legacy system calls, add-in compatibility is greatly improved. Showstoppers such as issues with hardcoded paths, short file names, and DLL redirection can all be remediated within the application package.
The isolation controls of Cloudpaging allow older versions of Office applications to be encoded for use within specified line-of-business purposes only, so they are never exposed to general usage. All file associations and general document usage, API or COM calls, and automation hooks will only be exposed for the current Office version, which is fully supported and maintained by Microsoft.
Once packaged with Cloudpaging, Office can be deployed in several ways using industry-standard electronic software distribution (ESD) solutions, including Microsoft System Center Configuration Manager (ConfigMgr or SCCM), to make deployments easier in any environment. With Cloudpaging, time is never wasted with installs or uninstalls. Using Cloudpaging’s native API’s, either directly or via PowerShell, administrators can quickly add or remove packages. This ease of management facilitates the running of legacy software only when needed, thus reducing the risk of a potential exploit affecting Office.
Many enterprises have a need to continue running legacy versions of Office. Their line-of-business applications may require the use unsupported add-ins. Or, they may be working with custom files which were built on a legacy version of Office. They may also be transitioning users to a newer version of Office (or add-ins). However, deploying and running legacy and modern versions of Office side-by-side can be cumbersome and restrictive due to many limitations imposed by Microsoft. During transitionary periods, IT departments can spend substantial amounts of resources to fix this problem by upgrading expensive add-ins, paying for development work, or introducing solutions that come at the cost of a bad user experience. These limitations can be defeated with the help of Cloudpaging’s granular-level control over application packaging, unique isolation options, superior application compatibility, and simplified deployment and removal processes.
To learn more about Java packaging technique using Cloudpaging, contact Numecent.
ABOUT THE AUTHOR
Giovanni Olivera is the lead packager at Numecent. He has been with Numecent since 2015 and provides packaging support and training for our customers. He has 17 years’ experience in the software support field. Giovanni has a BS in Information Technology from the University of Phoenix.