Add WMI and SQL permission diagnostics

docs/Integration.md

@@ -51,6 +51,7 @@ Empfohlene Service-Behandlung:
 | Service | Empfehlung |
 | --- | --- |
 | `BizTalk Platform` | `UNKNOWN` immer als Integrationsproblem behandeln. |
+| `BizTalk SQL Access` | `UNKNOWN` anhand der Kategorie `Permission`, `Connectivity`, `Timeout`, `Configuration` oder `Provider` bearbeiten. |
 | `BizTalk Suspended Instances` | In `PRD` alarmieren; in `ACC`/`TST`/`DEV` nach Teamvereinbarung. |
 | `BizTalk Host Instances` | `CRIT` alarmieren. |
 | `BizTalk Runtime Artifacts` | Erst beobachten; strenge Alarmierung nur bei klar definiertem Runtime-Sollzustand. |
@@ -94,7 +95,23 @@ Der direkte Start des Wrappers in einer administrativen Eingabeaufforderung ist
     Select-String -Pattern "BizTalk|Access denied|Unauthorized|UNKNOWN" -Context 0,1
 ```
 
-Die Ausgabe muss die fuenf `BizTalk ...` Services mit plausiblen Daten enthalten. `Access denied`, `UnauthorizedAccessException` und ein berechtigungsbedingtes `UNKNOWN` weisen auf eine fehlende Rollenzuordnung hin.
+Die Ausgabe muss die sechs stabilen `BizTalk ...` Services mit plausiblen Daten enthalten. `Access denied`, `UnauthorizedAccessException`, `Sql/Permission` und ein berechtigungsbedingtes `UNKNOWN` weisen auf eine fehlende Rollenzuordnung hin.
+
+Die EXE klassifiziert WMI- und SQL-Probleme und schreibt zu jeder Diagnose `Massnahme:` und `Technik:`. Eine fehlgeschlagene erforderliche WMI-Abfrage erzeugt beim betroffenen Service immer `UNKNOWN`; fehlende Daten werden nicht als Nullbestand und damit nicht als `OK` ausgegeben.
+
+Fuer den produktiven Betrieb wird empfohlen, den Local Check alle 300 Sekunden asynchron auszufuehren. Dadurch erzeugen fehlende SQL-Rechte nicht bei jedem Agent-Abruf neue fehlgeschlagene Logins. In `%ProgramData%\checkmk\agent\check_mk.user.yml`:
+
+```yaml
+local:
+  enabled: yes
+  execution:
+    - pattern: $CUSTOM_LOCAL_PATH$\biztalk_checkmk_pulse.cmd
+      async: yes
+      run: yes
+      cache_age: 300
+```
+
+Alternativ koennen die Checkmk-Kollegen in der Agent Bakery die Regeln `Set execution mode for plug-ins and local checks` und `Set cache age for plug-ins and local checks` verwenden. Der Cache reduziert Last und SQL-Fehlerlogs; ein Zustandswechsel wird dadurch um maximal die konfigurierte Cache-Zeit verzoegert.
 
 ### Least-Privilege-Vorgehen
 
@@ -111,8 +128,11 @@ Entscheidungsmatrix:
 
 | Beobachtung | Bewertung und Massnahme |
 | --- | --- |
-| Alle fuenf Services liefern plausible Werte | Keine Aenderung erforderlich. |
+| Alle sechs stabilen Services liefern plausible Werte | Keine Aenderung erforderlich. |
 | `root\MicrosoftBizTalkServer` ist nicht erreichbar | BizTalk-WMI-Provider, WMI-Dienst, Namespace und dessen ACL gezielt pruefen. |
+| `BizTalk SQL Access` meldet `Sql/Permission` | Maschinenkonto in die konfigurierte BizTalk-Operator-Gruppe aufnehmen, Kerberos erneuern und Agent-Dump wiederholen. |
+| `BizTalk SQL Access` meldet `Sql/Connectivity` | SQL-Server-/Instanzname, DNS, Dienst, TCP-Port und Firewall pruefen. |
+| `BizTalk SQL Access` meldet `Sql/Timeout` | SQL-/Netzwerkauslastung untersuchen; Timeout nur nach Ursachenanalyse anpassen. |
 | Verbindung funktioniert, einzelne SQL-gestuetzte Klassen melden Zugriffsfehler | `DOMAIN\BIZTALKSERVER$` zunaechst in die konfigurierte BizTalk-Operator-Gruppe aufnehmen. |
 | Nur `BizTalk Event Log` ist `UNKNOWN` | Lokalen Zugriff auf das Application Event Log pruefen. |
 | Fehler bleibt nach Operator-Zuweisung bestehen | Exakte WMI-Klasse anhand der Service-Ausgabe bestimmen und deren BizTalk-/SQL-Rollenanforderung pruefen. |
@@ -152,6 +172,7 @@ Dashboard-Kacheln:
 
 - Host/Service state fuer BizTalk-Host
 - Service state fuer `BizTalk Suspended Instances`
+- Service state fuer `BizTalk SQL Access`
 - Graph `biztalk_suspended_total`
 - Graph `biztalk_host_instances_stopped`
 - Graph `biztalk_eventlog_errors`