SCSM neues Self-Service-Portal: kapputtgefixt!

Da das neue HTML5-basierte Self-Service-Portal für System Center Service Manager leider nicht bugfrei ausgeliefert wurde (Ein schwerer Showstopper: Alle Tickets wurde für das Service Account angelegt…), war es auch für mich wichtig den ersten Hotfix  KB3124091 einzuspielen.
Abgesehen davon, dass man ein Portal freigibt, dass immer für den gleichen User Tickets anlegt (wer testet das und bemerkt sowas nicht?) hat der Patch nun auch mein Portal zerlegt. 500 – Internal Server Error, Pech gehabt:
Internal Server Error 500
Deutlich mehr Information erhalten wir dann mit anderen Browsern oder den deaktivieren “Kurzen Fehlermeldungen”:
Ausführlicher Fehler nach Hotfix
Angesichts der Tatsache, dass Workarounds im Stile von “Machen sie alle User zu Advances Operators, dann gehts” kursieren, habe ich meinen Livegang mal wieder verschoben und vertröste die Nutzer einmal mehr. Was nützt mir denn die volle Integration in die System Center Familie, wenn das Portal als elementarer Bestandteil entweder für den Eimer ist (Silverlight und Sharepoint) oder unausgegoren um nicht zu sagen unfertig?
Auch die Tatsache, dass einer der Hauptgründe für das neue Portal, nämlich Mobile Devices Zugang zu ermöglichen noch nicht vollständig (welche nette Umschreibung) Implementiert ist, vermag nur Stirnrunzeln hervorzurufen.
Ein ausgiebiges Stöbern in den Threads des Microsoft Blogs, in dem das Portal und auch der Hotfix angekündigt wurden fördern folgendes zu Tage:
  • Es gibt offenbar viele, vom gleichen Fehler 500 betroffene Nutzer
  • Der Gundton der Diskussion ist gereizt
  • Microsoft selbst hält sich aus der Diskussion weitestgehend raus
  • Es gibt mittlerweile eine Troubleshooting-Seite für das neue System Center Service Manager 2012 R2 Self-Service-Portal hier (die Existenz dieser Seite erfährt man übrigens auf Seite 13 im Diskussionsthread)

Die Lösungsansätze reichen vom Gruppieren der Nutzer als Advanced Operators bis zum Abschalten des Loggings mit dem Hinweis “Because the Web App runs in the logged-on user’s content, ensure you to provide write permissions to all users in the log folder. For example, c:\logs in the example above.”. Auch das bewährte Frisieren der Registry wird als Erste Hilfe empfohlen.

Leider hilft das empfohlene Deaktivieren der Logs (bei mir) überhaupt nicht, da ich – wie vermutet – keine derartigen Einträge in der Web.config gesetzt habe und auch die Registry ist “clean”. Das Fehlerlog reagiert mit seinen Informationen auch eher zurückhaltend:

Ansicht des Application Log

Wenn das neue Self-Service-Portal erst für den Release von System Center 2016 geplant ist, dann werft uns doch bitte keine fehlerbehaftete, unfertige Vorabversion vor. Das Teil ist RTM gekennzeichnet! Wenn rapid Prototyping und Test-driven-Development nur einen solchen Murks zur Folge haben, dann läuft irgendwas gerade mächtig schief.

Sind wir (schon) wieder soweit, dass man ohne Servicepack besser die Finger von Produkten aus Redmond lassen muss? Mein Office 2016 scheint ja entsprechendes anzudeuten, auch wenn sich – anders als bei Office 2013 – mein Excel diesmal nicht verrechnet sondern “nur” hängen bleibt und abstürzt…

Einmal mehr wird deutlich, warum es längst 3rd-Party-Portale gibt! Es wäre in diesem Zusammenhang auch erfreulich, wenn man sich bei Microsoft einmal auf eine klare Aussage zu SCSM als Schaltzentrale treffen würde – Orchestrator erfährt in 2016 keine einzige Neuerung. Initial als DAS Werkzeug für die erfolgreiche Automatisierung angepriesen hat sich der Fokus in Redmond still und leise auf Powershell Workflows und das Windows Azure Pack verlagert. Damit sind wir im Jahre 2016 wieder genau da, wo wir 2011 waren: Automatisierung bedeutet Scripting, vorzugsweise Powershell.
Man darf gespannt sein, ob es einen tragbaren Fix für das aktuelle Problem des Self-Service-Portal gibt, oder ob bis zum nächsten cumulative Update gewartet werden muss – ich werde Updates Posten.
[Update 21.12.: Bilder hinzugefügt]

Schreibe einen Kommentar