Freigeben über

Preparing for the IIS Migration with Web Deploy

  • Artikel

 

clip_image001

General Eisenhower made this quote right before the D-Day invasion in World War II and he continued to use the quote during the war and it sums up the migration process as the easiest part is using the Web Deploy tool to move the files to the new server and setup the IIS configuration. The challenges arise when troubleshooting the application exceptions  and other issues preventing the application from functioning. This post will explain the planning process I have used in the past to prepare for the migration.

Before each onsite visit for an IIS migration, I request the customer complete the following items to ensure the migration is successful as well as making sure we make good use of the time while I am onsite:

  • Catalog all sites and applications hosted on the server
  • Discuss the application dependencies with the development team
  • Determine owner of each site or application
  • Create a test plan to validate the application functions correctly on the new server(s)
  • Determine the IIS dependencies
  • Review Event Logs for Application Errors

Assumption: The IIS administrator is the migration project owner and responsible for the migration.

Catalog all applications and websites on server

This exercise will allow the IIS admin to create a listing of sites to migrate to the new server with the ability to remove old or outdated sites. It is surprising to see how cluttered web servers become when applications and web sites are loaded onto the server and essentially forgotten about, or not used for long period of time. Do some house cleaning and remove the clutter by having a discussion with the owner of the application/site and determine if it should be migrated. This will reduce the total time required during the migration and prevent you from troubleshooting an old application once it is migrated to the new server.

Methods to Determine Old Site:

  • Review the modified date on the files
  • Run log parser queries on the IIS logs to determine the last time server had a request
  • Discuss the catalog of sites and applications with the development team and ensure each site\application has an owner
  • Use Appcmd to generate a list of sites

Appcmd Methods to List Sites:

IIS 7.x and up only:

>Appcmd list Site

>appcmd list app

Another method is to output the list to a text file and import into Excel to build out a matrix

clip_image002

Here is a link to other methods to list the sites on a server: https://technet.microsoft.com/en-us/library/cc771280(v=WS.10).aspx

IIS 6.0

A combination of the following built in IIS scripts will output the web sites and virtual directories:

%SystemRoot%\System32\IIsWeb.vbs > c:\_webdeploy\IIS6Sites.txt

%SystemRoot%\System32\IIsVdir.vbs > c:\_webdeploy\IIS6VirtualDirectories.txt

This TechNet article has more information the IISWeb.vbs script usage: https://technet.microsoft.com/en-us/library/cc728368(v=WS.10).aspx

Discuss the application dependencies with the development team

This step allows the development teams to evaluate the applications running on the server and provide the dependencies required for the application to execute on the server. If the dependency is not marked as local (in the application folder), the .NET framework will check the GAC before an exception occurs. Update the Excel listing with the required dependencies for each application and install on the new server.

Determine owner of each site or application

What happens if there issues with the migrated site or application? Who do you contact to take ownership on the research and troubleshooting of the site or application? This is an important step in the migration process as someone is either familiar with the application or is the actual development team responsible for the application and becomes your go-to person for questions and troubleshooting. If there is not an owner, don't migrate the site or application.

Create a test plan to validate the application functions correctly on the new server(s)

This is the hardest part of the planning as it requires a review of the application with explicit steps to test the application on the new server. An application may compile after the migration and the user can log in and proceed to the landing page. However, pages may not function correctly or exhibit unexpected behavior deeper into the application. By having the test plan, the IIS admin can state without a doubt, the application has been successfully migrated.

Validate the test plan BEFORE the migration on the current IIS server.

The side effect of this planning task is that it allows the admin time to obtain logins to the application ahead of the migration date and become familiar with the testing.

Determine the IIS dependencies on the source server

Using the Web Deploy utility, determine the IIS components installed on the source server and ensure the exact same components are applied on the target server. A future post will explain how to proceed with the command.

Review Event Logs for Application Errors

Catalog all of the exceptions for each application on the source IIS server to eliminate troubleshooting errors and exceptions on the new IIS server. If the application is misbehaving on the current IIS server, it may continue to generate the same exceptions on the new IIS server and you don’t want to waste precious time troubleshooting these exceptions.

Good luck in the planning phase and let me know about additional steps you have taken to prepare for the migration.