Closed samaea closed 2 years ago
Hi @samaea,
Thank you for letting us know this doesn't seem right - I can see how that looks a little funny. The reason for this behavior is that we consider some checks to be "warning" level and not "blocking" - so while the site has an identified warning for the TcpPortCheck, we don't consider that to be a blocker for going ahead and trying out the migration and no other (Blocking) checks failed.
Specifically the TcpPortCheck looks at the bindings and whether the app is configured to receive traffic on ports other than 80 and 443. On App Service side incoming HTTP traffic will only be allowed on these 2 ports. The app may still be migrated without making code or configuration changes. Clients making requests to the new App Service site would have to specify the app service site URL without the less-standard ports, so we definitely still want you to be aware that this is something that would be different between the local IIS and App Service versions of the site since it might require changes to clients of the site.
I think the confusion came from the UI version of the tool which does not allow you to proceed with the migration upon that warning being thrown (if I recall correctly). Thanks for the clarity Krolson!
Even though migration warnings are displayed when running .\Get-SiteReadiness.ps1 that will prevent migration on Site X, it still states "Site X No Blocking issues found and the site is ready for migration to Azure!"
Investigative information
Please provide the following:
Repro steps
Provide the steps required to reproduce the problem:
Expected behavior
Script should inform me the site is not ready for migration and that remediation step Y is required to resolve the issue before I am able to migrate the site to App Service.
Actual behavior
Although TCP Port warnings are displayed, it states "Site X No Blocking issues found and the site is ready for migration to Azure!"
Known workarounds
N/A