Fix BizTalk application ownership mapping

README.md

@@ -22,6 +22,7 @@ WinForms tool for controlled Microsoft BizTalk Server 2020 platform operations d
 - Host instance handling for the selected BizTalk server
 - Dry-run mode enabled by default
 - WMI access through `root\MicrosoftBizTalkServer`
+- Correct application ownership from the read-only ExplorerOM application hierarchy, with WMI retained for runtime state and mutations
 - Startup check for administrator rights
 - Detailed operation logging in the GUI and daily rolling log files in a write-verified local directory
 - Automatic operation-log restoration into the grid after an application restart
@@ -33,7 +34,7 @@ WinForms tool for controlled Microsoft BizTalk Server 2020 platform operations d
 - Durable per-step result reports even when a shutdown or restore completes only partially
 - Environment status indicator based on host instance state
 - Clear and Close actions in the main toolbar
-- No compile-time dependency on BizTalk ExplorerOM assemblies
+- No compile-time dependency on BizTalk ExplorerOM assemblies; the installed Microsoft assembly is loaded process-locally with identity validation
 - Transactional Windows installer/updater with SHA-256 payload validation and rollback
 - Bounded activation retries plus a verified copy fallback for first installs and atomically backed-up updates when Windows/EDR blocks only the staging rename
 - Opt-in all-users desktop shortcut whose ACL, WSH, validation or rollback failures remain visible but cannot roll back the core installation
@@ -100,6 +101,8 @@ At every start, the application performs an actual create/write/flush/delete pro
 
 ## Troubleshooting
 
+The BizTalk runtime WMI classes for Send Ports, Receive Locations and Orchestrations do not expose a reliable application property. The tool therefore reads `MgmtDbServerName`/`MgmtDbName` from `MSBTS_GroupSetting`, opens the installed read-only ExplorerOM application catalog and builds an application/artifact index before collecting WMI state. **Diagnose** reports both visible and application-resolved Send Port counts. A mismatch is never silently presented as a valid association: affected rows stay under `(Unknown Application)` and the Operation Log records whether ExplorerOM loading, Management database access or catalog matching failed.
+
 The Operation Log shows the WMI class, key property, key value and method for real shutdown and restore steps. WMI objects are resolved with a broad `SELECT * FROM <class>` query and a client-side key filter so names containing special characters do not break the WMI query parser.
 
 Execution is deliberately best-effort. A failure such as an adapter-specific validation exception is written as `Failed` in the result report, but later independent plan steps are still attempted. The GUI ends in a failed/operator-review state when any step failed; it never reports a partial execution as an unconditional success. The post-operation snapshot is attempted independently and its own failure is preserved in the same report.
@@ -144,5 +147,6 @@ Targeted German inline comments explain non-obvious operational decisions such a
 - [PROD ScheduledTask control and runtime logging runbook](docs/PROD-ScheduledTask-und-Laufzeitlogging-2026-08-26.md)
 - [PROD runtime-log storage validation and 2.3.1 fix](docs/PROD-Laufzeitlog-Ablage-2026-08-26.md)
 - [PROD shutdown drain checkpoint and application-status analysis](docs/PROD-Shutdown-Drain-Checkpoint-2026-08-26.md)
+- [PROD application-association analysis and 2.3.3 validation](docs/PROD-Application-Zuordnung-2026-08-27.md)
 - [AI maintainer handoff](AI-README.md)
 - [References](REFERENCES.md)