AWS End-of-Support Migration Program (EMP) for Windows Server

(1)

AWS End-of-Support Migration Program (EMP)

for Windows Server

User Guide

(2)

AWS End-of-Support Migration Program (EMP) for Windows Server:

User Guide

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

What Is AWS End-of-Support Migration Program (EMP) for Windows Server?

The AWS End-of-Support Migration Program (EMP) for Windows Server provides the technology and guidance to migrate your applications running on Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 to the latest, supported versions of Windows Server running on Amazon Web Services (AWS). Using EMP technology, you can decouple critical applications from their underlying operating system so that they can be migrated to a supported version of Windows Server on AWS without code changes.

Topic contents

• Features of AWS End-of-Support Migration Program (EMP) for Windows Server (p. 1)

• AWS End-of-Support Migration Program (EMP) for Windows Server concepts (p. 2)

• Accessing AWS End-of-Support Migration Program (EMP) for Windows Server (p. 2)

• Pricing for EMP (p. 3)

Features of AWS End-of-Support Migration Program (EMP) for Windows Server

The AWS End-of-Support Migration Program (EMP) for Windows Server toolset oﬀers the following features to help you migrate your applications running on legacy Windows Server operating systems to supported versions.

Existing installation capture

During packaging, EMP tools capture the existing installation of a legacy application to an EMP package. The EMP tools typically perform this by detecting the components of an existing installation and extracting them to an EMP package. When installation media and knowledge are available, the installation can be monitored and captured to an EMP package.

Fresh installation capture

During packaging, a snapshot is taken of the current state of the operating system, and a capture process records all of the changes made during the application installation.

Runtime analysis

File and registry access, along with changes that occur when an application is launched from this section of the packing wizard, are recorded and made available for addition to the package being created. This feature allows EMP to include ﬁrst-launch changes by the application to the system.

Legacy operating system support

An EMP package is created on the operating system that is currently supported by the application being packaged. This compatibility packaging allows you to migrate an application from a compatible operating system to an incompatible operating system, while preserving application functionality.

(6)

Concepts Windows upgrade support

You can deploy a single package across multiple supported Windows versions. In addition, each package supports the upgrade of the underlying version of Windows version.

Pre-deployment and post-deployment scripts

You can include custom scripts in the package to deploy scripted installations, conﬁgurations, or to run other required tasks for the package and application deployment process.

Fast editing with no package recompilation

Test and remediation cycles for EMP packages take less time as a result of fast editing, which requires no package recompilation. Packages can be updated to include speciﬁc application updates or the latest EMP components without having to recompile the package.

AWS End-of-Support Migration Program (EMP) for Windows Server concepts

The following concept is central to your understanding and use of AWS End-of-Support Migration Program (EMP) for Windows Server.

Packaging

The process of capturing a legacy application using the EMP tools on the source operating system.

Source server

The server instance on which the application to be packaged is currently installed and running.

Clean packaging server

The server instance of the Windows operating system version that is supported by the application to be packaged. This server instance is used in the fresh install capture of an application.

Compatibility package

When the EMP compatibility packaging process is complete, the output of the package builder is called an EMP compatibility package.

Accessing AWS End-of-Support Migration Program (EMP) for Windows Server

AWS End-of-Support Migration Program (EMP) for Windows Server oﬀers standalone tools that you download and install on your source or packaging instance. You can download the EMP tools from the End-of-Support Migration Program for Windows Server product page.

New releases of the AWS End-of-Support Migration Program (EMP) for Windows Server Compatibility Package Builder are provided in MSI format. To upgrade to a new version from a previous version, uninstall the previous version by using the Add or Remove Programs feature from legacy Windows operating systems, or from Programs and Features in the Control Panel for later operating systems.

Then, reinstall the package with the latest MSI.

(7)

Pricing

Pricing for EMP

AWS End-of-Support Migration Program (EMP) for Windows Server is available for use at no cost to support migration of Windows workloads to the AWS Cloud.

(8)

How AWS End-of-Support Migration Program (EMP) for Windows Server works

AWS End-of-Support Migration Program (EMP) for Windows Server technology identiﬁes the

dependencies and resources for your application, and creates an application package from them. This application can be deployed to and run on a new version of Windows Server.

The EMP toolset creates packages for legacy Windows applications to run on any supported version of the operating system. It includes a set of packaging tools, which are used to address various packaging scenarios. When a package is created, application runtime analysis detects application file and registry activity, including additional configuration changes that occur when the application first runs. The EMP package is deployed with a command passed to its deployment program. Deployment can be automated with scripts or managed by enterprise tools, such as AWS Systems Manager.

Application compatibility packages include everything an application requires to run on a modern operating system. This includes all of the application ﬁles, runtimes, components, deployment tools, and the embedded redirection and compatibility engine. During the creation of a package, EMP

determines the application dependencies for the out-of-support operating system, and sets the required redirections. The redirection and compatibility engine are designed to run in user mode. When the package is deployed to the target machine, the ﬁle type associations are registered, and shortcuts are created to run the application.

Compatibility packaging follows these three principles:

• Packaging is performed on the operating system supported by the application.

• Runtime analysis is performed to detect and review the ﬁle and registry activity of the processes of the application. For a fresh install capture, runtime analysis detects ﬁrst-run activity of the application after installation.

• The redirection and compatibility engine, along with the package deployment program, are included in the package.

The package does not include the legacy operating system. This means that you do not run any part of the legacy Windows Server version on the new Windows Server to which the application is upgraded.

The redirection engine intercepts the API calls that the application makes to the underlying Windows Server operating system, and requests for ﬁles and registry data captured in the package are redirected there. As a result, the request by the application for resources that are present within the package are redirected to the package so that the application runs successfully on the new operating system. This lightweight strategy means that the target application can see a combination of the redirected and local ﬁle system and registry, with undetectable impact on the performance of the application or local machine. The approximate RAM overhead per application is 3 to 5 MB, with no measurable CPU impact after the application has started.

Common redirections, which do not include ﬁle and registry redirections, supported by the EMP compatibility engine include:

• The application uses a ﬁxed port. The EMP engine redirects to an appropriate and available port on the new version of the operating system.

(9)

Phases of the EMP process

• The application accesses data stored in a ﬁxed location that is not available on the new OS version.

The EMP engine redirects these requests to the appropriate location on the new version of the operating system.

• The application is hardcoded to C:\WinNT. The EMP engine redirects the application to C:

\Windows.

• The application requires Java version 1.3. EMP packages and isolates the application with Java 1.3 so that it does not make calls to newer Java runtimes in the new version of the operating system.

Topics

• The AWS End-of-Support Migration Program (EMP) for Windows Server process (p. 5)

• AWS End-of-Support Migration Program (EMP) for Windows Server System requirements (p. 6)

• AWS End-of-Support Migration Program (EMP) for Windows Server limitations (p. 7)

• Data collection (p. 7)

• Components of the EMP Compatibility Package Builder (p. 7)

The AWS End-of-Support Migration Program (EMP) for Windows Server process

This section provides a high-level overview of the EMP process, including the steps involved in each phase of the process.

The EMP process:

• Discovery (p. 6)

• Packaging preparation (p. 6)

• Packaging (p. 6)

• Deployment (p. 6)

(10)

Discovery

During discovery, target applications are recognized using AWS Optimization and Licensing Assessment (AWS OLA). Discovery includes identifying legacy applications that require EMP packaging for migration to later versions of the Windows Server operating system.

Packaging preparation

Packaging preparation includes the following steps.

1. Clone the server image to the AWS instance, if possible.

2. Complete application discovery.

3. Plan user acceptance testing (UAT).

4. Deﬁne the target environment.

Packaging

Packaging includes the following steps.

1. EMP package builder packages the application on the source server version, guided by application discovery. The source server version is the Windows Server operating system that currently hosts the application.

2. The package is tested on a clean source server version and any required remediation is performed.

3. The package is tested on the target server version instance following the UAT plan. Any necessary remediation is performed.

Deployment

Deployment includes the following steps.

1. Deployment and testing on the target environment.

2. Production deployment.

AWS End-of-Support Migration Program (EMP) for Windows Server System requirements

AWS End-of-Support Migration Program (EMP) for Windows Server supports the following operating systems:

• Windows Server 2019 (64-bit)

• Windows Server 2016 (64-bit)

• Windows Server 2012 R2 (64-bit)

• Windows Server 2008 R2 (64-bit)

• Windows Server 2008 (32-bit and 64-bit)

• Windows Server 2003 SP2 (32-bit)

(11)

Limitations

The following system requirements must be met to migrate your application with AWS End-of-Support Migration Program (EMP) for Windows Server.

• .NET. Microsoft .NET 4.0 Client Proﬁle, or later.

• Memory. As required by the packaged applications. Minimum 2 GB.

• Processor. As required by the packaged applications. Two CPUs recommended.

• Disk space. 10 GB required to create the snapshots. The size of the EMP package depends on the size of the application. It will be 10 to 50 percent larger than the application being packaged.

AWS End-of-Support Migration Program (EMP) for Windows Server limitations

The following application and component types cannot be migrated using AWS End-of-Support Migration Program (EMP) for Windows Server.

• Applications that do not run on the Windows operating system.

• 16-bit applications. If the target operating system is a 64-bit Windows operating system, the NT Virtual DOS Machine (NTVDM) required to run these applications is available on 32-bit Windows operating systems only.

• Kernel-mode drivers that are a diﬀerent bitness than the target operating system. Device drivers are not virtualized with EMP and therefore must be compatible with the target operating system.

Compatible drivers can be deployed with the package. For example, if you are moving to a 64-bit operating system, you must have a 64-bit driver that is compatible with the new operating system.

• Low-level applications. For example, antivirus, ﬁrewall, and VPN applications.

• Explorer Shell Extensions.

• Microsoft BizTalk and Microsoft Transaction Server (MTS)-based systems.

• Desktop applications.

Data collection

AWS collects usage information through the EMP telemetry module during the deployment and subsequent use of EMP packages. The telemetry module sends the collected data to an application modernization metrics service running on AWS. To view the data collected by the telemetry module, see Data collected by the AWS End-of-Support Migration Program (EMP) for Windows Server (p. 69) in the Security section of this guide.

Components of the EMP Compatibility Package Builder

The installation directory of the Compatibility Package Builder includes the following ﬁles and folders.

Files

• Compatibility.Package.Builder.exe — the Package Builder program.

• Compatibility.Package.Builder.cfg — Used to conﬁgure packager settings, such as ﬁle scan root directory.

• Compatibility.Package.Builder.exe.conﬁg — Contains packager program settings, such as packager event logging level and dependencies, such as the .NET runtime version.

(12)

Compatibility Package Builder components

• Compatibility.Package.Builder.log — Logs package builder events during packaging.

• Compatibility.Package.CmdLineBuilder.exe — The CLI version of the Package Builder. Uses the PackageScript.xml as its response ﬁle.

• Compatibility.Package.CmdLineBuilder.exe.conﬁg — Includes the CLI program settings, such as CLI event logging level and dependencies, such as the .NET runtime version.

• EMP.GRP.exe — The GRP program.

• EMP.GRP.exe.conﬁg — Used to conﬁgure the GRP program settings.

• EULA.rtf and eula.base — The end-user-license-agreement files. the content of the .rtf file is copied into the .base file, which is saved as HTML in the package root folder.

• ExclusionList.json — A configuration file that contains the list of files, folders, and registry keys that are ignored during scanning.

• GRPExclusion.json — A configuration file that contains the list of files, folders, and registry keys that are ignored by the GRP program.

• Open Source Licenses.txt — Contains the license for the open-source components in the Package Builder.

Folders

• Images — Contains the graphic ﬁles used by the Package Builder application.

• x64 (Engine Binaries) — Contains the EMP runtime ﬁles for packages to be deployed on a 64- bit system. When packaging is performed on a 64-bit machine, the contents of this folder are automatically copied into the root folder of the EMP package during the package build. An EMP package that was built on a 64-bit machine cannot be run on a 32-bit machine.

• x86 (Engine Binaries) — Contains the EMP runtime ﬁles for packages to be deployed on a 32- bit system. When packaging is performed on a 32-bit machine, the contents of this folder are automatically copied into the root folder of the EMP package during the package build. An EMP package that was built on a 32-bit machine will run on a 64-bit machine, however, we recommend that you use the appropriate runtimes for the destination platform. This is automatically handled during the deployment process.

• Tools — Contains three sets of tools that are available to EMP packages.

• DiscoveryTool — A command line tool that can perform a limited discovery of a server.

Commands

• Compatibility.Package.DiscoveryTool.exe -d "<InstallDirectory> — Writes a list of loaded COM servers and drivers in <Currentdirectory>\Report.json.

• Compatibility.Package.DiscoveryTool.exe -l — Lists features and subfeatures of the tool in the command console.

• Editor — Used to edit existing packages. This tool has a shortcut in the Start menu, where it goes by Compatibility Package Editor.

• ReversePackagingTools — A command line tool set used in the reverse packaging process, a method of compatibility packaging used when application installation media is not available. This tool set is used during the ﬁrst two stages of reverse packaging:

1.Install media reverse engineering — A reverse engineered installation media, called a package source is generated from a working instance of the application on the server.

2.EMP package build — The package source installation is then captured on a clean packaging server using the Compatibility Package Builder.

Commands

• type <procmoncapture.CSV> | GeneratePackageSource.exe |

(13)

Compatibility Package Builder components

package source from the CSV ﬁle using RemoveKnownFolders.exe to remove common known system registry keys, ﬁles, and folders.

• type <filteredoutputfilename.json> | ExportFromSystem.exe >

<logfilename.txt> — Extracts the listed ﬁles, directories, and registry keys from the operating system and compresses them along with the remaining contents of the

ReversePackagingTools folder into PackageSource.zip. This ﬁle is a reverse-engineered installation media for the application.

• type <filteredoutputfilename.json> | DeployToSystem.exe >

<logfilename.txt> — Installs Package Source during the package build on the packaging server using the package builder.

• IISTools — A set of command line scripts used to enable the automatic migration of legacy Windows IIS applications to a modern, supported version of Windows Server on AWS. For more information, see Package an IIS-based application (p. 30).

(14)

Decision tree

Get started with AWS End-of-

Support Migration Program (EMP) for Windows Server

This section helps you get started with creating an EMP package to help you migrate your legacy application to a modern Windows Server operating system. It includes a decision tree to help you determine whether the AWS End-of-Support Migration Program (EMP) for Windows Server is the right solution for your migration. It also includes considerations for planning your migration, high- level discovery steps, Compatibility Package Builder installation steps, procedures for packaging an application with or without installation media, and steps for deploying a packaged application.

Getting started topics

• AWS End-of-Support Migration Program (EMP) for Windows Server decision tree (p. 10)

• Planning an AWS End-of-Support Migration Program (EMP) for Windows Server migration (p. 11)

• High-level AWS End-of-Support Migration Program (EMP) for Windows Server application discovery exercise (p. 12)

• Install AWS EMP Compatibility Package Builder (p. 13)

• AWS End-of-Support Migration Program (EMP) for Windows Server application packaging model (p. 14)

• Package an IIS-based application (p. 30)

• EMP compatibility package contents (p. 34)

• Deploy an EMP package (p. 39)

AWS End-of-Support Migration Program (EMP) for Windows Server decision tree

The EMP decision tree is a set of questions to assist you in determining whether EMP is the right solution for migrating applications onto modern Windows Operating Systems in AWS.

(15)

Planning a migration

Planning an AWS End-of-Support Migration Program (EMP) for Windows Server migration

When you plan an AWS End-of-Support Migration Program (EMP) for Windows Server migration, consider the following:

• Application environment — legacy to target

It is important to understand the existing architecture of the application that is being migrated so that the target environment can be correctly set up. In an n-tier application model, you should identify each server that makes up the model and understand which of the servers require migration and which of them require EMP for the migration process. Some of the servers may already be migrated to AWS and using a step-by-step migration approach ensures a smooth transition to AWS.

For example, if you attempt to migrate a three-tier application that consists of an Internet Information Server (IIS) web server, application server, and SQL Server 2008, all running on Windows Server 2008 on premises, the migration plan might look like this: the IIS Web Server migrates to a Windows Server 2019 in AWS without the need for EMP migration. The application running on the application server is captured into an EMP package and migrated onto a Windows Server 2019 operating system running on AWS. SQL Server is migrated to Amazon Relational Database Service (Amazon RDS). If the application works only on the legacy version of SQL Server, then it can be captured into an EMP package and migrated to a modern operating system.

• Packaging model

• Standard packaging — Use when packaging an application with complete installation media, and the application spans only a single drive.

• Guided Reverse Packaging (GRP) — Use when packaging an application with no installation media, and the application spans only a single drive.

• Reverse packaging — Use when packaging an application with no installation media, and the application spans multiple drives.

(16)

High-level discovery

NoteWe recommend that you use the standard packaging model if your application meets the requirements.

• Packaging and testing environment

Set up your packaging and testing environments according to the results of the application discovery exercise. For more information about each packaging scenario, see AWS End-of-Support Migration Program (EMP) for Windows Server application packaging model (p. 14).

High-level AWS End-of-Support Migration

Program (EMP) for Windows Server application discovery exercise

After you identify the applications to migrate using EMP, we recommend that you perform an application discovery exercise for each application. EMP application discovery refers to the process of gathering and documenting all of the information about a legacy application that is required to inform the creation of a functioning EMP package and its deployment onto a modern, supported target environment. The information required to complete application discovery comes from both the legacy and target environments. It typically includes conﬁguration details, installation instructions, topology, customizations, security requirements, users, and more.

When the application discovery is complete, analyze the information against the EMP limitations (p. 7) to determine EMP eligibility.

We recommend that an application subject matter expert (SME) is available to assist with the discovery process. The application SME is a representative who knows how the application works for the business and is familiar with the business workflows within the application. The SME can demonstrate all business workflows and also define or agree upon an acceptance testing plan for the application if one does not exist. The acceptance testing plan can be used during the testing of the application in the EMP package.

The following table shows a discovery checklist to guide you through the discovery process.

Checklist item Details

Application name and version The name and version of the application that you want to migrate.

Application subject matter expert (SME) The name and contact details of the application SME to assist with the migration.

Software prerequisites required by the application The software required to be installed before or with the application. For example, .NET 2.0 SP1, earlier versions of Java, Visual C++ runtimes, and more. The dependencies can be included in the same package as the application.

Source operating system The operating system on which the application currently runs.

Target operating system The operating system to which you want to migrate the application.

Are the install media and install instructions

available? The answer to this question determines the

EMP packaging model to be followed for

(17)

Install Compatibility Package Builder

Checklist item Details

migration (standard (p. 15), GRP (p. 17), or reverse (p. 21) packaging). For standard packaging, gather install media, instructions, and customizations required to carry out a complete setup of the application on the legacy OS.

Application topology and external dependencies For example, three-tier topology with an application/desktop tier, an IIS-based web tier, and a database tier all hosted on diﬀerent servers requiring connectivity between one another.

Does the application require speciﬁc drivers? If so, is a 64-bit compatible version available?

(Check the EMP limitations (p. 7)).

Other application details What is the bitrate of the application: 32-bit or 64-bit? Does it use COM+ or DCOM components?

Are Windows Services installed or used by the application? Do any services require domain or local service accounts? Is the application subject to Data Execution Prevention (DEP)? Are there any ﬁrewall ports that should be opened?

Windows features and roles required The Windows features and roles required by the application to set up on the modern operating system.

Known issues Any known issues of the application to account for

during the testing phases.

Cross-check against EMP limitations Verify whether the application is in scope for EMP packaging.

Install AWS EMP Compatibility Package Builder

The AWS EMP Compatibility Package Builder is the primary tool used to create EMP compatibility packages to deploy functioning legacy Windows applications on modern Windows Server operating systems on which they would otherwise be incompatible. Package Builder is provided in an MSI installer ﬁle that installs the tool on a clean packaging server. A clean packaging server is a server instance of the Windows operating system version that is supported by the application to be packaged.

Perform the following steps to install the AWS EMP Compatibility Package Builder.

1. If you have not done so already, download AWS EMP Compatibility Package Builder from the AWS End-of-Support Migration Program (EMP) for Windows Server product page.

New releases of the AWS End-of-Support Migration Program (EMP) for Windows Server Compatibility Package Builder are provided in MSI format. To upgrade to a new version from a previous version, uninstall the previous version by using the Add or Remove Programs feature from legacy Windows operating systems, or from Programs and Features in the Control Panel for later operating systems. Then, reinstall the package with the latest MSI.

2. After you have downloaded the EMP tools, double-click the Compatibility Package Builder ﬁle to run it.

3. On the Welcome to the Compatibility Package Builder Setup Wizard pop-up, choose Next.

4. In the End-User License Agreement, select the terms agreement, and choose Next.

(18)

Package an application

5. Under EMP Telemetry, select the check box to enable telemetry (optional), and choose Next.

6. Accept the default Destination Folder, or modify it, and choose Next.

7. Choose Install.

8. When the application installation completes, choose Finish.

AWS End-of-Support Migration Program (EMP) for Windows Server application packaging model

The following model and descriptions show the process of packaging a legacy application using AWS End-of-Support Migration Program (EMP) for Windows Server. There are three packaging models:

• Standard packaging. Use when the application media and install instructions are available to recreate an up-to-date installation of a legacy application in its current supported operating system.

• Guided Reverse Packaging (GRP). Use when the application media and install instructions are not available to recreate an up-to-date installation of a legacy application in its current supported operating system. In addition, the application must be installed only on the system volume, and have no dependencies on another Windows volume.

• Reverse packaging. Use when the application media or the install instructions are not available to recreate an up-to-date installation of a legacy application in its current supported operating system.

There are no system drive restrictions for using this model.

Note

If the criteria for standard packaging is met, then we recommend that you apply this packaging model instead of the GRP or reverse packaging model.

Application server

The legacy application server on which the legacy application is installed and runs.

Clone of the application server

(19)

Standard packaging

Guided Reverse Packaging (GRP) is performed directly on the clone of the source server when discovery indicates that the application is installed only on the system drive, and there is no installation media or instructions. For more information about GRP, see How to package an application when installation media is not available (Guided Reverse Packaging) (p. 17). The clone of the source server is also used for the process monitoring phase of the reverse packaging process. For more information about the reverse packaging process, see How to manually package an application when installation media is not available (reverse packaging) (p. 21).

If you do not want to clone the production servers, then you can skip this step and continue with GRP, or follow the initial steps of the reverse packaging process on the production application server. We recommend that you follow standard best practices for working on a production system.

Packaging server

The server is an original build, including service packs, of the server operating system where the application is installed and runs. The EMP product is installed and used to create the EMP application package on this server.

Testing Server—source operating system

This testing server is an original build, including service packs, of the server operating system where the application is installed and runs. It is used to validate the EMP package on the operating system on which it was created.

AWS Testing Server—deployment operating system

This testing server is the target operating system on which the EMP package must run. This server is used to validate the application in an EMP package on the target operating system within the AWS environment.

On-premises testing server—deployment operating system

This server is the target operating system on which the EMP packages must run. This server is used to validate the application in an EMP package in the target, on-premises operating system.

NoteThis step is required only if there is a beneﬁt to test the package in an on-premises environment to validate that it works as expected before migrating the application to AWS, or if it is

required to troubleshoot any issues. It helps identify whether issues are the result of the AWS environment setup, the EMP package, or the target operating system.

If you want someone at AWS or one of our partners to perform the application packaging for you, then submit a request to AWS IQ.

Packaging instructions:

• How to package an application when installation media is available (standard packaging) (p. 15)

• How to package an application when installation media is not available (Guided Reverse Packaging) (p. 17)

• How to manually package an application when installation media is not available (reverse packaging) (p. 21)

How to package an application when installation media is available (standard packaging)

When installation media is available, an application is packaged with the EMP Compatibility Package Builder. The package builder uses installation snapshot-based packaging along with runtime analysis to create compatibility packages for applications.

(20)

Standard packaging

Perform the steps in the following stages to create a compatibility package using the package builder when installation media is available:

• Stage 1: Install capture (Required) (p. 16)

• Stage 2: Runtime analysis (Optional) (p. 16)

• Stage 3: Edit package contents (Optional) (p. 17)

• Stage 4: Package Finalization (Required) (p. 17)

Stage 1: Install capture (Required)

1. After you install the tools from the End-of-Support Migration Program for Windows Server product page, launch the package builder from your desktop.

2. On the Select Package Folder page, choose Select Folder. Select a package folder to specify where the package will be created, then choose OK.

3. Choose Next.

4. On the Start Capture page, choose Start Capture to capture the state of the system before the application is installed.

5. Choose Next when the capture is complete.

6. Install the application, components, and any required dependencies.

7. When all of the installations have completed, reboot ONLY if required by the application installer.

After the reboot completes, you can restart the package builder from your desktop.

8. Return to the package builder, and on the Install Application page, choose Next.

9. If required, proceed to Stage 2: Runtime analysis (Optional) (p. 16); otherwise, choose Next to proceed to Stage 3: Edit package contents (Optional) (p. 17) .

NoteWhen it is launched from the desktop shortcut only, runtime analysis reviews file and registry operations (for example, read, modification, and creation) performed by processes. This is not a required step, but can be used to review and include changes to the registry and file system during the first run of the application. It can also be helpful to review what the application processes do when running under the EMP engine.

Stage 2: Runtime analysis (Optional)

The package builder detects all files, registry keys, and shortcuts created or modified when the application runs for the first time. Shortcuts are displayed on the Run Installed Applications screen. If no shortcuts are displayed, proceed to Stage 3: Edit package contents (Optional) (p. 17).

Important

Do not use any desktop or Start menu shortcuts. Start the application using only the shortcuts displayed in the package builder. If you use shortcuts other than those displayed in the package builder, conﬁguration changes will not be captured by the package builder.

The following steps enable application files and registry entries that are created when the application is configured for the first time to be captured in the package.

1. Start the application by using the shortcut in the package builder. Do not use shortcuts on the desktop or Start menu.

2. Choose each shortcut to load the shortcuts.

3. Perform any required configuration changes to ensure that the application is configured for users the first time it starts. If the packaged application fails during a particular workflow, or an issue is identified during user acceptance testing (UAT), try to repeat the workflow during the packaging process.

(21)

Guided Reverse Packaging 4. Close the programs, and choose Next to continue.

5. Choose Complete Capture to record the ﬁnal state of the system.

6. After the capture successfully completes, the following message displays Capture completed.

Please click “next” to continue. Choose Next.

Important

Do not uninstall the application during runtime analysis or the package builder will capture this change and create the package without the application.

Stage 3: Edit package contents (Optional)

Files, registry keys, and redirects can be added to, removed from, or modiﬁed in the package depending on what was captured during the install capture and runtime analysis.

The following steps show how to modify the contents of the package.

1. On the Captured Files page, you can use the left-hand pane Files in package to view or remove ﬁles, or to add redirections for ﬁles captured in the package by the install capture process.

2. Navigate to the ﬁle or folder, open the context (right-click) menu, then choose Redirect or Remove Item, as required. If you choose a folder and want to redirect all subfolders, then choose Redirect Children.

If you redirect or remove an item, the available options on the context menu changes to Remove Redirect or Add Item, which allows you to reverse your changes.

3. To include the ﬁles detected by runtime analysis, use the right-hand pane Files requested at runtime

4. Navigate to the ﬁle, open the context (right-click) menu, and choose Include in package.

5. Choose Next, which displays the Captured Registry Keys page. From this page, you can view and manage registry keys in the same way as ﬁles.

6. Choose Next when you have made the required changes for registry keys.

Stage 4: Package Finalization (Required)

1. On the Package page, in the App Name box, enter a unique name for the application, which automatically populates the App ID box.

2. Optionally, enter a description for the application in the Description box.

3. From the Run drop-down list, optionally select the executable that is used to load the application.

4. Choose Package App to create the package.

5. Choose Next when the Press “Next” to continue message is displayed.

6. To view the contents of the package, choose Open Package.

7. To make changes, choose Edit this Package to modify the contents of the package or to change the name, description, and initial executable in the package.

8. When you are ﬁnished, close the package builder by choosing the X in the top right-hand corner.

How to package an application when installation media is not available (Guided Reverse Packaging)

You can package your applications running on end-of-support Windows servers with guided assistance using Guided Reverse Packaging (GRP). GRP automates much of the process of creating a compatibility

(22)

Guided Reverse Packaging

package using the EMP package builder. It also provides automated dependency recommendations to reduce the amount of manual discovery required to perform the packaging process. The output of the GRP process is an EMP package, which can run on the latest version of Windows Server.

NoteGRP improves the reverse packaging process. GRP currently supports applications spanning a single system drive. For applications spanning multiple local drives, we recommend that you follow the steps for the manual reverse packaging process (p. 21). For applications with installation media that spans only a single system drive, follow the steps for the standard packaging (p. 15) model.

GRP topics

• Prerequisites for Guided Reverse Packaging (p. 18)

• How Guided Reverse Packaging works (p. 18)

• EMP Compatibility Package Builder GRP tabs and controls (p. 18)

• Get started with Guided Reverse Packaging (p. 19)

• Managing advanced conﬁgurations (p. 20)

Prerequisites for Guided Reverse Packaging

In order to use Guided Reverse Packaging (GRP), the following prerequisites must be met:

• You must be able to access the source server with the application you want to package. The server can be on-premises or in the cloud.

• You must install AWS EMP Compatibility Package Builder using Microsoft Installer (MSI). For more information, see Install AWS EMP Compatibility Package Builder (p. 13).

For limits and OS requirements to use AWS EMP Compatibility Package Builder, see AWS End-of-Support Migration Program (EMP) for Windows Server limitations (p. 7) and AWS End-of-Support Migration Program (EMP) for Windows Server System requirements (p. 6).

How Guided Reverse Packaging works

The following high-level steps occur when EMP Guided Reverse Packaging (GRP) is performed:

1.Discovery — you provide entry points to the application, such as ﬁles and folders.

2.Dependency discovery

• Static analysis: GRP analyses the ﬁle and folders that are provided, and captures the relevant dependencies of your application based on data such as dependent components, keywords, timestamps, and application paths. You can verify these dependencies using GRP by optionally removing dependencies that are not related to the applications.

• Runtime analysis: GRP can monitor application process activity during workﬂow exercises so that dependencies used at application runtime are captured in the package.

3.Package ﬁnalization — you create an EMP compatibility package of the application.

EMP Compatibility Package Builder GRP tabs and controls

This section describes the functions of the GRP tabs and controls.

GRP tabs

• Selected ﬁles — permits you to select ﬁles and folders to include in the package.

(23)

• Discovered files — displays files and folders identified by the discovery process. You can use the interface to remove any unwanted files and folders by choosing Exclude next to the item that you want to remove. Excluded items are displayed in the Excluded files section. To include an item that was previously excluded, next to the item, choose Include.

• COM — displays discovered COM components.

• Services — displays discovered services.

• Registry — displays discovered registry keys. You can manually add or remove registry keys, if required. To add a new registry key, enter the path to the key that you want to add, and choose Add new key. The following formats for adding new keys are supported:

• HKCU

• HKLM

• HKEY_CURRENT_USER

• HKEY_LOCAL_MACHINE

GRP validates the existence of the key on the source server before adding it. To delete a key, next to the registry key you want to remove, choose Exclude. The key is moved to the Excluded keys section.

To include a key that was previously excluded, choose Include next to the key.

GRP controls

• Change folder — allows you to select a different project folder than what you initially specified. You can switch between different GRP project folders without having to close and reopen GRP each time a different package requires updating.

• Runtime analysis — allows you to start and stop runtime analysis, so that you can monitor the ﬁle and registry activity of running processes on the source server.

• Discover dependencies — allows you to perform GRP discovery with the data collected form the static and runtime analyses.

• Create package — allows you to create an EMP package when GRP discovery is complete.

Get started with Guided Reverse Packaging

1. Download the AWS EMP Compatibility Package Builder to your source server from the EMP Tooling for End-of-Support Migration Program for Windows Server page.

2. Run the MSI Installer to install the AWS EMP Compatibility Package Builder on the source server. If you have already installed a previous version of EMP, you can automatically upgrade using the latest MSI. For version history, see AWS End-of-Support Migration Program (EMP) for Windows Server version history (p. 72).

3. Double-click on the Guided Reverse Packaging (GRP) shortcut located on the Windows desktop or Windows Start menu.

4. Choose an empty folder to start a new packaging project and choose OK. The EMP package will be created in this folder.

5. You are taken to the Selected ﬁles tab, where you have access to other GRP tabs and controls located at the top of the page. For more information about each tab and control, see EMP Compatibility Package Builder GRP tabs and controls (p. 18).

6. On the Selected ﬁles tab, choose:

• Add folder to select the folder where the application is located/installed.

• Add ﬁles to add any additional ﬁles that have not been added with Add folder.

GRP uses this data to scan the server for application dependencies. The quality of the dependency discovery is greater when more data is provided at this stage.

(24)

If you are packaging an application for which you are initially unaware of the required application folders, we recommend that you perform a manual pre-discovery step, whereby you analyze other entry points of the application to trace back the required application installation directory.

For example, if you know which application services are running in Windows services, check the properties of the application services that contain the application installation folders and ﬁles required by GRP.

7. Choose Runtime analysis to perform typical workﬂows for the application. For example, launching the application from the Start menu to perform workﬂows, and restarting any Windows services.

When you have completed your performance of typical workﬂows, choose Runtime analysis to stop monitoring.

NoteTo capture high-quality application runtime dependencies, we recommend that you use the application as it is typically used in your environment. This includes running through common workflows performed by your users, and any workflows performed at the end of the month or quarter, such as reporting. This ensures that relevant runtime dependencies are captured in the GRP discovery and packaging cycle. If runtime analysis misses one or more dependencies because of not being able to perform a unique workflow, you may have to rerun the GRP process.

8. Discover dependencies will show an amber warning. Choose Discover dependencies to allow GRP to perform the automated discovery process. A progress bar displays the number of steps completed out of total number of steps in the discovery process. The amber warning clears when detection completes.

9. (Optional) Verify the data captures in the Discovered ﬁles, COM, Services, and Registry tabs. Add or remove any required additional ﬁles or registry keys.

NoteIf changes are made to the detected dependencies, then Discover dependencies will show an amber warning. Rerun Discover dependencies until the warning is cleared before you move to the next step. This ensures that your package is created with up-to-date discovery data.

10. Choose Create package when you are satisﬁed with the list of included dependencies. Enter an application name and ID for the compatibility package, and choose Package app. GRP proceeds to create a package for the application.

11. When the package creation is complete, choose Open package to navigate to the location of the newly created EMP package.

Managing advanced conﬁgurations

Guided Reverse Packaging (GRP) does not support automatic discovery and packaging for applications that use local users and groups/NTFS permissions. You can migrate applications that use local users and groups/NTFS permissions by using the DeploymentScript.xml program task. For local users and groups, identify the local users and groups to be migrated from the source server. Note the users added to these groups. Construct a script that creates these local users and groups on the target Windows server. Configure the DeploymentScript.xml file program task in the package to run this script during package deployment. For an example configuration, see Managing EMP custom configurations (p. 58).

Similar to the process for migrating local users and groups, for NTFS permissions, create a script that migrates the required NTFS permissions, and conﬁgure the DeploymentScript.xml ﬁle to run this script during the package deployment.

To manually add side-by-side assemblies required by the application, see Add side-by-side (SXS) assemblies to an EMP compatibility package (p. 63).

To package an IIS-based application, see Package an IIS-based application (p. 30).

(25)

Reverse packaging

How to manually package an application when

installation media is not available (reverse packaging)

The following steps can be performed to manually create a compatibility package using the package builder when installation media is not available, and the application dependencies are present across multiple Windows volumes on the source server.

NoteFor applications without installation media for which dependencies span multiple local drives, we recommend that you follow the steps in this topic for manual reverse packaging.

For applications without installation media for which dependencies are located on a single system drive (typically the C: drive), we recommend that you use Guided Reverse Packaging (p. 17)to create a compatibility package. For applications with installation media that span only a single system drive, follow the steps for the standard packaging model (p. 15).

Manual reverse packaging topics

• Prerequisites for manual reverse packaging (p. 21)

• Use Process Monitor to discover the ﬁles and registry keys used by the application (p. 22)

• Filter the capture (p. 23)

• Choose which processes to save in the capture (p. 23)

• Capture the ﬁles and registries (p. 23)

• Create the export bundle of the ﬁles and registry keys required for the application (p. 25)

• Create the new packaged version of the application (p. 25)

• Package applications on multiple drives (p. 26)

• Integrate COM+ applications into EMP packages (p. 27)

Prerequisites for manual reverse packaging

The following prerequisites must be met to manually package an application when the installation media is not available.

Requirements for manual reverse packaging

To successfully migrate server applications when the installation media is unavailable, you must have access to a virtual server or instance with a working version of the application.

Software prerequisites for manual reverse packaging

The following software is required to package an application without the installation media.

• Windows SysInternals Process Monitor (Procmon.exe). Used to trace ﬁles, processes, and registry keys of a running application. Copy the procmon.exe tool to a folder on the instance. In the

packaging procedure described in this topic, we copy it to the ReversePackagingTools folder of the EMP Compatibility Package Builder installation .

• The EMP package builder. To install the EMP Compatibility Package Builder, see Install AWS EMP Compatibility Package Builder (p. 13). You can ﬁnd the reverse packaging tools in the Tools folder of the installation.

• On a 32-bit instance, the default installation folder path is C:\Program Files\AWS\EMP.

• On a 64-bit instance, the default installation folder path is C:\Program Files (x86)\AWS\EMP.

• A text editor with syntax highlighting that supports JSON and XML. Notepad++ is one no cost option.

(26)

Reverse packaging

The next phase of this process is to use Process Monitor to discover the ﬁles and registry keys that are used by the application on the source machine.

To optimize the setup of Process Monitor for reverse packaging, see Optimize Process Monitor for Reverse Packaging (p. 53).

Use Process Monitor to discover the ﬁles and registry keys used by the application

The next phase of the manual reverse packaging process is to use Process Monitor to discover the ﬁles and registry keys that are used by the application on the source machine.

To set up Process Monitor for application discovery, see Optimize Process Monitor for Reverse Packaging (p. 53).

Reverse packaging steps

• Prepare to discover the application (p. 22)

• Discover the ﬁles and registry keys used by the application (p. 22)

Prepare to discover the application

To prepare for discovery, complete the following steps.

1. Verify that no applications or processes other than those required by Windows are running. This improves the quality of the capture.

2. Navigate to the ReversePackagingTools folder.

3. Open (double-click) procmon.exe to launch Process Monitor.

4. On the Process Monitor License Agreement pop-up, choose Agree to load Process Monitor.

5. To ensure that Process Monitor captures everything that happens on the machine, you must enable advanced output by selecting Enable Advanced Output from the Filter dropdown menu.

Discover the ﬁles and registry keys used by the application

After Process Monitor is installed and conﬁgured, complete the following steps to discover the application:

1. Load the application that you want to discover.

2. Use the application to perform typical operations.

To get a high-quality discovery of the application files and registry keys, use the common workflows performed by your users and any workflows performed at the end of the month or quarter, such as reporting. If you load and close the application only, you are more likely to generate a package that fails during user acceptance testing. We recommend that you use the application as it is typically used in your production environment, and for a longer period of time. This prevents the necessity of repeating the discovery process because of missed files and registry keys.

If you are not sure which workﬂows are relevant to the application, ask an end user of the application to perform their workﬂows on the application.

3. When you have ﬁnished using all of the features that you want to discover, close the application.

4. Return to the Process Monitor application.

5. Choose the Capture icon (image of a magnifying glass) on the Process Monitor toolbar. The Process Monitor dialog box will display, stating Disconnecting from Event Tracking for Windows (ETW). This can take up to a minute. When the disconnection completes, the Capture icon will appear as crossed out by a red line.

(27)

Reverse packaging

Filter the capture

After you create the capture, you must ﬁlter the output and determine which items to safely discard.

To ﬁlter the capture, perform the following steps:

1. Choose the Show Process and Thread Activity icon on the Process Monitor toolbar to clear the selection. This removes these operations from the Process Monitor trace because they are not required for this process.

2. Choose the Show Network Activity icon on the Process Monitor toolbar to clear the selection. This removes these operations from the Process Monitor trace because they are not required for this process.

3. Choose the Save icon on the toolbar.

4. On the Save to File pop-up, verify that both Events displayed using current ﬁlter and Also include proﬁling events are selected, then choose OK.

NoteLater in this procedure, we will save only the processes that we believe should be included in the capture as the basis for capturing and creating the packaged version of the

application. The reason we save the capture at this point in the overall process is to have the option to reload this version of the capture if we later realized we have omitted something from the ﬁnal capture. This prevents the necessity of repeating the capture from scratch if we omitted something in error.

5. Display the process tree by entering CTRL+T or by selecting Process Tree from the Tools menu. The process tree displays, showing all of the processes captured by the Process Monitor.

Choose which processes to save in the capture

After saving the capture, you must choose which processes to save. Choose only the processes required by the application to run successfully.

To save processes in the capture, complete the following steps.

1. Scroll through the Process Tree until you locate the executable used to load the application.

2. Choose the executable.

3. Choose Include Process to save this process in the ﬁnal capture.

4. Review the Process Tree for additional processes to include in the ﬁnal capture. Choose Include Process or Include Subtree as required.

5. When you are ﬁnished reviewing the Process Tree, choose Close.

6. On the toolbar, choose the Save icon.

7. On the Save to File pop-up, verify that both Events displayed using current ﬁlter and Also include proﬁling events are selected.

8. Under the Format section, select Comma-Separated Values (CSV), and then choose OK.

9. Open Windows Explorer and verify that the log ﬁle has been created in the .CSV format, and that the ﬁle size is greater than 0.

10. Close the Process Monitor.

Capture the ﬁles and registries

After creating the log ﬁle, you must run the EMP reverse packaging tools to process the .CSV capture ﬁle created by Process Monitor. The following two tools are used in this process:

(28)

Reverse packaging

• GeneratePackageSource. This command compiles a list of the ﬁles and registry keys accessed by the application from the Process Monitor capture. These are exported to a .JSON ﬁle one line at a time.

• RemoveKnownFolders. This command removes known ﬁles, folders, and registry keys that are not required from the Process Monitor capture. Examples include background Windows services and components that are already present on the target server.

To process the capture ﬁle with EMP tools, complete the following steps.

1. Open a command prompt as an administrator.

2. Navigate to the folder that contains the Process Monitor capture ﬁles, for example, C:\Program Files\AWS\EMP\Tools\ReversePackagingTools.

3. Enter the following command, where <procmoncapture.CSV> is the name of the .CSV ﬁle that you created and <outputfilename.json> is the name of output ﬁle that you want to create:

type <procmoncapture.CSV> | GeneratePackageSource.exe | RemoveKnownFolders.exe > <outputfilename.json>

For example:

type Logfile.CSV | GeneratePackageSource.exe | RemoveKnownFolders.exe > source.json

Note

The GeneratePackageSource and RemoveKnownFolders commands can be run one at a time by ﬁrst piping the logfile.CSV into GeneratePackageSource.exe, and then running RemoveKnownFolders.exe to generate the source.json. If the GeneratePackageSource.exe hangs, the Process Monitor may still have a lock on the CSV ﬁle. If this is the case, resolve by rebooting the machine.

4. Navigate to Windows Explorer and verify that the .JSON ﬁle has been created and that its size is greater than 0.

5. Edit the .JSON ﬁle in a text editor, such as Notepad++.

6. Remove the lines where the path name is the same because a folder includes any subfolders and contents.

In this example, the ﬁles listed in the selected area of the .JSON ﬁle can be updated to

"%ProgramFiles\\Microsoft SQL Server", because it includes the folders and contents of this folder.

7. Remove other items that are not relevant to the application and change entries, such as hardcoded drive letters, to variables.

(29)

Reverse packaging

8. Save the file with a different file name, such as FilteredSource.json. This allows you to revert to the original file if you encounter problems later in the packaging process.

Create the export bundle of the ﬁles and registry keys required for the application

After you edit and save the ﬁltered source .JSON ﬁle, you must run the ExportFromSystem EMP tool.

This tool reads the .JSON file and compiles copies of files and extracts copies of registry keys required to run the application. It adds them to the Files and Registry folders in the ReversePackagingTools folder. When the export is complete, these folders and their contents are compressed into a file called PackageSource.zip.

NoteBefore you run this command, verify that all application services and processes are stopped so that all of the required resources are successfully exported from the system. Any processes and services that are in use will prevent a successful export.

Follow these steps to run the ExportFromSystem EMP tool.

1. Return to the administrator command prompt that you opened previously. If you closed it, open a new command prompt as an administrator and navigate to C:\Program Files\AWS\EMP\Tools

\ReversePackagingTools.

2. Enter the following command. <filterfile.JSON> is the name of the .JSON file that you created when you captured the files and registry keys. <logfilename.txt> is the name of the log file that you want to create to capture the output of running the ExportFromSystem command.

type <filterfile.JSON> | ExportFromSystem.exe > <logfilename.txt>

For example:

type FilteredSource.json | ExportFromSystem.exe > exportfromsystem.txt

We recommend that you pipe the output to a ﬁle to check for errors.

NoteIt takes a while before the C:\Program Files\AWS\EMP\Tools

\ReversePackagingTools prompt displays. This is because of the number of actions being performed by the ExportFromSystem tool.

3. Open Windows Explorer and verify that the PackageSource.zip has been created and that its size is greater than 0. When the PackageSource.zip is created, you can use this to create an EMP package for the application.

Create the new packaged version of the application

The ﬁnal step in the manual reverse packaging process is to create a new packaged version of the application.

To package an application, the virtual machine on which the application is to be packaged must be running the same version and service packs as the source machine of the application.

You must ﬁrst copy the PackageSource.zip that you previously created to a new virtual machine.

1. Log on to the new virtual machine.

2. Copy and extract the PackageSource.zip to an empty folder.

(30)

Reverse packaging

The contents of the PackageSource.zip should be the same as the C:\Program Files\AWS

\EMP\Tools\ReversePackagingTools folder on the source machine.

3. Follow the steps to create a new package using the EMP Compatibility Package Builder. When Install Application is displayed, you can install the application.

You can now install the application using the EMP DeploytoSystem tool, which automates the

installation process. The application must be installed with this tool, and not with the application's native installation system.

1. As an administrator, open a command prompt.

2. Go to the folder that contains the ﬁles extracted from the PackageSource.zip.

3. Enter the following command, where <filterfile.JSON> is the name of the .JSON file that you previously created of the final list of files and registry keys used by the application, and

<logfilename.txt> is the name of the log ﬁle that you want to create to capture the output of the DeployToSystem command.

type <filterfile.JSON> | DeployToSystem.exe > <logfilename.txt>

For example:

type FilteredSource.json | DeployToSystem.exe > deploytosystem.txt

We recommend that you pipe the output to a ﬁle to check for errors.

It will take a while before your folder is redisplayed. If you are prompted to reboot the instance, you should do so only after the application is installed. If you reboot, run the Compatibility Package Builder using the desktop shortcut.

When the command prompt is displayed, return to the EMP Compatibility Package Builder to complete the packaging process.

Package applications on multiple drives

This section shows the additional conﬁguration required to capture applications that are set up on multiple drives. For this example, a typical install of SQL Server 2000 is installed on the C drive, and the data is stored on the D drive.

Application directories

• Data directory — D:\Program Files\Microsoft SQL Server

• Application directory — C:\Program Files\Microsoft SQL Server

The Process Monitor backing ﬁle should be used if process monitoring will take several minutes or hours.

Create this on the non-system drive with additional ﬁlters.

Example: package applications on multiple drives for SQL Server 2000 1. Expand PackageSource.zip to the C drive.

2. Run the DeployToSystem command from the C drive location. File copy errors may occur if you run this command from the D drive.

3. Package ﬁles in the C drive may contain references to D drive locations. These locations must be redirected in the AppRegistry.xml ﬁle.

(31)

Reverse packaging

<Write>

<KeyName>HKEY_CURRENT_USER\Software\AWSEMP\Compatibility.Package|%GUID%\HKLM

\SOFTWARE\Microsoft\MSSQLServer\Replication</KeyName>

<ValueName>WorkingDirectory</ValueName>

<Value ValueType="String">D:\ProgramFiles\Microsoft SQL Server\MSSQL\REPLDATA</

Value>

</Write>

Many applications also have an internal configuration file that contains important file or directory paths. For example, SQL 2000 includes a sqlsunin.ini file with important file paths. If redirection is not implemented in this file for calls to the D drive file locations, the SQL Server fails to start.

The procmon and compatibility engine logs will show several non-redirected and path not found errors, especially in the ERRORLOG ﬁle.

4. Add the following folder match redirection to Redirections.xml to redirect calls from the D drive to the package.

<To>ProgData</To>

</FolderMatch>

Integrate COM+ applications into EMP packages

This topic contains information for scripted integration of COM +applications into EMP packages. This includes how to detect whether an application includes COM+ applications and how to include COM+

applications in EMP packages.

COM+ application topics

• Detect whether an application includes COM+applications (p. 27)

• Include COM+ applications in an EMP package (p. 28)

Detect whether an application includes COM+applications

Detect COM+ applications

1. Open the Component Services console using one of the following methods.

• Run dcomcnfg in the command line or using PowerShell and expand Component Services.

• Open Component Services from the Start menu: Start>All Programs>Administrative Tools>Component Services.

• Enter Component Services in the Search box.

2. Expand Component Services to list the COM+ applications. The following are the default COM+

applications that are included in Windows Server 2003 R2 and 2008 R2, with IIS and Application Server roles enabled. .NET Utilities is included only in Windows Server 2003 R2. COM+ Utilities (32- bit) is only included on Windows Server 2008 R2. The rest of the applications are included on both operating system versions.

• .NET Utilities (Windows Server 2003 R2)

• COM+ Explorer

• COM+ QC Dead Letter Queue Listener

• COM+ Utilities

AWS End-of-Support Migration Program (EMP) for Windows Server

AWS End-of-Support Migration Program (EMP)

for Windows Server

User Guide

AWS End-of-Support Migration Program (EMP) for Windows Server:

User Guide

Table of Contents

What Is AWS End-of-Support Migration Program (EMP) for Windows Server?

Features of AWS End-of-Support Migration Program (EMP) for Windows Server

AWS End-of-Support Migration Program (EMP) for Windows Server concepts

Accessing AWS End-of-Support Migration Program (EMP) for Windows Server

Pricing for EMP

How AWS End-of-Support Migration Program (EMP) for Windows Server works

The AWS End-of-Support Migration Program (EMP) for Windows Server process

Discovery

Packaging preparation

Packaging

Deployment

AWS End-of-Support Migration Program (EMP) for Windows Server System requirements

AWS End-of-Support Migration Program (EMP) for Windows Server limitations

Data collection

Components of the EMP Compatibility Package Builder

Get started with AWS End-of-

Support Migration Program (EMP) for Windows Server

AWS End-of-Support Migration Program (EMP) for Windows Server decision tree

Planning an AWS End-of-Support Migration Program (EMP) for Windows Server migration

High-level AWS End-of-Support Migration

Program (EMP) for Windows Server application discovery exercise

Install AWS EMP Compatibility Package Builder

AWS End-of-Support Migration Program (EMP) for Windows Server application packaging model

How to package an application when installation media is available (standard packaging)

Stage 1: Install capture (Required)

Stage 2: Runtime analysis (Optional)

Stage 3: Edit package contents (Optional)

Stage 4: Package Finalization (Required)

How to package an application when installation media is not available (Guided Reverse Packaging)

Prerequisites for Guided Reverse Packaging

How Guided Reverse Packaging works

EMP Compatibility Package Builder GRP tabs and controls

Get started with Guided Reverse Packaging

Managing advanced conﬁgurations

How to manually package an application when

installation media is not available (reverse packaging)

Prerequisites for manual reverse packaging

Requirements for manual reverse packaging

Software prerequisites for manual reverse packaging

Use Process Monitor to discover the ﬁles and registry keys used by the application

Prepare to discover the application

Discover the ﬁles and registry keys used by the application

Filter the capture

Choose which processes to save in the capture

Capture the ﬁles and registries

Create the export bundle of the ﬁles and registry keys required for the application

Create the new packaged version of the application

Package applications on multiple drives

Integrate COM+ applications into EMP packages

Detect whether an application includes COM+applications