Im Netzwerkumfeld muss der Administrator viele Endsysteme wie PCs, Netzwerkkarten oder Drucker verwalten. Dies wird schnell zum Horrorszenario, denn das Implementieren von unterschiedlichen Geräten in ein bestehendes Firmennetzwerk führt häufig zu Problemen bei Konfiguration, Leistungsüberwachung, Fehleranalyse und beim Sicherheitsmanagement. So entstehen enorme Kosten (TCO) durch den hohen Arbeitsaufwand des Administrators. Hier greift DMI unterstützend ein.
Die herkömmlichen Netzwerkassistenten, so genannte Agenten, basieren auf SNMP und können diese Aufgaben nicht erfüllen. Denn sie sind an feste Protokoll-Strukturen gebunden und ursprünglich nur für das "Internet-Mangement" (Router, Switches oder Hubs) konzipiert.
Um dieses Manko zu beseitigen, schlossen sich führende IT-Unternehmen zusammen und entwickelten den Desktop-Management-Interface-Standard. Dieser arbeitet unabhängig von Protokollen und soll nach Wunsch der Initiatoren universell einsetzbar sein. Zudem ist es ein offener Standard, der allen Herstellern eine gemeinsame Basis zur lokalen Verwaltung und Wartung ihrer Hard- und Software garantiert. Darüber hinaus können die einzelnen Komponenten für Konfigurations- und Wartungsarbeiten per RPC-Netzwerkzugriff (ab DMI 2.0) angesprochen werden.
Die DMI-Technologie bildet ein Werkzeug zum Aufbau bedienungsfreundlicher, wartungsarmer Produkte. Sie stellt dem Anwender alle vom Hersteller vordefinierten Daten der verwalteten Komponente zur Verfügung. Ein DMI-fähiges Gerät oder eine Anwendung können die jeweiligen Anforderungen und Informationen einer übergeordneten Management-Software mitteilen und dem Anwender zugänglich machen. Wie das Desktop Management Interface aufgebaut ist und wie es funktioniert, erläutern wir ausführlich in diesem Artikel.
Entwicklungsverlauf des DMI
Die Grundidee des Desktop Management Interface basiert auf der Konfiguration und Inventarisierung von Desktop-PCs, Notebooks und Servern mit ihren einzelnen Komponenten. Dazu zählen Hardware, Software und Firmware.
Um diese Wunschvorstellung zu verwirklichen, gründeten 1992 eine Gruppe von Firmen wie Digital Equipment Corporation, Hewlett-Packard, IBM, Intel, Microsoft, Novell, SunSoft und SynOptics die Desktop Management Task Force (DMTF).
Die Organisation veröffentlichte bereits 1994 die erste Version des DMI-Standards. Zwei Jahre später folgte die überarbeitete Version 2.0. Sie ersetzt das proprietäre blockstrukturierte Übertragungs-Interface basierend auf einer API durch eine per Prozeduren gesteuerte Schnittstelle mit standarisierten Funktionen. So verwendet es zum Beispiel Remote Procedure Calls (RPC), um ein Geräte-Management durch Remote-Zugriffe zu ermöglichen.
1998 erweiterte die DMTF-Arbeitsgemeinschaft den DMI-Standard um sicherheitsrelevante Optionen und veröffentlichte DMI 2.0s. Das letzte Update erfolgte am 10. Januar 2003 auf die Version 2.0.1s und enthält lediglich Fehlerkorrekturen. Laut DMTF sind alle neuen DMI-Versionen abwärtskompatibel.
Architektur des DMI
Das Desktop Management Interface (DMI) stellt eine Struktur für die Verwaltung von unterschiedlichen Komponenten in Desktop-PCs, Servern, Notebooks und auch Applikationen zur Verfügung.
Eine wichtige Rolle auf einem zu verwaltenden System spielt der "Service Provider" (SP). Er stellt alle Schnittstellen und Informationen für den Zugriff auf die Komponentendaten zur Verfügung. Der Service Provider ist ein Programm, das die Informationen in der MIF-Datei verwaltet, alle lokal gebundenen Komponenteneigenschaften sammelt und diese auf Anfrage an die Management-Anwendung weiterleitet. Damit der SP eine Komponente bearbeiten kann, muss der Hersteller eine individuelle MIF-Datei für sie mitliefern. Darin sind Informationen enthalten, die das zu verwaltende Objekt in Form von Parametern beschreiben. Alle Informationen der einzelnen MIF-Dateien werden vom SP zur einer MIF-Datenbank (MIF-Database) zusammengefasst. Zusätzlich koordiniert der SP den Datenverkehr zwischen dem Management Interface (MI) und der DMI-Applikation sowie die Kommunikation über das Component Interface (CI) zu den Komponenten.
Neben den beschriebenen Aufgaben verfügt der SP auch über eine Anzahl von APIs, die die Entwicklung von Management-Software unterstützen.
Die zentralen Funktionseinheiten der DMI-Struktur sind in der folgenden Übersicht zusammengefasst:
Der Service Provider (SP) leitet alle Anfragen der Management-Anwendung an die Komponenten weiter. Er ist das Bindeglied zwischen dem Management Interface (MI) und dem Component Interface (CI).
Das MI ermöglicht den Management-Anwendungen den Zugriff auf die Komponentendaten. Bei definierten Ereignissen werden die Komponenten- und Ereignisdaten miteinander verglichen und für eine User-Benachrichtigung gespeichert (zum Beispiel knapper Festplattenspeicher oder Defekt einer Komponente).
Das CI ist die Schnittstelle zwischen dem SP und den Komponenten. Es ermöglicht eine Komponente direkt anzusprechen und zu verwalten.
Die MIF-Datei beschreibt, welche Komponentendaten von der Management-Anwendung abgefragt und beeinflusst werden können.
Darüber hinaus kann das DMI Informationen per SNMP bereitstellen. Dazu liefern die Hersteller in dem DMI-SDK (Software Development Kit) einen entsprechenden Compiler mit. Er übersetzt die MIF-Datei in das SNMP-Format. Über einen solchen Mapper können zum Beispiel flexible SNMP-Management-Agenten auf eine DMI-Architektur zugreifen.
Service Provider (SP)
Der DMI Service Provider (SP), auch Service Layer (SL) genannt, koordiniert und vermittelt Anfragen (Requests) von der Management-Anwendung über das Management oder Component Interface an die entsprechende Komponente und umgekehrt. Zu den Hauptaufgaben des SPs gehören zusätzlich die Installation und Registrierung von Komponenten in der MIF-Datenbank sowie die Synchronisation und Flusskontrolle zwischen dem MI und dem CI.
Die Entwickler haben die Interfaces so konzipiert, dass Befehle auf der MI-Ebene entweder vom SP abgearbeitet werden oder direkt zum CI gelangen. Das vereinfacht bei bestimmten Zugriffs-Funktionen das DMI-Handling.
Die folgende Übersicht erläutert detailliert, welche Aufgaben der DMI Service Provider erfüllt:
Der Service Provider koordiniert die dynamische Komponenteninstallation und regelt das automatische Entfernen von Management-Events oder -Anwendungen.
Er steuert und registriert Programmprozesse, die Managementaktivitäten einleiten.
Der SP ist für alle zur Laufzeit durchgeführten Zugriffe auf die MIF-Datei verantwortlich. Außerdem kann ein SP verwendet werden, um eine MIF-Datei in ein internes betriebsabhängiges Format (MIF-Datenbank) einzubinden. Das ermöglicht einen schnellen und einfachen Zugriff auf benötigte MIF-Informationen.
Falls notwendig, startet der SP bestimmte Komponentenprozesse wie zum Beispiel ein Firmware-Update.
Der SP überwacht periodisch Komponentenprozesse. Damit stellt er sicher, dass die Prozesse korrekt bis zur Beendigung ablaufen. Zusätzlich gewährleistet der SP, dass mehrfache Anfragen an einen Programmprozess in einer Warteschlange verwaltet und abgearbeitet werden.
Löst eine Komponente ein Ereignis aus oder startet die Management-Applikation eine Anfrage, so muss es der SP auswerten beziehungsweise filtern können.
Wenn eine Komponente in die MIF-Datenbank aufgenommen oder aus dem Datensatz gelöscht wird, muss der SP alle verantwortlichen Management-Applikationen benachrichtigen.
Management Interface (MI)
Das MI teilt sich in vier unterschiedliche Funktionsgruppen auf. Mit der Initialisierungs-Funktion lassen sich Management-Anwendungen beim SP registrieren und bestimmte Konfigurationsdaten abrufen. Die zweite Gruppe beinhaltet Auflistungsfunktionen. Sie entschlüsseln und listen die vom SP gelieferten Informationen auf. Mit den Operationsfunktionen ermöglichen die Management-Applikationen detaillierte Eigenschaften beziehungsweise definierte Parameter vom SP zu erhalten. Administrative Datenbankfunktionen und Befehle bilden die letzte Gruppe von MI-Funktionen.
Initialization Functions | Listing Functions | Operation Functions | Database Administration Functions | |
|---|---|---|---|---|
| ||||
DmiRegister | DmiListComponents- ByClass | DmiGetAttribute | DmiAddComponent | |
DmiUnregister | DmiListLanguages | DmiSetAttrubute | DmiAddLanguage | |
DmiGetVersion | DmiListClassNames | DmiGetMultiple | DmiAddGroup | |
DmiGetConfig | DmiListGroups | DmiSetMultiple | DmiDeleteComponent | |
DmiSetConfig | DmiListAttributes | DmiAddRow | DmiDeleteLanguage | |
DmiDeleteRow | DmiDeleteGroup |
Den grundlegenden Aufbau einer MI-Funktion zeigt das Beispiel (Quelle: DMI-Spezifikation, Version: 2.0.1s) anhand der Initialization Function: DmiGetVersion. Die Funktion ermittelt spezifische Informationen über den SP. So benutzt die Management-Software diesen Aufruf, um detaillierte Beschreibungen (description) zur Nutzung des SP zu erhalten. Sie hängen von der eingesetzten DMI-Version (DmiSpecLevel) ab.
DmiErrorStatus_t DMI_API
DmiGetVersion (
[in] DmiHandle_t handle,
[out] DmiString_t** dmiSpecLevel,
[out] DmiString_t** description,
[out] DmiFileTypeList_t** fileTypes );
Component Interface (CI)
Das optionale CI ist im Gegensatz zum MI plattform- und betriebssystemabhängig. Es erlaubt installierte Komponenten direkt mit dem DMI-SP zu verbinden und ist optional. Das CI setzt im Wesentlichen auf zwei APIs auf: Sie besitzen zum einen Service-Provider-Funktionen wie Anzeigen von Ereignissen (geöffneter PC-Gehäusedeckel) und zum anderen bieten sie Component-Provider-Funktionen, um Komponenten-Attribute per Get- und Set-Befehle direkt zu verändern.
Die Service-Provider-Funktionen arbeiten folgendermaßen: Sie können den SP derart beeinflussen, dass er den aktuellen Zugriffsmechanismus auf die registrierten Attribute der Komponente außer Kraft setzt. Anstatt die Informationen der MIF-Datenbank zu verändern oder entsprechende Programme zu starten, ruft der SP den Einsprungpunkt auf, den das CI durch eine Registrieranforderung liefert. Nach der Veränderung der Komponenten-Attribute kehrt der SP in seine "normale" Funktionsweise zurück. In diesem Zustand kann der CI den SP nur per Interrupt-Routinen unterbrechen, um spezielle Funktionen zu starten.
Nicht alle Betriebssysteme verfügen über ein DMI-CI oder unterstützen alle Funktionen. Dieses Manko kann das Betriebssystem durch native Mechanismen wie zum Beispiel Programme zur Komponentenregistrierung ausgleichen.
Data Structures Functions | Service Provider Functions for Components | Component Provider Functions | |
|---|---|---|---|
| |||
DmiAccessData | DmiRegisterCi | CiGetAttribute | |
DmiAccessDataList | DmiUnregisterCI | CiGetNextAttribute | |
DmiRegisterInfo | DmiOrginateEvent | CiSetAttribute | |
CiReserveAttribute | |||
CiReleaseAttribute | |||
CiAddRow | |||
CiDeleteRow |
Das folgende Beispiel (Quelle: DMI-Spezifikation, Version: 2.0.1s) verdeutlicht den prinzipiellen Aufbau einer "Service Provider Function" für Komponenten. Die Funktion installiert für eine Komponente ein aufrufbares Interface, um damit die SP-Version abfragen zu können.
DmiErrorStatus_t DMI_API
DmiRegisterCi (
[in] DmiRegisterInfo_t* regInfo,
[out] DmiHandle_t* handle,
[out] DmiString_t** dmiSpecLevel);
Im folgenden Beispiel (Quelle: DMI-Spezifikation, Version: 2.0.1s) wird ein grundlegender Aufbau einer "Component Provider Function" gezeigt. Die Funktion ermittelt den Wert eines einzelnen Komponenten-Attributs oder mehrerer Attribute in einer Gruppe.
DmiErrorStatus_t DMI_API
CiGetAttribute (
[in] DmiId_t componentId,
[in] DmiId_t groupId,
[in] DmiId_t attributeId,
[in] DmiString_t* language,
[in] DmiAttributeValues_t* keyList,
[out] DmiAttributeData_t** data);
Management Information Format (MIF)
Das DMI ermöglicht den verwendeten Management-Applikationen, einzelne Komponenten über den SP zu verwalten und direkt anzusteuern. Dazu muss jede Komponente genau definiert sein. Die Beschreibung der einzelnen verwaltbaren Eigenschaften wie Firmware-Version und die damit verknüpften Attribute einer Systemkomponente, zum Beispiel Netzwerkkarte, sind in einem Management Information Format (MIF) festgelegt. Die MIF-Datei hat eine festgelegte Syntax im ASCII-Format. Bei der Installation einer Komponente auf einem System werden die MIF-Informationen in eine MIF-Datenbank eingebunden. Jeder Hersteller, der seine Hard- oder Software per DMI ansteuern beziehungsweise verwalten will, muss dem Produkt eine solche MIF-Datei beifügen.
Eine MIF-Datei beinhaltet einzelne Funktionsblöcke mit einer festgelegten Struktur. Den Anfang einer Funktion leitet das Key-Wort "start" ein, beendet wird es mit einem "end"-Befehl. Die folgende Tabelle beschreibt die wichtigsten Blockfunktionen einer MIF-Datei:
Block | Zuordnung | Funktionsbeschreibung |
|---|---|---|
| ||
Component | MIF-Datei | Beschreibt eine Komponente; alle anderen Blöcke sind Teil dieser Komponente; es kann nur einen Component-Block in einer Datei geben. |
Path | component | Verknüpft einen String mit Pfadnamen für ein bestimmtes Betriebssystem (optional). |
Group | component | Definiert eine Anzahl von Attributen für eine Komponente. |
Attribute | group | Beschreibt eine Einheit von verwalteten Informationen innerhalb einer Gruppe. |
Table | component | Definiert eine oder mehrere Instanzen einer Gruppe unter Verwendung vorhandener Definitionen. |
Das aufgeführte Beispiel (Quelle: DMI-Spezifikation, Version: 2.0.1s) verdeutlicht den prinzipiellen Aufbau einer MIF-Datei:
start component
start path
end path
start group
start attribute
end attribute
end group
start table
end table
end component
Nachfolgend soll dargestellt werden, wie sich die Definition eines Attributs durchführen lässt. Dazu wird angenommen, dass eine MIF-Datei erstellt wird, die unter anderem den Namen einer Applikation und deren Version bereitstellt. Zusätzlich soll die Nutzung eines SNMP-Mappers möglich sein.
Die dazu nötige Code-Sequenz (Quelle: DMI-Spezifikation, Version: 2.0.1s) sieht wie folgt aus:
Start Group
Name = "Software Template"
Class = "DTS|BasicSoftware|001"
Key = 1 // key on Product Name
Pragma = "SNMP:1.2.3.4.5.6"
Start Attribute
ID= 1
Name = "ApplicationName"
Description = "The name of the Application"
Storage = Common
Type = String(64)
End Attribute
Start Attribute
ID = 2
Name = "ApplicationVersion"
Description = "The Application's version number"
Type = String(32)
Value = ""
End Attribute
End Group
Für das grundlegende Verständnis über den Aufbau einer MIF-Datei genügen die gezeigten Beispiele. Wer noch detaillierter in die Materie des MIF einsteigen will, findet weitere Informationen auf der DMTF-Homepage.
Remotable Interface (RI)
Für den Datenaustausch zwischen dem SP und der Management-Applikation haben die Entwickler in der DMI-Spezifikation Version 1.x ein Data Block Interface implementiert. Wie der Name bereits suggeriert, arbeitet das Interface blockorientiert. Es erfüllte die damaligen Anforderungen für einfache Low-Level-Zugriffe auf Geräteschnittstellen. Zusätzlich erlaubte diese Technologie, die angeforderten Informationen in einfache Datenpakete zu übertragen. Allerdings war das Data Block Interface bei der Datenübertragung sehr fehleranfällig und kompliziert zu programmieren.
Um diese Nachteile zu beseitigen, wurde ab DMI 2.0 ein Remote Interface integriert. Es basiert auf Remote Procedure Calls (RPC) und ist ein Protokoll, das die Einbindung verschiedener Netzwerkdienste vereinfacht. Die Grundidee dieser Technik ist, dass eine Applikation eine Programmfunktion nutzt, die auf einem anderen Rechner läuft, ohne sich um die komplexen Netzwerkdetails kümmern zu müssen.
Ein RPC-Aufruf nach DMI-2.x-Spezifikation arbeitet synchron, wobei das veraltete Data-Block-Interface asynchron Daten überträgt. Wie das Diagramm zeigt, agiert ein Remote Node als Client für prozedurale MI-Funktionsaufrufe und als Server, wenn er das Ergebnis erhält (Client-Server-Modell). Der verwaltete Knoten (Node) verhält sich bei den MI-Funktionsanforderungen umgekehrt.
DMI und Security
Dem Ruf nach mehr Datensicherheit beim DMI folgte die DMTF mit der Veröffentlichung der DMI-Spezifikation Version 2.0.1s. Sie definiert eine Reihe von Sicherheitsmechanismen, die hauptsächlich bei lokalen und Remote-Zugriffen von Bedeutung sind. Sie bilden keine eigenen Standards, sondern basieren auf den vorhandenen Sicherheitsfunktionen der RPCs und der Betriebssysteme.
DMI 2.0.1s sichert die bisher wenig geschützten Datenwege zwischen dem SP, den Management-Applikationen, den Komponentendaten und der MIF-Datenbank. Im Detail bietet DMI folgende Sicherheitsmaßnahmen:
Zugangskontrolle auf remote-gesteuerte DMI-Management-Programme
Sicherheit beim Zugriff auf die Komponenteneigenschaften
Zugriffssicherheit auf die MIF-Datenbank
Sicherheit beim Zugriff auf die lokalen Management-Applikationen
Auslösen von bestimmten Programmfunktionen bei sicherheitsrelevanten Ereignissen
Aufzeichnen sicherheitsrelevanter Ereignisse
Listenbasierende Autorisations-Modelle
Flexible, per Remote konfigurierbare Autorisations-Vereinbarungen
Implementierung eines Authentifizierungs-Interface (abhängig vom Betriebssystem)
Zum Beispiel schreibt die Zugangskontrolle (Authentication) auf Management-Applikationen eine eindeutige Identifizierung des Anwenders vor. Das kann durch Eingabe eines festgelegten Passworts, durch biometrische Geräte oder mit einer ID-Sicherheitskarte erfolgen. Die Zugriffskontrolle auf eine MIF-Datenbank beziehungsweise die Berechtigung (Authorization), die Daten zu verändern, wird vom Betriebssystem verwaltet. So erlaubt es autorisierten Anwendern Schreib- oder Lesezugriffe auf bestimmte statische oder dynamische DMI-Attribute durchzuführen. Anderen Usern werden dagegen nur Leserechte eingeräumt.
DMI in der Praxis
Die Verwaltung von heterogenen IT-Komponenten in einer Firma gestaltet sich in der Praxis oft schwierig, da unterschiedliche Hardware-Systeme und Software-Installationen vorhanden sind. Soll eine Netzwerkkarte eine neue Firmware oder die Office-Software ein Update erhalten, so steht der Administrator oft vor einer schwierigen Aufgabe. Denn er muss von allen Systemen den aktuellen Status der installierten Firmware und Software abfragen und ermitteln, auf welchen Maschinen ein Update notwendig ist.
Im ungünstigsten Fall müsste der Administrator jeden PC eigenhändig auf den aktuellen Status überprüfen und das Firmware- beziehungsweise Software-Update durchführen. Er könnte aber auch per Mail die notwendigen Informationen von den Usern anfordern, in der Hoffnung, dass alle Daten korrekt sind. Existieren Installationslisten, würden sie dem Administrator bei der bevorstehenden Updatearbeit helfen - doch sind die Listen auf dem neusten Stand? Haben die Anwender nicht bereits selber Updates auf ihren PCs durchgeführt?
Im günstigsten Fall startet der Administrator ein Programm, welches alle PCs nach ihren Komponenten, ihrer Software und der installierten Peripherie abfragt. Diese so gewonnen Ergebnisse werden zentral gesammelt und anschließend detailliert zum Beispiel nach Art der Komponente, Hersteller, Installationsdatum oder Version dem Administrator auf dem Bildschirm präsentiert. Mit der DMI-Funktion ausgestattete Komponenten ermöglichen dieses Szenario.
Darüber hinaus übernimmt DMI auch Diagnoseaufgaben: Überwachung der Spannungen von CPU oder Lüftern, Meldung eines Plattenüberlaufs oder Anzeigen kritischer Fehler wie offene Gehäuseabdeckung oder nicht angeschlossene Geräte (Floppy, Tastatur, Maus).
Als übergeordnete System-Management-Applikationen kommen Programme wie Intels LANDesk Client Manager oder OpenView von HP zum Einsatz. Diese Software-Pakete erhalten von allen DMI-konformen Komponenten die notwendigen Daten, die der Administrator abfragt. Entspricht eine Komponente nicht dem DMI-Standard, so muss der Administrator die Informationen eigenhändig am entsprechenden PC ermitteln.
Fazit: DMI in Verbindung mit geeigneten Management-Applikationen unterstützt den Administrator bei der aufwendigen Verwaltung seiner Systemkomponenten. Dazu zählen das Inventory- und Applikations-Management sowie das Fehler-Management.
Vor- und Nachteile des DMI
Die Ansätze der DMTF haben sich in den letzten Jahren durch die Unterstützung renommierter und namhafter Mitglieder wie Intel, IBM oder HP zu Standards entwickelt. Trotzdem zeigt die Praxis, dass nicht alle Hard- und Software-Hersteller die DMI-Spezifikationen akzeptieren und in ihre Produkte implementieren. Die folgenden Vor- und Nachteile von DMI sind bei dieser Entscheidung maßgebend:
Für DMI spricht, dass es als Management-Framework für Notebooks, PCs und Server dient. DMI bietet eine breite Schnittstelle für unterschiedliche Systeme. Dies macht DMI zu einem vielseitigen Werkzeug für das Netzwerk- und Komponenten-Management.
Einen weiteren positiven Aspekt offeriert das Management Information Format (MIF). Die einheitliche Beschreibung der Management-Komponenten erleichtert den Systemadministratoren, die Komponenten zu verwalten, und Entwicklern, diese definierten Beschreibungen für ihre Management-Programme zu nutzen.
Gegen den DMI-Standard spricht, dass die Hersteller ihn heute immer noch zu selten in ihre Produkte implementieren. Sie scheuen den Mehraufwand (Kosten) für die Entwicklung von DMI-fähigen Komponenten oder sie wollen sich nicht auf eine Spezifikation festlegen.
Auf der Negativseite des DMI steht darüber hinaus die häufige Inkompatibilität zu bestehenden Schnittstellen wie SNMP. Ohne ein geeignetes Netzwerk-Management-Protokoll könnte aber nur der lokale Anwender die Daten des DMI nutzen. Somit ist es erforderlich, die DMI-Semantik auf das SNMP zu übertragen. Hier kommt es bei der Umsetzung häufig zu Dateninkonsistenz.
Fazit
Das Desktop Management Interface ist ein Industriestandard der Desktop Management Task Force (DMFT). DMI dient als Schnittstelle zwischen einem Verwaltungsprogramm und den angeschlossenen Systemkomponenten. Es vereinfacht die Konfiguration und die Inventarisierung von Endsystemen mit seinen Komponenten. Dazu zählen nicht nur Desktop-PCs, sondern auch Server mit entsprechender DMI-Unterstützung. Zusätzlich bietet DMI Netzwerkfähigkeit per RPC-Aufruf.
Mit der Verabschiedung des DMI-2.0.1s-Standards wurden sicherheitsrelevante Funktionen implementiert. Sie gewährleisten in einem Server-Management-Umfeld ein längst überfälliges und notwendiges Sicherheits-Niveau.
Bei den Herstellern hat sich DMI bisher noch nicht als einheitlicher Standard durchgesetzt. Viele scheuen die extra Kosten durch den Mehraufwand für die Entwicklung DMI-konformer Komponenten und die Festlegung auf einen Standard. Außerdem wurde DMI ursprünglich nicht für eine Netzwerkumgebung konzipiert, so dass es zu Inkompatibilitäten bei der Datenübernahme zwischen DMI- und speziellen Netzwerk-Programmen kommen kann. (hal)