BizTalkPlatformManagementTool/docs/PROD-Application-Zuordnung-2026-08-27.md

PROD-Analyse: (Unknown Application) bei Runtime-Artefakten

Stand: 2026-08-27

Fehlerstand: 2.3.2

Zielversion: 2.3.3

Beobachtung und Bewertung

Im PROD-Shutdown-Plan wurden die gefundenen Send Ports mit korrekten Namen und Zuständen angezeigt, die Spalte Application enthielt jedoch durchgehend (Unknown Application). Damit war der WMI-Zugriff selbst erfolgreich; fehlerhaft war die nachgelagerte Zuordnung der Artefakte zu BizTalk-Anwendungen.

Der Lauf wäre technisch weiterhin in der global sicheren Kategorie-Reihenfolge ausführbar gewesen, weil Send Ports über ihren gruppenweit eindeutigen WMI-Namen adressiert werden. Die Anzeige ist dennoch ein Produktfehler: Planreview und anwendungsbezogene Snapshot-/Diff-Auswertung benötigen die echte Ownership. Ein realer Lauf mit ungeklärter Zuordnung ist daher nicht freizugeben.

Root Cause

Version 2.3.2 versuchte bei MSBTS_SendPort, MSBTS_ReceiveLocation und MSBTS_Orchestration Properties namens ApplicationName, Application oder BizTalkApplication auszulesen. Diese Properties gehören nicht zum dokumentierten Runtime-WMI-Vertrag der drei Klassen. Der Code fiel deshalb für jedes betroffene Objekt auf (Unknown Application) zurück.

Die BizTalk-Anwendung ist eine Kataloghierarchie, keine verlässliche Property dieser Runtime-WMI-Objekte. Microsoft stellt sie über Microsoft.BizTalk.ExplorerOM bereit: Eine Application enthält ihre Send Ports, Receive Ports samt Receive Locations und Orchestrierungen. MSBTS_GroupSetting liefert den Server und Namen der BizTalk Management-Datenbank, mit der BtsCatalogExplorer verbunden wird.

Korrektur in 2.3.3

BizTalkApplicationResolver baut vor der WMI-Zustandserfassung einen read-only Index auf:

1. MSBTS_GroupSetting lesen und genau einen Management-DB-Endpunkt verlangen.
2. Die lokal installierte Microsoft.BizTalk.ExplorerOM.dll über CLR/GAC oder vorhandene BizTalk-Verzeichnisse laden.
3. Vor einem dateibasierten Fallback Simple Name und Microsoft-Public-Key-Token prüfen.
4. Applications und deren Send Ports, Receive Ports/Locations sowie Orchestrierungen enumerieren.
5. WMI-Artefakte case-insensitiv gegen diesen Index auflösen; bei Receive Locations dient der Parent-Receive-Port als zusätzlicher Fallback.
6. Namen, die widersprüchlich unter mehreren Anwendungen auftauchen, nicht raten, sondern weiter als unbekannt markieren.

Es gibt weiterhin keine Compile-time-Referenz und keine mitgelieferte Kopie der BizTalk-DLL. Der Installer-Self-Test bleibt WMI- und BizTalk-frei. ExplorerOM wird ausschließlich gelesen; Zustände, Wait-Logik und sämtliche Shutdown-/Restore-Mutationen bleiben beim bestehenden WMI-Adapter.

Wenn Assembly, Management-Datenbank oder Berechtigung nicht verfügbar sind, bricht die Zustandserfassung nicht verdeckt ab. Die betroffenen Zeilen bleiben sichtbar unter (Unknown Application), und Grid sowie Laufzeitlog enthalten die vollständige Ursache. Diagnose meldet künftig sowohl die Zahl sichtbarer Send Ports als auch die Zahl erfolgreicher Application-Zuordnungen.

Lokale Verifikation

• Release-Rebuild aller vier .NET-Framework-4.6.1-Projekte erfolgreich.
• 41 portable Regressionstests erfolgreich.
• Neuer Test deckt Send Port, Receive Location, Receive-Port-Fallback, Orchestration, case-insensitive Namen und mehrdeutige Cross-Application-Namen ab.
• WMI-freier Anwendungsselftest erfolgreich mit 2.3.3-net461.
• Paketmanifest, Installer-ZIP, Certutil-Base64 und SHA-256 werden durch die Release-Chain erzeugt und separat gegengeprüft.

Die lokale Suite kann den echten BizTalk-2020-ExplorerOM-Katalog nicht simulieren. Die abschließende Freigabe benötigt deshalb die folgende PROD-Abnahme.

PROD-Abnahme nach dem Update

1. Setup 2.3.3 als Administrator ausführen und im Setup-Log setup_version=2.3.3.0 sowie erfolgreichen Ziel-Self-Test prüfen.
2. Tool starten, PROD-Zielserver kontrollieren und Dry run aktiviert lassen.
3. Diagnose ausführen. Erwartung: Send ports visible: N; application associations resolved: N. mit identischen Zahlen und ohne nachfolgende Association-Warnung.
4. Laufzeitlog über Log Folder öffnen und den Eintrag BizTalk application catalog loaded through ExplorerOM prüfen. Er muss plausible Zähler für Applications, Send Ports, Receive Ports/Locations und Orchestrations enthalten.
5. Snapshot Before erzeugen und before.json prüfen:
   • keine (Unknown Application)-Gruppe für regulär katalogisierte Runtime-Artefakte,
   • stichprobenartig mehrere Send Ports aus unterschiedlichen Anwendungen gegen die BizTalk Administration Console abgleichen,
   • Receive Locations und Orchestrierungen ebenfalls anwendungsrichtig gruppiert.
6. Shutdown nur als Dry-run ausführen. Im Grid und in shutdown-plan.json müssen die echten Application-Namen erscheinen; Reihenfolge und Schrittzahl gegen den Snapshot prüfen.
7. Erst nach erfolgreichem Katalog-, Snapshot- und Dry-run-Abgleich über einen echten Wartungslauf entscheiden.

Fehlerpfad und Supportdaten

Sind die Diagnosezahlen unterschiedlich oder erscheinen weiterhin unbekannte Anwendungen, keinen echten Shutdown starten. Sichern:

• aktuelle Tageslogdatei,
• Diagnose-Screenshot,
• before.json und Sidecars,
• shutdown-plan.json aus dem Dry-run,
• Setup-Log,
• genaue Windows-Identität des Toolprozesses,
• WMI-/ExplorerOM-/SQL-Exception einschließlich HRESULT und Inner Exceptions.

Dann insbesondere prüfen: lokale BizTalk-Administrationskomponenten/ExplorerOM-Installation, Erreichbarkeit der in MSBTS_GroupSetting gemeldeten Management-Datenbank und Leseberechtigung des ausführenden Kontos.

Microsoft-Quellen

• MSBTS_SendPort (WMI)
• MSBTS_ReceiveLocation (WMI)
• MSBTS_Orchestration (WMI)
• MSBTS_GroupSetting (WMI)
• BtsCatalogExplorer (ExplorerOM)
• Application (ExplorerOM)
• BtsOrchestration (ExplorerOM)