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. Das gilt selbst dann, wenn er es nicht bewusst auswählt. Die nicht verwaltete Variante ist dabei diejenige, in der tatsächlich gearbeitet werden sollte.

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. Die "solution.xml" enthält die Metadaten und die Liste der enthaltenen Komponenten, die "customizations.xml" die eigentlichen Definitionen. Dazu kommen je nach Inhalt weitere Ordner 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. Kommt ein Feld über eine nicht verwaltete Lösung in eine Umgebung kann es 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. Jeder für sich sieht plausibel aus.

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. Die alte nicht verwaltete Änderung liegt darüber 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.