biztalk-checkmk-pulse/docs/ACC-WMI-SQL-Berechtigung.txt

BizTalk Checkmk Pulse - ACC Berechtigungsfreigabe
Stand: 29.07.2026

BEFUND
======

Host: AV23AGPWBIO1
Lokale Identitaet: NT AUTHORITY\SYSTEM (LocalSystem)
Netzwerkidentitaet: BEW\AV23AGPWBIO1$
Fehler: COMException HRESULT=0x80131904
Innerer Fehler: Login failed for user 'BEW\AV23AGPWBIO1$'

Der lokale BizTalk-WMI-Namespace ist erreichbar. Der BizTalk-WMI-Provider wird
aber bei seinem SQL-Zugriff als Maschinenkonto abgewiesen. Deshalb sind
Platform, Host Instances, Runtime Artifacts und Suspended Instances UNKNOWN.
BizTalk SQL Access kann ohne MSBTS_GroupSetting keine Ziele ermitteln.

Keine DCOM-, Firewall- oder WMI-Namespace-Rechte erweitern. Keinen direkten
SQL-Login, keine manuellen BizTalk-Datenbankrollen und kein sysadmin fuer das
Maschinenkonto anlegen.

WICHTIG ZUR NEUEN VERSION
=========================

Die neue EXE repariert keine Berechtigungen. Sie erkennt den eingebetteten
SQL-Loginfehler korrekt, zeigt BEW\AV23AGPWBIO1$ und klassifiziert die
Folgediagnose als Berechtigungsproblem. Ohne die nachfolgende Freigabe bleiben
die betroffenen Checks auch mit der neuen Version UNKNOWN.

Die alte Version kann nach korrekter Freigabe grundsaetzlich funktionieren.
Empfohlen ist die neue Version zusammen mit der Gruppenfreigabe, weil sie
Fehlerursache, Konto und Massnahme eindeutig anzeigt.

FREIGABE
========

1. Exakte Operator-Gruppe ermitteln

In der BizTalk Administration Console:

  BizTalk Group > Properties > General > BizTalk Operators Group

Nicht ungeprueft den Standardnamen verwenden. Mit einem bereits berechtigten
Konto ist alternativ folgende Abfrage moeglich:

  Get-CimInstance -Namespace root/MicrosoftBizTalkServer `
      -ClassName MSBTS_GroupSetting |
      Select-Object Name, BizTalkOperatorGroup, MgmtDbServerName, MgmtDbName

2. Computerobjekt durch einen AD-Administrator aufnehmen

  Import-Module ActiveDirectory
  $computer = Get-ADComputer -Identity 'AV23AGPWBIO1'
  Add-ADGroupMember `
      -Identity '<EXAKTE_BIZTALK_OPERATOR_GRUPPE>' `
      -Members $computer `
      -WhatIf

Ziele kontrollieren und danach denselben Add-ADGroupMember-Befehl ohne
-WhatIf ausfuehren.

Mitgliedschaft pruefen:

  Get-ADPrincipalGroupMembership -Identity 'AV23AGPWBIO1' |
      Select-Object Name, SamAccountName

3. Neue Gruppenzugehoerigkeit aktivieren

AD-Replikation abwarten. Bevorzugt den BizTalk-Server in einem Wartungsfenster
neu starten. Alternativ in einer administrativen Shell:

  klist purge -li 0x3e7

Danach den zuvor eindeutig ermittelten Checkmk-Agent-Dienst neu starten. Falls
die neue Mitgliedschaft nicht wirksam wird, den Server neu starten.

4. Im echten Checkmk-Kontext verifizieren

  & "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump |
      Select-String `
          -Pattern "BizTalk|Login failed|Wmi/Permission|Sql/Permission|UNKNOWN" `
          -Context 0,1

Erwartetes Ergebnis:

- BizTalk Platform ist OK und zeigt operator_group=<exakte Gruppe>.
- BizTalk SQL Access zeigt targets=2, available=2,
  discovery_complete=True.
- Host Instances, Runtime Artifacts und Suspended Instances sind nicht mehr
  wegen WMI-/SQL-Berechtigungen UNKNOWN.
- Kein Login failed fuer BEW\AV23AGPWBIO1$.

Der separate Event-Log-Service zeigte im Screenshot zwei Fehler und sechs
Warnungen. Diese Ereignisse bleiben nach der Berechtigungsfreigabe fachlich zu
pruefen.

WENN ES DANACH WEITERHIN SCHEITERT
==================================

Normalerweise wurde die konfigurierte BizTalk-Operator-Gruppe bereits durch die
BizTalk-Konfiguration am SQL Server eingerichtet. Das Maschinenkonto erbt ueber
seine AD-Gruppenmitgliedschaft die Rolle BTS_OPERATORS und benoetigt keinen
eigenen SQL-Login.

Bleibt "Login failed" trotz bestaetigter Mitgliedschaft, AD-Replikation und
Token-Erneuerung bestehen, prueft die SQL-Administration read-only:

  SELECT name, type_desc
  FROM sys.server_principals
  WHERE name = N'BEW\<EXAKTE_BIZTALK_OPERATOR_GRUPPE>';

Danach jeweils in BizTalkMgmtDb und BizTalkMsgBoxDb:

  SELECT
      member_principal.name AS member_name,
      role_principal.name AS role_name
  FROM sys.database_role_members AS drm
  JOIN sys.database_principals AS role_principal
      ON role_principal.principal_id = drm.role_principal_id
  JOIN sys.database_principals AS member_principal
      ON member_principal.principal_id = drm.member_principal_id
  WHERE member_principal.name =
      N'BEW\<EXAKTE_BIZTALK_OPERATOR_GRUPPE>'
    AND role_principal.name = N'BTS_OPERATORS';

Fehlt die Abbildung, gleichen BizTalk- und SQL-Administration sie mit der
BizTalk-Konfiguration ab und reparieren sie fuer die konfigurierte Gruppe.
Keinen Einzel-Login oder Sonderrollen fuer BEW\AV23AGPWBIO1$ als Umgehung
anlegen.

SICHERHEIT
==========

Die Gruppenmitgliedschaft des Computerobjekts steht allen Diensten zur
Verfuegung, die auf AV23AGPWBIO1 als LocalSystem laufen und auf
Netzwerkressourcen zugreifen. Mit Security und BizTalk-Betrieb abstimmen.

Ist dies nicht akzeptabel, ist ein separater Collector unter einem dedizierten
gMSA-/Dienstkonto mit BizTalk-Operator-Rechten die sauberere Architektur. Nicht
allein fuer dieses Plugin die Identitaet des gesamten Checkmk-Agent-Dienstes
aendern.

QUELLEN
=======

https://learn.microsoft.com/en-us/windows/win32/services/localsystem-account
https://learn.microsoft.com/en-us/entra/architecture/service-accounts-computer
https://learn.microsoft.com/en-us/biztalk/core/windows-groups-and-user-accounts-in-biztalk-server
https://learn.microsoft.com/en-us/biztalk/core/access-control-for-administrative-roles
https://learn.microsoft.com/en-us/biztalk/core/how-to-modify-group-properties
https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adgroupmember
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist