Dateizuordnungen in Windows 11 sind verstellt: Wo sie gespeichert werden und wie man sie dauerhaft repariert

Wo Windows 11 Dateizuordnungen speichert: Benutzerprofil, Systemebene, ProgIDs und „UserChoice“

Windows 11 verwaltet Dateizuordnungen nicht an einer einzigen Stelle, sondern verteilt Informationen über mehrere Registry-Bereiche und mehrere Ebenen: pro Benutzer, systemweit und zusätzlich über registrierte Anwendungseinträge. Diese Aufteilung erklärt, warum eine Änderung in den Einstellungen manchmal „nicht hält“, warum neue App-Installationen bestehende Zuordnungen verdrängen können und weshalb Gruppenrichtlinien oder MDM-Konfigurationen vermeintlich lokale Entscheidungen überschreiben.

Benutzerprofil: „UserChoice“ als wirksame Entscheidungsebene

Für die tatsächlich wirksame Standard-App pro Dateiendung oder Protokoll ist unter Windows 11 häufig der Benutzerkontext entscheidend. Zentral ist dabei der Schlüsselbereich, in dem Windows die Auswahl einer Standard-App pro Benutzer festhält. Technisch wird diese Auswahl in einem „UserChoice“-Unterschlüssel abgelegt. Dort steht nicht „die App“, sondern eine ProgId, also ein programmatischer Bezeichner, der wiederum auf die konkrete Befehlszeile zur Ausführung verweist.

Windows schützt die UserChoice-Einträge vor willkürlichen Änderungen durch Drittsoftware und Skripte. Die Schutzmechanismen sind einer der Gründe, warum das direkte Bearbeiten von UserChoice in der Praxis oft scheitert oder beim nächsten Systemereignis wieder revidiert wird. Nachhaltig sind in der Regel nur Änderungen, die über unterstützte Systemoberflächen, App-Registrierung oder Richtlinien gesetzt werden.

• Dateiendungen (pro Benutzer): HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.ext\UserChoice
• URL-Protokolle (pro Benutzer): HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice (analog für https, mailto usw.)
• Wirkende Zuordnung: In UserChoice verweist ProgId auf eine registrierte ProgID, die Windows als Standard verwendet.

Systemebene: Default-Registrierungen, Klassen und Fallbacks

Unabhängig von der Benutzerwahl existieren systemweite Zuordnungsinformationen unter HKEY_LOCAL_MACHINE. Dort werden „Klassen“ (Dateitypen, ProgIDs, COM-Registrierungen) sowie Standardwerte hinterlegt, auf die Windows zurückfällt, wenn kein Benutzerentscheid vorliegt oder wenn eine Anwendung lediglich ihre Fähigkeiten registriert. Besonders relevant ist HKLM\Software\Classes, das effektiv dem systemweiten Anteil von HKEY_CLASSES_ROOT entspricht.

Die Ausführungskette ist dabei indirekt: Eine Dateiendung (z. B. .pdf) zeigt auf eine ProgID (z. B. AppX… oder AcroExch.Document.DC). Die ProgID definiert unter anderem Shell-Verben wie open und den dazugehörigen Befehl. So wird aus der abstrakten Zuordnung eine konkrete Startanweisung inklusive Parameterübergabe.

ProgIDs: Bindeglied zwischen Endung, App-Identität und Shell-Befehl

ProgIDs sind der entscheidende Verknüpfungspunkt. Eine ProgID beschreibt einen Dateityp oder eine Handler-Identität und enthält Shell-Informationen wie Symbol, Anzeigenamen und Startbefehl. Klassische Desktop-Programme nutzen häufig sprechende ProgIDs, während Store-Apps (UWP/Windows-App-Sandbox) typischerweise AppX-ProgIDs verwenden. In beiden Fällen hängt die tatsächliche Öffnungslogik an der ProgID, nicht an der Dateiendung selbst.

Für die Fehlersuche ist wichtig: Wenn UserChoice auf eine ProgID zeigt, die nicht (mehr) korrekt registriert ist, entsteht ein „toter“ Verweis. Das kann nach Deinstallationen, nach „App-Repairs“, nach Feature-Updates oder durch Bereinigungssoftware auftreten. Ebenso können konkurrierende ProgIDs existieren, wenn mehrere Programme die gleiche Endung beanspruchen; Windows wählt dann nach Priorisierung und nach vorhandenen Benutzerentscheidungen.

• Dateiendung zeigt auf ProgID: HKEY_CLASSES_ROOT\.ext (Standardwert enthält häufig die ProgID, wenn keine benutzerspezifische Abweichung existiert)
• ProgID definiert „Öffnen“-Befehl: HKEY_CLASSES_ROOT\ProgId\shell\open\command (konkrete Befehlszeile inkl. Platzhalter wie "%1")
• Benutzerspezifische Überlagerung: HKEY_CURRENT_USER\Software\Classes\.ext und HKEY_CURRENT_USER\Software\Classes\ProgId können HKLM-Definitionen aushebeln.

„Applications“ und „Capabilities“: Wie Programme Ansprüche anmelden

Damit Anwendungen überhaupt als Standard-App auswählbar sind, registrieren sie ihre Fähigkeiten (Capabilities). Windows nutzt diese Angaben, um im Einstellungsdialog passende Apps für Dateiendungen und Protokolle anzubieten. Die Registrierung erfolgt typischerweise über Capabilities-Einträge und eine Zuordnung von „ProgIDs, die die App bedienen kann“. Dadurch kann eine App mehrere Endungen unterstützen, ohne jede Endung direkt auf sich zu setzen.

Praktisch relevant ist diese Schicht, wenn zwar eine ProgID existiert, die App aber nicht als auswählbar erscheint, oder wenn nach einem Update neue ProgIDs hinzukommen und alte Einträge verwaisen. Auch die bekannte Irritation, dass ein Ordner oder Laufwerk „an ein Programm gebunden“ wirkt, lässt sich häufig als Shell-Override oder fehlgeleitete Klassenregistrierung deuten, nicht als klassische Dateiendungszuordnung.

• Systemweite App-Capabilities: HKEY_LOCAL_MACHINE\Software\RegisteredApplications (verweist auf Capabilities-Pfade der Anwendungen)
• Capabilities einer App (Beispielstruktur): HKEY_LOCAL_MACHINE\Software\Clients\StartMenuInternet (Browser) sowie zugehörige \Capabilities\FileAssociations und \Capabilities\UrlAssociations je nach Produkt
• Per-User App-Registrierungen (je nach Installer): Einträge können zusätzlich unter HKEY_CURRENT_USER\Software\RegisteredApplications und HKEY_CURRENT_USER\Software\Classes auftauchen, wenn Anwendungen ohne Adminrechte installiert wurden.

Praktische Konsequenzen für Analyse und Reparatur

Für eine belastbare Diagnose ist die Trennung der Ebenen entscheidend: Zuerst wird geprüft, welche ProgID im Benutzerkontext unter UserChoice aktiv ist. Danach folgt die Validierung, ob diese ProgID in HKCR (also zusammengeführt aus HKCU und HKLM) einen plausiblen open-Befehl und konsistente Shell-Verben besitzt. Erst wenn diese Kette stimmig ist, lohnt der Blick auf Capabilities und registrierte Anwendungen, um Auswahlprobleme oder Überschreibungen durch Installer/Updates zu erklären.

Systemweite Eingriffe unter HKLM wirken auf alle Benutzer und können bestehende per-user Überlagerungen dennoch unberührt lassen; umgekehrt kann ein einzelnes Profil durch HKCU\Software\Classes das Systemverhalten scheinbar „verbiegen“. Deshalb entstehen häufig Fälle, in denen eine Zuordnung „für einen Benutzer“ defekt ist, während sie in einem frisch angelegten Profil korrekt funktioniert. Genau diese Differenz weist oft auf einen fehlerhaften per-user Klassen- oder UserChoice-Eintrag hin, nicht auf einen globalen Defekt.

Typische Ursachen und Fehlerbilder: App-Installer, Updates, DefaultAppAssociations, MDM/GPO und Sonderfälle wie Ordner/Verknüpfungen

Fehlerhafte oder unerwünschte Dateizuordnungen unter Windows 11 entstehen selten „zufällig“. Meist greift ein klarer Mechanismus: Ein Installer registriert zusätzliche ProgIDs, ein Update bewertet eine App neu, eine Systemrichtlinie initialisiert Defaults, oder es werden Sonderobjekte wie Ordner und Verknüpfungen irrtümlich wie normale Dateitypen behandelt. Besonders tückisch sind Fälle, in denen die Benutzeroberfläche eine Zuordnung anzeigt, intern aber andere Werte priorisiert werden (z. B. pro Benutzer gesetzte UserChoice-Einträge gegenüber systemweiten Voreinstellungen).

App-Installer und „Default Apps“-Registrierungen: ProgIDs, Hash und Nebenwirkungen

Viele Desktop-Installer (MSI/EXE) und einige MSIX-Pakete registrieren Dateitypen, Protokolle und „Capabilities“ der Anwendung. Typisch ist das Anlegen oder Überschreiben von Einträgen unter HKLM\Software\Classes (systemweit) sowie das Ergänzen von „RegisteredApplications“ und „Capabilities“. Windows verwendet diese Informationen, um Apps in den Einstellungen als auswählbare Standardprogramme anzuzeigen. Problematisch wird es, wenn ein Installer aggressive „Default“-Werte setzt, unpräzise Zuordnungen registriert oder bestehende ProgIDs ersetzt, statt neue zu definieren.

Seit Windows 10 schützt Windows die pro Benutzer gesetzte Standard-App-Auswahl durch einen Hash in der UserChoice-Struktur. Dadurch lassen sich Zuordnungen nicht stabil per einfachem Registry-Schreiben „festnageln“. Wenn ein Tool oder Skript dennoch versucht, UserChoice-Werte direkt zu manipulieren, resultieren häufig Symptome wie zurückspringende Defaults, fehlende Auswahlmöglichkeiten oder das Ignorieren des gesetzten Programms nach dem nächsten Anmeldevorgang.

• Typische Installer-Eingriffe: Registrierung von Dateiendungen unter HKLM\Software\Classes\.pdf, Zuordnung über ProgID unter HKLM\Software\Classes\AcroExch.Document.DC\shell\open\command, App-Capabilities in HKLM\Software\RegisteredApplications und HKLM\Software\Clients\StartMenuInternet.
• Symptom nach „Tuning“/Skripten: Benutzerdefinierte Auswahl wird ignoriert, weil HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.EXT\UserChoice ohne gültigen Hash inkonsistent ist; Windows kann dann auf eine andere Zuordnung oder die App-Auswahl zurückfallen.
• Indikator für konkurrierende ProgIDs: Mehrere Apps bieten dieselbe Endung an; sichtbar über assoc und ftype (klassisch für einige Typen) sowie über die Einträge in HKCR\.EXT und HKCR\ProgID (Beachtung der HKCU/HKLM-Hierarchie).

Windows-Updates und App-Updates: Re-Evaluierung von Defaults und „Open with“-Listen

Kumulative Updates, Feature-Updates und Updates aus dem Microsoft Store können Zuordnungslisten neu bewerten. Häufig geschieht das indirekt: Eine App meldet nach einem Update neue Capabilities oder ändert ihre AppX-/Anwendungskennung, wodurch Windows sie als „besser passend“ für bestimmte Endungen einstuft. Ebenso können Reparaturinstallationen oder „App zurücksetzen“ dazu führen, dass Registrierungen erneut geschrieben werden.

Ein verbreitetes Fehlerbild ist die teilweise Rücksetzung: Einige Endungen bleiben korrekt, während einzelne Typen (z. B. .html, .pdf, .jpg) auf Edge, Fotos oder einen neu installierten Viewer wechseln. Ursache ist nicht zwingend ein globaler Reset, sondern eine Prioritätsänderung pro Dateityp oder die Wiederherstellung eines „recommended default“ nach App-Registrierungsänderungen.

DefaultAppAssociations und systemweite Vorgaben: XML-Import, OOBE und Zurücksetzen

Systemweite Vorgaben werden in Unternehmen häufig über eine Default-Associations-XML gesetzt. Diese greift nicht als „laufende“ Durchsetzung pro Benutzer, sondern typischerweise als Initialisierung: bei der Erstanmeldung neuer Profile oder in definierten Bereitstellungsszenarien. Wird die XML-Datei später geändert oder erneut angewendet, können neu erstellte Benutzerprofile andere Standards erhalten als bestehende. Das erzeugt in gemischten Umgebungen den Eindruck, Zuordnungen seien „instabil“, obwohl lediglich unterschiedliche Startzustände vorliegen.

• Erstellung/Export: Dism /Online /Export-DefaultAppAssociations:C:\Temp\DefaultApps.xml
• Import (systemweit, für neue Benutzerprofile): Dism /Online /Import-DefaultAppAssociations:C:\Temp\DefaultApps.xml
• Policy-typischer Speicherort: HKLM\Software\Policies\Microsoft\Windows\System mit DefaultAssociationsConfiguration (Pfad zur XML), wodurch bei der Profilerstellung standardisierte Zuordnungen angewendet werden können.

Ein häufiges Missverständnis betrifft „Zurücksetzen“ über die Einstellungen: Das Zurücksetzen der Standard-Apps betrifft vorrangig die Benutzerzuordnungen und kann durch nachgelagerte Mechanismen (XML-Initialisierung, App-Reparatur, Richtlinien) wieder überschrieben werden. Außerdem können systemweite XML-Vorgaben absichtlich unvollständig sein (nur wenige Endungen definiert), was Raum für spätere App-Einträge lässt.

MDM und GPO: erzwungene Defaults, Scope-Konflikte und „scheinbar nicht änderbare“ Zuordnungen

In verwalteten Umgebungen führen MDM-Konfigurationen und Gruppenrichtlinien zu den hartnäckigsten Fehlerbildern: Die Oberfläche erlaubt zwar eine Auswahl, nach kurzer Zeit kehrt Windows jedoch zu den vorgegebenen Standards zurück. Technisch liegt meist eine Vorgabe vor, die entweder den Initialzustand jedes neuen Profils steuert oder die Standardzuordnung bei der Profilerstellung festlegt. Hinzu kommen Scope-Konflikte: Gerät-Policies (device) können Benutzerentscheidungen überlagern, und mehrere Richtlinienquellen (lokale GPO, Domänen-GPO, MDM) können unterschiedliche XML-Pfade oder Zielzuordnungen definieren.

• Hinweis auf Richtlinien-Steuerung: Vorhandene Vorgabe in HKLM\Software\Policies\Microsoft\Windows\System (z. B. DefaultAssociationsConfiguration) oder MDM-Policies, sichtbar über dsregcmd /status (Gerätemanagement/MDM-Join als Kontext).
• Typischer Scope-Konflikt: Gerätweit gesetzte Defaults kollidieren mit Benutzerzuordnungen unter HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts; Änderungen wirken kurzzeitig, werden aber nach Policy-Refresh oder Neuaufbau des Profils verdrängt.
• Folgefehler bei inkonsistenter XML: Eine Zuordnung verweist auf eine ProgID, die auf einem Teil der Geräte nicht existiert; Ergebnis sind „App auswählen“-Dialoge oder Startfehler beim Öffnen, obwohl eine „Standard-App“ angezeigt wird.

Sonderfälle: Ordner, Verknüpfungen, Laufwerke und Protokolle

Nicht jedes Doppelklick-Verhalten wird über klassische Dateiendungen gesteuert. Ordner, Laufwerke und bestimmte Shell-Objekte folgen eigenen Klassen und Befehlen. Wenn Ordner plötzlich in einem Editor oder Archivprogramm „geöffnet“ werden, liegt die Ursache oft in einer manipulierten Shell-Command-Registrierung statt in einer Dateizuordnung. Ähnlich kritisch sind Verknüpfungen: Wird .lnk falsch verknüpft, kann das Starten von Programmen, das Öffnen von Ordnern aus dem Startmenü oder das Ausführen von Tools massiv gestört werden.

Für Ordner und Laufwerke sind insbesondere die Klassen Folder, Directory und Drive relevant. Abweichungen entstehen durch Shell-Erweiterungen, Kontextmenü-Tools oder Programme, die „Open“-Verben umdefinieren. Bei Verknüpfungen ist besondere Vorsicht geboten: Manipulationen an HKCR\.lnk oder HKCR\lnkfile können Sicherheitsmechanismen aushebeln oder Systemfunktionen beeinträchtigen. Protokollzuordnungen (z. B. http, mailto) zeigen ein ähnliches Muster wie Dateitypen, werden aber über URL-Protokollhandler und App-Capabilities gesteuert und reagieren empfindlich auf Browser-Installationen und -Updates.

• Ordner-Öffnen umgebogen: Prüfung der Shell-Commands unter HKCR\Folder\shell\open\command und HKCR\Directory\shell; Dritttools setzen hier gelegentlich eigene Handler.
• Laufwerke betroffen: Abweichungen unter HKCR\Drive\shell können AutoPlay-ähnliches Verhalten imitieren und den Explorer-Aufruf verdrängen.
• Verknüpfungen (.lnk) defekt: Fehlerhafte Zuordnung von .lnk führt dazu, dass nahezu „alles“ im falschen Programm startet; relevante Klassen sind HKCR\.lnk und HKCR\lnkfile, deren Reparatur nicht über die normale Standardapp-Oberfläche erfolgt.
• Protokolle statt Endungen: Browser- oder Mail-Client-Wechsel betrifft Handler wie HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice, HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice, HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice; Konflikte entstehen häufig nach paralleler Installation mehrerer Clients mit eigenen Capabilities.

Analyse und nachhaltige Korrektur: Zuordnungen auslesen, gezielt zurücksetzen, neu definieren und gegen Überschreiben absichern

Ist-Zustand sauber erfassen: Was ist wirklich zugeordnet?

Eine belastbare Korrektur beginnt mit einer Trennung der Ebenen: Für Endungen wie .pdf oder .jpg zählt die benutzerspezifische Wahl, für Protokolle (http, mailto) und einige Shell-Verknüpfungen gelten zusätzliche Registrierungspfade. Windows 11 verwaltet die Standard-Apps primär pro Benutzer; systemweite Registrierungseinträge liefern meist nur Vorschlagswerte oder die Liste möglicher Handler. Deshalb führt das Prüfen „nur“ der klassischen Schlüssel unter HKEY_CLASSES_ROOT häufig in die Irre, weil diese Ansicht eine Zusammenführung aus HKLM\Software\Classes und HKCU\Software\Classes darstellt und die tatsächliche Default-Entscheidung an anderer Stelle fällt.

Praktisch bewährt hat sich eine zweigleisige Bestandsaufnahme: Zum einen die operativen Einstellungen unter „Standard-Apps“ (GUI), zum anderen eine technische Sicht, die die von Windows verwendeten Zuordnungs-IDs (ProgIDs) und die tatsächlich aufgerufenen Befehlszeilen (Open-Commands) sichtbar macht. So lassen sich typische Fehlerbilder wie „Ordner öffnen mit …“ (Shell-Fehlzuordnung) von „Dateiendung startet falsche App“ (Extension-Default) trennen, bevor irreversible Änderungen erfolgen.

Zuordnungen auslesen: Bordmittel, Registry und zuverlässige Indikatoren

Für eine schnelle Übersicht eignen sich Bordmittel wie assoc und ftype. Diese Kommandos spiegeln jedoch primär die klassischen Zuordnungstabellen wider und bilden die benutzerspezifischen „UserChoice“-Entscheidungen nicht vollständig ab. Für eine verlässliche Diagnose müssen daher zusätzlich die „UserChoice“-Schlüssel geprüft werden, weil sie die wirksame ProgID festlegen, die Windows beim Öffnen verwendet. Gerade nach App-Installationen oder Feature-Updates bleiben die HKCR/HKLM-Einträge oft unverändert, während die Benutzerzuordnung umspringt.

Bei Auffälligkeiten empfiehlt sich außerdem ein Blick auf den konkreten Open-Command der ermittelten ProgID. Ein falscher Pfad, defekte Anführungszeichen oder eine uninstallierte App können dazu führen, dass zwar „die richtige“ ProgID gesetzt ist, aber der Startbefehl ins Leere läuft. Ebenso relevant: Manche Anwendungen registrieren mehrere ProgIDs (z. B. „Reader“ vs. „Editor“) oder ersetzen Kontextmenü-Aktionen, ohne den Default zu ändern. Diese Unterschiede erklären, warum das Öffnen per Doppelklick anders reagiert als „Öffnen mit“.

• Endung zu ProgID (klassisch): assoc .pdf
• ProgID zu Open-Command (klassisch): ftype AcroExch.Document.DC
• UserChoice für Dateiendung prüfen: reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice"
• UserChoice für Protokoll prüfen: reg query "HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice"
• Open-Command der ProgID verifizieren: reg query "HKCR\AcroExch.Document.DC\shell\open\command" /ve

Gezielt zurücksetzen: nur das Problem anfassen, nicht das ganze System

Ein vollständiges Zurücksetzen aller Standard-Apps kann Nebenwirkungen erzeugen, etwa bei Browsern, PDF-Workflows oder proprietären Protokollen. Präziser ist ein Eingriff pro betroffener Endung beziehungsweise pro Protokoll. In der Praxis bedeutet das: erst die wirksame ProgID identifizieren, dann die Ursache beheben (defekte App, fehlende Registrierung, Richtlinie) und erst anschließend die Zuordnung neu setzen. Wenn ausschließlich „UserChoice“ korrupt ist, genügt häufig ein Zurücksetzen über die Standard-Apps-Oberfläche; systemweite Klassen sollten nur angepasst werden, wenn Open-Commands oder ProgIDs tatsächlich fehlerhaft registriert sind.

Bei „Ordner sind an falsches Programm gebunden“ liegt das Problem meist nicht bei einer einzelnen Endung, sondern bei Shell-Klassen wie Directory oder Folder. Das äußert sich oft dadurch, dass Doppelklick im Explorer einen Editor, ein Archivprogramm oder eine IDE öffnet. Hier ist besondere Vorsicht erforderlich: Änderungen an HKCR\Directory / HKCR\Folder beeinflussen das Verhalten systemweit und können auch Kontextmenüs, „Öffnen“-Standardaktionen und Shell-Verb-Handler betreffen.

• Standard-Apps gezielt zurücksetzen (GUI): ms-settings:defaultapps (pro Dateityp/Linktyp statt globalem Reset)
• Explorer neu starten (nach Korrekturen): taskkill /f /im explorer.exe
start explorer.exe
• Offensichtliche Shell-Fehlleitung prüfen: reg query "HKCR\Directory\shell" /s
reg query "HKCR\Folder\shell" /s

Neu definieren und stabil halten: Überschreiben durch Updates, Apps und Richtlinien verhindern

Windows 11 überschreibt Benutzerzuordnungen typischerweise nicht „willkürlich“, aber es gibt wiederkehrende Auslöser: Neuinstallationen registrieren zusätzliche ProgIDs und setzen Defaults während der Ersteinrichtung, größere Updates können Standard-Apps erneut vorschlagen, und Unternehmensrichtlinien können Zuordnungen initialisieren oder zurückrollen. Für dauerhafte Stabilität ist entscheidend, ob die Umgebung verwaltet ist. In verwalteten Szenarien sollte eine zentrale Vorgabe über eine Default-Associations-Konfiguration genutzt werden; lokale Einzelkorrekturen werden sonst beim nächsten Anlegen eines Profils wieder ersetzt.

In nicht verwalteten Umgebungen ist die robusteste Absicherung die saubere, aktuelle Installation der gewünschten App inklusive korrekter Registrierung ihrer ProgIDs, kombiniert mit dem Setzen der Zuordnung über die Windows-Einstellungen. „Registry-Hacks“ an UserChoice sind als dauerhafte Lösung ungeeignet: Windows schützt diese Entscheidung durch Integritätsmechanismen, und manuelle Manipulationen führen häufig dazu, dass die Zuordnung beim nächsten Systemereignis wieder auf „Zur Auswahl auffordern“ oder auf einen Microsoft-Standard zurückfällt.

Für verwaltete Systeme ist ein kontrolliertes Exportieren und Verteilen von Zuordnungen sinnvoll, allerdings nur nach Validierung auf einem Referenzsystem und mit Bedacht auf Nebenwirkungen. Ein systemweiter Import kann unerwünschte Standardprogramme für neue Benutzerprofile festschreiben, auch dort, wo Spezialsoftware existiert. Außerdem sollten Zuordnungen nicht isoliert betrachtet werden: Wenn der hinterlegte Open-Command auf eine App-Version zeigt, die per Update ihren Installationspfad geändert hat, wirkt die „korrekte“ Zuordnung dennoch wie ein Fehler.

• Default-Associations exportieren (verwaltet): Dism /Online /Export-DefaultAppAssociations:C:\Temp\DefaultAppAssociations.xml
• Default-Associations importieren (verwaltet, systemweit): Dism /Online /Import-DefaultAppAssociations:C:\Temp\DefaultAppAssociations.xml
• Richtlinienbezug prüfen (Pfadindikator): HKLM\Software\Policies\Microsoft\Windows\System (typisch für gesetzte Defaults über DefaultAssociationsConfiguration)