091502CC8D7F487BA52A08145ED03720
  • Thomas Pollinger
  • 19.01.2018
  • DE

Root Cause Analysis: "IDENTITYSETTING action='load' ... > Please login"

Nicht jede Meldung in den wsms.logs kann man selbst fixen oder kommt direkt darauf was die Ursache ist. Daher ist es auch immer wichtig, solche Meldungen zu beobachten, auf mögliche Ursachen einzugrenzen und auch dann alles aufbereitet an den Support zu schicken. Wie in diesem Fall...


Regel 22

Siehe da! Die Menschen sind die Werkzeuge ihrer Werkzeuge geworden. (Henry David Thoreau)


Meldungen

<CLIENT guid="{guid}" date="{date}">
<IODATA loginguid="{guid}" sessionkey="{guid}">
  <ADMINISTRATION>
    <IDENTITYSETTING action="load" userguid="{guid}">
    </IDENTITYSETTING>
  </ADMINISTRATION>
</IODATA>
</CLIENT>
<SERVER guid="{guid}" date="{date}">
<ERROR>
  Please login
</ERROR>
</SERVER>

Ursache

Wenn man diese beiden Meldungen im wsms.log mehrfach bis häufig findet, ist die Ursache wie folgt:

  1. Man hat auf jeden Fall eine größere Installation des Management Servers in Form eines Clusters.
  2. Bestimmte Benutzer dürfen sich, auf Grund von mehreren zulässigen Sessions, mehrfach anmelden.

Lösung

Die genaue Ursache ist noch nicht so ganz klar, auf jeden Fall wird dieses Verhalten - welches keine technischen Nachteile auf dem System verursacht - derzeit durch die Entwicklung untersucht. Denn es tritt nur auf den Systemen innerhalb eines Clusters auf, die Anwender nutzen für die Bearbeitung von Inhalten bzw. auf denen man sich an der GUI anmeldet.

Es gibt jedoch einen Workaround, welches das Verhalten - sprich die vielen Meldungen im wsms.log - immer wieder für einige Zeit eindämmt. In dem man die Dienste auf den betroffenen Systemen einfach durchstartet. Kann man z.B. mit PowerShell wie folgt durchführen:

  1. Im Server-Manager einen Knoten auswählen und über das Aktionsmenü mit "Server deaktiven" auf inkativ setzen.
  2. Dann warten ca. 1 Minute, bis im wsms.log des inaktiven Servers ein Eintrag steht, dass der Server derzeit inaktiv ist.
  3. Nun via PowerShell die Dienste stoppen:
        PS:\> Stop-Service OTWSMNavigationService -Force
  4. Warten bis die Dienste beendet wurden und dann nochmals ca. 1 Minute warten. Damit auch Systemseitig alles korrekt beendet und entladen wurde. Es kann sonst zu einef Fehlermeldung beim Starten der Dienste kommen.
  5. Nun via PowerShell die Dienste starten:
        PS:\> Start-Service OTWSMClientService
  6. Warten bis die Dienste gestartet sind.
  7. Zum Schluss im Server-Manager den zuvor deaktivierten Knoten im Cluster wieder aktivieren.
  8. Schritt 1-7 für die anderen Knoten auch durchführen.

Anmerkungen

Hinweis: Man kann, sofern es nicht störend ist für die Arbeit, auch alle Knoten zeitgleich runterfahren:

    PS:\> Invoke-Command -ComputerName ("WindowsComputerName1","WindowsComputerName2","...") -ScriptBlock { Stop-Service OTWSMNavigationService -Force -PassThru }
    PS:\> Invoke-Command -ComputerName ("WindowsComputerName1","WindowsComputerName2","...") -ScriptBlock { Start-Service OTWSMClientService -Force -PassThru }

Über den Autor:
Thomas Pollinger

... ist Senior Site Reliability Engineer bei der Vodafone GmbH in Düsseldorf. Seit dem Jahr 2007 betreut er zusammen mit seinen Kollegen die OpenText- (vormals RedDot-) Plattform Web Site Management für die deutsche Konzernzentrale.

Er entwickelt Erweiterungen in Form von Plug-Ins und PowerShell Skripten. Seit den Anfängen in 2001 (RedDot CMS 4.0) kennt er sich speziell mit der Arbeitweise und den Funktionen des Management Server aus.