diff --git a/Sonstiges/LIAM_WF_GetDataAreas_Auffaelligkeiten_und_moegliche_Fixes (initial).md b/Sonstiges/LIAM_WF_GetDataAreas_Auffaelligkeiten_und_moegliche_Fixes (initial).md
new file mode 100644
index 0000000..1e42002
--- /dev/null
+++ b/Sonstiges/LIAM_WF_GetDataAreas_Auffaelligkeiten_und_moegliche_Fixes (initial).md	
@@ -0,0 +1,354 @@
+# LIAM WF GetDataAreas - Auffaelligkeiten und moegliche Fixes (initial)
+
+## Ziel des Dokuments
+
+Dieses Dokument betrachtet ausschliesslich den Stand `initial` (`f563d78417c8183ac0934beaa11d0f258b7537bf`).
+
+Es bewertet die Rueckfrage, warum `WF Get DataAreas` in einer betroffenen Situation nicht mehr hunderte Datenbereiche, sondern nur noch sehr wenige Eintraege, beispielsweise `3`, zurueckliefern kann.
+
+Ausdruecklich nicht im Fokus stehen hier:
+
+- geaenderte `MaxDepth`
+- geaenderte Naming-Conventions
+- spaetere Aenderungen im aktuellen Hauptstand
+
+Im Fokus stehen stattdessen nur moegliche Ursachen, die bereits im `initial`-Stand zu so einem Verhalten fuehren konnten:
+
+- geaenderte Ordnerstruktur
+- geaenderte Rechte auf Shares oder Ordnern
+- geaenderte ACL-Situation
+- geaenderte AD-Erreichbarkeit oder AD-Berechtigungen
+- geaenderte DFS-Erreichbarkeit
+- Logging-Luecken und stille Teilergebnisse
+
+## Kurzfazit
+
+Im `initial`-Stand ist das geschilderte Verhalten grundsaetzlich moeglich.
+
+Die plausibelsten Ursachen fuer `frueher viele, jetzt nur noch wenige` sind im Altstand:
+
+- geaenderte sichtbare Ordnerstruktur unterhalb des konfigurierten `RootPath`
+- geaenderte Leserechte auf Teilbaeumen des Dateisystems
+- Probleme beim rekursiven Traversieren, die im Code als Teilergebnis statt als klarer Fehler enden
+- Probleme bei der Erreichbarkeit des Root-Pfads selbst, insbesondere bei UNC-/DFS-Pfaden
+
+Reine AD-Probleme sind im `initial`-Stand fuer genau das Muster `es kommen noch 3 zurueck` deutlich weniger plausibel.
+
+Wenn AD im `initial`-Stand wirklich nicht funktioniert, fuehrt das eher zu einem Fehlschlag des Logons und damit zu `null` oder zu einem kompletten Fehlerbild, nicht zu einer kleinen aber formal erfolgreichen Teilmenge.
+
+Wichtig ist auch: Der `initial`-Stand verwendet fuer `GetDataAreas` noch keine explizite DFS-Klassifikation und keine Share-Enumeration. DFS-Probleme koennen also nur indirekt ueber den UNC-Pfad und dessen Dateisystemerreichbarkeit wirken, nicht ueber die spaetere Root-/DFS-Logik des heutigen Stands.
+
+## Gepruefter Umfang
+
+Fuer diese Einschaetzung wurden im `initial`-Stand insbesondere diese Dateien betrachtet:
+
+- `LiamWorkflowActivities/C4IT.LIAM.WorkflowActivities.cs`
+- `LiamWorkflowActivities/C4IT.LIAM.WorkflowactivityBase.cs`
+- `LiamNtfs/C4IT.LIAM.Ntfs.cs`
+- `LiamNtfs/cNtfsBase.cs`
+- `LiamNtfs/cActiveDirectoryBase.cs`
+- `LiamNtfs/C4IT_IAM_SET/cNetworkConnection.cs`
+
+## Workflow-Verhalten im initial-Stand
+
+Workflow-seitig ist der `initial`-Stand sehr duenn.
+
+Die damalige Methode `getDataAreasFromProvider(Guid ProviderConfigClassID)` ruft den Provider direkt mit `ProviderEntry.Provider.getDataAreasAsync(ProviderEntry.Provider.MaxDepth)` auf und behandelt `null` oder `Count <= 0` pauschal als `No data areas found`.
+
+Das bedeutet:
+
+- Es gibt keine Unterscheidung zwischen technischem Fehler, Teilergebnis und wirklich leerem Bestand.
+- Es gibt keine strukturierte Fehlerdiagnose fuer die Discovery.
+- Es wird nicht protokolliert, wie viele Ordner theoretisch erreichbar gewesen waeren oder wo die Traversierung abgebrochen ist.
+
+Damit ist bereits auf Workflow-Ebene erklaert, warum im Log oft nur wenig Aussagekraeftiges sichtbar ist.
+
+## Discovery-Logik im initial-Stand
+
+Die eigentliche Discovery sitzt in `cLiamProviderNtfs.getDataAreasAsync(int Depth = -1)`.
+
+Die Logik ist im `initial`-Stand im Kern:
+
+1. Lizenz pruefen
+2. `LogonAsync()` ausfuehren
+3. `RootPath` auf Leerwert pruefen
+4. Root-Typ ueber die Anzahl der UNC-Segmente herleiten
+5. `ntfsBase.RequestFoldersListAsync(this.RootPath, Depth)` aufrufen
+6. alle zurueckgelieferten Ordner in `DataAreas` uebernehmen
+
+Entscheidend ist:
+
+- Es gibt im `initial`-Stand keine explizite DFS-Metadatenpruefung.
+- Es gibt keine Share-Enumeration fuer den Root.
+- Es wird direkt versucht, unterhalb des konfigurierten `RootPath` Dateisystemordner zu enumerieren.
+
+Dadurch reagieren Ergebniszahl und Ergebnisqualitaet im `initial`-Stand primaer auf Dateisystemsichtbarkeit und Traversierungsrechte.
+
+## Priorisierte Auffaelligkeiten im initial-Stand
+
+### 1. Hoch: Zugriffsprobleme in der Ordnerrekursion werden als Teilergebnis zurueckgegeben
+
+Das kritischste Verhalten fuer das geschilderte Fehlerbild steckt in `cNtfsBase.privRequestFoldersListAsync(DirectoryInfo rootPath, int depth, cNtfsResultFolder parent = null)`.
+
+Wenn waehrend `rootPath.GetDirectories()` oder in tieferen Rekursionsstufen ein Fehler auftritt, landet der Code in einem allgemeinen `catch` und gibt einfach die bis dahin gesammelte Liste `folders` zurueck.
+
+Das bedeutet fachlich:
+
+- Ein Zugriff auf den Root kann funktionieren.
+- Die Traversierung kann auf tieferen Ebenen an einzelnen Ordnern scheitern.
+- Statt eines klaren Fehlers wird aber nur die bis dahin gefundene Teilmenge zurueckgegeben.
+
+Genau dieses Verhalten passt sehr gut zu:
+
+- `frueher hunderte`
+- `jetzt noch 3`
+- `im Log sehe ich nichts`
+
+Wenn sich zwischenzeitlich Leserechte oder effektive Traversierungsrechte auf Teilbaeumen geaendert haben, kann der `initial`-Stand damit sehr gut nur noch wenige erreichbare Ordner zurueckliefern.
+
+Das ist im `initial`-Stand keine theoretische Ecke, sondern ein reales stilles Fehlerbild.
+
+### 2. Hoch: Aenderungen an der Ordnerstruktur wirken im initial-Stand direkt auf die Rueckgabemenge
+
+Da der `initial`-Stand keine Root-Klassifikation ueber DFS-/Share-Metadaten macht, sondern schlicht rekursiv unterhalb von `RootPath` liest, haengt die Rueckgabemenge unmittelbar von der sichtbaren Ordnerstruktur ab.
+
+Wenn beispielsweise:
+
+- Unterordner entfernt wurden
+- Verzeichnisstrukturen verschoben wurden
+- Junctions oder Weiterleitungen anders wirken
+- der konfigurierte Root heute auf einen kleineren Teilbaum zeigt
+
+dann sinkt die Anzahl der gefundenen DataAreas direkt.
+
+Im `initial`-Stand gibt es keine zusaetzliche semantische Schicht, die das noch abfedert oder klarer diagnostiziert.
+
+### 3. Hoch: Der Root selbst muss erreichbar sein, sonst scheitert der gesamte Call
+
+Vor dem eigentlichen Lesen fuehrt der Provider `LogonAsync()` aus.
+
+Darin werden sowohl `ntfsBase.LogonAsync(LI)` als auch `activeDirectoryBase.LogonAsync(LI)` aufgerufen.
+
+Das bedeutet:
+
+- Der technische Benutzer muss den UNC-Root grundsaetzlich erreichen.
+- Der AD-Login muss ebenfalls gelingen.
+
+Wenn bereits der UNC-Zugriff auf `RootPath` scheitert, kommt es eher zu einem harten Fehlerbild.
+
+Fuer das Muster `nur noch 3` ist deshalb weniger der komplette Ausfall des Root-Zugriffs interessant, sondern eher der Fall:
+
+- Root erreichbar
+- einige Unterordner oder Teilbaeume nicht mehr sauber lesbar
+
+Genau dann greift wieder das stille Teilergebnis aus der Rekursion.
+
+### 4. Mittel-Hoch: DFS-Probleme koennen im initial-Stand indirekt wirken
+
+Im `initial`-Stand wird DFS fuer `GetDataAreas` nicht explizit ausgewertet.
+
+Es gibt dort:
+
+- keine DFS-Namespace-Klassifikation
+- keine DFS-Link-Erkennung
+- keine Nutzung von `NetDfsGetInfo()` im Discovery-Pfad
+
+Das ist wichtig, weil dadurch spaetere Ursachen aus dem aktuellen Stand hier gerade nicht gelten.
+
+Trotzdem kann DFS im `initial`-Stand indirekt relevant sein, wenn `RootPath` ein DFS-Pfad ist.
+
+Dann wirken DFS-Probleme nicht ueber Metadatenklassifikation, sondern ueber die schlichte Tatsache, dass `DirectoryInfo(rootPath).GetDirectories()` auf diesem UNC-Pfad heute vielleicht nur noch teilweise oder gar nicht mehr funktioniert.
+
+Moegliche Folgen:
+
+- DFS-Ziel aktuell nicht sauber erreichbar
+- Name oder Ziel nicht mehr korrekt aufloesbar
+- technische Session landet auf anderem oder reduziertem Ziel
+- Traversierung liefert nur eine kleine Teilmenge
+
+Damit ist DFS im `initial`-Stand als indirekter Infrastrukturhebel durchaus plausibel, aber nicht ueber denselben Mechanismus wie im heutigen Stand.
+
+### 5. Mittel: AD-Probleme erklaeren eher harte Fehler als kleine Treffermengen
+
+Der `initial`-Stand koppelt NTFS- und AD-Logon eng zusammen.
+
+Wenn `activeDirectoryBase.LogonAsync(LI)` scheitert, wird das gesamte `LogonAsync()` des Providers `false`, und `getDataAreasAsync()` gibt `null` zurueck.
+
+Das spricht gegen AD als primaere Ursache fuer eine kleine, aber noch erfolgreiche Trefferliste.
+
+Reine AD-Erreichbarkeitsprobleme passen im `initial`-Stand eher zu:
+
+- kompletter Fehler
+- keine DataAreas
+- harter Ausfall beim Providerzugriff
+
+Teilprobleme in AD koennen spaeter fuer Zusatzinformationen relevant sein, aber nicht besonders gut fuer `nur noch 3 DataAreas`.
+
+### 6. Mittel: ACL-/Gruppenaufloesung beeinflusst eher Zusatzdaten als die Anzahl
+
+Die ACL-Leselogik sitzt in `cActiveDirectoryBase.GetAccessControlList(string path)`.
+
+Wenn dort auf einem Ordner die ACL nicht gelesen werden kann, wird `null` geliefert.
+
+In der weiteren Verarbeitung fuehrt das eher dazu, dass zu einer bereits gefundenen DataArea Gruppeninformationen oder Owner-/Read-/Write-Zuordnungen fehlen.
+
+Das reduziert im `initial`-Stand typischerweise nicht die Anzahl der gefundenen DataAreas selbst.
+
+Darum gilt fuer die Fragestellung:
+
+- geaenderte ACLs koennen die Zahl der DataAreas reduzieren, wenn sie die Ordner-Traversierung blockieren
+- geaenderte ACLs erklaeren die reduzierte Zahl eher nicht, wenn nur die spaetere Permission-Group-Aufloesung betroffen ist
+
+### 7. Mittel: `Depth = 0` ist im initial-Stand fachlich fehlerhaft
+
+Im `initial`-Stand liefert `RequestFoldersListAsync(string rootPath, int depth)` bei `depth == 0` `null`.
+
+Dadurch wird spaeter im Provider `DAL == null` als Fehler interpretiert und das bereits erzeugte Root-Objekt geht verloren.
+
+Das ist ein echter Bug im Altstand.
+
+Fuer die vorliegende Rueckfrage ist er aber nur dann relevant, wenn die betroffene Konfiguration wirklich `MaxDepth = 0` verwendet haette.
+
+Da Konfigurationsaenderungen hier bewusst ausgeschlossen werden sollen, ist dieser Punkt eher nachrangig, aber als Code-Auffaelligkeit im `initial`-Stand trotzdem wichtig.
+
+## Bewertung der konkret genannten Umweltfaktoren fuer initial
+
+### Aenderungen an der Ordnerstruktur
+
+Sehr plausibel.
+
+Im `initial`-Stand wird direkt rekursiv unterhalb von `RootPath` gelesen. Wenn sich die effektive Struktur des Teilbaums geaendert hat, aendert sich die Anzahl der DataAreas unmittelbar.
+
+### Aenderungen an der Rechtesituation auf Ordnern oder Teilbaeumen
+
+Sehr plausibel.
+
+Das ist sogar einer der staerksten Kandidaten, weil die Rekursion bei Fehlern nicht klar scheitert, sondern mit Teilergebnissen weiterarbeitet.
+
+Wenn der technische Benutzer bestimmte Unterordner nicht mehr listen kann, koennen ganze Teilbaeume verschwinden, ohne dass das Ergebnis als Fehler gekennzeichnet wird.
+
+### Aenderungen an ACLs
+
+Teilweise plausibel.
+
+Wenn ACL-Aenderungen die Ordner-Traversierung selbst beeinflussen, dann ja, sehr plausibel.
+
+Wenn ACL-Aenderungen nur die spaetere Permission-Group-Aufloesung betreffen, dann eher nicht als Erklaerung fuer `nur noch 3`.
+
+### Aenderungen an AD-Rechten oder AD-Erreichbarkeit
+
+Eher als Primaerursache unplausibel fuer dieses konkrete Muster.
+
+Im `initial`-Stand fuehren ernsthafte AD-Probleme eher zum kompletten Logon-Fehler als zu einer kleinen Restliste.
+
+### Aenderungen an DFS-Erreichbarkeit
+
+Plausibel, aber indirekt.
+
+Im `initial`-Stand wirkt DFS nur ueber den UNC-Pfad und dessen praktische Erreichbarkeit. Wenn ein DFS-Pfad nicht mehr stabil oder nicht mehr gleich aufgeloest wird, kann das Lesen des Dateisystembaums reduziert oder unvollstaendig werden.
+
+## Warum man im initial-Log wenig sieht
+
+Der `initial`-Stand hat mehrere Diagnoseprobleme gleichzeitig:
+
+- Workflow-seitig gibt es nur pauschale Aussagen wie `No data areas found`
+- in der Ordnerrekursion gibt es ein stilles `catch` ohne strukturierte Diagnose
+- es gibt keine Statistik ueber erkannte, verworfene oder fehlgeschlagene Unterbaeume
+- es gibt keine Kennzeichnung von Teilergebnissen
+
+Dadurch kann ein fachlich stark reduziertes Ergebnis technisch wie ein normaler erfolgreicher Call aussehen.
+
+## Moegliche Fixes fuer den initial-Stand
+
+### 1. Rekursive Traversierung darf Fehler nicht still in Teilergebnisse umwandeln
+
+Empfohlene Aenderung:
+
+- Das innere `catch` in `privRequestFoldersListAsync()` sollte nicht kommentarlos `folders` zurueckgeben.
+- Stattdessen muss mindestens geloggt werden, an welchem Pfad die Traversierung abgebrochen ist.
+- Besser waere ein Ergebnisobjekt, das `Success`, `PartialResult` und `FailedPaths` sauber trennt.
+
+Nutzen:
+
+- Berechtigungs- oder Infrastrukturfehler auf Teilbaeumen werden endlich sichtbar.
+- Der Unterschied zwischen `wirklich nur 3 vorhanden` und `nur 3 erreichbar` wird nachvollziehbar.
+
+### 2. Teilergebnisse im Workflow explizit kennzeichnen
+
+Empfohlene Aenderung:
+
+- Workflow-seitig nicht nur `null` oder `Count <= 0` behandeln.
+- Discovery-Ergebnis um Diagnosedaten erweitern, etwa:
+  - `IsPartial`
+  - `FailedPathCount`
+  - `LastTraversalError`
+
+Nutzen:
+
+- Die Workflow-Schicht bekommt eine belastbare Grundlage fuer Support und Betrieb.
+
+### 3. RootPath und Traversierungsstatistik mitloggen
+
+Empfohlene Aenderung:
+
+Pro Call mindestens loggen:
+
+- `RootPath`
+- `Depth`
+- Anzahl direkt gefundener Ordner
+- Anzahl rekursiv gefundener Ordner
+- Anzahl abgebrochener Teilbaeume
+
+Nutzen:
+
+- Schon ein einzelner Logauszug reicht spaeter fuer eine deutlich bessere Einordnung.
+
+### 4. AD-Login fuer reine Discovery vom ACL-/Gruppenmapping entkoppeln
+
+Empfohlene Aenderung:
+
+- Fuer die reine Ordnerdiscovery sollte die NTFS-Erreichbarkeit ausschlaggebend sein.
+- AD-Fehler sollten die spaetere Zusatzdatenaufloesung beeintraechtigen koennen, aber nicht zwingend die gesamte Discovery blockieren.
+
+Nutzen:
+
+- Reine AD-Stoerungen fuehren nicht mehr automatisch dazu, dass Discovery unnoetig komplett scheitert.
+- Die Ursachenanalyse wird klarer getrennt.
+
+### 5. Diagnosemodus fuer den Dateibaum einfuehren
+
+Empfohlene Aenderung:
+
+- Optionaler Diagnosemodus, der je Traversierungsebene protokolliert:
+  - welcher Pfad gelesen wurde
+  - wie viele Unterordner gefunden wurden
+  - an welchem Pfad ein Fehler auftrat
+
+Nutzen:
+
+- Gerade fuer sporadische Infrastrukturprobleme ist das deutlich hilfreicher als das bisherige allgemeine Fehlerbild.
+
+## Praktische Pruefungen fuer den betroffenen initial-Fall
+
+Wenn der Fehler im `initial`-Stand analysiert werden soll, sind diese Pruefungen am wahrscheinlichsten zielfuehrend:
+
+1. Den exakten `RootPath` der betroffenen Konfiguration pruefen.
+2. Mit dem technischen Benutzer denselben UNC-Pfad ausserhalb des Workflows rekursiv lesen.
+3. Pruefen, ob auf tieferen Teilbaeumen Leserechte oder Traversierungsrechte geaendert wurden.
+4. Falls der `RootPath` ein DFS-Pfad ist, pruefen, ob dieser im betroffenen Zeitraum noch auf dasselbe Ziel und mit derselben Erreichbarkeit aufgeloest wurde.
+5. AD-Probleme nur dann priorisieren, wenn es Indizien fuer generelle Logon-Fehler oder komplett fehlgeschlagene Providerinitialisierung gibt.
+
+## Schlussbewertung
+
+Nur fuer den Stand `initial` betrachtet, sind die wahrscheinlichsten Ursachen fuer `statt hunderten nur noch 3 DataAreas`:
+
+- geaenderte sichtbare Ordnerstruktur
+- geaenderte Leserechte auf Unterordnern oder Teilbaeumen
+- indirekte DFS-/UNC-Erreichbarkeitsprobleme auf dem verwendeten Root-Pfad
+
+Deutlich weniger wahrscheinlich als primaere Ursache sind:
+
+- reine AD-Rechteprobleme
+- reine ACL-/Gruppenmapping-Probleme nach erfolgreicher Discovery
+
+Die wichtigste technische Auffaelligkeit im `initial`-Stand ist, dass Fehler in der Ordnerrekursion still zu Teilergebnissen werden koennen. Genau das kann das beobachtete Verhalten sehr gut erklaeren, ohne dass im Log ein klarer Fehler sichtbar wird.