Virtualizing Windows Server Applications Using the AppZero Toolset
AppZero helps customers move legacy applications from Windows Server 2003 and 2008 servers that are reaching end of support. AppZero uses a virtual container to extract applications and package them. Containers can be provisioned and run natively on any newer Windows OS, server, or cloud. The AppZero toolset works in a variety of migration scenarios by automating the monitoring, identification, extraction, and encapsulation of Windows Server applications. This whitepaper explains how Windows Server applications are virtualized and moved using the AppZero application migration toolset and containers in a modernization project.
How are applications installed on Windows Servers?
When an application is installed on a Windows Server, an install script is typically used to distribute application components across the Windows directory and file system. These components include EXEs, DLLs, COM+ components, DCOM, drivers, Admin data, and other artifacts. Install scripts often provide flexibility and configuration choices to direct where application components reside for any given installation, which makes the installation process more complicated. In addition, the expected directory and file locations of application components often change between upgrades of Windows Server OS versions. Not all installed applications behave as expected on Windows Server versions and some may not even show up in the Windows Server Add/Remove program dialogue after being installed.
How does AppZero virtualize and containerize an application?
An AppZero container decouples an application from the operating system and its underlying infrastructure. To separate the application from the operating system, AppZero inserts redirection intercepts at the NT layer. AppZero inserts these intercepts without modifying the application binaries stored on the drive. To this end, AppZero inserts a DLL (runtime) during process creation while each application component is executed. The intercepts can be removed once a successful migration is completed, the container can be dissolved if required, and all dependency on AppZero can be removed.
The resulting AppZero container is a single compressed and encrypted file on the target server, which includes all elements of the application, its execution dependencies, and configurable properties. The container contains application components only, no OS
The container emulates the way application components were originally distributed on the Windows Server source system. The AppZero runtime function acts as an intermediary between a container and the operating system, enabling an application to run in the context of a container. The runtime governs the application’s behavior to be identical to a native installation, with zero change to the OS. The configuration of the baseline OS, registry entries, directories and files are parameterized and resolved at runtime by AppZero.
Isolated from the underlying infrastructure, containers can be freely moved among servers (physical or virtual) on-premise or in the cloud, without re-configuring the application or the operating system. This isolation makes it easy for both legacy and new applications to move error-free from old-to-new or like-to-like operating system versions.
The container provides a safe isolation environment in which to test a migrated application and to ensure that all required components have been moved. It also allows for on-the-fly reconfiguration of system mappings (WOW64, x86, etc.) or IP and network addresses if needed between source and target systems.
Once testing has verified that the system has all required components, the container can be dissolved and the application components can be redistributed to where they should reside on the target Windows Server without the container. Before being dissolved, a compressed copy of the application container and all of its contents can be stored for backup or recovery purposes. The container or virtualized copy of the application on the source system can then be removed, along with all AppZero executables and components. The moved application will now run as if it were natively installed on the target server.
Traditional and innovative approaches to moving legacy Windows Server applications to new OS environments
There are several approaches to moving legacy applications off older WS2003 or WS2008 environments. Manual reinstallation, reconfiguration, data migration, and scripting are often viewed as the primary methods to move applications to a server running a new operating system.
However, because all applications are unique, the manual migration approach is labor intensive, expensive, time consuming, error prone, and not scalable.
Tools that move machines P2V (Physical to Virtual) or V2V (Virtual to Virtual) don’t help because they carry the old OS to the new destination machine, which doesn’t address moving applications running on WS2003 or WS2008 to more modern WS2012 or WS2016 servers or cloud-hosted VMs. Modern server and cloud management tools can’t manage legacy WS2003 and WS2008 instances and each OS version needs to be laboriously patched and individually managed. Also, P2V and V2V approaches replicate all disk storage, applications, and files. Replicating entire OS instances, including their burden of unused applications and unnecessary log files, substantially increases memory, processing, and storage hosting costs.
While application virtualization and containerization are not new, what is innovative and disruptive is using them to extract existing, installed server-side applications for migration and cloud onboarding. Application containerization offers an automated, scalable migration tool to solve repetitive, labor-intensive IT processes. With containers, applications are isolated to have all their dependencies and configurations "contained," so that no matter where they are deployed, they run independently of the operating system. Packaging applications separately from the operating system means that apps can be moved easily without re-engineering. Because hosting costs, service level agreements and functionality vary and can change, being cloud-provider agnostic is an important asset.
CIOs fear cloud lock-in. Application portability means that you can choose the cloud hosting that fits your needs best, whether it’s a private, public, hybrid, or managed cloud. The containerized migration approach identifies and copies all executables, settings, and data associated with applications, enabling them to move from one Windows Server to another. Capturing and separating the application dependencies from the OS makes the container-based approach ideally suited to moving applications to a newer OS. Unlike P2V (Physical to Virtual) or V2V (Virtual to Virtual) server migration, application virtualization focuses on the application, rather than replicating the entire OS, with all its applications and storage.
Instead of migrating entire server images, you can migrate specific applications and their data. Applications can be split or directed into individual containers on specific servers. Applications that are no longer needed don’t need to move. The application virtualization approach gives you cloud-to-datacenter agility. Simply put, small and agile containers make moving applications between physical and virtual environments fast and easy, without lock-in.
Implementing the AppZero Toolset
AppZero is the de facto gold standard for container-based enterprise application migration.
How you implement AppZero depends on your choices and your application features.
1: Use AZ-Maestro and AZ-Monitor for discovery and monitoring
Before a migration, install AZ-Maestro on your source network. With its graphical user interface, you’ll discover all the servers on which AppZero is installed on your network, as well as the server apps these servers are running.
You can select which sources and which applications to include or exclude in the monitoring process, and then monitor selected apps in your production or test environment using AZ-Monitor, an intelligent monitoring tool.
As AZ-Maestro monitors server activity, it gathers the information required to migrate applications to the target server. Allowing AZ-Maestro to gather data over time means a quicker migration process once you’re ready to migrate.
Together, AZ-Maestro and AZ-Monitor can help you:
• Prioritize which applications to move first, based on actual application use.
Applications that are no longer used are not good candidates for migration.
• See which applications are ready to be migrated once AZ-Maestro greenlights
the apps based on monitoring data.
• Manage users and roles associated with migration work.
• Plan capacity: determine size memory, processing, and storage requirements for
2: Use AZ-Migrate to automate migration
AZ-Migrate inherits the application template captured by AZ-Monitor and then automates the identification, extraction, and movement of an application to any cloud or server. As needed, the migration tool then dissolves the AppZero layer to allow installation on the target OS.
Can I use AZ-Migrate without AZ-Monitor? How does that work?
Yes, you can. Setting up AZ-Migrate without AZ-Monitor requires no new software on the source server. If you choose not to monitor applications with AZ-Monitor before you migrate, then the source machine is accessed via the network and AZ-Migrate is installed on the target server. The machines are "tethered" and the application is prepopulated or extracted using secure, compressed communications into a virtual container, complete with all the application's files, registry, configuration, and data.
When you start the application inside the container, AZ-Migrate automatically migrates any application artifacts missed during pre-populate from the source machine to the target machine, whether the target is in the cloud or a new machine. When the application runs in a container, it uses a light intercept layer that isolates the application from the OS. The intercept layer redirects any modifications that are made to an application’s artifacts (files, registry), keeping them contained in the virtual container.
When you initially migrate an application with AZ-Migrate, it’s self-contained in its container.
3: Run and keep applications in the container
Another approach to implementing AppZero involves running and keeping applications in the container. Keeping applications in the container is helpful for applications that may conflict with one another.
If you no longer need to keep an application in a container, AppZero's "dissolve" capability installs the application back to the underlying operating system, breaking the reliance on the AppZero virtualization runtime so that the application is distributed as it would be for traditionally installed applications.
Are there limits to using a container approach to moving applications?
The container approach can move most -- more than 90% -- but not all applications. For example, 16-bit applications can’t be moved to WS2008, WS2012, or WS2016 because 16-bit applications will not run on modern operating systems. Similarly, if an application is built using a Java library that is supported on WS2003 only, or if an application needs specific drivers or other components that can’t be substituted, then it likely won’t run on a more modern OS. Also, Microsoft-specific applications such as Active Directory and SharePoint comingle the application with the OS, so they need a different approach to successfully move them. Finally, security, authorization, and license keys may be needed from vendors to make applications work on newer OS platforms.
If the application will not move, AppZero virtualization will reveal the specific components that are preventing movement. These hard constraints can sometimes be remediated.
The AppZero toolset is all you need to simplify Windows Server application migration. AppZero has successfully completed thousands of Windows Server 2003 migrations for hundreds of Fortune 500 companies. Companies like Glaxo, Merck, TD Bank, CIBC, MetLife, and Clorox have depended on AppZero to migrate from WS2000 and WS2003 onto modern Windows Server platforms.