Visual Basic 6.0 Application Availability with Microsoft Virtualization

Microsoft Corporation

April 2008

Summary: This article will provide guidance for companies that want to keep some of their Microsoft Visual Basic 6.0 assets operational and available indefinitely, while mitigating the risks that are inherent in running legacy technologies in a modern environment. (21 printed pages)

Contents

Introduction

Legacy Visual Basic 6.0 Applications

Challenges of Keeping Legacy Applications

Virtualization "Panacea"

Overview of Virtualization Technologies

Hardware Virtualization

Presentation Virtualization

Application Virtualization

Applying Virtualization Technology to Legacy-Application Examples

Conclusion

Introduction

The Visual Basic 6.0 product line is now more than a decade old, and the majority of Visual Basic 6.0 customers and developers have adopted the .NET Framework and are in the process of, or have already completed, the migration of their key Visual Basic 6.0 assets. Still, many companies retain a valuable portfolio of stable, legacy Visual Basic 6.0 applications that they would like to continue to support in Visual Basic, either for a year or two while other applications are migrated, or for many years.

This article will provide guidance for companies that want to keep some of their Visual Basic 6.0 assets operational and available indefinitely, while simultaneously mitigating the risks that are inherent in running legacy technologies in a modern environment.

Legacy Visual Basic 6.0 Applications

Prior to the introduction of the .NET Framework, Visual Basic 6.0 was the tool of choice for many organizations building LOB applications, because it provided developers with a highly productive and efficient tool for building "forms over data" applications. Vast numbers of Visual Basic 6.0 applications were built, and these applications remain mission-critical components of IT infrastructure for many businesses.

Maintaining instead of replacing these legacy applications is valid for a variety of business reasons, including:

1. The applications are currently working properly and meeting existing business needs. A replacement would offer no new business value.
2. The applications are large and need to migrate gradually, with much of the existing legacy code base remaining in production for many years.
3. The internal functioning of the application no longer is well-understood. Relearning the internal functioning would be costly, and the odds of misunderstanding the internal operation of the application would be high—making migration risky.
4. The legacy applications have deployment challenges, namely DLL hell, that are becoming increasingly difficult to manage as other software is upgraded, updated, patched, etc.
5. The company wants to consolidate its physical servers, but can’t because legacy applications require older, less efficient hardware.

With IT organizations being tasked to enable new business strategies and increase operational efficiency, the migration of working applications might not be the best use of scarce resources. In addition, most IT organizations can relate to the experience of an application rewrite project gone awry: As Bjarne Stroustrup commented, "Legacy code often differs from its suggested alternative, by actually working and scaling." The trend of failed rewrites is so prevalent that it has led to a shift in thinking about legacy applications, and brought about the notion of "legacy modernization" instead of costly and constant wholesale replacement.

Challenges of Keeping Legacy Applications

The inherent risk in maintaining a portfolio of legacy applications is that they might prove incompatible with newer versions of commercial software. In the case of Visual Basic 6.0, while Microsoft is committed to supporting Visual Basic 6.0 applications through the life cycle of Windows Vista and Microsoft Windows Server 2008, many Visual Basic 6.0 applications rely on components and software manufactured by third-party technology companies. Some of those third-party components might become (or already are) incompatible with both operating systems, and there is no guarantee that those third-party software vendors will provide newer versions of their components.

In the case that third-party vendors do manufacture newer software, it might not be compatible with a legacy Visual Basic 6.0 application, a situation which could prevent the company from upgrading users to newer software that provides real productivity gains.

While most Visual Basic 6.0 applications should not present this kind of dilemma, when one does, it leaves IT organizations choosing between the lesser of two evils. Either the IT organization potentially traps a segment of their users on older software required by the legacy application, or the IT organization is forced to rewrite legacy applications, at high risk and cost, not because of any new functionality required for the legacy application, but simply to remove the legacy application as an obstacle to larger IT strategies.

Summary guidance

There are four main technological choices for virtualization:

1. Virtual PC, where the virtual computer is hosted on an end-user’s machine. While this requires extra end-user training and high-end computing resources on the client, it keeps IT support to a minimum and comes closest to replicating the original application environment without additional expenditures
2. Virtual Server with Terminal Services, where the virtual computer is hosted on a server and delivered to end-users via terminal services. This works better in an environment where end-user computing resources are limited and there are a large number of users.
3. Application Virtualization, where the application layer itself is virtualized, not the entire operating system. This approach works best when a widely-used application is incompatible with modern software, but where extensive application use of local computing resources like the registry, local temporary files, etc. makes Virtual Server with Terminal Services impractical.
4. Finally, if the application has no compatibility issues and is easy to support, simply leave it as is.

There are many reasons an organization may choose to use virtualization technologies, but in the context of Visual Basic 6, there are five main areas an organization should consider:

1. Is the application incompatible with modern software that must be in place on end-user machines?
2. How many application end users are there?
3. What are the costs of supporting the existing, unvirtualized application on end-user desktops?
4. Does the application have personalization, registry, local file access, or other features that make it impossible for each end-user to run the application on a single machine?
5. What kind of computers do end users have? Can they support a Virtual PC?

These five factors, while not an exhaustive list, should help organization determine how to assess which virtualization technologies are the best fit for their environment. The following table gives a summary of how these five different factors relate to virtualization options.

Application Factor	Leave in place	Virtual PC on Client	Terminal Services & Server Virtualization	Application Virtualization
Application incompatibility with modern software	No	Yes	Yes	Yes
Number of end-users	n/a	Few	Many	Many
Support/Deployment Costs	Low	Moderate	High	High
Application has personalization or local-state requirements	Yes	Yes	No	Yes
Users have high-powered, modern computers	n/a	Yes	No	n/a

Legacy-Application Examples

Beginning from the assumption that the preservation of legacy applications is (and always has been) a completely normal and typical responsibility of IT organizations, this article will walk through concrete tactics that can be used to preserve the Visual Basic 6.0 application investment of a company, while mitigating the risks of keeping older software running. For the purposes of illustration, this article will consider a number of "typical" application types, and focus on how to preserve and keep them available.

Application #1: Stand-Alone Desktop Application

Stand-alone desktop applications are applications that users run to perform processing on their local computers. Common examples would include image viewers, text-file editors, and even complex applications such Microsoft Office Word and Office Excel.

A prototypical example of a stand-alone Visual Basic 6.0 application:

• Processes text files that are exported from a mainframe, and generates monthly reports.
• Must be installed on the computers of three users: one person who has the primary responsibility of generating the reports, a backup resource who can generate the report when the primary individual is unavailable, and their manager.

The application is not compatible with Windows Vista, because it reads from and writes to files under C:\ and other directories that are protected in Windows Vista. There are too many hardcoded file paths to fix easily, and the security policy of the company requires users to run User Access Control (UAC) and log on as non-administrative users.

Figure 1. Example stand-alone Visual Basic 6.0 application

Application #2: Client-Server Application

Client-server applications—perhaps, the most common Visual Basic 6.0 application type–consist of a desktop application that communicates with a back-end database. Typical examples include order-entry applications, customer relationship management (CRM) systems, resource management, and many other forms of LOB applications.

The example client-server application is a sales-support application that tracks communications between sales representatives and clients. The application is specified as follows:

• The client user interface (UI) is installed on the computer of each sales representative; there are 30 sales representatives. It is rare for more than five people to use the application concurrently.
• The application does not maintain any state—such as registry keys, local files, and so forth—on the host computer. In other words, the application could have multiple instances running on the same computer without a problem.
• While the client application itself is compatible with Windows Vista, there are many critical forms that use a complex, third-party ActiveX control that does not run on Windows Vista. The company that built the control is no longer in business, and the control is used so frequently in the application that it is not feasible to remove it.
• Each client connects to a back-end Microsoft SQL Server 7.0 database (SQL Server 7.0 is not supported on any operating system (OS) after Windows Server 2000). While the company could upgrade to a more recent version of SQL Server, it has decided not to, for the time being.

Figure 2. Example client-server Visual Basic 6.0 application

Application #3: Three-Tier Application

Some Visual Basic 6.0 applications are more complex than client-server architectures; this application is divided into three (or more) tiers. The first tier is the client UI, which is installed on the desktop of each user. The middle tier contains business rules, which are implemented often as COM components. The business rules communicate with the back-end database.

Three-tier applications can be used for the same scenarios as two-tier applications (ERP, CRM, and so forth); however, three-tier applications typically are more complex, serve more users, and benefit from having centralized business rules.

The example three-tier application is a help-desk application that is specified as follows:

• The application is mission-critical and must have near 100 percent uptime.
• The client UI is implemented in Visual Basic 6.0; it is installed on over 200 user computers in a call center that is running Windows 2000.
• The application uses registry keys and local files on the host computer for personalization and customization purposes.
• The business rules are implemented in C++ and installed on a COM+ application server.
• The back-end database is implemented as a SQL Server database.
• Preliminary testing suggests that the application would run seamlessly on Windows Vista, but the computer hardware of the call center is at least six years old and not Windows Vista–compatible. The company does not want to purchase new computer hardware just to keep the Visual Basic 6.0 application on a supported OS.

Figure 3. Example three-tier Visual Basic 6.0 application

Virtualization "Panacea"

Virtualization has emerged most prominently as a technology for consolidating servers. In its most common form, physical servers are converted to "virtual" servers—allowing multiple virtual servers to coexist on a single physical computer. This alone is transforming data centers and wringing more use out of each costly square foot.

Virtualization is also a way to preserve legacy applications. A notable early use was running Microsoft Windows NT 4.0 servers as virtual machines, allowing Windows NT 4.0 to run on physical hardware for which there are not (and will never be) Windows NT 4.0 drivers. For the purposes of preserving Visual Basic 6.0 applications (and their required back-end servers), virtualization can be used to solve the following specific problems:

• Allow users to run legacy applications that are not compatible with the current OS (for example, Windows Vista) of the user.
• Allow users to run applications that depend on outdated software.
  For example, a legacy application might depend on Microsoft Office XP or Microsoft Internet Explorer 5.0. Virtualization allows a user to continue using these applications, even if the user has upgraded to Office 2007 or Internet Explorer 7.0.
• Eliminate the need to dedicate physical servers to run legacy back-end software.
  Legacy software might require outdated operating systems, such as Windows 2000 or Windows NT 4.0. Legacy software might require other legacy back-end servers, such as SQL Server 7.0. The last thing that IT organizations want to do is keep old 32-bit hardware in operation—consuming valuable data-center space just for such legacy applications. These older systems might not support newer, more efficient backup and recovery technologies, hardware, and so forth—which relegates these systems to "one-offs," from an IT perspective.

Overview of Virtualization Technologies

Virtualization is a broad term that applies to a set of technologies that can abstract one or more layers of the computing stack and ensure that an environment that is compatible with legacy applications is available indefinitely.

Various virtualization technologies address different potential needs of legacy applications. These virtualization technologies can be divided into three broad categories:

• Hardware virtualization
• Application virtualization
• Presentation virtualization

These categories will be analyzed individually for the solutions that they provide, and then combined to solve more complex scenarios as efficiently as possible.

Hardware Virtualization

Hardware-virtualization technologies allow you to run multiple "virtual machines" on a single physical computer by abstracting the computing hardware—including CPU, memory, mass storage, network interface cards, and so forth.

Figure 4. Multiple virtual machines running simultaneously on a single physical computer

Each virtual machine provides a basic set of virtual hardware that mimics, or passes through, to the physical hardware. Software that is running inside of a virtual machine sees a CPU, memory, disk drives, network adapters, and other hardware—just as software that is running on a physical computer would.

The OS and software that are running on a virtual machine effectively behave as though they were running on a physical computer. The OS and software are installed and configured just as they would be on a physical computer. The virtual machine gets its own IP address, sees its own drives, and so forth. Virtual machines can exchange data through networks by using standard protocols, such as HTTP, FTP, and SMB. Virtual machines that are running Microsoft Internet Information Services (IIS) appear on the network as any other Web server, and virtual machines that have SQL Server installed on them appear on the network as any other SQL Server. Legacy applications that are running on virtual machines can connect to databases, Web sites, network shares, or any other resources, without requiring any modification to the legacy application.

The following table shows an example of the hardware on a host computer, and how that host hardware might be represented in the virtual machine (the actual hardware that is seen by the virtual machine can be controlled by the administrator).

Physical hardware in host computers	Hardware seen by virtual machine
Quad core processor	Single processor
32 gigabytes (GB) of physical memory	2 gigabytes (GB) of physical memory
Four 250-GB hard drives	One 80-GB hard drive (implemented as a .vhd file that resides on one of the physical drives)
1-GB Ethernet adapter	1-GB Ethernet adapter (provides direct access to the physical adapter)
One DVD/CD-ROM drive	Emulated CDROM drive mapped to an .ISO image residing on one of the physical disks

When a virtual machine accesses hardware, requests are routed through a virtualization layer that is called Virtual Machine Monitor (VMM). The VMM translates calls to virtual hardware into calls to physical hardware. There are two kinds of VMM:

• Hosted VMMs that run on an existing OS—This is the approach that is used by Microsoft Virtual Server 2005 running on Windows Server 2003 software, and Microsoft Virtual PC 2007 running on Windows XP or Windows Vista.
• "Hypervisors" that run directly on the hardware—Instead of the computer starting a traditional OS, such as Windows, the computer instead starts the hypervisor. All other operating systems run on top of the hypervisor as virtual machines. (This kind of VMM is coming in Window Server 2008, with the code name "Hyper-V" technology.)

If multiple virtual machines are running on a single physical server, they are isolated from each other. Any event that happens inside one virtual machine (for example, a virtual machine restarts, or its OS crashes) does not affect other virtual machines or the host computer.

The hard drive for a virtual machine is simply a file that has a .vhd extension. To back up the virtual machine, you just make a copy of the file to another disk, or tape. To move the virtual machine, you just copy the file to another computer.

Hardware Virtualization for Legacy Applications

If, for whatever reason, a legacy application is not compatible with a new OS (for example, Windows Vista or Windows Server 2008), you can create a virtual machine, install a compatible OS in the virtual machine, and then install the legacy application. This allows the application to run in an isolated and completely compatible environment, even as your IT organization upgrades to the latest hardware and rolls forward to the latest operating systems. Hardware virtualization is the easiest and most certain way to preserve legacy applications and make them available.

Microsoft provides three hardware-virtualization products:

• Virtual PC 2007
• Virtual Server 2005 R2
• Windows Server Virtualization (currently, in beta and code-named "Hyper-V")

Virtual PC 2007

Virtual PC allows you to run virtual machines on your local desktop. Specifically designed to support older desktop operating systems on newer operating systems and hardware, Virtual PC 2007 is available for Windows XP and Windows Vista host operating systems. It offers performance improvements, such as support for 64-bit virtualization hosts and for first-generation virtualization enhancements that are built into the newer AMD and Intel processors.

Figure 5. Legacy application running locally on a virtual machine

Figure 5 illustrates how Virtual PC 2007 can keep available a legacy application that depends on Windows XP and Office XP, in an environment in which Windows Vista and Office 2007 are the corporate standard. When the user wants to use the legacy application, they first start a Windows XP virtual machine, and then they run the application within the virtual machine. If the legacy application requires an earlier version of Microsoft Office, this earlier version also runs inside of the virtual machine, and is isolated from the daily productivity suite of the user.

Virtual PC 2007 provides good integration between the host and guest OS. For example, you can perform copy-and-paste operations between the host and guest computers. You can also drag files from the host computer and drop them into the guest computer. Shared Folders also provide an easy mechanism for moving data into and out of the virtual machine.

Virtual PC 2007 focuses on desktop operating systems, including Windows 98, Windows ME, Windows 2000 Professional, Windows XP Home Edition, Windows XP Professional, Windows Vista Enterprise, Windows Vista Enterprise Business, and Windows Vista Enterprise Ultimate.

Virtual PC 2007 is available free of charge. It can be downloaded from https://www.microsoft.com/downloads/details.aspx?FamilyId=04D26402-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en.

Virtual Server 2005 R2 Service Pack 1

Where Virtual PC allows you to run virtual machines on your local desktop, Virtual Server allows you to run virtual machines on server-class hardware. Virtual Server 2005 R2 Service Pack 1 is the Microsoft flagship product for server virtualization. It is available for the Windows 2000, Windows Server 2003, and Windows Server 2008 host operating systems, and is designed with scalability in mind. It supports both 32-bit and 64-bit hosts, and 32-bit guest operating systems. On 64-bit hosts, it can scale up to 512 virtual machines—addressing up to 256 GB of memory. It also supports virtualization enhancements that are included in AMD and Intel processors, which further improves performance.

Typically, Virtual Server is the best choice for preserving legacy-application investment. If you have legacy applications that require a certain OS, you can configure a server with Windows Server 2003 R2 and Virtual Server 2005 R2. On that server, you then create a virtual machine that has the required OS.

For example, if your Visual Basic 6.0 application requires Windows 2000 Workstation, or even Windows NT 4.0, you could create a virtual machine with that OS, and then install your application on that virtual machine. Users could make a remote-desktop connection to the virtual machine and run the application, as shown in Figure 6.

Figure 6. Accessing an application that is running on a remote virtual machine

Each virtual machine can have up to 3.6 GB of RAM and up to four network interfaces. Virtual Server 2005 R2 SP1 ensures that virtual workloads do not affect each other (or affect the host OS), as Virtual Server allows you to throttle the amount of CPU that is used by any given virtual machine.

Virtual Server 2005 R2 SP1 also features Undo and Differencing Disks, which let you back-out changes that are made to the virtual machine.

Last, but not least, Virtual Server 2005 R2 SP1 can apply existing security models to every virtual machine, thanks to its tight integration with Microsoft Active Directory.

Microsoft offers Virtual Server 2005 R2 SP1 free of charge. It can be downloaded from https://www.microsoft.com/technet/virtualserver/software/default.mspx.

Windows Server Virtualization (Code-Name "Hyper-V")

Windows Server 2008 will bring a new form of hardware virtualization to the Microsoft product line. Unlike Virtual Server 2005, "Hyper-V" is a bare-metal VMM that will provide better performance and scalability. Thanks to a new virtualized I/O architecture, pass-through access to storage devices, and support for the latest virtualization features that are included in AMD and Intel processors, "Hyper-V" will reduce the typical virtualization overhead and offer substantially better performance.

At the same time, "Hyper-V" will become the solution of choice for running the most complex and resource-intensive applications. "Hyper-V" will support 64-bit guest operating systems and virtual symmetric multiprocessing (vSMP), and will allow you to allocate more memory to virtual machines than Virtual Server 2005 and Virtual PC 2007 allowed.

"Hyper-V" will further extend the Undo and Differencing Disks concept that was introduced in Virtual Server 2005—allowing you to taking snapshots of running virtual machines, and quickly revert to those snapshot points.

"Hyper-V" will be tightly integrated with Microsoft Active Directory, to allow granular assignment of virtual machines to specific domain groups and users.

Microsoft will offer "Hyper-V" as an integrated component in every Windows Server 2008 installation, and will allow a smooth transition for its customers who currently are implementing Virtual Server 2005 R2 SP1.

Like Virtual Server, "Hyper-V" focuses on server OS support, including the Windows 2000, Windows Server 2003, and Windows Server 2008 families. It is slated to ship as beta technology in Windows Server 2008 and to be finalized within 180 days of the release of Windows Server 2008.

Presentation Virtualization

For quite some time, administrators have used presentation-virtualization technologies such as Remote Desktop to administer servers in distant data centers, and users have utilized Terminal Server to access applications that are installed on remote computers.

If legacy applications are compatible with server operating systems such as Windows Server 2003 or even Windows Server 2000, the legacy application can be installed on the server, and users can use Terminal Server to run the legacy application. The local desktop or laptop of the user might be running an OS that is incompatible with the application; however, this does not prevent its use, because the application is running on the remote server and merely is serving its display to the local computer.

Windows Server 2000 and Windows Server 2003 terminal-server technologies transmit the entire remote desktop, as shown in Figure 7. While this is effective, it does provide a user experience that is slightly different from running an application on a local desktop computer.

Figure 7. Legacy application running through presentation virtualization

By using Windows Server 2008, you will be able to remote the application windows without the entire desktop, as with earlier versions of Windows Server. This approach is known as a "seamless window," and makes it appear to the user that the application is running locally on their computer (as shown in Figure 8), even though the application actually is running on a remote server and using the resources of that server.

Figure 8. Legacy application running through seamless windows

Often, if you are running a remote application, you might need to access local resources. For example, if the application allows you to export data as an Office Excel spreadsheet, you likely would want to save that spreadsheet to your local file system. If you are printing from the remote application, you might want to print to a local printer. The Remote Desktop Protocol (RDP) supports these kinds of operations—making local resources such as the file system, printers, and clipboard available. This provides an experience that makes the remote application feel as if it were running locally.

If the legacy application is not compatible with the server OS, the application can be installed on a virtual machine that is running on the server, and can be accessed remotely by using the same remote-desktop functionality.

Application Virtualization

The oft-mentioned "DLL hell" is a significant issue for legacy applications. If newer software updates the DLLs on which a legacy application depends, the legacy application no longer might function. If the code base for the legacy application no longer is being maintained, it might not be possible to develop a fix for such needed applications.

Many applications require you to uninstall the previous version before you can install the latest version. Developing an application that supports side-by-side operation with previous versions is challenging; Internet Explorer and Windows Media Player are examples of such applications, and a legacy LOB Visual Basic 6.0 application might have similar requirements.

Another challenge with legacy Visual Basic 6.0 applications is that some are designed for desktop operation, with an assumption that it will not be used simultaneously by multiple users on a single workstation. When such an application is installed on a central server, and multiple users are running the application at the same time through Terminal Server, the application might perform erratically, as multiple users simultaneously read and write to the same registry keys, files, and so forth.

By using Microsoft SoftGrid 4.2, application virtualization can address both of these legacy-application scenarios. Application virtualization differs from hardware virtualization in that it focuses on abstracting facets of the OS—such as the registry, file system, permission profiles, application dependencies, and so forth—into "virtual layers." Applications are installed into virtual layers, which are isolated from each other.

To the user, applications that are inside of virtual layers appear no different from traditional non-virtualized applications. Virtualized applications can have installation folders, configuration files, specific versions of run-time DLLs, menu shortcuts, registry entries, desktop icons, and so forth. However, when the application accesses a portion of the OS, such as the registry, it is not accessing the "real" registry, but instead is accessing a virtual registry. The application can make changes to this virtual registry, and these changes are isolated from other applications or the OS. Also, it can have its own set of run-time files that are mutually incompatible with the latest release.

A single OS can run several virtual layers at the same time, and a virtual layer can contain one or more applications.

Figure 9. Host OS running several virtual layers

Virtual layers are represented as simple files, and are stored on the file system of the host. Users can use these layers in the same way that they use other documents. For example, copying a virtual layer from a library to a host OS corresponds to installing a virtual layer.

Virtual layers can be large; to simplify installation and speed startup time, SoftGrid 4.2 features streaming capabilities. By using SoftGrid System Center Virtual Application Server, end users on average can start working with a new virtualized application after receiving just 30 percent of the deployment, which typically takes 5 to 15 seconds. SoftGrid 4.2 uses a local cache on the end-user desktop to avoid re-streaming parts of the application that previously have been sent. This eliminates network bottlenecks and unavailability if the streaming server becomes unreachable, and it shortens startup time after the first use of the application.

SoftGrid 4.2 is tightly integrated with other Microsoft technologies, such as Active Directory, which allows granular assignment of virtualized applications to domain groups and users. Microsoft System Center Configuration Manager 2007 allows enterprise-wide distribution and maintenance of virtualized applications.

SoftGrid 4.2 is included in the Desktop Optimization Pack, and is available free of charge to all Microsoft customers who subscribe to the Microsoft Software Assurance option.

Application virtualization often is combined with presentation virtualization. This allows applications that are in virtual layers to be deployed to application servers in which users access the applications through Terminal Services—allowing multiuser access to non–multiuser virtualized applications.

Figure 10. Combining application and presentation virtualization for application availability

Figure 10 shows how a user could connect to a server computer by using Terminal Server. The user then attempts to launch a legacy application, which shows up in the Start menu and appears to be installed. In actuality, the application is in a virtual layer and has never been run on this server. The virtual layer begins streaming to the server from the Virtual Application Server, and, in a few seconds, the application is up and running.

Applying Virtualization Technology to Legacy-Application Examples

Each legacy application should be analyzed individually. What makes the most sense for one application might not make the most sense for another. Depending on the architecture and dependencies of a Visual Basic 6.0 application, and on the needs of the company, some virtualization technologies are best suited for preserving specific types of legacy applications. The three example legacy applications that were introduced earlier—while not comprehensive in the variability of legacy Visual Basic 6.0 applications that are deployed today—serve as a way to understand how to choose the virtualization technologies that will be best suited to your business needs.

Application #1: Stand-Alone Desktop Application

The first application example is a stand-alone desktop application that processes information that is exported from a mainframe, and generates reports. The application is specified as follows:

• Processes text files that are exported from a mainframe, and generates monthly reports.
• Must be installed on the computers of three users: one person who has the primary responsibility of generating the reports, a backup resource who can generate the report when the primary individual is unavailable, and their manager.

The application is not compatible with Windows Vista, because it reads from and writes to files that are under C:\ and other directories that are protected in Windows Vista. There are too many hardcoded file paths to fix easily, and the security policy of the company requires users to run UAC and log on as non-administrative users.

The decision process for preserving this specific application might be as follows:

1. The users are running Windows Vista, and the application is not compatible with Windows Vista. This leaves only two options:
   1. Run the application as virtualized on the local computer.
   2. Run the application remotely.
2. Running the application remotely requires configuring a server with the application installed, and providing access to that server for the users.
3. There are only three users who need access to this application, and they are all within the same department.
4. The application is relatively lightweight, and does not require extensive amounts of disk space or memory. In addition, the application does not connect to a back-end database. It needs only text files as input.
5. The users have newer computers, with 2 GB of memory and 80 GB of disk space.
6. For the IT department to configure a server for this application will take weeks or months, given current high-priority IT projects that are in progress.
7. Virtual PC 2007 is compatible with Windows Vista. Users could use Virtual PC 2007 to run the application in a Windows XP virtual machine, on their local desktops.
8. Running the applications in a local virtual machine would let users drag files that are exported from the mainframe and drop them into the virtual machine for processing by the application. Alternatively, the application that is running in the virtual machine could connect directly to a share that contains the files that are to be processed.
9. If running the application in a local virtual machine is difficult to support or otherwise problematic, the virtual machine could be moved easily to a central server later.

Based on this analysis, it makes the most sense to use Virtual PC 2007 to run a Windows XP virtual machine on the local computer of the user.

Figure 11. Stand-alone application running on a virtual machine

This will provide access quickly to the legacy application before the reports of next month must be generated, and will minimize the impact on a busy IT organization. If the solution continues to work well, it can be left in place as is. However, if the IT organization does not want to put one-off solutions such as this one in place frequently, the virtual machines can be moved later to a server that is in the data center, where they can be centrally backed up and managed. The only change to users is that they would access the virtual machines through a remote desktop connection, instead of launching them locally by using Virtual PC 2007.

Application #2: Client-Server Application

The second application example was a client-server application that is used by the sales team. The application is specified as follows:

• The client UI is installed on the computer of each sales representative, and there are 30 sales representatives. It is rare for more than five people to use the application concurrently.
• The application does not maintain any state—such as registry keys, local files, and so forth—on the host computer. In other words, the application could have multiple instances running on the same computer without a problem.
• While the client application itself is compatible with Windows Vista, there are many critical forms that use a complex, third-party ActiveX control that does not run on Windows Vista. The company that built the control no longer is in business, and the control is used so frequently in the application that it is not feasible to remove it.
• Each client connects to a back-end SQL Server 7.0 database (SQL Server 7.0 is not supported on any OS after Windows Server 2000). While the company could upgrade to a more recent version of SQL Server, it has decided not to, for the time being.

Obviously, this application is more complex than the stand-alone application; however, by analyzing each piece—client and server—independently, the best solution for preserving the application can be obtained.

The virtualization solution here is to virtualize both the client and the server applications, and have them run on a server. Users would connect to the client application by using either Windows 2003 Terminal Services or the Windows 2008 Seamless Windows terminal-server technology.

1. The back-end database is SQL Server 7.0.
   1. SQL Server 7.0 is not supported on any OS after Windows Server 2000.
   2. Windows Server 2000 can be run as a virtual machine by using Virtual Server on Windows Server 2003 or Windows Server 2008.
   3. Running the database as virtualized allows the database server to be consolidated on the latest hardware with other servers.
2. The client application is not compatible with Windows Vista, and some of the users are running Windows Vista. This leaves two options:
   1. Run the application as virtualized on the local computer.
   2. Run the application remotely.
3. The application is needed by 30 users. Having 30 users run local virtual machines is prohibitive for the following reasons:
   1. Doing so requires each user to have 2 GB of physical memory, and approximately 10 GB of free disk space. Ensuring this across 30 users might be difficult.
   2. Having each user run the virtual machine locally complicates the configuration of the computer of the user, each of which would need more than the standard IT configuration.
   3. Training new salespeople (who are the users of this application) is more complicated, because they need to understand the basics of Virtual PC 2007.
4. The application could be run remotely.
   1. The application is compatible with Windows Server 2003.
   2. By using Terminal Server, multiple users can connect to the Windows Server 2003 computer on which the application is installed and run the application simultaneously; however:
   • The application was designed to be run on a workstation, and it does not work correctly if multiple users try to run it simultaneously on a server.
   • If SoftGrid 4.2 is used to deploy the application onto the server, it can be run by many users simultaneously, because each instance is running in a separate, isolated virtual layer.

This analysis leads to the architecture that is pictured in Figure 12:

Figure 12. Virtualizing a client-server application

The database will run on a Windows Server 2000 virtual machine, and it can continue to run on this virtual machine indefinitely. Running the database in a Windows Server 2000 virtual machine, which is installed on a Windows Server 2003 (or in the future Windows Server 2008) physical computer, allows the database to benefit from faster processors, faster IO subsystems, hot-swap drives and memory, and other leading-edge technology. It also simplifies the backup and recovery of the database, as the entire virtual machine is just backed up and restored.

The client application is run on a separate virtual machine, hosted on a central server. Based on the preceding analysis, it likely would create too many support requests and require too much hardware for the computer of each user to run the virtual machine on the local system of the user. Running the client application on a server-side virtual machine also allows easier backup, restore, and monitoring by the IT organization. This also keeps the legacy application from being a one-off solution, and keeps the legacy application from requiring special configuration of the computer of the user.

To allow multiple users to access the application simultaneously, the users connect to the virtual machine by using Terminal Services. Although the application was not designed for multiuser operation on a single computer, SoftGrid 4.2 provides isolation between each instance, so that multiple users can access the application simultaneously.

Application #3: Three-Tier Application

You might recall that the third example application is a help-desk three-tier application that is specified as follows:

• The application is mission-critical and must have near 100 percent uptime.
• The client UI is implemented in Visual Basic 6.0 and installed on over 200 user computers in a call center that is running Windows 2000.
• The application uses registry keys and local files on the host computer for personalization and customization purposes.
• The business rules are implemented in C++ and installed on a COM+ application server.
• The back-end database is implemented as a SQL Server database.
• Preliminary testing suggests that the application would run seamlessly on Windows Vista, but the computer hardware of the call center is at least six years old and is not Windows Vista–compatible. The company does not want to purchase new computer hardware just to keep the Visual Basic 6.0 application on a supported OS.
• The third example, a three-tier application, does not actually differ much from a virtualization perspective.

While apparently quite different from the two-tier application—with respect to scope, scale, availability, and so forth, from a virtualization perspective—the three-tier application is the same as the client-server application, except that a business-rules layer exists between the UI and that database. The same analysis that applied to the client-server application applies to the three-tier application, with the additional constraint that the three-tier application must be used by hundreds of users—making it completely unfeasible to deploy the UI in a virtual machine to each user. The UI application must be placed on a central server. The database can run on a server in a virtual machine, just as with the client-server application. The business rules, which typically run on a separate application server, can run also in a virtual machine.

Figure 13 shows the architecture:

Figure 13. Virtualizing a three-tier application

There is one critical difference, however: The two-tier application could run as multiple instances on the same virtual machine or physical computer. The three-tier application cannot run as multiple instances on the same computer; each user experience is customized by using local files and registry keys. The most efficient solution here is to use SoftGrid 4.2 to virtualize the application layer itself—allowing hundreds of users to access the application concurrently.

There is a workaround to using SoftGrid 4.2 application virtualization, which is available only as part of the Software Assurance support package that is found at https://www.microsoft.com/licensing/sa/default.mspx. For example, if the two-tier application accessed also local files and registry keys, the low number of concurrent users provides a workaround: With no more than 5 concurrent users out of 30, the company could have five or more virtual machines on the server that users could access via Terminal Services. This workaround would be cumbersome, however, with hundreds of concurrent users.

Making Decisions

There are a number of options for preserving legacy applications. If the application is needed by very few users, and if the organization is small, it might make sense just to use Virtual PC to keep the application available. If the application is needed by more than a few users or comprises two or more tiers, or if the organization is large enough to have a data center and centralized IT, running the application on the server side makes more sense. In this architecture, the user accesses the application by using Terminal Services. If the application was not designed to be run on one computer by multiple simultaneous users, SoftGrid 4.2 can be added to the equation to provide isolation between the application instances.

Figure 14. Deciding on a design

Handling Specific Application Constraints

Most applications fall into the categories that are discussed in this article and do not require any exotic configurations. Hopefully, the majority of legacy applications in your organization can be well-serviced by a combination of hardware, presentation, and application virtualization. However, there are specific "gotchas" that are worth pointing out before you travel too far down the path with an envisioned virtualization solution.

Applications with Hardware Constraints

Sometimes, applications require access to specific hardware devices, such as copy-protection dongles, smart cards, and so forth. In these cases, the required hardware should be connected to a Windows 2003 Server or Windows 2008 Server, and the software should be accessed by users via Terminal Server. Some forms of hardware (for example, USB devices) currently are not passed through to virtual machines, so it is important that the legacy application be compatible with some server OS that supports Terminal Server (which does pass through connections to USB devices).

Security Considerations

In most scenarios, it is highly recommended to use Microsoft virtualization solutions in conjunction with Active Directory. This lets you leverage the existing corporate security model and control access to virtualized applications strictly.

If Active Directory is not being used, Virtual PC, Virtual Server, and Terminal Services still are options, as they can operate outside of an Active Directory infrastructure. SoftGrid 4.2 requires Active Directory.

Conclusion

Through the combined use of hardware virtualization, presentation virtualization, and application virtualization, Microsoft delivers a cost-effective virtualization strategy to help customers support their existing legacy applications in the environments of tomorrow.

Virtual Server 2005, Virtual PC 2007, and Windows Server 2008 Virtualization allow you to access applications on computers that have incompatible operating systems. These technologies allow you, for example, to run an application in a Windows 2000 virtual machine that is running on a Windows Vista desktop or Windows Server 2003 (or Windows Server 2008) OS.

Combining SoftGrid and Terminal Server provides remote access to mission-critical legacy applications—allowing many users to be serviced by a single server, and insulating the application from compatibility issues with desktop operating systems and other software.

Often, virtualization technologies will be combined to provide the optimum solution. If the application runs in tiers or requires a back-end database, those tiers might be run in virtual servers. The client often will be deployed to a central server and accessed through Terminal Server. To ensure the best operation and performance, and to overcome issues of multiple users running applications that are designed to run as a single instance, SoftGrid 4.2 often will be employed in conjunction with Terminal Server to provide application isolation.

Virtualization is a key deliverable on the Microsoft Dynamic Systems Initiative (DSI) road map, in line with the continued investment of Microsoft in delivering technologies that help IT organizations manage complexity and achieve agility.