Tag: Solution

Solving solution import error 0x80048011 – There are multiple root elements in sitemap client extension

Posted on by Peter Geil

UPDATE 27.07.2021

Microsoft support did confirm that this is a platform bug. A fix is in the making and should be rolled out beginning end of august 2021.

There was a CRM online environment which I did lift and upgrade from CRM2016 on-premise into the cloud (v9.2x) using the MS FastTrack OP2OL project service. So far so good. But whenever the (legacy) default Site Map component was exported in a solution, the resulting customizations.xml solution file was corrupted.

The legacy Site Map client extension was part of the problematic solution

The result was a nasty solution import failure saying that the Client Extension sitemap could not be processed because the related XML element contains multiple root elements.

Client ExtensionssitemapFailure0x80048011There are multiple root elements. Line 1, position 58.
Solution import error being reported

After inspecting the customizations.xml and validating it against the official XML Schemata for XML customization data provided by Microsoft as of today, it became clear why. For some reason the <SiteMap/> collection element contained invalid child nodes which renders the whole customizations.xml invalid.

Not only lines 8-11 contain invalid nodes, also dozens of other schema violations were reported (which are not new)

Solution

Manually edit the customizations.xml file inside the solution zip file and delete the XML nodes shown in the screenshot above (EnableCollapsibleGroups, ShowHome, ShowPinned and ShowRecents), or – when acceptable – just keep the whole legacy Sitemap out of your solutions. The legacy sitemap nowadays should only be needed when the non-UCI menu structure must be customized, which mostly affects the advanced settings area. So moving this into a separate solution that only needs to be deployed every now and then could be a reasonable solution.

Solution Importfehler – Entity {0} cannot be disabled for relevance search, because child entity new_someentity is enabled for relevance search

Posted on by Peter Geil

Neue Woche neues Spiel. Von einem Tag auf den anderen begann der Import einer Base-Solution plötzlich fehlzuschlagen und zwar aus einem mir bis dato unbekannten Fehlergrund:

Entity {0} cannot be disabled for relevance search, because child entity ActivityMimeAttachment is enabled for relevance search.

Fehlermeldung des ImportSolution jobs

Erfreulicherweise inkludiert die Fehlermeldung auch gleich eine vermeintliche Lösung und auch insgesamt klingt das Fehlerszenario für mich im Ansatz nachvollziehbar, wenn auch mit einem amüsant-irritierten Beigeschmack.  Denn an den Einstellungen der Relevance Search, welche Teil des System-Customizings ist (Solutioneditor -> Entitäten -> Button “Relevanzsuche konfigurieren” im Entitätssubgrid) wurde in den betroffenen System seit dem letzten Deployment nichts mehr verändert. Zudem ist die Relevance Search Konfiguration nicht Teil einer Solution, sodass diese ohnehin nicht durch einen Solutionimportant zwischen mehreren Systemen verteilt werden kann.

Daher vermute ich dahinter mal wieder einen von Microsofts “Nightly-Harakiri-Patches” für die darunterliegenden Power Plattform bzw. Datenbank, welches häufig mit kleinen heimtückischen Seiteneffekten daherkommt, die erst bemerkt werden wenn es irgendwo gekracht hat.

Lösung

Ein vergleichender Blick auf die Einstellungen der Relevance Search in den betroffenen Systemen, offenbart auch direkt die vermutete Ursache: im Quellsystem liegt eine völlig abweichende Relevance Search Einstellung vor: u.a. betroffen waren die Entities “Notiz” (annotation) und “Anlage” (activitymimeattachment). Nachdem ich für diese die Relevance Search deaktivierte, liefen die automatischen Deployments auch wieder erfolgreich durch.
Vergleich: Relevance Search Einstellungen in den verschiedenen Systemen

Kommentar

Ich würde erwarten, dass derartige Fehler bereits auf Platform-Ebene abgefangen werden, da weil die Child-Relationship der besagten Entität “Anlage” (activitymimeattachment) anhand der Metadaten bereits zum Zeitpunkt der Konfigurationsänderung validiert werden kann, ob es aufgrund nicht mehr auflösbarer Eltern-Kind-Beziehungen später zu einem ungültigen Konfigurations-Stand kommen wird. Beim entfernen einer Elternentität X, müsste die Konfigurations UI bzw. die Plattformlogik dafür sorgen dass vor dem Entfernen der Elternentität, zunächst alle abhängigen Child-Entitäten aus der Relevance Search entfernt werden müssen.