Übersicht über Dienstmetadaten

  • Artikel

MBAE-Veraltetswarnung

Wichtig

Ab Windows 10 Version 1803 wird die MBAE-App-Oberfläche durch eine MO-UWP-App ersetzt. Weitere Informationen zu MO-UWP-Apps finden Sie unter Mobile Breitband-Apps für UWP.

Sie können ein Dienstmetadatenpaket erstellen und übermitteln, um eine Umgebung zu erstellen, die tief in Windows integriert ist. Wenn Windows mobile Breitbandhardware erkennt, die dem Dienstmetadatenpaket des Betreibers entspricht, lädt es automatisch die Dienstmetadaten und die angegebene mobile Breitband-App herunter.

Dienstmetadaten enthalten die Informationen, die einen Dienst beschreiben, einschließlich der folgenden:

Die Informationen in den Metadaten werden verwendet, um Aspekte der Windows 8, Windows 8.1 und Windows 10 Benutzerfreundlichkeit anzupassen und die Integration in eine mobile Breitband-App bereitzustellen, die früher als Mobilfunkanbieter-App bezeichnet wurde.

Ein Dienstmetadatenpaket besteht aus mehreren XML-Dokumenten, die in einer Devicemetadata-ms-Datei gespeichert sind. Jedes Dokument gibt verschiedene Komponenten der Attribute des Diensts an. Diese XML-Dokumente stellen Windows-Verbindungs-Manager mit Anpassungen bereit, die dem Benutzer angezeigt werden, sowie Informationen zur Netzwerkkonfiguration.

Referenzinformationen zu den XML-Dokumenten in einem Dienstmetadatenpaket finden Sie unter Schemareferenz für Dienstmetadatenpakete.

Dienstmetadateninhalte

In der folgenden Zusammenfassung werden einige der interessantesten Felder beschrieben, die in einem Dienstmetadatenpaket enthalten und definiert sind:

  • Hardware-IDs
    Für ein GSM-Netzwerk können Sie ein Metadatenpaket übermitteln, das die IMSI- oder ICCID-Bereiche beschreibt, für die Ihr Dienstmetadatenpaket übereinstimmen soll. Wenn Sie ein MVNO sind, können Sie einen oder mehrere IMSIs- oder SIM-ICC-IDs angeben, die Sie von einem MNO geleast haben. Für ein CDMA-Netzwerk können Sie ein Paket mithilfe der Anbieter-ID (SID/NID) oder des Anbieternamens übermitteln. Die Hardware-IDs entsprechen dem HardwareID-Element im Dienstmetadatenpaketschema. Weitere Informationen zum Planen Ihrer HWID-Bereiche (Hardware Identification) für MNO- und MVNO-Szenarien finden Sie unter Bereitstellen von Erfahrungen für MVNOs.

  • Dienstnummer
    Die eindeutige ID für den mobilen Breitbanddienstanbieter. Diese GUID wird auch verwendet, um den Operator zu identifizieren, wenn Metadaten für die Kontobereitstellung verwendet werden. Wenn Sie das Gerätemetadatenpaket aktualisieren, muss diese GUID unverändert bleiben. Die Dienstnummer entspricht dem ServiceNumber-Element im Dienstmetadatenpaketschema.

  • Operatorlogo Ein benutzerdefiniertes Logo, das in Windows Verbindungs-Manager neben Ihrem Netzwerkeintrag angezeigt wird. (Das Logo wird ausgeblendet, wenn sich der Benutzer in einem Roamingnetzwerk befindet.) Das Operatorlogo entspricht dem ServiceIconFile-Element im Dienstmetadatenpaketschema. Weitere Informationen zu den Logoanforderungen finden Sie unter Anforderungen an Dienstsymbole.

    Wichtig

    In Windows 10 Version 1709 und höher wurde dieses Feld durch branding über COSA ersetzt. Felder in COSA für das Branding werden unter Planen der COSA/APN-Datenbankübermittlung für Ihren Desktop beschrieben. Wenn Sie Windows-Versionen vor Windows 10 Version 1709 als Ziel verwenden, erstellen Sie weiterhin ein Metadatenpaket, wie in diesem Abschnitt beschrieben. Weitere Informationen zu COSA finden Sie unter COSA-Übersicht.

  • Mobile Breitband-App
    Eine UWP-Geräte-App, die automatisch heruntergeladen und auf den Computer angewendet wird. Diese App kann wichtige Funktionen wie Den Kauf planen, Datennutzung sowie Hilfe und Support bereitstellen und Mehrwertdienste hervorheben.

  • MB-Kaufprofil
    Kaufprofil, das zum Einrichten einer eingeschränkten Konnektivität für den Kauf eines Abonnements verwendet wird.

    Wenn Sie ein GSM-Operator sind, der nur über einen Einkaufs-APN für alle Abonnenten verfügt, können Sie die Dienstmetadaten verwenden, um diese auf dem Computer bereitzustellen. Wenn Sie über mehrere Kauf-APNs verfügen, sollten Sie Metadaten zur Kontobereitstellung verwenden, um den entsprechenden Kauf-APN festzulegen. Oder Sie können nichts tun und die Einträge verwenden, die in der APN-Datenbank gespeichert sind, um APN-Konnektivitätsinformationen bereitzustellen.

  • MB-Internetprofil
    Jedes mobile Breitbandabonnement kann über ein Standardprofil verfügen, das zum Herstellen einer Verbindung mit dem Heimnetzbetreiber verwendet wird. Die Windows-Verbindungs-Manager verwendet dieses Profil für die automatische Verbindung mit dem Netzwerk.

    Wenn Sie ein GSM-Operator sind, der nur über einen Internet-APN für alle Abonnenten verfügt, können Sie die Dienstmetadaten verwenden, um den Computer bereitzustellen. Wenn Sie über mehrere Internet-APNs verfügen, sollten Sie metadaten für die Kontobereitstellung verwenden, um den entsprechenden Internet-APN festzulegen. Oder Sie können nichts tun und die Einträge verwenden, die in der APN-Datenbank gespeichert sind, um APN-Konnektivitätsinformationen bereitzustellen.

  • Zertifikatdaten
    Zertifikatinformationen, die für die Bereitstellung verwendet werden. Dies schließt den Namen des Zertifikatausstellers und den Antragstellernamen ein. Diese Informationen werden verwendet, um sicherzustellen, dass von einer Website initiierte Kontobereitstellungsvorgänge von einem vertrauenswürdigen Operator ausgegeben werden.

  • Name des benutzerdefinierten Operators
    Das mobile Breitbandgerät stellt in der Regel den Betreibernamen bereit, den Windows in Windows Verbindungs-Manager anzeigt. Sie können diesen Namen überschreiben, indem Sie einen benutzerdefinierten Namen in Metadaten angeben. Dieser Name wird nur angezeigt, wenn sich der Benutzer in einem Heimnetzwerk und nicht in einem Roamingnetzwerk befindet. Ein angezeigter Roamingnetzwerkname basiert auf Informationen, die vom Gerät empfangen werden. Dies entspricht dem ServiceProvider-Element im Metadatenschema des Dienstpakets.

    Wichtig

    In Windows 10 Version 1709 und höher wurde dieses Feld durch branding über COSA ersetzt. Felder in COSA für das Branding werden unter Planen der COSA/APN-Datenbankübermittlung für Ihren Desktop beschrieben. Wenn Sie Versionen von Windows vor Windows 10 Version 1709 verwenden, erstellen Sie weiterhin ein Metadatenpaket, wie in diesem Abschnitt beschrieben. Weitere Informationen zu COSA finden Sie unter COSA-Übersicht.

  • Gerätebenachrichtigungshandler
    Im Allgemeinen muss eine App vom Benutzer mindestens einmal ausgeführt werden, bevor sie Arbeitselemente beim Systemereignisbroker registrieren kann. Mobile Breitband-Apps müssen jedoch möglicherweise wichtige Ereignisse empfangen, bevor der Benutzer die App ausführen kann. Sie können das DeviceNotificationHandler-Element in Dienstmetadaten angeben, das Windows zum Registrieren einiger kritischer Ereignisse verwendet. Weitere Informationen zu SMS-Benachrichtigungen finden Sie unter Bereitstellen von Erfahrungen für MVNOs.

  • Liste der privilegierten Apps mit Zugriff auf mobile Breitbandschnittstellen
    Mobile Breitband-APIs und -Schnittstellen (einschließlich Kontobereitstellung und SMS) sind nur für mobile Breitband-Apps verfügbar. Eine Liste privilegierter Apps, die Zugriff auf diese privilegierten APIs haben, kann im Dienstmetadatenpaket im PrivilegedApplications-Element angegeben werden. Privilegierte Apps können Debuggen oder Testen von Apps sein. Sie müssen nicht über den Microsoft Store verteilt werden.

Dienstmetadatenpaketstruktur

Die Komponenten eines Dienstmetadatenpakets werden in einer komprimierten Schrankdatei gespeichert und müssen über die Dateierweiterung ".devicemetadata-ms" verfügen. Dienstmetadatenpakete verwenden diese Dateierweiterung, da sie dieselbe zugrunde liegende Plattform wie Gerätemetadatenpakete verwenden. Bevor Sie die Datei ".devicemetadata-ms " erstellen, müssen Sie zunächst einen globalen eindeutigen Bezeichner (GUID) für das Metadatenpaket erstellen. Anschließend müssen Sie die folgende Benennungskonvention verwenden, wenn Sie die Datei ".devicemetadata-ms" erstellen: <GUID.devicemetadata-ms>.

Hinweis Obwohl die übliche Dateierweiterung einer Schrankdatei .cabist, muss die Dateierweiterung für eine Dienstmetadatenpaketdatei .devicemetadata-ms sein. Dies soll die Tatsache unterstreichen, dass Endbenutzer diese Pakete nicht dekomprimieren oder ändern dürfen.

Es gibt zwei Arten von Dienstmetadatenpaketen: ein einzelnes Gebietsschemadienstmetadatenpaket und ein Metadatenpaket für mehrere Gebietsschemadienste.

Dienstmetadatenpaket für einzelne Gebietsschemas

Die lokalisierbaren Ressourcen im Dienstmetadatenpaket sind der Operatorname, der in Windows Verbindungs-Manager angezeigt wird, und das Dienstsymbol, das daneben angezeigt wird. Wenn Sie Ihren Namen nicht lokalisieren oder Ihr Symbol basierend auf Gebietsschemainformationen vom PC ändern müssen, erstellen Sie ein einzelnes Gebietsschemadienstmetadatenpaket. Unabhängig davon, welches Gebietsschema der Benutzer auf dem PC verwendet, erhalten sie den Operatornamen und das Dienstsymbol, die im Metadatenpaket des einzelnen Gebietsschemadiensts definiert sind.

Ein einzelnes Gebietsschemadienstmetadatenpaket muss über die folgende Dateistruktur verfügen:

Diagramm, das die Dateistruktur eines einzelnen Gebietsschemadienstmetadatenpakets zeigt.

Einige Überlegungen für ein einzelnes Gebietsschemametadatenpaket:

  • Die Symboldatei kann einen beliebigen Dateinamen haben. Die einzelnen XML-Dokumente müssen jedoch PackageInfo.xml, ServiceInfo.xml, WindowsInfo.xmlund SoftwareInfo.xmlbenannt werden.

  • Der Name der MobileBroadbandInfo.xml-Datei wird im ServiceInfo.xmldefiniert. Sie sollten die in diesem Dokument aufgeführten Namen für diese Datei verwenden.

  • Die Datei ".devicemetadata-ms " darf nicht "{" oder "}" im Namen enthalten. Die GUID für jeden Metadatenpaketdateinamen muss eindeutig sein. Wenn Sie ein neues oder überarbeitetes Dienstmetadatenpaket erstellen, müssen Sie eine neue GUID erstellen, auch wenn die Änderungen geringfügig sind.

  • Windows erkennt Dienstmetadatenpakete mit der Dateierweiterung .devicemetadata-ms.

Metadatenpaketstruktur für mehrere Gebietsschemas

Ein Dienstmetadatenpaket unterstützt mehrere Gebietsschemadateien in einem Paket. Wenn Sie mehrere Gebietsschemas für Ihren Dienst unterstützen, können Sie mehrere Gebietsschemadateien in ein Dienstmetadatenpaket einfügen.

Sie können ein Paket mit mehreren lokalen Dienstmetadaten verwenden, wenn Sie einen lokalisierten Namen für Ihren Dienst in windows Verbindungs-Manager Netzwerkliste oder ein anderes Logo in Windows Verbindungs-Manager für Ihr Netzwerk anzeigen möchten. Windows zeigt den lokalisierten Netzwerknamen und das Logo basierend auf der bevorzugten Sprache des Systems an, die normalerweise während windows Setup konfiguriert wird. Auch wenn sich die Sprache des aktuellen Benutzers von der vom System bevorzugten Sprache unterscheidet, werden das Symbol und der Netzwerkname immer in der bevorzugten Systemsprache angezeigt. Wenn das Dienstmetadatenpaket kein Gebietsschema enthält, wird die sprachneutrale Beschreibung aus dem Stamm des Dienstmetadatenpakets angezeigt. Für die meisten Benutzer entspricht ihre Sprache der vom System bevorzugten Sprache.

Ein Metadatenpaket für mehrere Gebietsschemadienste muss die folgende Dateistruktur aufweisen:

Diagramm, das die Dateistruktur eines Dienstmetadatenpakets mit mehreren Gebietsschemas veranschaulicht.

Einige Überlegungen für ein Metadatenpaket mit mehreren Gebietsschemas:

  • Erstellen Sie einen Gebietsschemanamenordner in jedem Ordner, und legen Sie die XML-Datei oder die relevante Datei im Ordner Gebietsschemaname ab.

  • Sie müssen weiterhin die XML-Datei der obersten Ebene und relevante Dateien, z. B. die Symboldatei, auf der obersten Ebene jedes Ordners haben. Dies bietet einen Fallbackmechanismus, wenn das Gebietsschema nicht in Ihrem Dienstmetadatenpaket enthalten ist.

  • Stellen Sie sicher, dass alle erforderlichen Dateien und felder in diesen Dateien in jedem gebietsschemaspezifischen Ordner, den Sie erstellen, vollständig ausgefüllt sind. Dies ist zusätzlich zu den Inhalten auf der obersten Ebene jedes Ordners. Beispielsweise muss das ServiceNumber-Element in ServiceInfo.xml im Ordner der obersten Ebene und in jedem gebietsschemaspezifischen Ordner, den Sie erstellen, ausgefüllt und dupliziert werden. Wenn dies nicht geschieht, führt dies zu Fehlern.

  • Das SoftwareInformation XML-Dokument unterstützt nicht mehrere Gebietsschemas, da Sie nicht unterschiedliche SoftwareInfo.xml Dateien pro Gebietsschema angeben können.

Übermittlung und Wartung von Dienstmetadaten

Weitere Informationen zum Übermitteln von Dienstmetadatenpaketen an das Windows Dev Center-Dashboard – Hardware finden Sie unter Entwicklerhandbuch zum Erstellen von Dienstmetadaten.

Es ist wichtig, Metadatenpakete auf dem neuesten Stand zu halten, was ihre Beschreibung angeht und welche IMSI- und ICCID- oder CDMA-Anbieternamen oder SID-Werte sie aufweisen. Dies kann einen MNO oder MVNO erfordern, um einen neuen Workflow zu implementieren, der Teil der SIM- oder Geräteakquisition ist, um neue Bestellungen von SIMs und dem MNO oder MVNO nachzuverfolgen, für den diese ICCIDs oder IMSIs bereitgestellt werden.

Es empfiehlt sich, häufige Änderungen an Ihren Dienstmetadaten zu vermeiden, indem Sie ICCID- oder IMSI-Bereiche (oder CDMA-SIM-/Anbietername) für den MNO und MVNO im Voraus reservieren, sodass neue SIMs (oder CDMA-Geräte) bereits in Ihrem Dienstmetadatenpaket berücksichtigt werden.

Wenn Sie Ihre Dienstbezeichner aktualisieren müssen, die auf dem Windows Dev Center-Hardware-Dashboard registriert sind, finden Sie weitere Informationen unter Aktualisierungen des Besitzes von Dienstbezeichnern.

Metadatenupdates werden basierend auf der internen Windows-Logik (in der Regel alle acht Tage) automatisch angewendet, wenn Windows WMIS abfragt, ob aktualisierte Metadatenupdates vorhanden sind.

Die App sollte so konzipiert sein, dass sie eine frühere Version der Metadaten behandelt, auf die sie sich bezieht, bis die neuesten Metadaten auf das System angewendet werden.

Das Entwerfen der Benutzeroberfläche einer mobilen Breitband-App enthält Richtlinien zum Entwerfen der Benutzeroberfläche, um häufige Fehlerfälle zu beheben, z. B. wenn das Gerät fehlt oder nicht erkannt wird.