MediaMill Blog

Kategorie: Windows Server

  • Tausende Logmeldungen im Application Log eines ADFS Servers Event ID 28005: Error: 15517, State: 1. Cannot execute as the database principal because the principal „dbo“ does not exist

    Im Rahmen der Administration eines Active Directory Federation Service (ADFS) Servers stießen wir auf ein Problem: Tausende von Fehlermeldungen im Eventlog des Servers, die keinen direkten Einfluss auf die Funktionalität hatten, aber dennoch störend waren und die Übersicht im Log massiv beeinträchtigten. In diesem Blogartikel möchten wir die Ursache und Lösung des Problems im Detail erläutern.

    Problem: Massenhaft Fehler im Application Log

    Im Application Log eines ADFS-Servers fanden sich über 170.000 Fehlermeldungen innerhalb von 24 Stunden, was zu einer durchschnittlichen Rate von fast zwei Logeinträgen pro Sekunde führte. Der Logeintrag hatte die folgende Fehlermeldung:

    An exception occurred while enqueueing a message in the target queue. Error: 15517, State: 1. Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.

    Obwohl diese Fehler keinen direkten Einfluss auf die Funktionalität des ADFS-Servers hatten, waren sie störend und erschwerten das Monitoring und die Diagnose anderer potenzieller Probleme.

    Ursache: Datenbank-Fehlkonfiguration

    Nach einer eingehenden Untersuchung und einer Internetrecherche zeigte sich, dass das Problem durch eine Fehlkonfiguration in der Windows Internal Database (WID) verursacht wurde, die ADFS verwendet. Genauer gesagt war der Datenbankbesitzer („DBO“, Database Owner) der relevanten ADFS-Datenbanken nicht korrekt gesetzt. Der Fehler „Cannot execute as the database principal because the principal ‚dbo‘ does not exist“ deutete darauf hin, dass der Datenbankbesitzer in den betroffenen ADFS-Datenbanken NULL war.

    Lösung: Anpassen des DBOwners der ADFS-Datenbanken

    Um das Problem zu beheben, haben wir die folgenden Schritte durchgeführt:

    1. Installation von SQL Server Management Studio (SSMS)
      Um die Konfiguration der WID-Datenbanken zu ändern, ist es notwendig, das SQL Server Management Studio (SSMS) zu verwenden.
    2. Verbindung zur Windows Internal Database (WID)
      Als Nächstes haben wir uns mit der WID-Instanz auf dem ADFS-Server verbunden. Dies geschieht mit folgendem Verbindungsstring:
    np:\\.\pipe\MICROSOFT##WID\tsql\query

    Wichtiger Hinweis: SSMS muss als Administrator gestartet werden, da die Verbindung zur WID-Instanz sonst fehlschlägt.

    Ändern des Datenbankbesitzers (DBOwner) für die ADFS-Datenbanken
    In der WID-Instanz haben wir dann den Datenbankbesitzer für die beiden ADFS-Datenbanken „AdfsConfigurationV4“ und „AdfsArtifactStore“ geändert. Dies geschah mit den folgenden SQL-Befehlen:

    use [AdfsConfigurationV4]
EXEC sp_changedbowner 'sa'

use [AdfsArtifactStore]
EXEC sp_changedbowner 'sa'

    Vor dieser Änderung war der Besitzer der beiden Datenbanken auf NULL gesetzt, was die Fehlermeldungen verursachte.

      Ergebnis: Keine weiteren Fehlermeldungen

      Nach der erfolgreichen Änderung des DBOwners in der WID-Instanz wurden die störenden Logeinträge im Application Log vollständig beseitigt. Der ADFS-Server lief weiterhin ohne Probleme, und die Änderung hatte keinerlei negative Auswirkungen auf die Funktionalität des Servers.

      Hilfreichen Artikeln:

    1. SSL-Zertifikatstauschs beim Windows Admin Center (WAC)

      Im Gegensatz zu anderen Anwendungen bietet das Windows Admin Center keinen direkten Eintrag im Startmenü an, um einen Konfigurationsdialog zum Zertifikatstausch aufzurufen. Zudem wird es nicht über die IIS-Bindungen verwaltet, was die Sache noch komplizierter macht.

      Beginnen wir damit, wie man zum Konfigurationsdialog gelangt. Dieser befindet sich in den Einstellungen unter „Apps and Features“ oder „Programme hinzufügen und entfernen“. Hier muss man das Windows Admin Center auswählen und auf „Modify“ klicken, um den Setup-Dialog zu starten. Im Setup-Dialog muss man dann erneut auf „Ändern“ klicken.

      In dem folgenden Dialogfenster kann man den Thumbprint des neuen Zertifikats eingeben. Wichtig ist, dass dieses Zertifikat zuvor in den Zertifikatsstore von Windows importiert wurde.

      Nach Abschluss des Installationsassistenten des Windows Admin Centers wird das neue Zertifikat konfiguriert.

      Insgesamt handelt es sich hierbei um einen eher ungewöhnlichen und komplizierten Prozess.

      Es wäre wesentlich praktischer, wenn es einen direkten Eintrag im Startmenü gäbe, der den Konfigurationsassistenten aufruft. Des Weiteren würde eine Auswahl der möglichen Zertifikate anstatt der Eingabe des Zertifikats-Thumbprints den Prozess erleichtern und benutzerfreundlicher gestalten.

    2. Identifizieren defekter Disks in einem Storage Spaces Direct Cluster (S2D) mit PowerShell

      Das folgende PowerShell-Skript ermittelt defekte Disks in einem Storage Spaces Direct Cluster und zeigt den Namen des Clusterknotens, in dem die Disk verbaut ist:

      $errordisks=@()

foreach($ed in Get-PhysicalDisk |? Operationalstatus -ne 'OK'|Sort-Object FriendlyName)
{
    $Nodename=($ed|Get-StorageScaleUnit).friendlyname

    $cobject = [PSCustomObject]@{
        FriendlyName = $ed.FriendlyName
        SerialNumber = $ed.SerialNumber
        MediaType=$ed.MediaType
        OperationalStatus=$ed.OperationalStatus
        Size=$ed.Size/1GB
        HealthStatus=$ed.HealthStatus
        Nodename=$Nodename
    }
    $errordisks+=$cobject
}

$errordisks|ft

      Das Skript erstellt ein Array namens $errordisks, das die Informationen zu defekten Disks enthält. Es durchläuft alle physischen Disks, die einen vom Status „OK“ abweichenden OperationalStatus haben. Für jede gefundene Disk wird der zugehörige Clusterknotenname ermittelt und ein benutzerdefiniertes PowerShell-Objekt mit den relevanten Informationen erstellt. Schließlich wird das Array $errordisks ausgegeben, und die Informationen werden im Format einer Tabelle angezeigt.

      Beispiel: Anzeige einer defekten SSD in einem Storage Space Direct Cluster

      Mit einer kleinen Änderung des Scripts lassen sich alle Disks, unabhängig von ihrem Status, in einen Storage Space Direkt Cluster, zugeordnet zu dem jeweiligen Clusternode, anzeigen. 

      $S2Ddisks=@()

foreach($ed in Get-PhysicalDisk)
{
$Nodename=($ed|Get-StorageScaleUnit).friendlyname

 if($nodename)
 { 
 
  $cobject = [PSCustomObject]@{
                    FriendlyName = $ed.FriendlyName
                    SerialNumber = $ed.SerialNumber
                    MediaType=$ed.MediaType
                    OperationalStatus=$ed.OperationalStatus
                    Size=$ed.Size/1GB
                    HealthStatus=$ed.HealthStatus
                    Nodename=$Nodename
                    }


  $S2Ddisks+=$cobject
  }

}

$S2Ddisks|Sort-Object  Nodename,FriendlyName|ft
      Anzeigen aller Disks in einem Storage Space Direct Cluster, mit dem Clusterknoten in dem die Disk verbaut ist.

    3. Schneller Zugriff auf den Zertifikatspeicher des lokalen Computers unter Windows

      Obwohl es mehrere Möglichkeiten gibt, auf den Zertifikatspeicher (Certificate Store) von Windows zuzugreifen, möchte ich in diesem Blogbeitrag eine schnelle und effiziente Methode vorstellen und die ich gerne mit euch teilen möchte.

      Die gängige Methode, um auf den Zertifikatspeicher des lokalen Computers zuzugreifen, besteht darin, die Microsoft Management Console (MMC) zu verwenden, das Zertifikat-Snap-In hinzuzufügen und dann den lokalen Computer als Ziel auszuwählen. Dieser Prozess kann jedoch zeitaufwändig sein, insbesondere wenn man regelmäßig auf den Zertifikatspeicher zugreifen muss.

      Glücklicherweise gibt es eine einfachere und schnellere Methode, um direkt auf den Zertifikatspeicher des lokalen Computers zuzugreifen. Anstatt die MMC zu öffnen und manuell das Zertifikat-Snap-In hinzuzufügen, kann man einfach den Befehl certlm.msc verwenden.

      Um den Zertifikatspeicher des lokalen Computers direkt aufzurufen, befolgen Sie die folgenden Schritte:

      1. Drücken Sie die Windows-Taste + R, um das „Ausführen“-Dialogfeld zu öffnen.
      2. Geben Sie certlm.msc ein und drücken Sie Enter.

      Der Zertifikatspeicher des lokalen Computers wird nun geöffnet, und Sie können die Zertifikate einsehen und verwalten.

      „Windows Certifiacte Store Local Machine“ mit dem Befehl certlm.msc direkt aufrufen.
      Windows Zertifikatspeicher lokaler Computer

    4. Ändern der Zeitzone / Timezone bei Windows Servern

      Wenn man bei Windows Servern nachträglich die Zeitzone ändern möchte, kommt man auf dem offensichtlichen Weg nicht weiter.

      Wenn man als Administrator in der Systemsteuerung / Control Panel über Change Timezone die Zeitzone ändern möchte kommt eine Fehlermeldung „Unable to Continue“.

      Die Lösung des Problems ist relativ einfach.

      Man öffnet als Administrator eine Powershell und ruft das Systemsteuerungselement Datum und Zeit / Date and Time direkt über die Admin-Powershell auf. Dazu gibt man auf der Shell „timedate.cpl“ ein.

      Jetzt lässt sich die Zeitzone problemlos über „Change Timezone“ ändern.