Was ist eine Unverwaltete Lösung in Dynamics 365?

Jede Anpassung in Dynamics 365 lebt in einer Lösung. Wer ein Feld anlegt, eine Ansicht baut oder einen Flow schreibt, tut das immer innerhalb eines solchen Containers selbst wenn er es nicht bewusst auswählt. Die nicht verwaltete Variante ist dabei diejenige, in der tatsächlich gearbeitet werden sollt.

Was in einer nicht verwalteten Lösung steckt

Sie ist kein Ordner mit Dateien, sondern eine Sammlung von Verweisen. Die Lösung merkt sich, welche Tabellen, Felder, Formulare, Ansichten, Prozesse und Web-Ressourcen zu ihr gehören. Die Komponenten selbst liegen in der Umgebung.

Exportiert man sie, entsteht eine ZIP-Datei mit drei zentralen Bestandteilen: einer "solution.xml" mit den Metadaten und der Liste der enthaltenen Komponenten, einer "customizations.xml" mit den eigentlichen Definitionen und je nach Inhalt weiteren Ordnern für z.B. Web-Ressourcen, Flows oder Canvas Apps.

Das entscheidende Verhalten

Zwei Eigenschaften unterscheiden die nicht verwaltete von der verwalteten Lösung.

Erstens bleibt alles bearbeitbar. Ein Feld, welches über eine nicht verwaltete Lösung in eine Umgebung kommt kann dort umbenannt, geändert oder gelöscht werden.

Zweitens ist die Zugehörigkeit lose. Löscht man die Lösung, verschwinden die Komponenten nicht. Sie bleiben in der Umgebung zurück, nur eben ohne den Container. Das klingt harmlos, führt in der Praxis aber zu verwaisten Anpassungen, die niemand mehr zuordnen kann.

Warum sie nicht in Produktion gehört

In der Entwicklungsumgebung ist die nicht verwaltete Lösung genau richtig. Dort muss man Dinge ändern und verwerfen können. Oder man muss Komponenten möglicherweise zu mehreren Lösungen zuordnen können.

In Test und Produktion kehrt sich der Vorteil um. Dort bedeutet bearbeitbar: Jeder mit den passenden Rechten kann direkt am Formular schrauben und die Entwicklung erfährt nie davon. Beim nächsten Deployment kollidieren dann möglicherweise zwei Stände von denen jeder für sich plausibel aussieht.

Der zweite Effekt ist subtiler. Nicht verwaltete Anpassungen liegen in der Schichtung über allem, was verwaltet ausgeliefert wird (ein so genannter Solution Layer). Wer später eine korrigierte Fassung als verwaltete Lösung nachliefert stellt fest, dass sie nicht greift, weil die alte nicht verwaltete Änderung darüber liegt und gewinnt.

Woran Sie erkennen, womit Sie es zu tun haben

In der Lösungsübersicht von Power Apps zeigt eine Spalte den Typ an. Wer nur die ZIP-Datei hat, öffnet die "solution.xml" und sucht nach "Managed": Eine 0 heißt nicht verwaltet, eine 1 verwaltet.

Weniger offensichtlich ist die Frage, ob in einer Umgebung nicht verwaltete Anpassungen an Komponenten existieren, die eigentlich aus verwalteten Lösungen stammen. Genau diese Mischform sorgt für die meisten Überraschungen bei Deployments.

Praktische Konsequenz

Die Gegenüberstellung beider Varianten mit ihren Konsequenzen steht unter Managed vs. Unmanaged.

Eine saubere Aufstellung sieht so aus: In der Entwicklung wird nicht verwaltet gearbeitet, exportiert wird für Test und Produktion verwaltet. Damit bleibt die Entwicklungsumgebung die einzige Stelle, an der Anpassungen entstehen, und niemand kann in Produktion unbemerkt eingreifen.

Es gibt Gründe, davon abzuweichen. Aber dann bitte aufgeschrieben, mit Datum und Name. Alles andere rächt sich.