Problems with IIS Module detection

[nlinnett-cfmws]

We are trying to migrate an ASP.Net app from IIS 7.5 on Server 2008R2 up to Azure. The initial run of the assistant gave us three errors, two of which I could clear myself, one we cannot clear.

It is detecting the AppWarmupModule installed in the application (it was originally installed). To clear this error I have:

• Removed the module from the app and restarted the server, no success
• Removed the module from IIS totally, and restarted the server, no success

I came here hoping there would be code so that I could see what it was being triggered by.

We are currently working with John Scott (from Microsoft AZURE team) on the migration, and he is trying to reach out.

Any help would be appreciated.

[krolson]

Hi @nlinnett-cfmws,

We've been working with the contact you referenced, and posting here also:

The modules check is searching the globalModules list for any that are not in the "allow list" of modules, and will flag if any are present. This section is in applicationHost.config under system.webServer/globalModules (i.e. it is server-level configuration) - you should be able to open applicationhost.config and find the references with a text search on the module name "AppWarmupModule" and see it in a location like below:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   [...]
   <system.applicationHost>
        [...]
    </system.applicationHost>

    <system.webServer>
        [...]
        <globalModules>
            [...]
            <add name="AppWarmupModule" image="[some file path]" />
        </globalModules>

In order for this module not to be flagged, the "AppWarmupModule" globalModules entry would need to be removed (and in order to avoid config 500s, any references to AppWarmupModule in applicationHost.config or web.configs would then also need to be removed. I’m afraid I don’t recall if there’s a direct way to make this globalModules removal happen using the IIS Manager UI – if the removal that was done already was using IIS Manager UI then my guess is that it might allow modifying the modules entry but leave the globalModules entry behind or something similar – and that directly modifying the applicationhost.config may be the most direct way to fully remove this reference (following best practices including backing up the file first!).

[nlinnett-cfmws]

Hi @krolson,

I really didn't want to have to remove the module since it is used by all applications on the server (and it was installed for a reason).

I have tested it on a pre-production server, and commenting out the line in the globalModules section, as well as in the modules section, did in fact allow the assistant to complete successfully. Prior to that, I had tried to just add a locaiotn section and remove the module, but that didn't work either.

We will go ahead and test with this into our Azure pre-prod area, and then work out a schedule when when we can remove the AppWarmupModule temporarily to do the production migration.

Thanks for the help and guidance.

[krolson]

Thank you for this update. It is true that the current assessment logic is based solely on the global module definition even if the module is removed/disabled for a specific site - use of location tags is by itself a potential migration blocker (to avoid losing configuration in apphost.config location tags that won't migrate with the site), and putting a disable reference to a handler like this in web.config that app service doesn't have defined might also cause 500s. I can see how this is a cumbersome limitation in cases like this, and we are looking into some alternative options for making this kind of scenario better in future.

Another option for this particular site, having already done and reviewed the assessment results, might be to use other existing options for the deploying the site step. For example, the site can be created manually using the click-through UI experience of the web portal (portal.azure.com), using Migration Assistant from a different server/source with a placeholder site, or though shell options like AzureCLI (https://docs.microsoft.com/en-us/cli/azure/webapp?view=azure-cli-latest). Then the content could be deployed using FTP (https://docs.microsoft.com/en-us/azure/app-service/deploy-ftp), web deploy/Visual Studio, or even a "drag-n-drop" style .zip deployment that mimics how Migration Assistant would package and deploy the site (steps for this are noted in replies on this issue: https://github.com/Azure/App-Service-Migration-Assistant/issues/31, or related generic deploy doc: https://docs.microsoft.com/en-us/azure/app-service/deploy-zip). The main things you might need to take extra care to set with these approaches would be picking the site settings like framework and defining the virtual directories/applications. I bring this up as using one of the alternate options for moving the site content might be less disruptive than changing up server settings that are in use by other apps. The Migration Assistant is just one method for migration, and while we hope it makes some scenarios easier, it does impose some limitations that can block other cases.

[krolson]

We are looking at options to enable working around this kind of check failure for future versions (including the ability to migrate even when errors are identified: https://github.com/Azure/App-Service-Migration-Assistant/issues/26), in the meantime please use the options noted above either to remove the global module configuration or to manually create a new site and deploy the site content.