Bug tracked down: Fehler in der Darstellung von Firmenlogos in der Hierarchieansicht in Microsoft Dynamics 365 On-premises

[Go to english version] Fazit: Firmenlogos werden nur im Standardmandant des jeweiligen Benutzers korrekt angezeigt. Dieser Standardmandant ist eine benutzerbezogene Einstellung, die in der MSCRM_Config-Datenbank hinterlegt ist und dort bei Bedarf angepasst werden kann. Die Möglichkeit Firmen, Kontakte und Verkaufschancen, die mit einander verknüpft sind, hierarchisch darzustellen, besteht seit der 2015er Version von Microsofts Dynamics CRM-Software. Ein Kunde meldete jüngst ein Problem mit diesem Feature bei Tests im Zuge einiger Formularanpassungen: es wurden in der hierarchischen Darstellung die hinterlegten Firmenlogos nicht korrekt geladen, obwohl die Logos in den Datensatzformularen selbst normal dargestellt werden konnten.   Abb. 1: nicht korrekt geladene Firmenlogos in der CRM-Firmenhierarchieansicht Bei Betrachtung der gesendeten Requests zeigen sich zwei Dinge: Der Abruf der Firmenlogos ist (offensichtlich) nicht funktional und wird mit dem Fehlercode 404 quittiert. Bei genauer Betrachtung der URL zeigt sich allerdings eine weitere Auffälligkeit: Den Requests für die Firmenlogos fehlt der entsprechende Mandantenname. Die vollständige aufgerufene URL entspricht also dem Schema http ://[CRM-Server]:[Port]/Image/download.aspx?[...] Ein anschließender Test über mehrere unserer Entwicklungsmandanten (Dynamics 365 on premise, Version 8.2.2.112) mit zwei unterschiedlichen Testbenutzern ergibt ein interessantes Bild: Bei einem von fünf Mandanten werden die Firmenlogos korrekt geladen, allerdings unterscheidet sich der funktionale Mandant zwischen den beiden Testbenutzern. Tiefergehende Recherchen zeigen die Ursache: Der Standardmandant der beiden gewählten Testbenutzer unterscheidet sich und jedem Benutzer wurden nur in seinem Standardmandanten die Firmenlogos korrekt dargestellt. Der Standardmandant ist der Mandant, in dem ein Benutzer, innerhalb eines CRM-Systems mit mehreren Mandanten, initial angelegt wurde; der Wert selbst ist für alle Benutzer in der Konfigurationsdatenbank MSCRM_CONFIG in der Tabelle SystemUser hinterlegt. Microsoft leitet offensichtlich Requests, denen der Mandantenname fehlt, zum Standardmandanten weiter. Eine Anpassung des Standardmandanten für die Testbenutzer auf einen vorher bei beiden nicht funktionalen Mandanten (inkl. eines IIS-Resets (der Wert wird im App-Pool gecachet)) bestätigt das erste Testergebnis, da bei dem neu eingestellten Standardmandanten die Firmenlogos wieder korrekt in der hierarchischen Ansicht geladen werden.   Abb.: 2: Standardmandantenzuordnung in der Tabelle SystemUser (CONFIG_MSCRM) Wir konnten unserem Kunden bei diesem (nach unserem Verständnis) Bug von Microsoft weiterhelfen, da auf dem Kundensystem zwar mehrere Mandanten bestehen, aber nur einer für das produktive Geschäft genutzt wird und der in diesem Artikel beschriebene Effekt keinen Einfluss auf das Test- und Schulungssystem hat und wir entsprechend alle Benutzer auf den gewünschten Mandanten umschlüsseln konnten. Der Eingriff in die Konfigurationsdatenbank des CRM-Systems ist natürlich ein nicht von Microsoft unterstützter Vorgang – allerdings gibt es keinen Weg, den Standardmandanten über eine Konfigurationsoberfläche oder ein anderes MSCRM-Tool zu modifizieren. Es sollte bei einem Eingriff in diese Datenbank immer ein Backup erstellt werden, was durch die sehr geringe Größe der Datenbank aber kein Hindernis darstellt. Weiterhin möchte ich hier noch anmerken, dass die Benutzer-IDs aus den Mandanten nicht denen in der Konfigurationsdatenbank entsprechen, hier muss bei einer Abfrage für bestimmte Benutzer erst der Umweg über die Tabelle SystemUserOrganizations, genauer über die Spalte „CrmUserId“ genommen werden. Im Detail wird diese Anpassung der Konfigurationsdatenbank in diesem Blogartikel beschrieben, der uns bei unseren Recherchen auf die richtige Spur geführt hat.