Azure Migrate appliance: web app discovery returns 0 web servers via getfabriclayout, despite Server Discovery successfully reporting AppsAndRoles=True

Hello Ahmed, it sounds like you’ve got server discovery happily reporting AppsAndRoles=True, but the WebApp agent’s getfabriclayout call still shows zero IIS servers. Here’s how it all ties together and what you can try:

1. What feeds the getfabriclayout list? • The Azure Migrate backend only includes machines in getfabriclayout when – Server Discovery sees the IIS role in the software inventory, and – The AppsAndRoles flag is pushed successfully. • In other words, it’s not a separate “magic” property – it’s driven by the combination of:
   1. your software inventory identifying a web-server role
   2. the Server Discovery agent pushing AppsAndRoles=True
   • If either step isn’t fully persisted in the backend database, WebApp discovery won’t show your server.
2. What about timing/lag? • Web-app discovery is batched on the service side about once every 24 hours by default. • After you enable web-apps in a project or Server Discovery pushes an updatefabriclayout, it can take up to 24 hours for getfabriclayout to start returning results. • In practice you’ll often see it appear within a few minutes, but it’s not instantaneous.
3. Can you force an immediate refresh? Yes – two options: a) In the Azure portal:
   1. Go to Azure Migrate > your project > Migration Goals > Servers, databases, and web apps
   2. Click the appliance hyperlink under Discovery and assessment
   3. At the bottom of the table, select Refresh services
   b) On the appliance VM:
   1. Open Services
   2. Restart amwebappsvc (the WebApp discovery and assessment service)
   Both will kick off an on-demand WebApp discovery cycle without waiting for the 24h sync.
4. Why did it drop back to 0 after you re-added the source – and how to avoid it? • Deleting & re-adding the discovery source or credential in the appliance UI effectively clears the web-app cache for that source, so the next sync will start from zero. • Supported way to update credentials without losing your web-app inventory: – In the appliance Configuration Manager, Edit the existing credential (rather than Delete + Add), update the password, and save. – Then trigger an on-demand refresh (portal Refresh services or restart amwebappsvc). This retains the existing server-to-web-app mapping in the backend.

Additional tips:

• Check the Notifications under the Azure Migrate: Discovery and assessment tile – it’ll show any web-app discovery errors (40001‒40007, etc.).

• On the appliance, tail the WebApp agent logs under C:\ProgramData\Microsoft Azure\Logs to see if IIS errors (e.g. 40004 “unable to access IIS config”) are cropping up.

• Verify the IIS Management Console feature is still installed and your service account still has full access to %windir%\System32\inetsrv\config.

Hope this helps. and please feel free to reach out if you have any further questions.

Reference documentation

• Resolve common Azure web app discovery issues

• On-demand web app discovery (portal Refresh services / restart amwebappsvc)

• Common web-apps discovery errors

The behavior described (server discovery and software inventory working while web app discovery shows 0 web servers) is not covered in the provided documentation, and the specific internal behavior of getfabriclayout / updatefabriclayout and their correlation is not documented in the context.

The available guidance for web app discovery issues focuses on standard error codes and prerequisites on the IIS side:

• IIS Management Console must be enabled and the OS must be Windows Server 2008 R2 or later.
• The appliance must be able to connect to the server with valid credentials over WS-Management / PowerShell remoting.
• The credentials must be administrator-level and have access to IIS configuration paths (%windir%\System32\inetsrv and %windir%\System32\inetsrv\config).
• If discovery fails with generic or uncategorized errors (40005, 40006), logs from the appliance should be collected and a Microsoft support case opened.

In addition, the documentation notes that:

• Web apps discovery is performed by a dedicated “Web apps discovery and assessment agent” on the appliance.
• Software inventory must be enabled before workload discovery (including web apps) is initiated.
• When issues persist beyond the normal discovery cycles, the recommended path is to open a Microsoft support case, providing appliance logs from C:\ProgramData\Microsoft Azure\Logs.

Given the context, the questions about:

1. The exact mechanism that populates the WebApp getfabriclayout list and how it correlates with AppsAndRoles: True.
2. Any documented backend-correlation lag between updatefabriclayout and getfabriclayout.
3. Any portal-side or REST operation to force that correlation.
4. Whether the regression from 1 to 0 web servers after deleting/re-adding the discovery source is documented behavior, and the supported way to remap credentials without losing web-app inventory.

are not answered in the provided documentation. The only documented next step for persistent or unexplained discovery behavior is to collect logs and raise a Microsoft support case so the backend behavior can be investigated.

References:

• Troubleshoot ongoing server discovery, software inventory, and SQL and web apps discovery
• Azure Migrate appliance
• Discovery methods in Azure Migrate